[00:37] barry: do you know what the bug id you open for landscape-client? [00:37] in regards to the name tweak? [00:38] disregard I found it >.< [01:28] skaet: no status page for kubuntu quantal yet? [01:31] apachelogger, give me a list of blueprints you want linked, and I'll set it up. :) [01:38] skaet: groovy... https://blueprints.launchpad.net/sprints/uds-q?searchtext=kubuntu all starting with kubuntu- please :) [02:15] apachelogger, https://blueprints.launchpad.net/ubuntu/+spec/topic-quantal-flavor-kubuntu has been setup. for the work items to show up, the kubuntu-q-* blueprints will need to have priority set, and have their definition approved. [02:18] skaet: thank you [02:19] ScottK: ^ [02:47] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso [02:47] Note to the KDE team: launchpad will hate you should you try to do things like https://bugs.launchpad.net/ubuntu/+source/meta-kde/+bug/1002336 - it's not possible to accept the nominations for Precise because LP times out. [02:47] Launchpad bug 1002336 in smokeqt (Ubuntu) "SRU tracking bug for KDE SC 4.8.3" [Undecided,Fix released] === Jacky is now known as JackyAlcine === JackyAlcine is now known as Jacky === dendrobates is now known as dendro-afk [03:35] Good morning === Jacky is now known as siibot [04:17] apw: apt-cache show linux-firmware-nonfree has the modaliases now :) === siibot is now known as Jacky [04:18] apw: btw, the script spits out firwmare files which are not referenced by any module; it seems that l-f-nonfree ships an older version of the DVB-USB firmware, while linux-firmware ships the current and actually working versions [04:18] apw: I hope that's not an accident (i. e. the firwmare is actually free) [04:18] apw: so I guess we should remove the old one from -nonfree? === thegodfather is now known as fabbione === astraljava1 is now known as astraljava === mbiebl_ is now known as mbiebl [06:43] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [07:05] good morning [07:20] pitti, generally the firmware in linux-firmware comes either from the upstream firmware tree which is all redistributible or has been through legal for confirmation, if you know the filename i'll get the right people to confirm [07:20] apw: ah, great; one example is /lib/firmware/dvb-usb-dib0700-1.20.fw [07:21] apw: nonfree ships a -1.10 version [07:21] apw: I don't doubt much that it's ok to have in -free now (great thing!), just saying that we can most probably ditch the old version from -nonfree? [07:23] pitti, yeah for sure, i believe the latter too, and getting rid of anything from -nonfree should be on our list for sure [07:24] apw: not sure if you already looked at the changelog, but for now you need to run "debian/rules debian/linux-firmware-nonfree.modaliases" manually every now and then [07:25] apw: do you see a way how this could work during build time, even on the buildds? [07:25] apw: i. e. could we do something like build-depen on linux-generic to pull the current kernel into the buildd chroot, and iterate over that instead of /lib/modules/`uname -r`? [07:25] apw: then the modaliases would auto-update itself during build and would always be current [07:26] and we would also have the list of abandoned firmware files for free in every build log [07:27] pitti, hmmm i was indeed reading that changelog with dismay :) [07:27] apw: because of the manual step, or something else? [07:28] pitti, heh yeah just the manual step, as i assume the manual step includes installing and booting the kernel from the wording [07:28] apw: yes; IOW, you'd usually run this on your developer machine [07:29] apw: I just don't know whether it has ever been tried to build-depend on the current kernel [07:29] pitti, which branch are you using for this, i'd like to have a look [07:29] apw: ubuntu:linux-firmware-nonfree (the UDD branch) [07:30] apw: I guess that would need to be something like linux-generic [i386 amd64], linux-whatever [powerpc], linux-ti-omap4 [armel, armhf], etc.? [07:30] pitti, i would expect to be able to do that indeed, build-dep on the binary kernels and do it in the build [07:30] pitti, well the issue is that its an arch: all package, so only builds on i386 [07:30] oh, right [07:30] so we'd only get the deps on that one [07:30] so linux-generic would actually be sufficient [07:31] apw: well, if we find out that ti-omap4 has modules that need -nonfree firmware (we don't have that ATM), we can always extend that [07:31] yeah, and probabally that'd be close enough for most use cases, if its not then we'd probabally want to do the others manually [07:31] it's an improvement either way [07:31] yeah [07:31] and right now (running manually) I only get linux-generic as well [07:35] pitti, i think this can be done, i'll poke it [07:46] pitti, if i want to use sed in my debian/rules do i need a builddep (and how do i work that out) [07:47] apw: no, sed is essential [07:47] apw: but I did forget to add a python3 build dep, for the gen-modaliases script [07:47] apw: why do you need sed, OOI? dh_modaliases already does the substitution in the Modalises: field [07:48] pitti, this is to work out the version of the kernel that we installed by depending on linux-image-generic [07:48] ah [07:49] it may not be sed by the time i am done, i was realising i needed to tell it about some commands, rsync for instance in the kernel package and i don't know how to know what is "essential" and therefore not necessary to mention [07:50] apw: I guess this is a good start? dpkg-query -f'${Depends}' -W linux-image-generic [07:50] $ dpkg-query -f'${Depends}' -W linux-image-generic | cut -f1 -d, | cut -f3- -d- [07:50] 3.4.0-3-generic [07:51] apw: first cut gets the first dependency, second cut chops off the linux-image- prefix [07:51] apw: as a check I'd add a test -d /lib/modules/$version to debian/rules, so that it fails if it's not there [07:54] yep thats slightly simpler than my: [07:54] kernel_version = $(shell, apt-cache depends linux-image-generic | sed -ne 's/^ Depends: linux-image-//p') [07:55] but replies on the order ... hmmm mine is order independant [07:56] apw: actually, using apt-cache is more clever because you don't need to build-depend on it [07:56] ok cool [07:56] hm why does that not work here [07:57] oh! translations [07:57] $ LC_MESSAGES=C apt-cache depends linux-image-generic | sed -ne 's/^ Depends: linux-image-//p' [07:57] 3.4.0-3-generic [07:57] extra-3.4.0-3-generic [07:57] oh of course [07:57] ok [07:57] apw: so it's still order dependent, you'd need to find the one without extra- ? [07:58] LC_MESSAGES=C apt-cache depends linux-image-generic | sed -ne 's/^ Depends: linux-image-[0-9]//p [07:58] LC_MESSAGES=C apt-cache depends linux-image-generic | sed -ne 's/^ Depends: linux-image-[0-9]//p;' [07:58] apw: ^ how about this? [07:58] pitti, i think thats the same :) [07:59] ah, snap [07:59] but it loses the 3 [07:59] * pitti ch$ LC_MESSAGES=C apt-cache depends linux-image-generic | sed -ne 's/^ Depends: linux-image-$[0-9]$/\1/p;' [07:59] 3.4.0-3-generic [07:59] yep thats the one [07:59] without the /me ch crap, of course [08:00] apw: oh, hang on -- we still need to build-depend on it, as we need to iterate over the modules [08:00] right [08:01] * apw is working on it :) [08:13] Is it possible for upstream to be the repository itself? [08:19] apw: how do you know if it's essential> apt-cache show sed | grep ^Essential [08:19] well, ^Essential: [08:19] cjwatson, awsome, thats what i wanted to know [08:20] with one extra caveat: awk is "virtual Essential" by way of a Pre-Depends from base-files (i.e. the Essential facility is having one of mawk or gawk installed, although neither specific one is Essential) [08:29] pitti, subprocess.Popen communicate is barfing on a utf8 character in modinfo output, know how to fix that off the top of your head ? [08:30] apw: oh, with python 3? [08:30] pitti, indeed using your script, was just testing my mod to take a directory for the modules, using the ones on my precise system [08:31] pitti, and there is: [08:31] author: Bj�rn Stenberg [08:31] in one of them, and it dies on it... [08:31] hm, I already specified universal_newlines=True, so it shoudl do the decoding itself [08:31] apw: UnicodeDecoreError, or Encode? [08:31] UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf6 in position 125: invalid start byte [08:31] the special 'o' there in the author: field [08:31] oh, so it's already trying UTF-8, not ascii [08:31] apw: try dropping universal_newlines=True [08:32] apw: and instead [08:32] out = modinfo.communicate()[0].decode('UTF-8', errors='ignore') [08:32] apw: that might be fixed in quantal's kernel? It ran flawlessly on 3.4.0-2 [08:33] that takes a lot longer [08:33] yeah it maybe that the modules don't have the name in the later kernel indeed [08:33] apw: which module is that? [08:33] will find out, but i wanted to zap the bug while i was seeing it [08:33] modinfo /lib/modules/3.2.0-23-generic/kernel/drivers/usb/storage/ums-isd200.ko [08:33] no, authors are still there [08:34] author: Björn Stenberg [08:34] but note that when you pasted it its an o" [08:34] your special 'o' was broken here (a diamond with a question mark) [08:34] and when i pasted it it was ... right [08:34] so i suspect its been corrected in the source to be valid [08:34] apw: heh, funny; exactly the other way roundhere [08:35] apw: when I do modinfo ums-isd200, I get an o with two dots on top, it looks correct [08:35] nnng [08:35] ahh no i was saying ... "right what you said" not it was "right" [08:36] and when i pasted it it was ... "what you said" [08:36] ok ... so i think the kernel source has the name fixed or something b [08:36] aah [08:36] confusion FTW [08:36] but its good to catch the errors case [08:36] right [08:36] thanks for spotting [08:36] * apw gets this cleaned up [08:37] we don't really need the author or anything being UTF-8anyway [08:39] apw: I expect the problem is that the output was in ISO-8859-1 [08:40] Yep, indeed [08:40] pitti, right ... we don't care on the encoding though i believe the kernel should be utf-8 so i am not supprised it got fixed [08:41] cjwatson, ahh that makes sense then, a common other form === dpm__ is now known as dpm [08:47] pitti, and we said it needs a python3 build-dep as well yes ? may as well fix that while i am here [08:47] apw: when we run the script during build, yes [08:48] pitti, of course, i am running it in the build now, *slap* [09:06] pitti, it is me or are a huge number of the firmware files saying they are unreferenced [09:06] apw: yes, here as well [09:06] ok ... then i didn't break it [09:06] apw: I guess b43 is still a bit special, the module doesn't declare firmware: [09:06] apw: but the various dvb bits are indeed obsolete [09:06] pitti, i shall add a WI to our config review to review it, tim can do it, he loves firmware :) [09:07] apw: http://paste.ubuntu.com/1002650/ is what I get on quantal [09:08] apw: we shoudl probably not print the message for b43, but the rest could be real === elleuca is now known as deborho === deborho is now known as deboroh [09:26] hi pitti, did you have a chance to look at the example on https://bugzilla.gnome.org/show_bug.cgi?id=676543 - sorry to keep asking, it's a major blocker for shipping localized apps in our app developer process, and I'm trying to see what we can do as the next steps. Alternatively, any other pygobject/gtk people you'd suggest me to talk to, so as not to keep bothering you? thanks! [09:26] Gnome bug 676543 in GtkBuilder "Cannot load translations from a locale dir other than the default" [Normal,Unconfirmed] [09:27] dpm: not yet, sorry [09:40] pitti, no worries. Any other gtk/pygobject people I could ask? [09:40] not sure if there is a #gtk channel on gimpnet [09:43] dpm, pitti: #gtk+ on irc.gnome.org [09:44] or #gnome-hackers is usually good for GNOME,GTK questions as well [09:44] thanks seb128 :) [10:41] pitti, i notice i failed to remove the pre-built file, i've dropped that in the top if the tree [10:41] pitti, you said that b43 doesn't have aliases, but i note in the built version it actually does: Modaliases: b43(bcma:m04BFid0812rev1Dcl ...) [10:41] apw: ah, you mean the .modalias file should be generated, and removed again after dh_modaliaes? [10:41] apw: it does have aliases -- I said (or at least meant) that b43 does not have firmware: links [10:42] pitti, you had made one by hand and checked it in, i removed that from the bzr branch [10:42] pitti, ahh ok makes sense [10:42] apw: right, that was necessary while it wasn't generated at build time; I guess it doesn't matter that much to keep it, but it's cleaner to remove now indeed [10:42] pitti, seems we got away with it in the builds cause it is older, but it is now gone for the next upload [10:45] pitti, i'll upload it with the cleanout of old firmwares [10:45] thanks! === MacSlow is now known as MacSlow|lunch [11:07] apw: hm, in your l-f-nonfree commit, it seems you forgot to actually rm the file? or committed this after building, and forgot to rm the file in debian/rules after dh_modaliases? [11:12] pitti, ihmmm [11:13] mvo: is there an apt config option to disable authentication checks? (for a test suite) [11:13] pitti, sorting [11:15] pitti: like APT::Get::AllowUnauthenticated? [11:16] geser: ah, thanks; I was looking in man apt.conf, and it's not there [11:16] ah, it's in man apt-get [11:16] mvo: unping, sorry [11:17] pitti: /usr/share/doc/apt/examples/configure-index.gz has all the available options listed [11:17] pitti: if using d-i (guess you are not?), d-i debian-installer/allow_unauthenticated boolean true [11:17] nope, regular apt [11:17] geser, Daviey: working fine, thanks! === yofel_ is now known as yofel [11:25] tseliot: do you see a reason why ubuntu-drivers-common should not be arch:all ? [11:27] pitti: there's a C program for hybrid graphics which shouldn't run on archs other than i386 and amd64 [12:16] tseliot: (sorry, was at lunch) ah, I see; but the package is already built on arm{el,hf}, too?} [12:17] is jockey supposed to use that in the future ? [12:18] (do i need to make any adjustments for armhf drivers ?) [12:18] ogra_: no, jockey is going to _be_ that in the future :) [12:18] ah [12:18] ogra_: in other words, we plan to drop jockey and replace it with something much simpler [12:18] well, ping me if arm changes are needed [12:18] :) [12:18] it was built for a lot more and different use cases that we are actually using it for === _salem is now known as salem_ [12:19] ogra_: I have a work item to see what to do with that pvr-omap4 handler that we currently have [12:20] ogra_: could you please check if "modinfo omapdrm_pvr" shows any modaliases? [12:20] ogra_: i. e. is that module loaded automatically, or do you need some special magic for it? [12:20] will do, i have no panda running atm, gimme a few [12:20] ogra_: no worries, not urgent [12:21] you dont look for the architecture ? [12:21] * ogra_ would have thought just using archdetect would be easier [12:21] I'm still working on the infrastructure bits, the special cases and migration come later [12:22] ogra_: just looking for the arch is not enough for e. g. the nvidia or the bcmwl driver [12:22] on arm you usually only have one driver for one SoC, its a bit easier than all these PCI and AGP cards on x86 [12:22] we need to check the system's modaliases against the patterns that the kmods specify [12:22] k [12:22] ogra_: so _if_ it has modaliases which match, it will just work if we fix the package to actually declare them [12:22] if not, we'll need a special case [12:22] but that shouldn't be hard to do [12:23] Can somebody nominate https://bugs.launchpad.net/ubuntu/+source/munin/+bug/598385 for Lucid? [12:23] Launchpad bug 598385 in munin (Ubuntu Oneiric) "[SRU] munin plugin exim_mailqueue has incorrect graph configuration" [Undecided,In progress] [12:23] tegra will be problematic here, it doesnt use any kernel modules [12:23] vibhav: done [12:24] pitti: thanks! [12:24] ogra_: I'll make sure we'll have replacements for all the existing handlers before we switch over [12:24] yeah, no hurry :) [12:25] tegra users are used to having to jump through hoops ... i'm happy with every release that makes it a bit easier but people usually can cope :) [12:31] what version of perl does oneiric and lucid use? [12:32] $ rmadison -s lucid,oneiric perl [12:32] perl | 5.10.1-8ubuntu2 | lucid | source, amd64, armel, i386, ia64, powerpc, sparc [12:32] perl | 5.12.4-4 | oneiric | source, amd64, armel, i386, powerpc [12:32] thanks pitti ! [12:33] vibhav: rmadison is in devscripts, FYI [12:33] I did not know that, thanks (again) [12:35] https://bugs.launchpad.net/ubuntu/+source/munin/+bug/598385/comments/12 says that he is too affected by the bug, But I noticed the bug only affected perl 5.14 , any ideas? [12:35] Launchpad bug 598385 in munin (Ubuntu Oneiric) "[SRU] munin plugin exim_mailqueue has incorrect graph configuration" [Undecided,In progress] [12:36] jamespage: ^^ [12:39] pitti: err.. is it? [12:40] tseliot, well, if it replaces jockey it surely should :) [12:40] tseliot: yes, because there is a pvr-omap4 handler [12:40] oh [12:40] tseliot: which needs the alternatives handling, I guess [12:41] right [12:41] tseliot: I didn't write that myself [12:41] so I can't tell much about it [12:41] there also will be a tegra handler soon [12:41] yes, I remember now [12:41] ogra_: please don't write a new one, though; the new system shoudl be ready by next week hopefully [12:41] and probably an omap3 one if we ever get armhf drivers from TI [12:42] pitti: let's just make sure that C app is not built and installed on anything other than amd64 and i386 then [12:42] but as long as installing a package will set up everything, we can integrate it [12:42] pitti, no worries, but i want all drivers supported by release [12:42] (all we have packages for in the archive) [12:42] ogra_: you can certainly start packaging those, but the logic needs to be/go into the postinsts, not external [12:42] tseliot: that can certainly be arranged [12:42] good [12:42] pitti, they are packaged since precise :) [12:43] tseliot: and then arch:any, I guess [12:43] ogra_: I mean, the jockey handler has an awful lot of extra code to juggle around alternatives symlinks, etc. [12:43] yep [12:43] this needs to go into the postinst (if it isn't already) [12:43] pitti, oh, indeed, i didnt plkan to touch that right now [12:55] What should be the ubuntu delta for an SRU which has a previous version from debian? [12:56] 5.0.15-2 in unstable; should it be 5.0.15-2ubuntu0.1 for an SRU? [12:57] yes, that will work fine [12:57] It must be less than the version in the development release [12:58] thanks [12:58] 5.0.15-2ubuntu0.1 in precise-proposed would be inappropriate if the same fix is in 5.0.15-2 in quantal [12:59] cjwatson: What it should be then? [12:59] vibhav: oh, I assumed when you said "unstable" you meant "that version was synced from Debian into whichever Ubuntu release you want to SRU TO" [13:00] vibhav: There is fairly comprehensive advice in https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging [13:00] pitti: Your right,I assumed that [13:00] You can follow the same convention for SRUs [13:01] (This is linked from https://wiki.ubuntu.com/StableReleaseUpdates#Procedure) [13:01] thanks [13:03] RAOF: For the KDE SRU tracking bug - we've done a single bug up to now in the previous updates. [13:11] openerp-server is removed from precise and quantal, would it be considered sane to fix bugs for openerp-server in oneiric and other supported releases? [13:17] If they are serious enough to meet the SRU criteria, although I'd suspect there'd be relatively few users of a package like that on non-LTS releases so it may not be the highest priority thing to tackle. [13:19] vibhav: please, no. [13:19] * xnox is OpenERP developer in previous live. [13:20] me and a few other people are in process of repackaging 6.1, 6.0 & 5.0 together with migration scripts. [13:20] anyone running 5.0 is doomed, and they know it =))) [13:20] seb128, I was thinking of writing a patch for sound-nua, but cjcurran has so many assorted branches of that, do you have any idea of what branch one should start with? [13:20] xnox: thanks! [13:21] vibhav: I would check if CVE affect it, e.g. the recent feedparser. [13:21] diwic, is that a patch for precise? [13:21] seb128, probably [13:21] diwic, https://code.launchpad.net/~cjcurran/+junk/soundnua-gtk-warnings [13:21] diwic, don't ask about the name, he just kept working on that vcs [13:21] seb128, all right, thanks [13:21] diwic, that what we currently have in precise [13:22] diwic, well rather we have that and r31 from lp:~diwic/+junk/soundnua-lp984637 [13:22] diwic, so just stack it on top of that branch of yours [13:23] seb128, okay, thanks [13:23] diwic, yw! [13:35] tseliot: ok, hybrid-detect now only gets built on x86 in my latest branch [13:35] tseliot: I'm quite satisfied for a first run with what's in the branch now [13:36] tseliot: but I'd like to see it tested at bit on an nvidia or fglrx machine before uploading; do you have some minutes for that? === MacSlow|lunch is now known as MacSlow [13:41] pitti: I have an nvidia machine here with hybrid graphics [13:43] tseliot: it doesn't handle the hybrid special case yet (I have a WI for this) [13:44] tseliot: I'm mainly interested whether "ubuntu-driver list" shows the nvidia cards [13:44] tseliot: and it now assumes that merely installing nvidia-current sets up all the alternatives, etc. [13:44] tseliot: i. e. no extra code any more that the handlers used to do [13:45] pitti: I thought you wanted to test hybrid-detect [13:45] tseliot: I didn't touch the source [13:45] tseliot: just setup.py to only build/install it on 86; I already tested taht [13:45] pitti: ok, feel free to send me whatever script you'd like me to test [13:46] tseliot: the main thing that I haven't tested yet is that jockey still detects and installs the nvidia drivers with all the nvidia-common -> u-d-common renaming and changed file paths [13:46] tseliot: i. e. check out https://github.com/martinpitt/ubuntu-drivers-common, build/install it, and test in jockey; plus ensure that "ubuntu-drivers list" shows the nvidia bits === andreas__ is now known as ahasenack [13:47] pitti: which jockey shall I test it with? The one in precise? [13:47] tseliot: that's fine, yes [13:48] Hmm, why is that on github and not launchpad? [13:48] pitti: ok, I'll test both cases [13:48] tseliot: note that if you run precise, then the test suite will fail, it needs some fixes in aptdaemon's test module [13:48] Daviey: do we have git hosting on launchpad? [13:48] tseliot: i think you know the answer to that. [13:48] Daviey: I branched from tseliot's nvidia-common git, which is there [13:48] Daviey: and that's your answer ;) [13:49] pitti: ok, I can probably use a quantal chroot and see if it works [13:49] tseliot: this is a ubuntu native codebase, right? Not forked from a project that uses git upstream? [13:50] Daviey: yes [13:50] it's a matter of taste [13:59] Could anybody nominate https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/924002 for oneiric?? [13:59] Launchpad bug 924002 in autofs5 (Ubuntu) "build system strips binaries, so no debug symbol packages available" [Medium,Fix released] [14:01] tseliot: back in 45 mins or so, have to run for some errands [14:01] ok === bregma_ is now known as bregma === dendro-afk is now known as dendrobates === deryck is now known as deryck[afk] [14:40] sorry, I know this has been mentioned before, but is there something I can do on quantal to fix the following: [14:40] /gnulib/tests/test-stdalign.c:72:1: error: static assertion failed: "verify (alignof (int64_t) == offsetof (int64_t_helper, slot2))" [14:41] (from a libvirt build failure in buildds) [14:41] I thought there was a fix going in... === debfx_ is now known as debfx [14:59] tseliot: re === emma is now known as em [15:13] pitti: ping [15:13] vibhav: pong [15:13] pitti: Could you check if https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/924002 can be nominated for oneiric? [15:13] Launchpad bug 924002 in autofs5 (Ubuntu) "build system strips binaries, so no debug symbol packages available" [Medium,Fix released] [15:14] vibhav: done [15:17] pitti: Could you also check the debdiff I attached? [15:17] not right now, sorry; can you please just subscribe sponsors? [15:18] They are already suscribed [15:18] Since the bug was fixed in precise [15:27] anyone know if a rebuild of libc for armhf is planned? /win 29 [15:28] it failed to build 3 weeks ago so nothing is multi-arch co-installable: https://launchpad.net/ubuntu/+source/eglibc/2.15-0ubuntu11/+build/3458753 [15:31] SpamapS: you read the comments on the remmina bug? :) [15:32] wookey_: Isn't it awaiting a compiler fix (infinity was working on that, I think), not simply another build attempt? [15:32] wookey_: Unless you've just checked that a rebuild attempt would succeed, that is :) [15:32] cjwatson: looking at the log - it does look like something actually needs fixing, yes [15:33] does x86 libc migrate even if armhf didn't build? [15:33] dupondje: not yet, just woke up [15:34] wookey_: We have no migration as yet [15:34] wookey_: So, er, yes and no? :-) [15:34] right. [15:35] I guess this is what happens in 'latest'. [15:35] SpamapS: np, first grab your breakfast :) [15:35] wookey_: I'm hoping we'll get a roughly sort of testing-like migration thing in place soonish [15:36] I guess armel built, so I'll go back to crossing that for now, so as to get some useful output [15:40] Makes sense [15:41] I see the apt [] resolution bug got fixed in Debian [15:41] infinity: ^^ how goes it with giving us back libc on armhf? Was the plan still to disable the biarch from that side? [15:41] cjwatson: it did? sweet [15:41] yep - on monday [15:41] I got some cross-build stats on unstable yesterday - 'not great' :-) [15:42] http://people.linaro.org/~wookey/buildd/unstable/sbuild-ma/status.html [15:42] needs either a lot of M-A: foreign fixes or the apt fix to make it default that way for arch:all [15:42] wookey_: Do you know what's happening with :any support on Debian buildds? [15:43] in a word, no [15:43] wookey_: We've tried to push some gettext:any patches to Debian, but they've bounced because Debian's buildd configuration means that fails to build everywhere [15:43] cjwatson: :any == I took an action to follow up on that [15:43] Significant progress in unstable is going to be contingent on getting that fixed [15:43] slangasek: right [15:43] of course then my irc server rebooted and I lost the record of what I'd agreed to because I don't log that client [15:43] but I have a general idea still :P [15:43] slangasek: The plan for right now is just to flip libc-armel (on armhf) back to v7. [15:44] cjwatson, slangasek: can you poke someone to import the new cifs-utils as the currently imported one does not work at all [15:44] from Debian that is [15:44] luk_work: A package sync you mean? [15:44] right [15:44] luk_work: looking [15:44] slangasek, a utouch-geis sru was uploaded after the archive branch but before quantal was open, it needs to be copied over to quantal [15:44] (i.e., :any support needs backported for DSA) [15:44] how do I make that happen? [15:44] wookey_: Sorry about that, I didn't think that it would be an issue for your M-A work, I'll upload a fix today. === dendrobates is now known as dendro-afk [15:45] cjwatson: apparently it's a merge [15:45] Yeah, was just looking at that [15:45] any opinoin on whether I should file a lot of M-A: foreign fixes or try and get the apt behaviour change in? [15:45] Daviey: ^^ you merged the critically-broken version of cifs-utils, can you merge the fixed one? ;) [15:45] would solve #903888 and #1001680 [15:45] #666772 [15:46] wookey_: ultimately both, but we should get the apt behaviour change done I think since it makes things a lot more practical ... === deryck[afk] is now known as deryck [15:46] dobey: could you review https://code.launchpad.net/~brian-murray/lptools/grab-descriptions/+merge/106469 [15:46] slangasek: why is it we have a +1 team again? :) [15:46] Daviey: not to clean up after the server team :P [15:46] Daviey: the +1 team doesn't have a charter to do all the work themselves [15:47] cjwatson / slangasek: right, but it's a QRF to solve issues like this? no? [15:47] Anyway, yes.. i'll take it.. but i can't do it /right now/. [15:47] Daviey: The +1 team's biggest job is to annoy other people to fix their bugs. [15:48] * Daviey pretends he is annoyed. [15:48] pitti: yes? [15:48] tseliot: just said "I'm back" back then, in case you wanted to discuss some stuff [15:48] Daviey: the +1 team's main charter is to give us a consistent archive. cifs-utils doesn't break the archive, just itself [15:49] pitti: ah, ok, sorry too many pings at the same time ;) [15:49] actually, http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html had beer for most of the day :) [15:49] slangasek: don't try and use logic to combat my slippery shoulders. [15:49] :) [15:49] the ti-omap4 breakage is very very recent [15:50] slangasek / cjwatson: For the avoidance of doubt, i wasn't being serious. [15:50] :) [15:53] pitti: Yeah, the kernel team likes to drop building tools every second release. :P [15:58] * pitti waves good night, time for sport [15:59] slangasek: hey! we (the Software Center team) have an SRU 5.2.2 that's in process, as you know, but we have unfortunately discovered a regression in one of the fixes (bug #1002271) [15:59] Launchpad bug 1002271 in software-center (Ubuntu) "REGRESSION: crash in cell renderer" [Medium,In progress] https://launchpad.net/bugs/1002271 [16:00] slangasek: and another of the fixes was inadvertently disabled in the release, so three bugs can't be strictly verified [16:01] slangasek: so we are wondering if the best approach is to release 5.2.3 now, which we have in the queue and is ready to go, or should we cherry pick the specific fixes for a 5.2.2.1 release? to me, it seems the former is best as either case will reset the clock, no? [16:03] tremolux: I think the latter is far preferable... otherwise we can be on that verification treadmill indefinitely [16:04] slangasek: but, doesn't the clock reset in either case? the former will just add a few more to the already large number that we have to deal with anyway ;) [16:05] slangasek: unless a cherry-pick can shorten the 1-week hold time, I don't see it buying us too much, but maybe I don't know all the gritty details [16:06] is everything in 5.2.3 an SRU-worthy bugfix? [16:06] from my POV, the number of bugs in the previous upload is already on the far end of what the SRU process can effectively handle [16:09] slangasek: yes, I think we are fixing all worthy bugs, many or from errors.ubuntu.com [16:09] slangasek: is the issue the sheer number of bugs for each release? [16:09] tremolux: yes [16:10] slangasek: we are trying, as a team, to take a policy of releasing all bug fixes that don't break UI/strings/etc. back to Precise [16:10] right - but we need to have discrete points where we can validate one batch and push it through to -updates [16:10] slangasek: and we want to continue this for the next couple of weeks [16:10]