| === htorque_ is now known as htorque | ||
| === Igorots is now known as Knightlust | ||
| NCommander | Any archive admins floating around? I have a binary package which appears to have been universe'd by accident | 02:34 |
|---|---|---|
| NCommander | Looks like the package was rejected at one point and after that the deb appears to end up in universe | 02:36 |
| NCommander | python-dbus-common to be specific | 02:36 |
| NCommander | ^- GRiD | 02:36 |
| NCommander | er | 02:36 |
| NCommander | GrueMaster: | 02:37 |
| infinity | NCommander: Looking. | 02:40 |
| GrueMaster | infinity: Not sure if this is relevant, but looking over the diffs for dbus-python, I see that python-dbus-common was added in 2ubuntu1, but it lists python-dbus as a conflicting package, whereas python-debus lists python-dbus-common as a requires. | 02:46 |
| infinity | I see a replaces, no conflicts. | 02:47 |
| infinity | Anyhow, promoting, it obviously shouldn't be in universe. | 02:47 |
| infinity | But trying to sort out why component-mismatches wants python3-dbus in main too. | 02:47 |
| === tilgovi_ is now known as tilgovi | ||
| pitti | Good morning | 04:41 |
| pitti | doko_: I've been running with the PPA libc6 packages for a week (since you asked), and no problems so far; but yesterday the gdk-pixbuf package trigger started crashing, causing lightdm and desktop session to go totally black | 05:07 |
| pitti | doko_: reproducer for me: /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so | 05:08 |
| pitti | doko_: backtrace is not very helpful, though :( http://paste.ubuntu.com/810009/ | 05:08 |
| pitti | doko_: does that work for you? | 05:08 |
| poolie | pitti, hi, thanks for the review and comments | 05:39 |
| pitti | poolie: my pleasure :) thanks for the improvement | 05:39 |
| poolie | pitti, i may well be confused, but i thought that if apport was enabled, you did not get regular core files | 05:39 |
| poolie | even with ulimit -c unlimited | 05:39 |
| pitti | you do | 05:41 |
| pitti | apport writes them for you | 05:41 |
| pitti | it's not supposed to break that, as core files are quite useful for developers | 05:41 |
| pitti | poolie: I have half a dozen test cases to make sure that this works | 05:41 |
| poolie | ok, good for you | 05:41 |
| pitti | doesn't it for you? | 05:42 |
| poolie | people were complaining to me that they didn't get core files | 05:42 |
| pitti | $ ulimit -c unlimited; sh -c 'kill -SEGV $$'; file core | 05:42 |
| pitti | Speicherzugriffsfehler (Speicherabzug geschrieben) | 05:42 |
| pitti | core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 'sh -c kill -SEGV $$' | 05:42 |
| poolie | <3 deutsche :) | 05:43 |
| pitti | ah, sorry | 05:43 |
| poolie | no it's ok it's awesome | 05:43 |
| poolie | i know what you mean | 05:43 |
| pitti | it's the usual "segfault" | 05:43 |
| poolie | it seems like apport will not overwrite an existing core file, but the default kernel behaviour will | 05:44 |
| poolie | could that be true? | 05:44 |
| pitti | no, the kernel doesn't | 05:46 |
| pitti | it mimics kernel behavior pretty closely | 05:46 |
| pitti | well, at least that was the case a few years ago when I wrote that stuff | 05:46 |
| pitti | but overwriting existing files sounds a bit evil | 05:46 |
| pitti | let me try | 05:46 |
| poolie | istr overwriting was the default in the past | 05:47 |
| pitti | oh, indeed it does | 05:47 |
| poolie | that's why i used to customize it to core.$pid | 05:47 |
| pitti | interesting, so apport should do the same then | 05:48 |
| poolie | i think so | 05:48 |
| poolie | shall i file a separate bug about that? | 05:48 |
| poolie | wanting noise on stderr would then be invalid | 05:49 |
| pitti | hah, bug 160999 | 05:49 |
| ubottu | Launchpad bug 160999 in apport (Ubuntu) "Apport doesn't conform to core(5)" [Low,Triaged] https://launchpad.net/bugs/160999 | 05:49 |
| poolie | it's already questionable | 05:49 |
| pitti | poolie: yeah, let's invalidate the other one then, and point to ^ | 05:49 |
| pitti | I'll fix that one now, easy thing | 05:49 |
| poolie | if you are not using nofollow that's a bit of a security risk | 05:49 |
| poolie | istr in fact this was exploitable on some old kernels | 05:50 |
| poolie | but that may have been fixed separately | 05:50 |
| pitti | hm, good point; is there a race free method of replacing an existing file? | 05:50 |
| pitti | it currently uses os.O_WRONLY|os.O_CREAT|os.O_EXCL which is race free and secure for new files | 05:51 |
| poolie | well, like Gerald says there, i think you want O_NOFOLLOW but not O_EXCL | 05:52 |
| pitti | so I guess it'd need to write a core.RANDOMJUNK and rename it to "core" | 05:52 |
| poolie | hm | 05:52 |
| poolie | yeah, races if two write at once... | 05:52 |
| poolie | ooh | 05:53 |
| poolie | the other checks in http://lxr.linux.no/linux+v2.6.26.3/fs/exec.c#L1749 probably need to be copied too | 05:53 |
| poolie | l1766 | 05:53 |
| pitti | ok, will queue this up for later then, not a 5-minute fix | 05:54 |
| poolie | maybe you should write a random file and rename it | 05:54 |
| poolie | the kernel doesn't seem to care (at least in 2.6) if it gets corrupted by concurrent crashes | 05:54 |
| poolie | ok, that's fine with me to leave it as a known bug | 05:56 |
| poolie | thanks for helping me understand it | 05:56 |
| poolie | pitti, i wonder if we should mention that a core file is still written in apport-bug | 06:01 |
| pitti | poolie: well, apport-bug is not really an interface for crashes.. | 06:01 |
| pitti | "man core" is meant to be that documentation | 06:01 |
| pitti | even the previous /var/crash/ is a bit out of place there, but I merged it because you can use apport-bug to report existing .crash files | 06:02 |
| poolie | i guess the text i added is not wrong | 06:02 |
| poolie | right, possibly there should be an overall 'man apport' | 06:03 |
| poolie | anyhow, i think that's enough for now | 06:03 |
| poolie | thanks | 06:03 |
| pitti | but apport itself does nothing with core files | 06:03 |
| pitti | yeah, perhaps; https://wiki.ubuntu.com/Apport could be condensed into a manpage | 06:03 |
| pitti | . o O { wow, these screenshots are old! } | 06:03 |
| === bradm_ is now known as bradm | ||
| pitti | SpamapS: as the blocking bug is now resolved, can you guys go ahead with bug 711425? or don't want to target that at 10.04.4 any more? | 08:17 |
| ubottu | Launchpad bug 711425 in sysvinit (Ubuntu Maverick) "portmap does not stop during shutdown, causing possible root fs corruption" [High,Triaged] https://launchpad.net/bugs/711425 | 08:17 |
| pitti | cjwatson: bug 563895 has a patch and is targetted for 10.04.4; is that a merge question of sponsoring, or does that need more investigatino? | 08:32 |
| ubottu | Launchpad bug 563895 in grub2 (Ubuntu Lucid) "grub2 fails to boot or install when an LVM snapshot exists" [Undecided,Confirmed] https://launchpad.net/bugs/563895 | 08:32 |
| cjwatson | pitti: oh yes, that milestoning was a reminder to myself - I do want to review it, but I'll do that this morning | 08:49 |
| pitti | cjwatson: thanks | 08:49 |
| pitti | cjwatson: I cleaned https://bugs.launchpad.net/ubuntu/lucid/+bugs?field.milestone%3Alist=30510 a bit, I figure we'll go through the rest in today's release meeting | 08:53 |
| pitti | I pinged some people about particular bugs; still want to ask tseliot about the fglrx one once he comes online | 08:53 |
| tseliot | pitti: I'm here | 08:54 |
| pitti | tseliot: oh, sorry; didn't see you some minutes ago, good morning! | 08:55 |
| pitti | tseliot: so, wanted to ask whether bug 566437 is an easy backport, or whether it should be dropped from 10.04.4? | 08:55 |
| tseliot | pitti: good morning to you ;) | 08:55 |
| ubottu | Launchpad bug 566437 in fglrx-installer (Ubuntu Lucid) "package fglrx 2:8.723.1-0ubuntu2 failed to REMOVE: error exit status 2 - dpkg-divert: mismatch on package - while removing the package" [High,Confirmed] https://launchpad.net/bugs/566437 | 08:55 |
| pitti | cnd, bryce, RAOF: so, staging X.org doesn't kill any kittens here on thinkpad x201 (Intel Arrandale) | 08:57 |
| tseliot | pitti: I haven't used dpkg-divert for ages now in my packages... | 09:00 |
| pitti | tseliot: that's for lucid | 09:01 |
| tseliot | pitti: I'll check again my packages for lucid then | 09:03 |
| pitti | tseliot: if it's a corner case, we can drop it from the 10.04.4 list, too | 09:04 |
| tseliot | pitti: ok, I'll let you know | 09:04 |
| SpamapS | pitti: will do the SRU for 711425 | 09:08 |
| pitti | SpamapS: splendid, thanks | 09:09 |
| jodh | SpamapS: thanks for the cookbook update! | 09:19 |
| micahg | pitti: I'm finishing up the lucid rapid release testing now, are we still ok to push today, or did you want to wait for Monday? | 09:20 |
| SpamapS | jodh: no problem. It was relevant to the zookeeper package. :) | 09:20 |
| pitti | micahg: I'm a bit more hesitant on Fridays, but if you feel sure about it, ok | 09:20 |
| micahg | pitti: personally, I prefer to be cautious, Monday would be fine for me | 09:21 |
| pitti | micahg: ok, let's do that then | 09:21 |
| micahg | in that case, I'll finish up something else tonight | 09:21 |
| jamespage | @pilot in | 09:26 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage | ||
| SpamapS | jamespage: did you see my zookeeper MP? | 09:27 |
| jamespage | SpamapS, I did | 09:27 |
| jamespage | not had time yet to review in full but looked OK to me | 09:28 |
| SpamapS | jamespage: ok, just wanted to make sure it didn't slip into the ether | 09:30 |
| jamespage | SpamapS, it won't! | 09:30 |
| jamespage | (on my list alongside the FIX TESTING stuff) | 09:30 |
| SpamapS | jamespage: I'm still having a hard time wrapping my head around the testing to make it reboot .. :-P | 09:31 |
| janimo | is there a declarative way of stating per-arch install files? debian/binpkg.install is for all archs | 09:43 |
| SpamapS | pitti: portmap + sysvinit uploaded to lucid-proposed. | 09:45 |
| * SpamapS heads to bed | 09:45 | |
| pitti | SpamapS: great, I'll review the queue in a bit when they get diffy | 09:45 |
| mvo | janimo: yes, hold on a sec I look for a example | 09:46 |
| mvo | janimo: pkgname.install.$arch should work | 09:52 |
| janimo | mvo, thanks a lot. hug :) | 09:52 |
| mvo | yw! | 09:52 |
| janimo | that looks like the approach with symbols files, I just never saw examples and googling was unsuccessful | 09:53 |
| janimo | still a control file like approach would have been more powerful (ex: usr/lib/file/to/install [!armel !armhf] | 09:54 |
| mvo | janimo: yeah, its a bit odd its not documented in the man page either, worth addding I guess | 09:54 |
| janimo | as I am looking to exclude some files | 09:54 |
| cjwatson | It is documented in debhelper(7) under "DEBHELPER CONFIG FILES" | 09:56 |
| cjwatson | Since it applies to debhelper commands in general, not just dh_install(1) | 09:56 |
| janimo | cjwatson, thanks, good to know. | 09:59 |
| mvo | oh, thanks cjwatson - I just looked at dh_install, my mistake | 10:06 |
| mvo | feedback on this http://paste.ubuntu.com/810533/ would be welcome, its about the need to change libept1 to something that changes when the libapt-pkgX.YY soname changes, my current idea about it is that libept1 embeds the libapt version in there too, otherwise may end up with a libept that is linked against a old apt and a app linked against libept and new libapt - or is there a better way for this? | 10:09 |
| geser | mvo: could versioning the symbols in libapt fix it too? but you might want to ask someone who is an expert in libraries | 10:17 |
| geser | (I hope I understood the idea behind symbol versioning correctly) | 10:18 |
| mvo | geser: thanks! it would certainly help but currently there is a global symbol (pkgSystem::SysList) that is touch by both lib versions so linking them both in will segv spectaculary :/ | 10:21 |
| mvo | so that needs to be fixed first | 10:21 |
| cjwatson | mvo: is this what's blocking bug 850264? | 10:26 |
| ubottu | Launchpad bug 850264 in apt (Ubuntu Precise) "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [High,Fix committed] https://launchpad.net/bugs/850264 | 10:26 |
| cjwatson | mvo: that seems OK as a general approach but (a) I guess you really want to ask the libept developers :-) (b) I wonder if there are any binaries linked directly to both libept and libapt, in which case they would still have problems | 10:28 |
| mvo | cjwatson: its the current blocker, donkult and I resolved some problems in dpkgpm.cc with the new debian dpkg multiarch interface, so apt itself should be good | 10:29 |
| mvo | cjwatson: thanks! a) is indeed important, I asked upstream (but no reply yet) and b) there are binaries linked with both (synaptic, aptitude) so that is a real issue :/ for the builds we can solve it with build-versions, but of course its a lurking problem for local builds - any good tips ? :) | 10:31 |
| === chrisccoulson_ is now known as chrisccoulson | ||
| cjwatson | mvo: do they actually need to link to both or is it overlinking? | 10:36 |
| cjwatson | I mean do they use symbols from both directly? | 10:36 |
| === ion__ is now known as ion | ||
| l3on | pitti: hi! :) | 10:47 |
| pitti | hello l3on | 10:48 |
| === doko_ is now known as doko | ||
| l3on | hi... I saw your comment... but rebuild1 (precise) is still less than ubuntu1 | 10:48 |
| l3on | i'm talking about bug 843734 | 10:49 |
| ubottu | Launchpad bug 843734 in ruby-sinatra (Ubuntu Oneiric) "ruby-sinatra : Depends: ruby-rack but it is not installable" [Undecided,Fix committed] https://launchpad.net/bugs/843734 | 10:49 |
| doko | pitti: yes, thanks. apparently the same thing that smoser did tell me at the ralley. I have now amd64 installed on my laptop | 10:49 |
| l3on | pitti: what do you think about oneiric ubuntu0.1 / precise ubuntu1 ? | 10:49 |
| pitti | doko: not sure whether it just uncovers a bug in librsvg or whether it's a genuine bug in dlopen | 10:49 |
| micahg | l3on: a no change rebuild SRU should have been 1.2.6-1build0.1 IMHO | 10:50 |
| pitti | l3on: I want to avoid ubuntu1 for precise, as this would stop autosyncs, and there are no ubuntu modifications | 10:50 |
| pitti | l3on: that's why I proposed 1rebuild1 | 10:50 |
| pitti | for precise | 10:50 |
| pitti | 1rebuild1 (precise) > 1ubuntu0.1 (oneiric-proposed) | 10:50 |
| pitti | micahg: it's a dependency change in o-proposed | 10:50 |
| micahg | ah | 10:50 |
| pitti | arguably the dependency shoudl be fixed in oneiric-proposed, though | 10:51 |
| pitti | by e. g. adding a Provides: | 10:51 |
| pitti | but it'd introduce a delta either way, so it doesn't matter much | 10:51 |
| micahg | pitti: 1.2.6-1+build1 would be better as it's higher in precise, but lower than an NMU | 10:53 |
| === _salem is now known as salem_ | ||
| pitti | fine for me | 10:54 |
| l3on | so, I'm not following you :) can you explain precisely which versions we should have either in precise and oneiric ? | 10:55 |
| micahg | 1.2.6-1rebuild1 wouldn't be higher as r<u | 10:55 |
| * micahg learned the + trick from pitti a few weeks back :) | 10:56 | |
| l3on | dpkg --compare-versions 1build1 gt 1ubuntu1 || echo false | 10:56 |
| micahg | l3on: it's not 1build1, it's 1+build1 | 10:57 |
| l3on | ah ok :DD | 10:57 |
| l3on | ok... I'm going to prepare branches each for precise and oneiric | 10:58 |
| l3on | thanks micahg and pitti for explanation | 10:58 |
| micahg | l3on: pitti: actually, there's another package that build depends on ruby-rack in oneiric, ruby-actionpack-2.3, maybe provides is better? | 11:01 |
| geser | hmm, will the autosync for p+1 ignore the "+build1" too and sync this package or will it need a manual sync? | 11:07 |
| micahg | ISTR it ignoring everything except ubuntu in the string | 11:07 |
| micahg | we could sync 1.4.0 from testing as well :) | 11:08 |
| l3on | see you! | 11:09 |
| cjwatson | geser: Yes, it will ignore it | 11:13 |
| cjwatson | geser: lp:ubuntu-archive-tools auto-sync | 11:13 |
| jamespage | doko: planning an update to openjdk-6 in precise any time soon? | 11:23 |
| jamespage | just discussed a few issues that I am seeing on armhf with zero with xranby which are probably fixed in latest icedtea6-hg | 11:23 |
| doko | jamespage, yes, I have to ... | 11:23 |
| doko | hopefully this we | 11:23 |
| doko | jamespage, but we still default to jamvm on arm* | 11:26 |
| jamespage | doko: thats fine for the time being; I have to switch to zero as the testing I'm doing with hadoop breaks on JamVM | 11:27 |
| jamespage | discussing that with xranby as well | 11:27 |
| tjaalton | Riddell: kubuntu-restricted-addons seems to have a Recommends on libtunepimp5, which is obsolete (see bug 793929). ok if I remove it from there? | 11:30 |
| ubottu | Launchpad bug 793929 in libmusicbrainz-2.1 (Ubuntu) "Deprecate libmusicbrainz-2.1, libtunepimp" [Medium,Triaged] https://launchpad.net/bugs/793929 | 11:30 |
| Riddell | tjaalton: yes, thanks | 11:31 |
| tjaalton | Riddell: thanks, dropping | 11:31 |
| cjwatson | mvo: hmm, trying 'do-release-upgrade -d -f DistUpgradeViewNonInteractive' in a lucid chroot - what's supposed to fetch libstdc++6 (>= 4.6) for the new libapt-pkg4.11? | 11:42 |
| cjwatson | in fact, why is that coming from precise rather than from lucid-updates ... | 11:43 |
| cjwatson | mvo: ah, never mind, my sources.list configuration was wrong before starting d-r-u | 11:44 |
| tjaalton | Riddell: also, kdemultimedia can drop the build-dep on libtunepimp-dev (same bug) | 12:00 |
| tjaalton | Riddell: then juk won't depend on libtunepimp5 anymore | 12:00 |
| Riddell | tjaalton: thanks, I'll change that in bzr and upload next week | 12:01 |
| tjaalton | Riddell: cool | 12:01 |
| === MacSlow is now known as MacSlow|lunch | ||
| mvo | cjwatson: *puh* thanks, I was a bit worried for a moment | 12:13 |
| pitti | apw: FYI, binNEWed linux -10 | 12:48 |
| === MacSlow|lunch is now known as MacSlow | ||
| === plars is now known as plars-away | ||
| smoser | doko, did you get an email from me on that ? | 13:22 |
| smoser | i can't find anything that i sent you but i thought i did | 13:23 |
| jamespage | @pilot out | 13:23 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| doko | smoser, no, don't see anything | 13:24 |
| smoser | coming now. | 13:24 |
| doko | asked pitti to file a report as well, so maybe you can comment on this too | 13:25 |
| smoser | sent. | 13:26 |
| smoser | i sent you mail just now | 13:26 |
| smoser | sorry i forgot to on friday | 13:26 |
| brendand | is there any plan to include python-qt4 in main for precise? | 13:37 |
| pitti | brendand: it's been in main forever | 13:38 |
| brendand | pitti - i guess i'm using main wrongly. on the cd? | 13:39 |
| pitti | brendand: ah, "main" != "cd" | 13:39 |
| pitti | brendand: no, python-qt4 is huge, doesn't fit on the ubuntu CDs | 13:39 |
| brendand | pitti - ok, i stand corrected! from henceforth i will never use 'main' to mean on the cd :) | 13:40 |
| pitti | brendand: heh, no worries; we have too much terminology | 13:40 |
| pitti | brendand: roughly, main is the union of everything that's on ubuntu and kubuntu CDs and DVDs, plus all their build dependencies and their dependencies | 13:41 |
| pitti | plus a few extra bits which we don't want to ship anywhere, but officially support | 13:41 |
| apw | pitti, thanks | 13:45 |
| brendand | pitti - i 'only' get 51.4 MB of extra dependencies when installing it (i guess that's alot relatively speaking) | 13:51 |
| brendand | especially as the image is already full ;) | 13:51 |
| pitti | oh yes | 13:52 |
| pitti | we are currently 11 MB oversized | 13:52 |
| pitti | we usually start arguing if something is bigger than .5 MB | 13:52 |
| brendand | in this case it's 100 times bigger - so i'll leave it | 13:52 |
| === dendrobates is now known as dendro-afk | ||
| brendand | we doing some work on checkbox that is introducing a python-qt4 dependency. i don't know if you talked with roadmr or cr3 about resolving that? | 13:53 |
| Riddell | brendand: ask the ubuntu one people, they might be wanting python-qt in ubuntu desktop | 13:56 |
| === dendro-afk is now known as dendrobates | ||
| brendand | pitti - have the been asking ? ^ | 13:56 |
| brendand | s/the/they/ | 13:56 |
| pitti | they asked, yes -- same answer, though | 13:56 |
| pitti | not easy to change the physical size of a CD :) | 13:57 |
| brendand | pitti - use your magic powers :) | 13:57 |
| pitti | brendand: I'd rather use it to shrink pyqt4 down to 0.5 MB :) | 13:57 |
| Riddell | there is some shrinking that could be done to pyqt, but I suspect not enough | 13:58 |
| pitti | now, where did I leave my magic wand and the toad blood.. | 13:58 |
| dobey | pitti, brendand, Riddell: we are making some space, but if CD is 11MB over, I'm not sure if we're going to get enough with what we're doing, even with splitting up pyqt packaging :( | 14:02 |
| pitti | we have a libo in the pipeline which gets it down to 706 MB | 14:03 |
| pitti | we need to fix gwibber and ubuntu-sso to drop the old webkit 1.0 stuff | 14:03 |
| pitti | that will reclaim another 7 | 14:03 |
| pitti | then we are back in the game | 14:03 |
| chrisccoulson | fixing bug 894166 will probably get us another 2.5 | 14:03 |
| ubottu | Launchpad bug 894166 in firefox (Ubuntu Precise) "Make hyphenation work with system hyphenation patterns" [High,Triaged] https://launchpad.net/bugs/894166 | 14:03 |
| dobey | pitti: oh, ok. then i guess we might be ok | 14:04 |
| brendand | not sure i understand exactly what's happening though. is the intention to include python-qt4? | 14:07 |
| dobey | brendand: yes | 14:07 |
| pitti | brendand: most likely not for precise, unless someone finds the time to split it, and the needed parts are less than, say, 2 MB | 14:07 |
| pitti | right now it's about 13 | 14:07 |
| dobey | brendand: well, i don't know which pieces of it you need exactly | 14:08 |
| dobey | pitti: well, the needed bits are a little bigger than 2MB | 14:08 |
| brendand | dobey - probably only the basics. might we get away with depending on other packages apart from while python-qt4? | 14:08 |
| brendand | dobey - we need to be able to use most GUI components | 14:09 |
| dobey | pitti: i think i calculated something like dropping 7MB, and adding 6MB back, with all we want to do for u1 | 14:09 |
| brendand | dobey - i imagine requirements are similar to yours | 14:09 |
| dobey | brendand: i mean, python-qt4 has several modules itself, which are shipped as separate libraries for the C++ version | 14:09 |
| dobey | brendand: then you should be ok, i think. | 14:10 |
| Riddell | brendand: what are you asking for? | 14:10 |
| brendand | Riddell - In terms of what? Python modules - or something else? | 14:12 |
| Riddell | brendand: what are you planning to use pyqt for? | 14:13 |
| brendand | Riddell - oh, to implement a new UI for Checkbox that will run on Ubuntu and Kubuntu | 14:14 |
| Riddell | nice | 14:15 |
| Riddell | and every other platform of course, go Qt :) | 14:15 |
| brendand | Riddell - python-qt4 is already safely on the kubuntu cd | 14:16 |
| Riddell | brendand: I knew, we maintain it :) | 14:17 |
| pitti | oh dear.. | 14:19 |
| pitti | https://launchpad.net/ubuntu/+source/libreoffice/1:3.5.0~beta2-2ubuntu3/+build/3091291 | 14:19 |
| pitti | Started 2012-01-13 | 14:19 |
| pitti | (that's armel) | 14:19 |
| brendand | 1 week. nice | 14:19 |
| pitti | I can haz libreoffice blacklist on the old babbage buildds? :) | 14:19 |
| pitti | tseliot: thanks muchly! | 14:20 |
| pitti | cjwatson: nice, https://bugs.launchpad.net/ubuntu/lucid/+bugs?field.milestone%3Alist=30510 looks a lot better now :) | 14:23 |
| === bladernr_afk is now known as bladernr_ | ||
| === bladernr_ is now known as bladernr_afk | ||
| === bladernr_afk is now known as bladernr_ | ||
| pitti | cjwatson: I guess if bug 810068 doesn't make it, it's not a big loss? | 14:24 |
| ubottu | Launchpad bug 810068 in partman-iscsi (Ubuntu Natty) "kickstart iscsi option broken" [High,Triaged] https://launchpad.net/bugs/810068 | 14:24 |
| pitti | (seems you never got any real testing feedback) | 14:24 |
| tseliot | pitti: thanks for bringing that bug to my attention ;) | 14:25 |
| psusi | is initramfs-tools an ubuntu homegrown package, or is there an upstream somewhere? | 14:39 |
| cjwatson | pitti: I was actually just preparing branches for that anyway | 14:40 |
| cjwatson | psusi: upstream is Debian, although IIRC it originated in Ubuntu | 14:40 |
| psusi | cjwatson: ohh... so not all distributions are using it? I thoguht the old initrd format was depreciated? | 14:42 |
| psusi | the kernel just supports both and doesn't plan on changing that? | 14:43 |
| cjwatson | using an initramfs doesn't imply using initramfs-tools | 14:43 |
| cjwatson | it's just a gzipped cpio archive; the format is not difficult to generate, it's what you put in it that tends to be rather distribution-specific | 14:44 |
| psusi | what other tools are there? using Linux doesn't imply that you're going to use util-linux's fdisk, but that's kind of the reference implementation... is there not a reference implementation for how to generate an initramfs? | 14:44 |
| cjwatson | there used to be yaird, and Fedora uses something entirely separate whose name I forget | 14:45 |
| james_w | dracut | 14:45 |
| cjwatson | there is no single reference implementation, no | 14:45 |
| cjwatson | james_w: thanks, that's the one | 14:45 |
| psusi | ahh | 14:45 |
| james_w | they are intending that to be /the/ version | 14:45 |
| cjwatson | yeah, but they can intend all they like ... :-) | 14:45 |
| james_w | indeed :-) | 14:46 |
| cjwatson | we looked at it in the past and IIRC it just wasn't worth the ridiculous amount of effort to convert | 14:46 |
| === yofel_ is now known as yofel | ||
| cjwatson | Debian maintains initramfs-tools pretty well | 14:47 |
| psusi | hrm... launchpad lists the upstream website as www.ubuntulinux.org and the wiki as wiki.ubuntu.com/EarlyUserspace... I take it that is quite out of date? | 14:50 |
| cjwatson | yup | 14:51 |
| cjwatson | by about five years | 14:51 |
| psusi | any idea what the correct links should be? maybe poke an lp admin to fix it? | 14:58 |
| pitti | Daviey: will you still send a server release team meeting update? | 14:59 |
| Daviey | pitti: arosales is ON THE CASE. :) | 15:08 |
| arosales | pitti: Yes, apologies for the delay in sending it. Working on getting that out now. Traveling at the moment and fell a little behind on some tasks | 15:09 |
| infinity | psusi: I suspect http://anonscm.debian.org/gitweb/?p=kernel/initramfs-tools.git is as close as you'll get to an upstream website for initramfs-tools. | 15:11 |
| infinity | psusi: When we wrote it in Ubuntu, it wasn't done by people who particularly loved writing documentation (*shifty look*), and when maks took it over in Debian, I think he was even less interested in websites and logos. | 15:12 |
| pitti | arosales: thanks! | 15:13 |
| Daviey | infinity: consider yourself poked, violently. | 15:16 |
| Daviey | bug 759545 | 15:17 |
| ubottu | Launchpad bug 759545 in grub2 (Ubuntu Precise) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Triaged] https://launchpad.net/bugs/759545 | 15:17 |
| Daviey | infinity: ^^ | 15:18 |
| ev | pitti: for the "Stop cleaning up ddebs after 7 days" task in support of the crash database, is it just a lack of disk space preventing us tweaking this, and thus a conversation I should have with James? | 15:18 |
| pitti | ev: yes, pretty much; we are running into ENOSPC all the time, and already had to kill many arches/releases from ddebs.u.c. | 15:18 |
| ev | okay | 15:19 |
| infinity | Daviey: Ow. HR violation being filed. | 15:19 |
| ev | I'll go beg then | 15:19 |
| pitti | ev: we recently got some more space on that machine, I already sent an emergency RT a few weeks ago | 15:19 |
| pitti | ev: I can certainly bump it a bit, though; how many days do you need? | 15:19 |
| Daviey | infinity: i was simply following your request :) | 15:20 |
| ev | well, I'd like to see what the upper limit on their side is, as, and correct me if I'm wrong, this is what's causing us to have to mark slightly out of date crashes as invalid | 15:20 |
| Daviey | infinity: anyway, you'd need to speak to Machine Resources, HR would be confused why you are speakng to them :) | 15:20 |
| pitti | ev: well, not only that; apport-retrace currently uses python-apt to retrieve the debs, i. e. it needs package indexes | 15:21 |
| pitti | and our Packages.gz only has the most recent version | 15:21 |
| pitti | ev: so it'll require some more work in ddeb-retriever to figure out in which Packages.gz an old version should go into, and then some version selection in apport | 15:22 |
| pitti | so far there was not much pressure to do that, since we couldn't even fit all our current ddebs | 15:22 |
| ev | pitti: okay, thanks for the clarification | 15:23 |
| pitti | ev: and we don't only need the ddebs, we also need the regular .debs in their old version | 15:24 |
| infinity | pitti: I take it we're still stalled on ddebs in soyuz? Cause it has all the logic required to do these things, I suspect (inculding keeping old versions in the index for a while). | 15:24 |
| pitti | ev: at that point I guess it's easier to stop using Packages.gz and just directly look up the .deb/.ddeb on the mirror, assuming that they use a standard directory layout | 15:24 |
| pitti | infinity: I haven't heard any update about that in a while, so I take it it's "yes, still stalled" | 15:25 |
| ev | ah, okay | 15:25 |
| infinity | pitti: Maybe we should revisit it sometime. See what still needs to be done to make it work, identify some bite-sized chunks, and either work on it or escalate. | 15:25 |
| infinity | pitti: The "temporary" ddeb infrastructure is a bit past its prime. :P | 15:26 |
| pitti | infinity: nice understatement :) | 15:26 |
| pitti | nothing ever lasts as long as a stopgap solution | 15:27 |
| psusi | hrm... something seems wonky with lp's changelog parser... https://launchpad.net/ubuntu/+source/lm-sensors shows a double entry that folds the debian change entry into mine and makes it look like I did it, but that's not what the changelog looks like in bzr | 15:43 |
| psusi | any idea what went wrong there? that's just goofy... | 15:49 |
| infinity | psusi: You mean https://launchpad.net/ubuntu/+source/lm-sensors/1:3.3.1-1ubuntu1 ? | 15:49 |
| Laney | that is from the .changes file: http://launchpadlibrarian.net/90508993/lm-sensors_3.3.1-1ubuntu1_source.changes | 15:50 |
| infinity | psusi: It just attributes the upload to you, that's all. It shouldn't be viewed as an authoritative changelog. | 15:50 |
| cjwatson | psusi: pretty sure that's a known bug | 15:52 |
| psusi | infinity: it attributed both my entry and the debian dev's entry to me | 15:56 |
| psusi | so dpkg-genchanges goofed? | 15:58 |
| Laney | no. It's just a presentational thing that LP made it look like a changelog. | 15:59 |
| Laney | Those are the changes relative to the last version in Ubuntu, so it's correct in that sense | 15:59 |
| psusi | listing them both in .changes is correct... removing the debian dev's signature and applying mine to both entries is not | 16:01 |
| psusi | well, may be correct.. I'm still not sure about that | 16:01 |
| psusi | but it certainly shouldn't be moving my sigangure to cover the debian dev's entry | 16:01 |
| cjwatson | like I say it's a known bug. | 16:01 |
| psusi | kk... | 16:01 |
| psusi | well I guess I'm happy I didn't screw something up... | 16:02 |
| cjwatson | https://bugs.launchpad.net/launchpad/+bug/55795 | 16:02 |
| ubottu | Ubuntu bug 55795 in Launchpad itself "+changelog includes misleading information related to package versions and authors" [Low,Triaged] | 16:02 |
| infinity | +changelog being an amalgamation of .changes entries is a bug, to be sure. But .changes doing what it does is more of a feature than a bug. It's upload attribution, not changelog attribution. | 16:05 |
| ScottK | The fundamental problem is that the page called +changelog isn't a changelog. | 16:07 |
| ScottK | Either the content should match the label or the label should be changed. | 16:08 |
| pitti | jibel: seems http://reports.qa.ubuntu.com/reports/boot-speed/acer-veriton-01/2012-01-20_03-39-32/bootchart.png is back to normal, though? | 16:13 |
| pitti | jibel: not sure where that huge delay came from | 16:15 |
| psusi | isn't the bug in dpkg-genchanges? since it's incorrect right there in the changes file? and that is generated when the sponsor runs debuild right? | 16:23 |
| infinity | psusi: .changes documents the upload, not the changes. It's perhaps poorly-named. :P | 16:24 |
| jibel | pitti, could it be a network problem ? it seems the system is waiting on something. | 16:25 |
| Laney | they are the changes in that upload though (relative to the last version in Ubuntu) | 16:25 |
| psusi | Laney: sure... listing them both is fine.. the issue I have is that it mangled the signature to attribute both changes to me, instead of showing two changes, with two signatures | 16:26 |
| ScottK | Laney: For merges not always (it's not rare for people to for -v) | 16:26 |
| pitti | slangasek: actually, I do remember that the buildd descriptions said "panda", but I don't see them now on any of the builders on https://launchpad.net/builders | 16:26 |
| slangasek | oh, hmm | 16:27 |
| === Quintasan_ is now known as Quintasan | ||
| Laney | ScottK: well, yes, since it's manual the usage isn't as consistent as it could be | 16:27 |
| slangasek | pitti: ah, if you drill down into the pages, they're listed as e.g., "nasl (arm panda)" | 16:28 |
| slangasek | kitalpha is (arm), so not panda | 16:28 |
| pitti | ah, seems we only have a few then, thanks | 16:28 |
| pitti | slangasek: oh, that's armhf | 16:28 |
| pitti | we need armel | 16:28 |
| slangasek | pitti, ScottK: note that qtwebkit-source *also* FTBFS on armhf, and *all* the armhf buildds are pandas | 16:29 |
| ScottK | slangasek: Different issue. | 16:29 |
| slangasek | ah? | 16:29 |
| * slangasek digs | 16:29 | |
| infinity | Which issue are we talking about here? | 16:29 |
| ScottK | We need to update the symbols files. | 16:30 |
| ScottK | The armel issue is memory exhausted during linking. | 16:30 |
| ogra_ | infinity, the mmap issue of the arm kernels on the buildds | 16:30 |
| slangasek | ScottK: it did on armhf too | 16:30 |
| slangasek | "/usr/bin/ld: final link failed: Memory exhausted" | 16:30 |
| infinity | ScottK: That is a kernel bug, not a "we need a panda" issue. | 16:30 |
| slangasek | infinity: no, the pandas have the fixed kernel deployed | 16:30 |
| infinity | ScottK: The armel buildds are being updated for it as well. | 16:30 |
| ScottK | infinity: Allededly the pandas have said kernel | 16:30 |
| infinity | slangasek: Well, yes. There's that. But it's being deployed everywhere. | 16:30 |
| slangasek | if it's still OOMing, then it needs > 3GB, not just > 2GB | 16:30 |
| slangasek | infinity: point is, "wait for kernel update and retry" is the wrong strategy | 16:31 |
| infinity | (And since the package needs a new upload ANYWAY, I'm not sure it's worth caring right now) | 16:31 |
| ScottK | Sure enough. OOM on armhf too. | 16:31 |
| ScottK | I swear I looked at that yesterday and it didn't. | 16:31 |
| infinity | Kernel version: 2.6.38-1209-omap4 #19-Ubuntu SMP PREEMPT Tue Dec 20 15:41:36 UTC 2011 armv7l <-- Not the fixed kernel. | 16:31 |
| infinity | slangasek: Whoever said all the pandas were updated may have fibbed. :P | 16:31 |
| ScottK | I must have looked at powerpc twice by accident. | 16:31 |
| slangasek | hmm | 16:31 |
| slangasek | infinity: well then - all the more reason "wait for kernel update" is the wrong strategy, because I was assured the pandas had already been upgraded which means it's probably not on the todo list ;) | 16:32 |
| * slangasek digs up the RT | 16:32 | |
| infinity | Well, that was also 4 days ago. Let me look at a current build on nasl. | 16:32 |
| infinity | Or nihal. Or whatever that was. | 16:33 |
| infinity | Yeah, still out of date. | 16:33 |
| infinity | lamont: Ping, re: mmap kernel updates. | 16:33 |
| slangasek | doko: do you recall the RT ticket # for the ARM kernel upgrade? | 16:34 |
| slangasek | from what I can tell it's no longer open | 16:34 |
| infinity | slangasek: So, looking at recent build logs, it looks like the only one of the distro builders that's been updated is meissa. | 16:36 |
| slangasek | score | 16:36 |
| doko | slangasek, there was none, buildds did get it with -updates | 16:37 |
| infinity | slangasek: I know some of the other pandas around the DC (pseudo-virt PPAs, etc) were updated, but only one of seven of the distro buildds, apparently. :P | 16:37 |
| doko | but afaik there still the omap3 kernel missing | 16:37 |
| slangasek | doko: but the buildds needed a coordinated reboot, I thought there was an RT filed for that? | 16:37 |
| doko | #50176] | 16:37 |
| slangasek | doko: thanks | 16:38 |
| infinity | That ticket starts out by assuming all the machines were actually updated. | 16:38 |
| infinity | I suspect that's the failure. | 16:38 |
| slangasek | heh | 16:39 |
| infinity | slangasek: And, to be fair, there's no coordinated reboot required. | 16:39 |
| doko | so the pandas should be updated | 16:39 |
| ogra_ | just a random one ? | 16:39 |
| doko | infinity, that's what I was told | 16:39 |
| ogra_ | :P | 16:39 |
| infinity | slangasek: Coordinated power-cycling is required when one wants to dump the pandafarm, but if you just type "reboot", they do as you'd expect individually. | 16:39 |
| slangasek | infinity: well, I know it was made out to be an involved process when I pinged <shrug> | 16:40 |
| ScottK | infinity: So would it be worth retrying qtwebkit-source on meissa to see if it makes it there? | 16:49 |
| slangasek | it would | 16:49 |
| infinity | ScottK: Sure, but it'll still fail due to symbols files being goofy, won't it? :P | 16:50 |
| infinity | ScottK: Or is that PPC-only that's broken? | 16:50 |
| infinity | ScottK: (Anyhow, I can make that happen) | 16:50 |
| ScottK | infinity: It probably will, but then I'll have the build log to fix it. | 16:50 |
| infinity | ScottK: Fair point. | 16:51 |
| ScottK | infinity: Please try it. | 16:51 |
| pitti | ScottK: still need me to kick a retry? the backscroll looks like that won't help? | 16:52 |
| infinity | ScottK: Done. | 16:52 |
| ScottK | pitti: I think infinity just did it. | 16:52 |
| ScottK | Err he did | 16:52 |
| pitti | for armhf, yes | 16:53 |
| pitti | I mean for armel | 16:53 |
| ScottK | Right. No point for armel yet. | 16:53 |
| infinity | ScottK: Should I try to wrangle something for armel, or will the symbols breakage be the same for both? | 16:53 |
| pitti | that's what I understood; ok | 16:54 |
| * infinity tries to remember the last qt/kde symbols file he fixed for armhf... | 16:54 | |
| pitti | unmangled symbols won't work? | 16:54 |
| ScottK | I'm checking to see if there are differences currently. | 16:54 |
| ScottK | infinity: It may just be powerpc. Let's see how armhf comes out before you spend time on something complicated. | 16:56 |
| * BenC perks up on powerpc | 17:01 | |
| ScottK | BenC: Just a per arch symbils difference. Nothing exciting. | 17:04 |
| * BenC goes back to sleep | 17:04 | |
| debfx | we could just pass -c0 to dpkg-gensymbols again like we do in qt4-x11 since it's unlikely that upstream will break abi and 95% of the symbols aren't really part of the public abi anyway | 17:08 |
| ScottK | Does the Qt4 ABI guarantee apply to Qt Webkit? | 17:19 |
| debfx | yes, qtwebkit is still part of Qt4 | 17:20 |
| ScottK | OK. Might make sense then. | 17:21 |
| === doko_ is now known as doko | ||
| doko | seb128, fixed python2.7 uploaded, a backport was incomplete | 17:26 |
| seb128 | doko, thanks! | 17:26 |
| jtaylor | doko: can you fix the argparse issue too please? | 17:45 |
| jtaylor | bug 916188 | 17:46 |
| ubottu | Launchpad bug 916188 in python-defaults (Ubuntu) "argparse provide breaks builds" [High,New] https://launchpad.net/bugs/916188 | 17:46 |
| seb128 | do the ppa builders always default to use -j2? | 18:25 |
| seb128 | is there any way to turn that off? | 18:26 |
| seb128 | webkit seems to not like it and fails to build | 18:26 |
| === deryck is now known as deryck[lunch] | ||
| micahg | seb128: ~line 30 in debian/rules is where it's set | 18:40 |
| seb128 | micahg, hum, it's not set on my local build though, weird | 18:42 |
| micahg | default is 1 :) | 18:42 |
| seb128 | micahg, but I guess I can just drop those lines, thanks | 18:42 |
| micahg | seb128: well, they can be dropped until upstream gets parallelizable | 18:42 |
| hallyn | jdstrand: so, 'make check' for netcf succeeds in sbuild. But it fails on the buildds. (https://launchpadlibrarian.net/90473282/buildlog_ubuntu-precise-amd64.netcf_0.1.9-2ubuntu2_FAILEDTOBUILD.txt.gz) | 18:43 |
| hallyn | don't know enough about the buildds to be sure what's going on there. | 18:43 |
| jdstrand | hallyn: tests/test-suite.log would be helpful | 18:48 |
| jdstrand | hallyn: there isn't obvious in the build log | 18:49 |
| hallyn | yeah - i'm looking through strace of successful test in sbuild for a clue | 18:50 |
| hallyn | nothing in test-suite.log actually | 18:50 |
| jdstrand | interesting that it passed on armel | 18:50 |
| hallyn | and test-debian.log only shows 6 successful tests :) | 18:50 |
| hallyn | yeah | 18:50 |
| jdstrand | PASS: test-debian | 18:51 |
| jdstrand | so the buildds should all be native builders for the archive | 18:52 |
| jdstrand | so I'm not sure why they would fail if it were a buildd problem | 18:52 |
| jdstrand | might need to do a ppa build, perhaps cat'ing tests/test-suite.log on failure | 18:53 |
| micahg | hallyn: do any of the tests require network access? | 18:54 |
| jdstrand | well, the armel should fail then | 18:54 |
| jdstrand | and when I ran the tests before I didn't see any network traffic | 18:54 |
| hallyn | I've run them locally in an empty netns, successfully | 18:54 |
| hallyn | no execs of ifconfig or ip | 18:55 |
| jdstrand | hallyn: that would have been my next suggestion | 18:55 |
| jdstrand | interesting :) | 18:55 |
| hallyn | some missing dep, i would have to think... | 18:56 |
| infinity | hallyn: If it works locally (in a clean chroot) and not on the buildds, it's almost certainly network-related. | 18:56 |
| infinity | hallyn: Note that the buildds can't even resolve DNS outside their own network. It's stricter than most people think. | 18:57 |
| jdstrand | yeah, but the empty netns points to something else-- and that arm succeeded | 18:57 |
| infinity | Oh, I didn't notice that arm* succeeded. | 18:57 |
| jdstrand | I run it with tcpdump and didn't see any traffic at all | 18:57 |
| infinity | In which case, something's even more special. ;) | 18:57 |
| * infinity grabs the source. | 18:58 | |
| jdstrand | s/run/ran/ | 18:58 |
| jtaylor | doko: why stop provide in 2.7? isn't that the place it should be provided? | 19:03 |
| jtaylor | python-defaults is to me the package that should not provide it | 19:04 |
| jtaylor | (though it does not really matter as we only have one py version anyway) | 19:04 |
| infinity | Seems weird for "python" to do anything other than depend on python${version} | 19:04 |
| superm1 | infinity: the mirror that buildds pull packages from, would it be feasible for pulling a source package from too, or are there only binary packages there? | 19:15 |
| infinity | superm1: It's ftpmaster. | 19:16 |
| jtaylor | doko: why is the argparse provide in debian o_O | 19:16 |
| infinity | superm1: But I'm more curious about the origin of this question... | 19:17 |
| jtaylor | debian still has 2.6 | 19:17 |
| infinity | superm1: As in, what do you want to provide source packages to? | 19:17 |
| superm1 | infinity: well i wanted to add a test to a package that requires pulling the source of grub2 and compiling it with a patch applied. the binary package wouldn't ship with it | 19:17 |
| superm1 | but to know if in the field that would break ahead of time with grub that's in the archive | 19:17 |
| infinity | superm1: I guess no one can stop you from doing that, since it will, technically, work. | 19:18 |
| infinity | superm1: But make the build smart enough to use the mirror in sources.list, don't hardcode it. | 19:18 |
| superm1 | okay | 19:18 |
| superm1 | do you have oppositions to the concept of doing a test like that though I take it? | 19:19 |
| infinity | superm1: (Mirroring, for example, how debian-installer gets extra stuff during build) | 19:19 |
| superm1 | right | 19:19 |
| infinity | superm1: I have a general icky feeling about testsuites that assume network access. | 19:19 |
| infinity | superm1: In the case of "pulling from a Debian repository", you do know it'll work on buildds, though. | 19:19 |
| infinity | superm1: It's still icky. :P | 19:19 |
| superm1 | well maybe make the test not fail if it can't apt-get source then, but only fail if the compile fails | 19:20 |
| infinity | superm1: It won't be able to apt-get source at all. | 19:20 |
| infinity | superm1: But in the spirit of what you meant, yeah. I guess it wouldn't be awful. | 19:20 |
| superm1 | yeah i haven't looked at semantics of how it's done by debian-installer during build yet, so perhaps not apt-get source | 19:21 |
| superm1 | okay, thanks! | 19:21 |
| infinity | superm1: Well, apt-get source won't work because there are no deb-src lines in sources.list. | 19:21 |
| infinity | superm1: You could build a sources.list of your own and apt-get -o APT::conf::whatever=mysources | 19:22 |
| superm1 | but you can specify alternate sources.list files right | 19:22 |
| infinity | superm1: But that seems rather like effort. | 19:22 |
| superm1 | that that's what i was thinking | 19:22 |
| infinity | superm1: The end goal of this being a package that allows users to make non-GPL changes to GRUB, I'm guessing? | 19:22 |
| infinity | Or, makes said changes for them... | 19:22 |
| superm1 | infinity: well actually the code is GPL, but it needs to be compiled under mingw | 19:23 |
| superm1 | and want to make sure that it matches the grub in the archive for any CD builds that would have it built in | 19:23 |
| infinity | I think I just burst a blood vessel in my brain. | 19:23 |
| superm1 | haha | 19:23 |
| superm1 | long story short, need a grub-setup.exe that can load a core.img boot from grub-mkimage | 19:24 |
| infinity | Check. | 19:24 |
| infinity | But I'm still mildly curious why you can't ship the resulting binary? | 19:24 |
| infinity | I mean, we can, if you're talking about putting it on CDs... | 19:24 |
| infinity | So, why not just ship it as an arch_all package? | 19:25 |
| superm1 | hmm. | 19:25 |
| superm1 | oh because previously I wasn't aware that it would be possible to fetch a source package from ftpmaster at all | 19:25 |
| superm1 | so i guess that is a good alternative now | 19:25 |
| infinity | Well, that would be the wrong way to go if you wanted to actually ship the binary. | 19:26 |
| superm1 | but the problem would be what if grub in the archive got updated and this package wasn't rebuilt | 19:26 |
| infinity | The right way to go would be either building it from grub2 itself (no-go, since mingw is in universe), or making grub2 produce a grub2-source package that you can build-dep on. | 19:26 |
| infinity | While debian-installer does do crazy things outside the realm of build-deps, I'm not sure we want to use it as a precedent either. | 19:27 |
| superm1 | that would still have the same rebuild problem though if grub in the archive changed | 19:27 |
| infinity | Well, any solution other than "build it from grub" has that problem. | 19:27 |
| infinity | At some point, someone needs to manually rebuild it, whether locally or by an upload. | 19:28 |
| superm1 | the current way that it's done is during postinst with an apt-get source, which avoids that problem | 19:28 |
| infinity | That's still a local rebuild. | 19:28 |
| infinity | And needs to be re-done if grub revs. | 19:28 |
| superm1 | well not for CD builds at least | 19:28 |
| infinity | It also gives you no guarantees that the binary is the same everywhere. | 19:28 |
| infinity | Err, oh. And if you have CD builds now requiring a compiler, that's a bit of extra ick. | 19:29 |
| SpamapS | Can things in lucid-proposed still make it in to 10.04.4 ? | 19:29 |
| SpamapS | I see that the freeze was tomorrow | 19:29 |
| SpamapS | err | 19:29 |
| SpamapS | yesterday | 19:29 |
| superm1 | infinity: yeah it's a bit of a mess, there's some extra hooks to clean up that compiler after the postinst is done right now | 19:29 |
| infinity | SpamapS: If they pass validation, that's a big "maybe". | 19:29 |
| SpamapS | really want to see bug 711425 land | 19:29 |
| ubottu | Launchpad bug 711425 in sysvinit (Ubuntu Lucid) "portmap does not stop during shutdown, causing possible root fs corruption" [High,Fix committed] https://launchpad.net/bugs/711425 | 19:29 |
| infinity | SpamapS: But as #ubuntu-release. | 19:29 |
| infinity | superm1: Yeah, that all sounds very much like a bad way to do it, IMO. | 19:30 |
| SpamapS | we'd have to waive the 7 day rule too | 19:30 |
| SpamapS | seems like its too late. :( | 19:30 |
| infinity | SpamapS: Exceptions can be made. But generally only for something that affects media. | 19:31 |
| infinity | SpamapS: And this doesn't look to. Upgrading post-install still fixes the bug. | 19:31 |
| infinity | SpamapS: (I guess doing a netinst to an nfsroot would be problematic here, that's about all I can see to make it an installer blocker, though...) | 19:32 |
| SpamapS | infinity: indeed, postinstall it is then. | 19:32 |
| SpamapS | infinity: no, its not an installer blocker, should be fine | 19:36 |
| infinity | hallyn: It could just be the age of the kernel? ARM buildds are newer kernels. | 19:40 |
| infinity | hallyn: The machine where your build failed was running linux-image-2.6.24-30-server from hardy. | 19:40 |
| hallyn | infinity: it's not inconceivable... | 19:41 |
| infinity | hallyn: Spin up a hardy VM? :) | 19:41 |
| === deryck[lunch] is now known as deryck | ||
| cjwatson | hallyn: are you actually testing in sbuild, or only in a chroot? occasionally that makes a difference. | 19:41 |
| infinity | hallyn: (FWIW, I couldn't make it fail in a clean precise chroot, it's definitely not a dependency issue) | 19:41 |
| hallyn | alrighty, will do, thx | 19:41 |
| hallyn | cjwatson: sbuild | 19:41 |
| cjwatson | OK | 19:42 |
| infinity | cjwatson: The failure on x86 and success on arm* definitely makes me suspect kernel versions. | 19:42 |
| cjwatson | I debugged a problem for doko the other day that turned out to happen in sbuild but not in a build started interactively in a chroot, because sbuild redirects stdin from /dev/null | 19:42 |
| infinity | I'd suspect weird userspace/toolchain bugs, but those usually affect things in the opposite direction. :P | 19:42 |
| cjwatson | I agree kernel versions are a good candidate, I just see too many people blaming "the buildds" without trying in a local sbuild. :-) | 19:43 |
| infinity | cjwatson: Well, in this case, it works in sbuild on other arches. | 19:43 |
| infinity | (But yeah, still a fair point to make) | 19:43 |
| zyga | [ 2.220049] ata1: SATA link down (SStatus 0 SControl 300) | 19:44 |
| infinity | Some day, I need to write a quick-n-dirty lp-buildd reproducer. | 19:44 |
| zyga | sorry, loose mouse | 19:44 |
| infinity | ie: grabs the chroot tarball, runs the build in an lp-buildd instance. | 19:44 |
| cjwatson | (PS lesson learned from that debugging session: you can't use script(1) in a package build) | 19:45 |
| infinity | I'm sure you could if you felt the urge to play FD tag. | 19:46 |
| infinity | But given that script exists to make such things unnecessary, I suppose that sort of defeats the purpose. | 19:46 |
| cjwatson | I wrote a 51-line Python script instead. | 19:47 |
| cjwatson | (About half of which was the licence statement.) | 19:48 |
| jdstrand | hallyn: so, the kernel version differences makes sense to me too. if the fix isn't straightforward, it is still worthwhile to either have 'make check' not fail the build or better, to have the one failing test not fail the build. obviously ideally, we fix the issue and have make check fail the build | 19:48 |
| hallyn | jdstrand: yeah, this should at least give me an idea of where to look for the fault. | 19:49 |
| hallyn | infinity: thx | 19:49 |
| infinity | jdstrand: Having make check fail the build is still the right answer, IMO, disabling the one offending test would be the way to go. | 19:49 |
| infinity | jdstrand: (And when the buildds move to precise kernels, said test can be turned back on) | 19:50 |
| jdstrand | there is that-- but the test is worthwhile on arm | 19:50 |
| infinity | All assuming this is the issue. | 19:50 |
| jdstrand | *shrug* | 19:50 |
| jdstrand | let's try to get the issue fixed first :) | 19:50 |
| infinity | jdstrand: Well, one could conditionally run that specific test based on kernel version. ;) | 19:50 |
| jdstrand | true | 19:50 |
| infinity | minver=2.6.38 or something. | 19:50 |
| jdstrand | that is an even better option if the issue can't be fixed | 19:50 |
| infinity | Well, it may be unfixable because it may be trying to do things old kernels just plain can't. | 19:51 |
| jdstrand | that way local sbuilds would fail appropriately | 19:51 |
| infinity | I wouldn't be shocked. | 19:51 |
| cjwatson | There exist tests that only fail on newer kernels, too :-/ | 19:51 |
| cjwatson | (Not this one, I know ...) | 19:51 |
| cjwatson | libdevel-bt-perl comes to mind. I never did get that fixed. | 19:51 |
| === kancerman_ is now known as kancerman | ||
| jdstrand | I'm assuming that was more difficult than the 2.6 to 3.0 transition | 19:53 |
| superm1 | cjwatson: how would you feel about a grub2-src binary package to come up with a cleaner solution to what infinity and I were talking about above? | 19:58 |
| cjwatson | Not particularly happy | 19:59 |
| infinity | The two cleanest solutions are definitely either grub2-src or d-i-style pulling-from-the-archive-during build. Neither lacks ickiness. | 19:59 |
| cjwatson | Mainly because I don't like what you're doing in the first place and don't want to encourage it - grub2 objects should be built out of grub2 | 19:59 |
| cjwatson | And I feel I ship enough weird cruft from the grub2 source package as it is :-) | 19:59 |
| infinity | cjwatson: Well, the least icky solution (from a packaging perspective) is pulling mingw into main, but I don't know if we want to open that can of worms. | 20:00 |
| cjwatson | That's what I was about to suggest, actually | 20:00 |
| cjwatson | Though maybe not for precise? | 20:00 |
| infinity | I'm not against the idea, per se. I just don't know enough about mingw's supportability, etc. | 20:01 |
| cjwatson | Ditto | 20:01 |
| superm1 | okay, so next release cycle will come up with a cleaner way to be doing this then | 20:02 |
| cjwatson | Wubi does a few nasty things as well, but at least it only uses shipped tools and doesn't compile anything | 20:04 |
| cjwatson | And we do have an arrangement to upgrade the bit of it that goes on installed user systems when grub is upgraded | 20:05 |
| cjwatson | With grub2-src you'd also have to be very careful about GPL compliance, and LP doesn't yet support Built-Using so won't help you | 20:08 |
| doko | Processing triggers for libgdk-pixbuf2.0-0 ... | 20:11 |
| doko | Segmentation fault | 20:11 |
| doko | seb128, ^^^ but no error | 20:11 |
| maxb | Is there any way to capture stdout from a process run as an upstart job, for debugging? | 20:11 |
| seb128 | doko, seems the same issue pitti was having yesterday, he said that's due to your ppa's glibc | 20:11 |
| doko | ahh | 20:12 |
| doko | yes, that's a chroot with it installed | 20:12 |
| seb128 | doko, not sure if he debug it further | 20:12 |
| seb128 | he nailed it down due to the ppa version | 20:12 |
| seb128 | sorry but I don't have details out of this | 20:12 |
| doko | that's enough | 20:13 |
| stgraber | maxb: yes, upstart 1.4 lets you do that (though it's currently turned off because of a bug that makes upstart crash with some specific jobs) | 20:13 |
| stgraber | maxb: you can boot with "--log" added to your kernel command line to turn on the feature until a new upstart is uploaded with a fix | 20:14 |
| stgraber | maxb: then you'll get /var/log/upstart/*.log with the output of the jobs | 20:14 |
| maxb | stgraber: ok.... well I guess I'll cheat horribly for now..... "console output", and replace /dev/console with a plain file :-) | 20:14 |
| stgraber | maxb: (that's assuming you're running on Precise) | 20:14 |
| cjwatson | or you can just redirect output to a file in /run for no | 20:14 |
| cjwatson | w | 20:14 |
| slangasek | pitti: I've learned in a rather roundabout way of urfkill, which seems to be the last component needed to let us get rid of acpi-support; do you happen to know anything about this and if we can reasonably include it in the default install for precise? | 20:15 |
| slangasek | seems a bit raw though; it has a config file that lets you twiddle things no one should ever want to manually twiddle, which implies it doesn't actually autodetect everything it should | 20:18 |
| slangasek | oh, but there are vendor profiles that override | 20:19 |
| cjwatson | astraljava: scott-work laid out for me what ought to be on the Ubuntu Studio live DVD, so I've just gone ahead and implemented that in the seeds - hope you don't mind, I belatedly remembered that you'd taken a work item for that | 20:54 |
| cjwatson | astraljava: I'm stealing the "create seeds" work item and marking it done - you still have a "review edubuntu 'dvd-live' seed" work item, but maybe you just want to drop that at this point? | 20:56 |
| cjwatson | just waiting for tasksel and livecd-rootfs to build and publish, then I can probably try a build | 20:59 |
| cjwatson | assuming I haven't forgotten anything else | 20:59 |
| infinity | cjwatson: You've forgotten that it's 9pm on a Friday, and you should walk away from the keyboard? ;) | 21:00 |
| cjwatson | infinity: Silence. | 21:04 |
| scott-work | cjwatson: within two days i shall review the work items mainly checking for items that should be marked 'postponed' or 'blocked', but i will resolve any outstanding items such as "review edubuntu 'dvd-live' seed" | 21:04 |
| cjwatson | scott-work: OK | 21:05 |
| cjwatson | I had to copy the ship seed to dvd - couldn't easily reuse it unfortunately due to how germinate works. I suppose it could have been a symlink but I suspect it may want to diverge in the future anyway. | 21:07 |
| astraljava | cjwatson: Wow! Thanks so much! I haven't had much time for the past couple of days for *buntu stuff, so muchly appreciated! | 21:08 |
| astraljava | cjwatson: But I suppose we still need to include the ubiquity patch for tasks selection? | 21:09 |
| cjwatson | astraljava: Yes (plugin actually, not patch) - I'm not going to do anything with that | 21:10 |
| jelmer | /win 8 | 21:11 |
| astraljava | cjwatson: Ok, thanks for confirming that. I'll get on that next, then. | 21:11 |
| barry | cjwatson: still around? | 21:13 |
| cjwatson | barry: was just about to leave before infinity mocks me further - is it quick? | 21:13 |
| barry | :) yes. launchpadlib for python3. are you working on it, or planning to? seems like that's the next one on the critical path for me. | 21:14 |
| barry | cjwatson: ^^ if not, i'll tackle it | 21:14 |
| cjwatson | barry: still trying to finish up python3-apt fixes + python3-debian | 21:15 |
| cjwatson | barry: I had been planning to, but if you're blocked, feel free to steal it - there are actually a few packages to work on theree | 21:15 |
| barry | cjwatson: cool. i'll file a bug against launchpadlib, add it to the blueprint and take a crack at it... yep, +1 | 21:16 |
| cjwatson | barry: I believe it's oauth, lazr.restfulclient, keyring, launchpadlib (at least) | 21:16 |
| cjwatson | barry: plus chasing down some releases/packaging/etc. | 21:16 |
| barry | cjwatson: oauth is gonna suck because it's basically unmaintained upstream | 21:16 |
| cjwatson | bug 823252 | 21:17 |
| ubottu | Launchpad bug 823252 in python-oauth (Ubuntu) "Please provide a python3 package" [Undecided,New] https://launchpad.net/bugs/823252 | 21:17 |
| cjwatson | I started on making oauth be either six or 2to3 - given relative lack of upstream maintenance I really don't think branching it is a good idea | 21:17 |
| cjwatson | the patch isn't really all that terrifying though | 21:17 |
| cjwatson | barry: maybe you could figure out keyring and I'll finish up what I was doing with oauth at the earliest opportunity? | 21:18 |
| barry | cjwatson: that sounds like a plan for today. | 21:18 |
| * ScottK thinks the only python that terrifies barry is python 1.5. | 21:18 | |
| barry | ScottK: actually, 1.6 is the most frightening :) | 21:18 |
| ScottK | Ah. | 21:19 |
| * ScottK was close. | 21:19 | |
| cjwatson | my python-debian 3 branch is fairly scary, and currently failing tests :-( | 21:19 |
| barry | but nobody knows about the contractual obligation release :) | 21:19 |
| barry | cjwatson: dang. bytes/strings? | 21:19 |
| cjwatson | yup | 21:19 |
| cjwatson | there's a horrible bit where it needs to parse text before knowing whether it's bytes or unicode | 21:19 |
| barry | ouch | 21:20 |
| cjwatson | foo = re.compile(r'blah'); if isinstance(text, bytes): foo = re.compile(foo.pattern.encode()) | 21:20 |
| cjwatson | makes slightly more sense in context but still *shudder* | 21:20 |
| ScottK | barry: Google knows about it: http://mail.python.org/pipermail/python-dev/2011-August/112846.html | 21:21 |
| barry | cjwatson: try foo = re.compile(br'blah') for a nice change of data types :) | 21:22 |
| cjwatson | yeah, I know about that but it didn't really work out | 21:22 |
| cjwatson | I left out a 'for line in sequence:' above | 21:22 |
| barry | ScottK: google knows everything. http://www.python.org/getit/releases/1.6.1/ | 21:23 |
| cjwatson | anyway will probably still change things around given it's failing tests right now - I just took a break to try to split out some of the working bits into reasonably-sized commits | 21:23 |
| barry | at least python 3.3 will let you write rb'foo' too :) | 21:23 |
| * barry nods | 21:23 | |
| cjwatson | http://anonscm.debian.org/gitweb/?p=users/cjwatson/python-debian.git;a=shortlog;h=refs/heads/python3 | 21:24 |
| cjwatson | uncommitted WIP is a 1700-line patch | 21:24 |
| ScottK | barry: I particularly love the name of the "CNRI Open Source GPL-Compatible License" | 21:24 |
| ScottK | That resulted in a lintian bug report. | 21:25 |
| barry | ;) | 21:25 |
| barry | cjwatson: nice: http://pypi.python.org/pypi/keyring/0.7#id1 | 21:27 |
| cjwatson | Handy | 21:27 |
| barry | cjwatson: i'll prep a debian update and test it on precise | 21:28 |
| cjwatson | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656336 is the lazr.uri bug | 21:28 |
| ubottu | Debian bug 656336 in lazr.uri "lazr.uri: new upstream 1.0.3 with Python 3 support" [Wishlist,Open] | 21:28 |
| cjwatson | barry: you might need to harass somebody to do a wadllib release | 21:29 |
| cjwatson | the patch has landed in trunk | 21:29 |
| barry | cjwatson: blueprint updated | 21:32 |
| barry | slangasek will not be happy with the burndown chart :) | 21:33 |
| === salem_ is now known as _salem | ||
| stgraber | barry: I'll try to do some Edubuntu work this weekend, that should improve our chart a bit ;) | 21:35 |
| barry | stgraber: i like how that works out. i add items and you close them. :) | 21:36 |
| ScottK | barry: What was the result of your contacting POX about the status of multibuild? | 21:58 |
| barry | ScottK: he says he's been busy with real life, but has some time now to move things forward | 21:58 |
| ScottK | Thanks. | 21:59 |
| ScottK | infinity: "/usr/bin/ld: final link failed: Memory exhausted" new kernel is not enough for qtwebkit-source. Urk! | 21:59 |
| === ISK_ is now known as ISK | ||
| infinity | ScottK: That's... Not comforting. | 22:02 |
| ScottK | infinity: Right. I wanted to make sure you had a nice weekend. | 22:02 |
| infinity | ScottK: That means it must be pretty dangerously borderline on all 32-bit arches. | 22:02 |
| ScottK | ;-) | 22:02 |
| ScottK | Really? It's not that different than what we had before that built. | 22:03 |
| infinity | ScottK: I'm going to try this locally on a Panda with that kernel over the weekend and see what I can come up with. | 22:05 |
| ScottK | Builds on armel in Debian. | 22:05 |
| ScottK | infinity: Sounds very good. Thanks. | 22:05 |
| ScottK | Interestingly it gives an ICE on armhf in Debian, so count your blessings. | 22:06 |
| infinity | I think Debian's behind on GCC patches, hence the ICE. | 22:07 |
| infinity | But binutils needing more than 3G to link this thing is ridiculous. :/ | 22:07 |
| infinity | And me needing natty to debug it is equally annoying... | 22:08 |
| * infinity goes SD card hunting. | 22:08 | |
| infinity | ScottK: If it's any consolation, our control build (haskell-src-exts) also failed. It might just be that this kernel is a dud, and wasn't verified correctly... | 22:09 |
| micahg | infinity: Chromium is pretty close to 3GB for linking as well BTW | 22:09 |
| janimo | infinity, the buildd pandas all have 1GB active now? | 22:10 |
| infinity | janimo: Real RAM isn't the issue here, it's the 3G addressable bit. | 22:10 |
| infinity | janimo: (And I'm not sure if lamont fixed their cmdline, but even if he didn't, that's only 64M lost or something?) | 22:11 |
| janimo | infinity, well I was thinkging of haskell-src-exts | 22:11 |
| infinity | janimo: Same story... | 22:11 |
| janimo | infinity, at one point they were using half a gig only | 22:11 |
| infinity | janimo: In both cases, real RAM isn't the issue. | 22:11 |
| infinity | Err, what? | 22:12 |
| infinity | I don't recall that ever being true. | 22:12 |
| janimo | infinity, well I think some of the builds failed because of thrashing so more physical RAM would have helped | 22:12 |
| janimo | infinity, in maverick or even natty at one point pandas were unstable with 1G so we had half a gig or so. Or maybe 600-700M | 22:12 |
| janimo | anyway not the full RAM minus fb size | 22:12 |
| infinity | janimo: Anyhow, just confirmed that the entire RAM is there. | 22:14 |
| janimo | ok | 22:14 |
| infinity | I'm cursed. | 22:16 |
| infinity | I just panicked an x86 machine while downloading a natty arm image. | 22:16 |
| infinity | apw: I blame you. | 22:17 |
| === EyesIsServer is now known as EyesIsAsleep | ||
| infinity | ... | 22:22 |
| infinity | And again. | 22:22 |
| hallyn | mdeslaur: vm-new is trying to download from releases.ubuntu.com? | 22:29 |
| hallyn | trying mini... | 22:33 |
| hallyn | slangasek: do you know of anyone ideally suited to look at bug 893450 ? it turns out to be a perf problem somewhere in the storage stack... | 22:34 |
| ubottu | Launchpad bug 893450 in libvirt (Ubuntu) "libvirt fails to start correctly because LVM is not ready" [High,Incomplete] https://launchpad.net/bugs/893450 | 22:34 |
| barry | stgraber: ping | 22:53 |
| stgraber | barry: pong | 22:54 |
| barry | stgraber: hi. iirc, you have some output about the environment in the buildd chroots, right? i'm seeing something in my local sbuilds with the locale being different than my normal shell locale. this causes problems with python because sys.getfilesystemencoding() ends up being 'ascii'. i'm wondering what the actual local is on the buildds | 22:56 |
| barry | stgraber: iow, sys.getfilesystemencoding() is 'utf-8' in a normal shell, but 'ascii' in a schroot | 22:56 |
| Laney | ls | 22:57 |
| Laney | noooooo | 22:57 |
| stgraber | barry: https://api.launchpad.net/1.0/ubuntu/precise/amd64 will give you the link to the current chroot used by LP, not sure how much information about the environment you can get out of that though | 22:58 |
| tumbleweed | we normally build in the C locale | 22:58 |
| tumbleweed | LC_ALL=C python -c 'import sys; print sys.getfilesystemencoding()' gives me ANSI_X3.4-1968 | 22:58 |
| barry | stgraber: not enough, but thanks ;) | 22:58 |
| barry | tumbleweed: hmm. that tells me that my chroot is accurately reflecting the buildd's which is good. but now i have to work around the ascii fs encoding ;) pain awaits. | 23:00 |
| stgraber | barry: http://paste.ubuntu.com/811279/ | 23:00 |
| barry | stgraber: c locale. cool, thanks, that jives w/tumbleweed. i'll hack around it | 23:01 |
| tumbleweed | barry: yeah, for some packages we have to generate a UTF-8 locale so that the tests can run | 23:01 |
| tumbleweed | (e.g. beets, comes to mind) | 23:01 |
| stgraber | barry: taken from jodh's procenv's package tests in the buildlog (IIRC that's how we discovered the /dev/stdin weirdness last week): https://launchpadlibrarian.net/89515945/buildlog_ubuntu-precise-amd64.procenv_0.2-1ubuntu7_BUILDING.txt.gz | 23:01 |
| barry | stgraber: ah yes, right. james had that nice little package. thanks! | 23:02 |
| barry | tumbleweed: maybe i should look at how beets does that for python-keyring | 23:02 |
| barry | tumbleweed: ah. i see how it does it. i have to get python-keyring to set the local before it runs setup.py, since that's the first failure | 23:04 |
| tumbleweed | that sucks if it won't even install in a non-UTF-8 locale | 23:04 |
| tumbleweed | (python's encoding heuristics are one fo my least favorite bits of the language) | 23:05 |
| barry | tumbleweed: yep. it reads the CHANGES.txt file next to setup.py, which contains non-ascii | 23:05 |
| tumbleweed | ah, yeah, seen that before too | 23:06 |
| tumbleweed | I got upstream to take an ASCII-ificantion patch | 23:06 |
| barry | tumbleweed: could be an easy solution is a quilt patch to ignore encoding errors | 23:06 |
| tumbleweed | yeah, that'd work too | 23:07 |
| * barry wonders how far that'll get him | 23:07 | |
| barry | it's definitely worth submitting an upstream bug | 23:07 |
| === mathias is now known as Guest697 | ||
| broder | hmm...is it possible to set a SIGSEGV handler without interfering with apport/kernel's core dumping? | 23:45 |
| cjwatson | lamont: I don't suppose you'd have a chance to look at RT#50437? Should be quick ... | 23:46 |
| cjwatson | (will unblock an ubuntustudio work item for me) | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
