Tag Archives: debian

apt-get update

Et kort lite tips hvis du bruker apt-get mye: hvis du bruker en relativt ny utgave av distroen din kan du sannsynligvis bruke apt istedenfor. Apt er fire tegn kortere å skrive og fungerer som forventet for alle de vanligste valgene:
apt-get updateapt update
apt-get dist-upgradeapt dist-upgrade
osv.
Som en ekstra bonus viser apt teksten i ulike farger for å indikere fremgang.

Så hvis du sitter på Ubuntu 14.04 eller nyere, kan det være kjekt å gå over til apt fremfor apt-get.

Jeg er usikker på om apt vil ta over/pakke inn all funksjonaliteten til apt-get på sikt, men inntil videre er det fortsett et par valg som kun finnes i apt-get. Det jeg har merket mest er at jeg fortsatt må kjøre apt-get autoremove, men det er ikke noe jeg gjør ofte nok til at det er plagsomt.

Debian bug squashing party

Last weekend I attended a Debian bug squashing party, organized by NUUG, Skolelinux and Bitraf. In other words, roughly nine people gathered in front of their computers in the same room, trying to fix bugs and make Debian better.

First we were introduced to some of the tools and how to interact with the Debian BTS. Then we looked at the list of Release Critical bugs currently affecting Debian. At the time, there was more than 1000 bugs which would prevent a new release. Since this is too many (Debian require the number to drop to zero before making a release) we took a look at some of them.

First we looked at a bug report about a program crashing at startup, while getting to know our way around the BTS. We all tested to see if we could reproduce the issue in various environments. I was the only one who got the crash in my virtual machin running Sid (yay!). However, the exact same version of the package would not crash on Ubuntu Saucy, so the underlying issue was assumed to reside in one of the dependencies. We gathered a list of which versions/environments we had tested along with the results and a diff of the changes in dependencies from a working version to the crashing one. We submitted this as a comment to the bug report.

Next up, we looked at various bugs which had been filed as a result of failing rebuilds. A lot of them had a common cause, compilers have become stricter about imports, so some programs need to explicitly import libraries the compiler would add automatically in the past. One bug was picked as an example, and we all looked into it in parallel, attempting to patch it and get it to build. Related to this, we went through the process of installing dependencies, building the package, generating a diff and adding it as a proper patch.

After getting acquainted with the various tools and parts, we were let loose, all tasked with finding a similar bug and hopefully fix it by the end of the day. After some back-and-forth, I got a working patch for one of the bugs and submitted it. (Looks like another patch was used instead, but it also looks better than mine. Anyways, the important thing is that the package is now working again.) For a total list of all the bugs we looked at, see here.

All in all, it was a fun and nice experience. I had looked at most of the tools previously, but it was nice to have someone who were more familiar with them and would answer questions when someone ran into issues. I was also pleasantly surprised how easy (relatively speaking) it was to fix an issue, even an FTBFS one in packages I had never heard about.

My list of virtual machines

list_of_vmsThought I’d share the setup I have for virtual machines, how I use them to triage bugs and experiment with various software.

First a small digression, since the observant reader will notice I am using Virtualbox. When I first discovered and started playing around with virtual machines I had a computer incapable of hardware supported virtualization. I discovered this rather quickly since every virtualization solution I tried failed to work because they all required specific CPU features. After testing several solutions, I settled on Virtualbox because it also supported software-based virtualization. I’ve later replaced that machine, and while my current computer supports hardware assisted virtualization I’m still using Virtualbox as it is straight-forward and I am familiar with it. I did briefly try a couple of other solutions when I got my new computer, but didn’t find any obvious advantages they had over sticking with my existing setup.

Now, the machines. I have a set of the currently supported Ubuntu releases, organized by their code names. (Yes, I’m aware 11.04 reached end of life a while back.) They come in handy when confirming bugs or trying to track down which release something broke (or got fixed). My main use case is: load up the relevant release a bug was reported against, verify it is reproducible there, and then check whether it is also present in the latest development release.

All are kept more or less up to date, to make sure I have the latest version of libraries and other software when attempting to reproduce bugs. When I started triaging bug reports I used to simply install the software on my main system and check if the bug was reproducible there, though I quickly changed my approach for several reasons. Mainly because my main system wouldn’t easily allow me to test with multiple releases, but also in case my setup or set of installed packages would produce a different result than a system out of the box. The latter may not always be relevant, but there are some cases where it matters. For instance, say a program fails to run without a specific library which is not installed as a dependency, however since I already have installed the library for other reasons I wouldn’t be able to reproduce the issue. In cases like that it makes more sense to check what happens on a system out of the box.

