=== htorque_ is now known as htorque === Igorots is now known as Knightlust [02:34] Any archive admins floating around? I have a binary package which appears to have been universe'd by accident [02:36] Looks like the package was rejected at one point and after that the deb appears to end up in universe [02:36] python-dbus-common to be specific [02:36] ^- GRiD [02:36] er [02:37] GrueMaster: [02:40] NCommander: Looking. [02:46] 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:47] I see a replaces, no conflicts. [02:47] Anyhow, promoting, it obviously shouldn't be in universe. [02:47] But trying to sort out why component-mismatches wants python3-dbus in main too. === tilgovi_ is now known as tilgovi [04:41] Good morning [05:07] 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:08] 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] doko_: backtrace is not very helpful, though :( http://paste.ubuntu.com/810009/ [05:08] doko_: does that work for you? [05:39] pitti, hi, thanks for the review and comments [05:39] poolie: my pleasure :) thanks for the improvement [05:39] pitti, i may well be confused, but i thought that if apport was enabled, you did not get regular core files [05:39] even with ulimit -c unlimited [05:41] you do [05:41] apport writes them for you [05:41] it's not supposed to break that, as core files are quite useful for developers [05:41] poolie: I have half a dozen test cases to make sure that this works [05:41] ok, good for you [05:42] doesn't it for you? [05:42] people were complaining to me that they didn't get core files [05:42] $ ulimit -c unlimited; sh -c 'kill -SEGV $$'; file core [05:42] Speicherzugriffsfehler (Speicherabzug geschrieben) [05:42] core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 'sh -c kill -SEGV $$' [05:43] <3 deutsche :) [05:43] ah, sorry [05:43] no it's ok it's awesome [05:43] i know what you mean [05:43] it's the usual "segfault" [05:44] it seems like apport will not overwrite an existing core file, but the default kernel behaviour will [05:44] could that be true? [05:46] no, the kernel doesn't [05:46] it mimics kernel behavior pretty closely [05:46] well, at least that was the case a few years ago when I wrote that stuff [05:46] but overwriting existing files sounds a bit evil [05:46] let me try [05:47] istr overwriting was the default in the past [05:47] oh, indeed it does [05:47] that's why i used to customize it to core.$pid [05:48] interesting, so apport should do the same then [05:48] i think so [05:48] shall i file a separate bug about that? [05:49] wanting noise on stderr would then be invalid [05:49] hah, bug 160999 [05:49] Launchpad bug 160999 in apport (Ubuntu) "Apport doesn't conform to core(5)" [Low,Triaged] https://launchpad.net/bugs/160999 [05:49] it's already questionable [05:49] poolie: yeah, let's invalidate the other one then, and point to ^ [05:49] I'll fix that one now, easy thing [05:49] if you are not using nofollow that's a bit of a security risk [05:50] istr in fact this was exploitable on some old kernels [05:50] but that may have been fixed separately [05:50] hm, good point; is there a race free method of replacing an existing file? [05:51] it currently uses os.O_WRONLY|os.O_CREAT|os.O_EXCL which is race free and secure for new files [05:52] well, like Gerald says there, i think you want O_NOFOLLOW but not O_EXCL [05:52] so I guess it'd need to write a core.RANDOMJUNK and rename it to "core" [05:52] hm [05:52] yeah, races if two write at once... [05:53] ooh [05:53] 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] l1766 [05:54] ok, will queue this up for later then, not a 5-minute fix [05:54] maybe you should write a random file and rename it [05:54] the kernel doesn't seem to care (at least in 2.6) if it gets corrupted by concurrent crashes [05:56] ok, that's fine with me to leave it as a known bug [05:56] thanks for helping me understand it [06:01] pitti, i wonder if we should mention that a core file is still written in apport-bug [06:01] poolie: well, apport-bug is not really an interface for crashes.. [06:01] "man core" is meant to be that documentation [06:02] 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] i guess the text i added is not wrong [06:03] right, possibly there should be an overall 'man apport' [06:03] anyhow, i think that's enough for now [06:03] thanks [06:03] but apport itself does nothing with core files [06:03] yeah, perhaps; https://wiki.ubuntu.com/Apport could be condensed into a manpage [06:03] . o O { wow, these screenshots are old! } === bradm_ is now known as bradm [08:17] 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] 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:32] 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] 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:49] 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] cjwatson: thanks [08:53] 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] I pinged some people about particular bugs; still want to ask tseliot about the fglrx one once he comes online [08:54] pitti: I'm here [08:55] tseliot: oh, sorry; didn't see you some minutes ago, good morning! [08:55] tseliot: so, wanted to ask whether bug 566437 is an easy backport, or whether it should be dropped from 10.04.4? [08:55] pitti: good morning to you ;) [08:55] 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:57] cnd, bryce, RAOF: so, staging X.org doesn't kill any kittens here on thinkpad x201 (Intel Arrandale) [09:00] pitti: I haven't used dpkg-divert for ages now in my packages... [09:01] tseliot: that's for lucid [09:03] pitti: I'll check again my packages for lucid then [09:04] tseliot: if it's a corner case, we can drop it from the 10.04.4 list, too [09:04] pitti: ok, I'll let you know [09:08] pitti: will do the SRU for 711425 [09:09] SpamapS: splendid, thanks [09:19] SpamapS: thanks for the cookbook update! [09:20] 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] jodh: no problem. It was relevant to the zookeeper package. :) [09:20] micahg: I'm a bit more hesitant on Fridays, but if you feel sure about it, ok [09:21] pitti: personally, I prefer to be cautious, Monday would be fine for me [09:21] micahg: ok, let's do that then [09:21] in that case, I'll finish up something else tonight [09:26] @pilot in === 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 [09:27] jamespage: did you see my zookeeper MP? [09:27] SpamapS, I did [09:28] not had time yet to review in full but looked OK to me [09:30] jamespage: ok, just wanted to make sure it didn't slip into the ether [09:30] SpamapS, it won't! [09:30] (on my list alongside the FIX TESTING stuff) [09:31] jamespage: I'm still having a hard time wrapping my head around the testing to make it reboot .. :-P [09:43] is there a declarative way of stating per-arch install files? debian/binpkg.install is for all archs [09:45] pitti: portmap + sysvinit uploaded to lucid-proposed. [09:45] * SpamapS heads to bed [09:45] SpamapS: great, I'll review the queue in a bit when they get diffy [09:46] janimo: yes, hold on a sec I look for a example [09:52] janimo: pkgname.install.$arch should work [09:52] mvo, thanks a lot. hug :) [09:52] yw! [09:53] that looks like the approach with symbols files, I just never saw examples and googling was unsuccessful [09:54] still a control file like approach would have been more powerful (ex: usr/lib/file/to/install [!armel !armhf] [09:54] janimo: yeah, its a bit odd its not documented in the man page either, worth addding I guess [09:54] as I am looking to exclude some files [09:56] It is documented in debhelper(7) under "DEBHELPER CONFIG FILES" [09:56] Since it applies to debhelper commands in general, not just dh_install(1) [09:59] cjwatson, thanks, good to know. [10:06] oh, thanks cjwatson - I just looked at dh_install, my mistake [10:09] 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:17] mvo: could versioning the symbols in libapt fix it too? but you might want to ask someone who is an expert in libraries [10:18] (I hope I understood the idea behind symbol versioning correctly) [10:21] 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] so that needs to be fixed first [10:26] mvo: is this what's blocking bug 850264? [10:26] 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:28] 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:29] 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:31] 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 ? :) === chrisccoulson_ is now known as chrisccoulson [10:36] mvo: do they actually need to link to both or is it overlinking? [10:36] I mean do they use symbols from both directly? === ion__ is now known as ion [10:47] pitti: hi! :) [10:48] hello l3on === doko_ is now known as doko [10:48] hi... I saw your comment... but rebuild1 (precise) is still less than ubuntu1 [10:49] i'm talking about bug 843734 [10:49] 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] 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] pitti: what do you think about oneiric ubuntu0.1 / precise ubuntu1 ? [10:49] doko: not sure whether it just uncovers a bug in librsvg or whether it's a genuine bug in dlopen [10:50] l3on: a no change rebuild SRU should have been 1.2.6-1build0.1 IMHO [10:50] l3on: I want to avoid ubuntu1 for precise, as this would stop autosyncs, and there are no ubuntu modifications [10:50] l3on: that's why I proposed 1rebuild1 [10:50] for precise [10:50] 1rebuild1 (precise) > 1ubuntu0.1 (oneiric-proposed) [10:50] micahg: it's a dependency change in o-proposed [10:50] ah [10:51] arguably the dependency shoudl be fixed in oneiric-proposed, though [10:51] by e. g. adding a Provides: [10:51] but it'd introduce a delta either way, so it doesn't matter much [10:53] pitti: 1.2.6-1+build1 would be better as it's higher in precise, but lower than an NMU === _salem is now known as salem_ [10:54] fine for me [10:55] so, I'm not following you :) can you explain precisely which versions we should have either in precise and oneiric ? [10:55] 1.2.6-1rebuild1 wouldn't be higher as r dpkg --compare-versions 1build1 gt 1ubuntu1 || echo false [10:57] l3on: it's not 1build1, it's 1+build1 [10:57] ah ok :DD [10:58] ok... I'm going to prepare branches each for precise and oneiric [10:58] thanks micahg and pitti for explanation [11:01] l3on: pitti: actually, there's another package that build depends on ruby-rack in oneiric, ruby-actionpack-2.3, maybe provides is better? [11:07] hmm, will the autosync for p+1 ignore the "+build1" too and sync this package or will it need a manual sync? [11:07] ISTR it ignoring everything except ubuntu in the string [11:08] we could sync 1.4.0 from testing as well :) [11:09] see you! [11:13] geser: Yes, it will ignore it [11:13] geser: lp:ubuntu-archive-tools auto-sync [11:23] doko: planning an update to openjdk-6 in precise any time soon? [11:23] 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] jamespage, yes, I have to ... [11:23] hopefully this we [11:26] jamespage, but we still default to jamvm on arm* [11:27] 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] discussing that with xranby as well [11:30] 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] Launchpad bug 793929 in libmusicbrainz-2.1 (Ubuntu) "Deprecate libmusicbrainz-2.1, libtunepimp" [Medium,Triaged] https://launchpad.net/bugs/793929 [11:31] tjaalton: yes, thanks [11:31] Riddell: thanks, dropping [11:42] 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:43] in fact, why is that coming from precise rather than from lucid-updates ... [11:44] mvo: ah, never mind, my sources.list configuration was wrong before starting d-r-u [12:00] Riddell: also, kdemultimedia can drop the build-dep on libtunepimp-dev (same bug) [12:00] Riddell: then juk won't depend on libtunepimp5 anymore [12:01] tjaalton: thanks, I'll change that in bzr and upload next week [12:01] Riddell: cool === MacSlow is now known as MacSlow|lunch [12:13] cjwatson: *puh* thanks, I was a bit worried for a moment [12:48] apw: FYI, binNEWed linux -10 === MacSlow|lunch is now known as MacSlow === plars is now known as plars-away [13:22] doko, did you get an email from me on that ? [13:23] i can't find anything that i sent you but i thought i did [13:23] @pilot out === 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: [13:24] smoser, no, don't see anything [13:24] coming now. [13:25] asked pitti to file a report as well, so maybe you can comment on this too [13:26] sent. [13:26] i sent you mail just now [13:26] sorry i forgot to on friday [13:37] is there any plan to include python-qt4 in main for precise? [13:38] brendand: it's been in main forever [13:39] pitti - i guess i'm using main wrongly. on the cd? [13:39] brendand: ah, "main" != "cd" [13:39] brendand: no, python-qt4 is huge, doesn't fit on the ubuntu CDs [13:40] pitti - ok, i stand corrected! from henceforth i will never use 'main' to mean on the cd :) [13:40] brendand: heh, no worries; we have too much terminology [13:41] 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] plus a few extra bits which we don't want to ship anywhere, but officially support [13:45] pitti, thanks [13:51] pitti - i 'only' get 51.4 MB of extra dependencies when installing it (i guess that's alot relatively speaking) [13:51] especially as the image is already full ;) [13:52] oh yes [13:52] we are currently 11 MB oversized [13:52] we usually start arguing if something is bigger than .5 MB [13:52] in this case it's 100 times bigger - so i'll leave it === dendrobates is now known as dendro-afk [13:53] 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:56] brendand: ask the ubuntu one people, they might be wanting python-qt in ubuntu desktop === dendro-afk is now known as dendrobates [13:56] pitti - have the been asking ? ^ [13:56] s/the/they/ [13:56] they asked, yes -- same answer, though [13:57] not easy to change the physical size of a CD :) [13:57] pitti - use your magic powers :) [13:57] brendand: I'd rather use it to shrink pyqt4 down to 0.5 MB :) [13:58] there is some shrinking that could be done to pyqt, but I suspect not enough [13:58] now, where did I leave my magic wand and the toad blood.. [14:02] 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:03] we have a libo in the pipeline which gets it down to 706 MB [14:03] we need to fix gwibber and ubuntu-sso to drop the old webkit 1.0 stuff [14:03] that will reclaim another 7 [14:03] then we are back in the game [14:03] fixing bug 894166 will probably get us another 2.5 [14:03] Launchpad bug 894166 in firefox (Ubuntu Precise) "Make hyphenation work with system hyphenation patterns" [High,Triaged] https://launchpad.net/bugs/894166 [14:04] pitti: oh, ok. then i guess we might be ok [14:07] not sure i understand exactly what's happening though. is the intention to include python-qt4? [14:07] brendand: yes [14:07] 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] right now it's about 13 [14:08] brendand: well, i don't know which pieces of it you need exactly [14:08] pitti: well, the needed bits are a little bigger than 2MB [14:08] dobey - probably only the basics. might we get away with depending on other packages apart from while python-qt4? [14:09] dobey - we need to be able to use most GUI components [14:09] pitti: i think i calculated something like dropping 7MB, and adding 6MB back, with all we want to do for u1 [14:09] dobey - i imagine requirements are similar to yours [14:09] brendand: i mean, python-qt4 has several modules itself, which are shipped as separate libraries for the C++ version [14:10] brendand: then you should be ok, i think. [14:10] brendand: what are you asking for? [14:12] Riddell - In terms of what? Python modules - or something else? [14:13] brendand: what are you planning to use pyqt for? [14:14] Riddell - oh, to implement a new UI for Checkbox that will run on Ubuntu and Kubuntu [14:15] nice [14:15] and every other platform of course, go Qt :) [14:16] Riddell - python-qt4 is already safely on the kubuntu cd [14:17] brendand: I knew, we maintain it :) [14:19] oh dear.. [14:19] https://launchpad.net/ubuntu/+source/libreoffice/1:3.5.0~beta2-2ubuntu3/+build/3091291 [14:19] Started 2012-01-13 [14:19] (that's armel) [14:19] 1 week. nice [14:19] I can haz libreoffice blacklist on the old babbage buildds? :) [14:20] tseliot: thanks muchly! [14:23] cjwatson: nice, https://bugs.launchpad.net/ubuntu/lucid/+bugs?field.milestone%3Alist=30510 looks a lot better now :) === bladernr_afk is now known as bladernr_ === bladernr_ is now known as bladernr_afk === bladernr_afk is now known as bladernr_ [14:24] cjwatson: I guess if bug 810068 doesn't make it, it's not a big loss? [14:24] Launchpad bug 810068 in partman-iscsi (Ubuntu Natty) "kickstart iscsi option broken" [High,Triaged] https://launchpad.net/bugs/810068 [14:24] (seems you never got any real testing feedback) [14:25] pitti: thanks for bringing that bug to my attention ;) [14:39] is initramfs-tools an ubuntu homegrown package, or is there an upstream somewhere? [14:40] pitti: I was actually just preparing branches for that anyway [14:40] psusi: upstream is Debian, although IIRC it originated in Ubuntu [14:42] cjwatson: ohh... so not all distributions are using it? I thoguht the old initrd format was depreciated? [14:43] the kernel just supports both and doesn't plan on changing that? [14:43] using an initramfs doesn't imply using initramfs-tools [14:44] 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] 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:45] there used to be yaird, and Fedora uses something entirely separate whose name I forget [14:45] dracut [14:45] there is no single reference implementation, no [14:45] james_w: thanks, that's the one [14:45] ahh [14:45] they are intending that to be /the/ version [14:45] yeah, but they can intend all they like ... :-) [14:46] indeed :-) [14:46] we looked at it in the past and IIRC it just wasn't worth the ridiculous amount of effort to convert === yofel_ is now known as yofel [14:47] Debian maintains initramfs-tools pretty well [14:50] 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:51] yup [14:51] by about five years [14:58] any idea what the correct links should be? maybe poke an lp admin to fix it? [14:59] Daviey: will you still send a server release team meeting update? [15:08] pitti: arosales is ON THE CASE. :) [15:09] 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:11] 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:12] 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:13] arosales: thanks! [15:16] infinity: consider yourself poked, violently. [15:17] bug 759545 [15:17] 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:18] infinity: ^^ [15:18] 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] 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:19] okay [15:19] Daviey: Ow. HR violation being filed. [15:19] I'll go beg then [15:19] ev: we recently got some more space on that machine, I already sent an emergency RT a few weeks ago [15:19] ev: I can certainly bump it a bit, though; how many days do you need? [15:20] infinity: i was simply following your request :) [15:20] 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] infinity: anyway, you'd need to speak to Machine Resources, HR would be confused why you are speakng to them :) [15:21] ev: well, not only that; apport-retrace currently uses python-apt to retrieve the debs, i. e. it needs package indexes [15:21] and our Packages.gz only has the most recent version [15:22] 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] so far there was not much pressure to do that, since we couldn't even fit all our current ddebs [15:23] pitti: okay, thanks for the clarification [15:24] ev: and we don't only need the ddebs, we also need the regular .debs in their old version [15:24] 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] 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:25] infinity: I haven't heard any update about that in a while, so I take it it's "yes, still stalled" [15:25] ah, okay [15:25] 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:26] pitti: The "temporary" ddeb infrastructure is a bit past its prime. :P [15:26] infinity: nice understatement :) [15:27] nothing ever lasts as long as a stopgap solution [15:43] 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:49] any idea what went wrong there? that's just goofy... [15:49] psusi: You mean https://launchpad.net/ubuntu/+source/lm-sensors/1:3.3.1-1ubuntu1 ? [15:50] that is from the .changes file: http://launchpadlibrarian.net/90508993/lm-sensors_3.3.1-1ubuntu1_source.changes [15:50] psusi: It just attributes the upload to you, that's all. It shouldn't be viewed as an authoritative changelog. [15:52] psusi: pretty sure that's a known bug [15:56] infinity: it attributed both my entry and the debian dev's entry to me [15:58] so dpkg-genchanges goofed? [15:59] no. It's just a presentational thing that LP made it look like a changelog. [15:59] Those are the changes relative to the last version in Ubuntu, so it's correct in that sense [16:01] listing them both in .changes is correct... removing the debian dev's signature and applying mine to both entries is not [16:01] well, may be correct.. I'm still not sure about that [16:01] but it certainly shouldn't be moving my sigangure to cover the debian dev's entry [16:01] like I say it's a known bug. [16:01] kk... [16:02] well I guess I'm happy I didn't screw something up... [16:02] https://bugs.launchpad.net/launchpad/+bug/55795 [16:02] Ubuntu bug 55795 in Launchpad itself "+changelog includes misleading information related to package versions and authors" [Low,Triaged] [16:05] +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:07] The fundamental problem is that the page called +changelog isn't a changelog. [16:08] Either the content should match the label or the label should be changed. [16:13] 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:15] jibel: not sure where that huge delay came from [16:23] 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:24] psusi: .changes documents the upload, not the changes. It's perhaps poorly-named. :P [16:25] pitti, could it be a network problem ? it seems the system is waiting on something. [16:25] they are the changes in that upload though (relative to the last version in Ubuntu) [16:26] 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] Laney: For merges not always (it's not rare for people to for -v) [16:26] 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:27] oh, hmm === Quintasan_ is now known as Quintasan [16:27] ScottK: well, yes, since it's manual the usage isn't as consistent as it could be [16:28] pitti: ah, if you drill down into the pages, they're listed as e.g., "nasl (arm panda)" [16:28] kitalpha is (arm), so not panda [16:28] ah, seems we only have a few then, thanks [16:28] slangasek: oh, that's armhf [16:28] we need armel [16:29] pitti, ScottK: note that qtwebkit-source *also* FTBFS on armhf, and *all* the armhf buildds are pandas [16:29] slangasek: Different issue. [16:29] ah? [16:29] * slangasek digs [16:29] Which issue are we talking about here? [16:30] We need to update the symbols files. [16:30] The armel issue is memory exhausted during linking. [16:30] infinity, the mmap issue of the arm kernels on the buildds [16:30] ScottK: it did on armhf too [16:30] "/usr/bin/ld: final link failed: Memory exhausted" [16:30] ScottK: That is a kernel bug, not a "we need a panda" issue. [16:30] infinity: no, the pandas have the fixed kernel deployed [16:30] ScottK: The armel buildds are being updated for it as well. [16:30] infinity: Allededly the pandas have said kernel [16:30] slangasek: Well, yes. There's that. But it's being deployed everywhere. [16:30] if it's still OOMing, then it needs > 3GB, not just > 2GB [16:31] infinity: point is, "wait for kernel update and retry" is the wrong strategy [16:31] (And since the package needs a new upload ANYWAY, I'm not sure it's worth caring right now) [16:31] Sure enough. OOM on armhf too. [16:31] I swear I looked at that yesterday and it didn't. [16:31] 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] slangasek: Whoever said all the pandas were updated may have fibbed. :P [16:31] I must have looked at powerpc twice by accident. [16:31] hmm [16:32] 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] Well, that was also 4 days ago. Let me look at a current build on nasl. [16:33] Or nihal. Or whatever that was. [16:33] Yeah, still out of date. [16:33] lamont: Ping, re: mmap kernel updates. [16:34] doko: do you recall the RT ticket # for the ARM kernel upgrade? [16:34] from what I can tell it's no longer open [16:36] 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] score [16:37] slangasek, there was none, buildds did get it with -updates [16:37]