In addition to the Ubuntu releases, I also run a couple of other systems. Arch Linux is nice and since it is rolling release distribution it usually includes the latest version of programs/libraries before most other distros. It’s ideal for testing whether projects still work as expected with the latest version of their dependencies, or to try out features in newer versions of programs. If newer versions of a library or compiler is released, it’s really convinient to be able to catch any issues early before it ends up the stable version of other distributions. In addition, Arch has a rather different philosophy and approach compared to Ubuntu, which is interesting to explore.

The Debian machine is running Sid (unstable). For most of the same reason as Arch, being able to test the latest version of projects, plus it will eventually turn into the next releases of Debian, Ubuntu (and related derivatives). As Ubuntu is based on Debian, it is of course also relevant for checking whether bugs are reproducible both places in case they should be forwarded upstream. As Debian is currently in freeze for the upcoming Wheezy release, there’s not many updates these days though.

Oh, and there’s a Windows 8 preview I was trying out when it became available. Used it some when it was announced. I’m pretty sure that will expire soon.

Første test av Debian Wheezy

Morsomt. Installerte Debian Wheezy på en virtuell maskin tidligere ikveld.

For de som ikke vet det er Wheezy det gjeldende navnet på testing-varianten av Debian. Den inneholder nyere pakker enn den stabile versjonen (Squeeze, som ble sluppet tidligere i år), og er beregnet for utviklere eller de som vil teste neste versjon. En gang i uken blir det generert nye bilder av CDer/DVDer man kan bruke til å installere Debian. Etter at Squeeze ble sluppet, leste jeg at det var en lang rekke med nye versjoner av programpakker som skulle bli lagt til, så jeg var spent på hvilke oppdateringer som var blitt gjort siden da.

Jeg hadde lastet ned installasjons-CDen for denne uken og startet opp fra den i en virtuell maskin. Installasjonen gikk helt fint, og jeg fikk startet maskinen med nyinstallert Debian. Så skulle jeg installere et par programmer, med det var snarere sagt enn gjort. Jeg oppdaget raskt at hverken update-manager eller synaptic hadde blitt lagt inn under installasjonen. Litt uventet, men det er tross alt testing. Ok, da kan man jo bare bruke ‘apt-get install’ fra terminalen, det er jo ikke noe problem. Hm… den ser ikke ut til å finne noen av pakkene jeg vil installere? Så jeg sjekket /etc/apt/sources.list og der var kun sikkerhetsoppdateringer og CDen lagt til som steder man kunne installere fra. Flott. Heldigvis hadde jeg lest om hvordan man manuelt legger til kilder i sources.list før, så det var ikke noe problem. Etter å ha lagt til arkivet for Wheezy (og kommentert ut CDen, siden den ikke ville være til stor hjelp), oppdaterte jeg pakkelistene og la inn det jeg ville ha.

Litt tungvint kanskje, men det gikk da. Jeg er generelt fan av problemer som ikke er for omfattende eller frustrende, men akkurat innenfor grensen til hva jeg allerede vet eller kan sette meg inn i. Jeg regner i utgangspunktet med at jeg egentlig skulle hatt grafiske verktøy for å kunne installere og oppdatere programmer ut av boksen, men noe gikk feil under installasjonen. Sannsynligvis vil kommende installasjonsbilder løse problemet snarlig, og hvis ikke bør jeg vel nesten rapportere det.

Oppdatering: Jeg har i ettertid prøvd med nyere bygg av Wheezy som har fungert uten problemer. Enten gjorde jeg en tabbe under installasjonen, eller så hadde jeg uflaks med den versjonen som var tilgjengelig den uken.

Debian Squeeze er ute!

De fleste har vel fått det med seg, men i helgen kom altså en ny utgave av Debian. Debian er er fritt operativsystem (som bla. Ubuntu baserer seg på) som er kjent for å være bunnsolid, med en stor mengde programpakker. Etter to år med testing, fiksing av bugs og nye pakker er nå Squeeze klar for å ta over etter Lenny. Jeg har prøvd Squeeze fra tid til annen den siste tiden, og likte spesielt det nye temaet med romskip og planeter. Det virket også veldig klart etter hvert som de siste kritiske problemene har blitt fikset før lansering.

Debian er forøvrig allerede igang med utviklingen av neste versjon, Wheezy.