[00:51] ockham_: I think I would have to see the source package to work it out [00:51] cjwatson: it's in the debian games git repo [00:51] i've pushed it recently [00:52] git://git.debian.org/git/pkg-games/pysolfc.git [01:00] can you give me a URL for the upstream tarball? [01:07] ockham_: ^- [01:07] cjwatson: http://sourceforge.net/projects/pysolfc/files/PySolFC/PySolFC-2.0/ [01:14] hrm... sphinxsearch from debian unstable looks broken on arm. [01:17] ugh between multiarch and --as-needed fixes I'm becoming an autoconf expert. :-P [01:17] excellent [01:17] ockham_: (working on it) [01:18] cjwatson: great, thx! [01:18] SpamapS: you should never admit to that publicly [01:21] broder: it was a weak moment [01:22] ockham_: oh, I see - your debian/control stanza for pysol has Section in between the short description and the extended description, and this thoroughly confuses everything [01:22] ockham_: move that Section line up a line or two [01:23] cjwatson: wow, i really didn't figure it was the order of those attributes... [01:24] it's not about ordering, it's that you have a multi-line Section field :-) [01:25] Section can come after Description (though that would be unconventional), but if you put it in the *middle* of Description, what you get is "Section: oldlibs\n Package to ease upgrading from ..." [01:25] and that is very much not good [01:26] cjwatson: oh damnit. i just cut and pasted it, but i really had not noticed it had been *there* [01:26] time to blush [01:26] anyway, i'm trying to build it now [01:26] sry to bother you with something so trivial... [01:27] oh the irony, http://sphinxsearch.com/bugs/my_view_page.php has no search field. [01:28] cjwatson: build successful. yay! [01:29] cool [01:34] cjwatson: uploading to mentors now. feel like reviewing (or even sponsoring) it? [01:35] * SpamapS submits his 20th bug report to debian related to the libmysqlclient transition [01:35] um, probably not sorry, it's a bit too late at night for me to try to exercise critical faculties, and I have a fairly busy week ahead with alpha-1 coming up [01:38] cjwatson: ok, thx anyway. maybe another time [01:38] ... [01:46] SpamapS: use MariaDB ;) === Guest30432 is now known as JackyAlcine === Guest28630 is now known as shirgall === shirgall is now known as Guest34864 === rsalveti` is now known as rsalveti [05:19] so if i want to attack the remaining ia32-libs problems, i should try to install ia32-libs-multiarch, pick a package that's not available, and go to town, right? [05:21] well, that package or its reverse dependencies if it has any [05:22] broder: gstreamer is an excellent candidate :) [05:23] ...that sounds like entrapment [05:24] but i'll at least download the source and look at how bad it is [05:24] Moderately bad. [05:25] You inherit a library and a bunch of architecture-dependent plugins to that library. [05:25] So you get to play transition time! [05:25] yeah, that's what i would have figured [05:26] why would i play transition time instead of check-a-list-of-paths time? [05:26] Well… because you wanted to make gstreamer uninstallable for a while? [05:27] lol [05:31] as much as that sounds like a fun game, i'll at least *start* by trying to check a list of paths [05:40] mneptok: I doubt maria will solve these problems, unless it magically convinces m4 scripts that files in /usr/lib/x86_64-gcc-linux are actually in /usr/lib [05:42] m4 scripts shouldn't hard code paths [06:00] Good morning [06:02] micahg: exactly. its ridiculous [06:04] micahg: to be fair, about half of the libmysqlclient using packages (50 or so of the 111) do it right by simply using AC_LINK_IFELSE [06:17] RAOF: nope, i give up. too much work to start at 10 pm :) [07:10] how to find out why a package upload got rejected? [07:10] tjaalton: the email doesn't say? that's the usual way [07:11] pitti: no, can't see any comments there [07:12] was it a -proposed stable upload? rejections from the +queue page don't have comments [07:12] the reason for those should be noted in the corresponding SRU bug by the SRU team [07:13] or if it was a source NEW upload, you should get mail from teh archive admins [07:13] what kind of upload was that/ [07:13] ? [07:15] it was n-m for oneiric-proposed, and i have a hunch why it got rejected [07:16] sponsored the upload, and it wasn't pushed to bzr [07:16] and the changelog entry didn't have LP: #xxxxxx [07:19] tjaalton: oneiric-proposed would of been higher version than precise too [07:20] oh that too [07:20] hmm [07:20] meh :) [07:21] well, that's not a cause for a reject, unless it was versioned wrong [07:21] it got -Xubuntu5.1 [07:21] so, that wouldn't be a reason for reject, just a reason not to move to -updates [07:22] but not closing the bug would be :) [07:24] tjaalton: Right. I rejected that, and sent an email to the dude in the changelog. No LP reference :) [07:25] RAOF: ha! so I get to fix that too :) [07:26] Hm. Maybe I should have checked the changes file; I think that should have listed you as the uploader somewhere. [07:27] not the changes file [07:28] no, the uploader is only visible as the GPG signer of the .changes file [07:28] the +queue page doesn't show it anywhere [07:28] gpg --verify -> "you don't have the key for foo" -> gpg --recv-keys foo [07:29] I forget. Can you get the signed changes file out of the queue? [07:29] how confusing.. n-m versions have bumped the "major" ubuntu version in -proposed [07:30] so -0ubuntu{4,5} [07:30] people aren't careful right after release which IMHO should be warned about more strongly [07:32] but IANA release or SRU team member [07:32] i've now done the same change as 0ubuntu6 for precise [07:32] s/release/archive/ [07:39] RAOF: I've reuploaded it, precise too this time (0u6) [08:01] good morning [09:00] pitti: can you copy something quickly for me? thunderbird 8.0+build1-0ubuntu0.11.10.1 from ubuntu-mozilla-security to oneiric-security? [09:03] darn, missed the publisher, copy-package takes really long :( [09:03] micahg: done now, but I figure it was a few seconds too late :( [09:04] ugh, ok, I thought it would be close, should be ok though, the newer extensions have a build-dep on the newer thunderbird, so update-manager won't offer them until thunderbird gets in [09:04] oops, I meant binary-dep :) [09:04] pitti: thanks [09:07] pitti: BTW, copy-packages being slow is why I have to keep asking you :) [09:07] micahg: ah, because lplib scripts time out, too? [09:08] yeah [09:08] we have that problem all the time with SRUs [09:08] it's a problem when there are too many binaries for me [09:24] apw, smb: can we have a current l-b-m and l-meta for 3.2.0-2? [09:24] so that alpha-1 will actually test -2, and we get rid of the remaining NBS? [09:26] pitti, We will have a look. I thought ogasawara or apw did mention something there... [09:26] smb: danke! [09:26] pitti, bitte! :) [09:27] pitti, smb, sorry yes, will do that now [09:28] apw: great, thanks! [09:28] pitti: apparently we caught the publisher in time :) [09:28] micahg: ah, nice [09:30] apw, Will you also push/create the initial precise-lbm tree on zinc? [09:41] apw: Oh hey. [09:41] apw: While you're fiddling with kernel packaging, can I get you to fix armhf for me? ;) [09:41] infinity, whats wrong? [09:42] flock -w 60 /home/adconrad/linux-3.2.0/debian/.LOCK dh_gencontrol -plinux-image-3.2.0-2-omap [09:42] dpkg-gencontrol: error: current host architecture 'armhf' does not appear in package's architecture list (armel) [09:42] apw: You missed giving us a kernel on control. [09:42] s/on/in/ [09:42] apw: Not that I care deeply about the kernel itself anyway, but I need the build to complete for linux-libc-dev to get spit out the other end. ;) [09:43] infinity, ok will have a look see after meta [09:43] apw: Danke. [09:43] hard to test as i have no chroot to test it in will you get it working (circlular dependancy erro) [09:43] apw: Do you have arm kit locally? I can give you a chroot with all the kernel build-deps installed. === doko_ is now known as doko [09:46] apw: I'm just tidying up some last-minute gotchas in the eglibc packaging, but we're basically ready to go except for linux-libc-dev. I can (and likely will, if I have to) open using the hacked up linux-libc-dev I have here, but I'd rather use the Ubuntu saucy one. [09:46] infinity, nope no kit either, we should have the chroot on the porter really [09:47] apw: It got all the way to the above, though, so I imagine it just needs s/armel/armel armhf/ across the various control shippets, and life's happy. [09:47] i can probabally figure it out without one, as it should clean at least [09:47] which generates control [09:47] let me get pitti happy and i'll poke it [09:47] infinity, could you zap me the whole build log into pastebin [09:47] apw: There will be chroots on scheat reasonably soon, I imagine, but I suspect people are wary of basing them on my 1st/2nd-stage bootstrap. [09:47] apw: If I had logged it, sure. :P [09:47] apw: (Yeah, I know...) [09:49] apw: My backscroll goes back to debian/rules binary-arch, which is probably all that's interesting. Let me grab that. [09:49] pitti, ok linux-meta in the pipe. there is no lbm at this early stage, if you have NBS on linux-backports-modules-2.6.35, those die with oneiric and can be culled [09:50] pitti, i probabally don't mean 2.6.35, which version are they [09:50] apw: http://paste.ubuntu.com/752311/ [09:51] apw: I can remove linux-backports-modules-3.0.0 in its entirety if that's appropriate, yes [09:51] pitti, yean 3.0 is oneiric's one so that is not needed in precise [09:52] it will get replaced by a 3.2.0 in time [09:52] apw: ok, done [09:52] pitti, thanks [09:53] apw: ah, tanks for the -meta upload, that should clear up http://people.canonical.com/~ubuntu-archive/nbs.html quite a bit [10:00] apw: Is that paste sufficient for your needs? [10:01] infinity, /me looks [10:05] infinity, yeah think that i've got it, if i pastebin you a patch can you test it for me [10:06] apw: Yep, turnaround's going to suck, you're conteding with 3 GCC builds and an eglibc build. ;) [10:06] apw: But I'll definitely test it here, so I have a proper linux-libc-dev in my 2nd-stage repository for tomorrow. [10:07] infinity, will just double check it [10:08] infinity, http://paste.ubuntu.com/752319/ [10:08] seems to put armhf everywhere armel is, so ... that should be right [10:08] apw: Big patch. [10:09] infinity, heh indeed. if you are only making linux-libc-dev could you not use the shortcut STAGE thing that linaro added [10:10] apw: I didn't know there was such a thing. :P [10:10] infinity, i belive if you build with DEB_STAGE=stage1 you only get bootstrap packages [10:10] apw: Oh, shiny. [10:10] (you also get a couple of useless ones which are empty) [10:10] apw: Maybe I should do that, then do a test of your patch for you. [10:11] infinity, sounds appropriate [10:11] Though, I have to nap anyway. [10:11] Testing your patch should finish before I wake up. [10:11] I'll just do that. [10:11] heh ok [10:13] infinity, ok i've pushed that fix to our repos anyhow, its got to be better than whats there [10:13] apw: I suspect it'll do the trick. === smb` is now known as smb [10:20] infinity, yeah pretty sure it will. the DEB_STAGE stuff if your friend though, its definatly for this specific purpose === Guest51058 is now known as Laney === zyga is now known as zyga-brb === _salem is now known as salem_ === zyga-brb is now known as zyga [11:27] soren: are you planning to update user-mode-linux to 3.2.0? looks like you did the last update [11:57] cjwatson: It wasn't on my radar, but I certainly can. [11:57] thanks [11:58] cjwatson: Hm... Where did you spot this? [12:00] cjwatson: Oh, processing NBS? [12:08] when does patch pilot start? [12:09] om26er_, whenever they feel like starting, there is no fixed time [12:09] om26er_: depends on when today's pilot starts work. [12:10] ok, i'll wait then. [12:10] om26er_: Is there something specific you were looking for piloty help with? [12:11] infinity, just wanted to get two SRUs uploaded, it could wait a bit ;-) [12:12] Mmkay. If you're cool with waiting, I'll go have breakfast instead of being helpful. ;) [12:15] Riddell: can you have a look at quantum again please? thanks [12:15] soren: NBS, yes [12:17] infinity, oops, totally missed the message, does the offer still stand? https://code.launchpad.net/~om26er/ubuntu/oneiric/indicator-sound/fix-864405/+merge/83589 [12:17] ;-) [12:17] and also https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz-plugins-main/fix-sru-regressions-2/+merge/83590 [12:20] om26er, the compiz one, there is a packaging vcs you should use this one [12:20] I wonder if we should rename the kernel source binary package to linux-source-3.2 (rather than linux-source-3.2.0). [12:21] om26er, the packaging vcs has a fix commited for the grid keybinding issues which didn't get uploaded yet and should probably go in the same upload [12:22] seb128, https://code.launchpad.net/~compiz/compcomm-plugins-main/ubuntu ? [12:22] om26er, same issue with the indicator-sound sru, those issues should also be fixed in precise before sru-ed [12:22] om26er, yes [12:23] seb128, okay, I will get indicator-sound uplaoded to precise first and then SRU [12:23] seb128, about compiz plugins, does that also need to be uploaded to precise first? [12:23] yes, any SRU requires to be uploaded to the current serie first [12:24] there is a different fix for precise with test cases.. for bug 891886 [12:24] Launchpad bug 891886 in compiz-plugins-main (Ubuntu) "Compiz grid plugin is fired when resizing a window" [High,In progress] https://launchpad.net/bugs/891886 [12:25] om26er, ok, well the fix needs to be uploaded in precise first then you can get a SRU [12:26] seb128, so for precise the i pull the branch with test cases and get it uploaded, then for oneiric the simpler version of the branch? [12:27] om26er, correct, the goal is to ensure that the bugs are fixed in the current serie as well [12:28] om26er, you can probably ping kenvandine directly for the indicator sponsor and see if didrocks is interested in sponsoring the compiz one or if he prefers you to go through patch pilot sponsoring rather [12:28] didrocks, ^ not sure if you want to deal with the compiz uploads or are happy to let them through the sponsoring workflow [12:29] seb128: this can go to the sponsoring workflow (if it's not upstream, we should ensure that smspillaz reviewed it and that there is a test due to the new req.) [12:33] sam reviewed fix for bug 891886 and approved it, the thing is he took the branch from the contributor and added test cases, what I am wondering is does it need to go with test cases to oneiric or would be fine without test cases, [12:33] Launchpad bug 891886 in compiz-plugins-main (Ubuntu) "Compiz grid plugin is fired when resizing a window" [High,In progress] https://launchpad.net/bugs/891886 [12:38] om26er: would be fine without the test case if the test case is running in precise [12:39] didrocks, okay thx [12:41] yw :) === MacSlow is now known as MacSlow|lunch === yofel_ is now known as yofel === Ursinha` is now known as Ursinha === Ursinha is now known as Guest68920 === Guest34864 is now known as shirgall === Guest68920 is now known as Ursula === Ursula is now known as release === release is now known as Ursula === Ursula is now known as Ursinha [13:43] anyone else hitting bug 897230 [13:43] Launchpad bug 897230 in qt4-x11 (Ubuntu) "libqt4-networkupgrade fails" [Undecided,New] https://launchpad.net/bugs/897230 [13:49] smoser: yes, you want bug 893826 [13:49] Launchpad bug 893826 in pkgbinarymangler (Ubuntu Precise) "symlinked docs are different between architectures, depending on dpkg-deb package order" [Medium,Triaged] https://launchpad.net/bugs/893826 [13:49] tumbleweed, mark that as a dupe? [13:50] your one is a dup [13:55] hum, nss was forked for ubuntu four years ago.. does anyone know why? [13:56] (no merges since Sun, 16 Dec 2007) [13:57] tjaalton: Probably because we forked all the mozilla.org components back then. [13:58] tjaalton: Though I can think of no particular argument to have nss or nspr forked. [13:59] infinity: ok.. just wondering if we or debian are going to get the systemwide nssdb stuff packaged anytime soon.. [14:00] tjaalton: No idea. But merging with Debian and then working with them might not be an awful plan. [14:01] infinity: yeah, I'll ask mike what he feels about it. there are some bugreports that seem related [14:03] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | 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: stgraber [14:13] infinity: merges.ubuntu.com has a comment for nss: "do not merge".. [14:15] SpamapS: FYI, committing your qt4-x11 upload to its bzr (Vcs-Bzr) [14:16] tjaalton: Yes, I imagine nss and nspr are both blacklisted since they were forked, but it's worth re-examining that. [14:17] tjaalton: Perhaps talk to asac about the rationale at the time. [14:17] infinity: yeah, I will [14:21] infinity, cjwatson: I'm pondering what to do for bug 893826, do you have a minute to discuss this? [14:21] Launchpad bug 893826 in qt4-x11 (Ubuntu Precise) "symlinked docs are different between architectures, depending on dpkg-deb package order" [High,In progress] https://launchpad.net/bugs/893826 [14:21] pitti: Sure. [14:21] pitti: My knee-jerk reaction is "stop doing that", but I suspect that's not an option? ;) [14:22] infinity, cjwatson: tl;dr: if a package uses dh --parallel, dh_builddeb also gets called with --parallel, which effectively ruins the predictable order that dh_builddeb gives us [14:22] sounds like an evil upstream :P [14:22] so aside from "drop doc symlinking altogether" (which doesn't sound very appealing as it will increase our CDs by some 12 MB), the other option that I see is to never run dpkg-deb in parallel [14:23] How do you propose stopping people from doing so? [14:23] so we could eitehr modify debhelper to not respect the --parallel option for dh_builddeb only, or have pkgbinarymangler divert dh_builddeb to filter out the option [14:23] Doc symlinking still sort of scares me anyway. [14:23] the former is trivial, but introduces another permanent delta into debhelepr [14:24] infinity: agreed that it's scary in a way [14:24] Not just "in a way". [14:24] yeah, I'd prefer a diversion for that given that it's much more closely related to pkgbinarymangler than to debhelper really [14:24] It's downright scary. [14:24] The way dpkg deals with links versus targets is curiously fun. [14:24] infinity: only for directories [14:24] infinity: pkgbinarymangler doesn't symlink directories for that very reason [14:24] Ahh, and you only link individual files? [14:24] Fair enough. [14:24] infinity: quite a lot of packages did that manually in the past, before we had that [14:24] and it was a mess [14:25] infinity: yes [14:25] And I assume only between arch:any packages, etc, etc. [14:25] Anyhow. Whatever. I suspect it's here to stay. [14:25] infinity: yes [14:25] infinity: we don't link any -> all to avoid skew between i386 and other arch builds [14:25] But you're also going to not actually solve your problem by mangling dh --parallel. [14:26] There are other ways to run dpkg --build in parallel. [14:26] infinity: not dh --parallel, just dh_builddeb --parallel [14:26] infinity: right, but then the pacakge needs to explicitly do that [14:26] infinity: I suspect I can count the number of packages doing that on the fingers of one head, though [14:26] There are packages that explicitly do that. :P [14:26] Wow. You strange finger-headed person. [14:26] but fixing these individually is a doable task [14:27] (not calling dpkg raw, but calling dh_builddeb without --parallel while still being, well, parallel) [14:27] I would like to avoid having to change qt4-x11 and friends to DTRT here and be aware of pkgbinarymangler, that sounds wrong [14:27] Given that --parallel happened after DEB_BUILD_OPTIONS=parallel, the latter has home-brew hacks all over. [14:28] But. Maybe those cases don't matter as much. [14:28] Given that the first that springs to mind is the kernel. [14:28] Which won't hit the multiarch bug anyway. :P [14:28] yeah, multiarch isn't much of a problem there [14:28] (gcc is another, and it can) [14:28] the other scary alternative is to modify the diverted dpkg-deb to background itself and queue until they know which order to run in [14:28] But I don't think gcc runs binary-arch in paralle. [14:28] l === MacSlow|lunch is now known as MacSlow [14:28] but I suspect that's too terrifying to live [14:29] cjwatson: that actually crossed my mind, but it seems very easy to get wrong [14:29] cjwatson: I think I just threw up a little. But I kinda like it. [14:29] cjwatson: dpkg-deb triggers. [14:29] WCPGW [14:29] so I think pkgbinarymangler diverting dh_builddeb and filtering DH_OPTIONS/--parallel etc. still seems reasonably safe and confines changes to pkgbinarymangler itself [14:29] dpkg-deb queueing has a certain appeal but I think it's probably too fragile [14:29] still a bit "ugh" due to the diversion, that's why I wanted to consult you [14:30] least of three evils [14:30] it can't possibly be scarier than diverting dpkg-deb, which pkgbinarymangler already does [14:30] this is probably just me showing off that I don't know anything about packaging, but as I understand the problem is that some file or symlink ends up in different packages on different builds (due to some kind of race). Wouldn't you explicitly specify what files and symlinks belong to which package? [14:30] pitti: Can you confirm that said hack actually DTRT? [14:31] diwic: no, this is a special mangling operation that we do on the buildds outside of packaging [14:31] cjwatson: Of course, since we already divert dpkg-deb (you're welcome for that insanity), we can totally add triggers. [14:31] infinity: I'll start writing tests around that, etc. now, but it's what I finally figured out as the root cause [14:31] cjwatson, ok, thanks [14:31] pitti: I'm rather unfamiliar with how dh --parallel works, but it still just calls each helper once? [14:31] diwic: pkgstriptranslations walks the dependencies and symlinks an identical file in /usr/share/doc// to the version in its Depends: [14:32] pitti: And then lets them fork? [14:32] diwic: e.g. so that we can do certain hacks without having to modify everything [14:32] diwic: but that fails if the order of processed packages differs on different arches [14:32] phone, brb [14:34] * infinity notes that dh(1) is remarkably unhelpful about what --parallel actually does. [14:43] so this is only a problem on source packages that build two binary packages that would be dependent on each other. [14:43] pitti: Okay, yeah, after looking at how --parallel works, diverting dh_builddeb to filter the option seems like the least objectionable idea. [14:44] diwic: Yeah. [14:44] in which case one can wonder why they are two separate packages in the first place, but I guess that's a completely different topic... [14:45] there are sometimes good reasons for circular deps [14:45] It's not always circular... [14:45] liba and a-bin both depend on a-common, for instance. [14:45] So docs from the first two can be links to the third. [14:53] hallyn: bug 897254 - I'd rather not accept qemu-kvm through binary NEW until that's fixed [14:53] Launchpad bug 897254 in qemu-kvm (Ubuntu) "qemu-utils missing Breaks/Replaces on qemu-kvm" [Critical,New] https://launchpad.net/bugs/897254 [14:54] in fact, I'm rejecting it from binary NEW (though that's unusual) to prevent it breaking upgrades for everyone who has it installed [14:54] cjwatson: checking [14:55] re, sorry [14:56] infinity: yes, I looked in dh_builddeb [14:56] cjwatson, ok, thanks [14:56] infinity: it spawns dpkg-deb processes until the limit, and then picks them up [14:56] cjwatson: does rejecting as you're doing mean i can re-use the version # by chance? [14:56] infinity: so if the limit is 1, it's completely serial [14:56] hallyn: no, the source is already in the archive, so you'll need to bump [14:56] infinity: and the input list is ordered according to the order in control, I checked that [14:56] cjwatson: ok, was pretty sure, just checking, thanks. [14:57] (unfortunately, one consequence of source-only uploads is that we don't get to catch this kind of thing until after builds have happened) [14:57] darn you smoser :) [14:57] diwic: it's not just circular depends [14:57] (this is why Debian's planned approach of source+throwaway-binary uploads is probably technically better even though it feels odd) [14:57] diwic: in this case, it's qt4-something depends: libqt-foo1, libqt-bar1 [14:58] diwic: and depending on which order it processes the binaries, the qt4-something symlink goes into libqt-foo1 or libqt-bar1 [14:58] infinity, cjwatson: thanks for the feedback, I'll go with that then [14:59] pitti, hmm, I think this is the case where I understand that than I thought I understood, the more is explained to me :-) [14:59] cjwatson: stupid question, in the Replaces/Breaks, now do i use the version # that just failed? or the one before it? [14:59] hallyn: sorry for the delay in reviewing this in the queue [14:59] hallyn: the versions I gave in the bug report should be correct - it's best to do << the first version that had it in the new location (whether that got built successfully or not) [15:00] pitti, where I understand that I understand less than I thought I understood [15:00] or something [15:00] heh [15:00] hallyn: that accounts for people who might have built it locally, say, although that's probably theoretical in this case, but still [15:00] cjwatson: great, thanks [15:04] cjwatson: and how bogus is it to add the other bug# into this commit msg? [15:05] hallyn: not especially but I think if it were me I'd just close it by hand with the text of the previous changelog entry [15:05] ok, will do, thx [15:06] or I suppose you could add the bug# and then use debuild -S -v0.15.0+noroms-0ubuntu2 [15:06] which would have the effect of closing the bug with the text of both changelog entries (check the .changes file before uploading to confirm this) [15:06] i *think* i see what you mean, but i think i'll do it byhand right now :) [15:25] Hey everyone! I need to report a couple upstream bugs on the kernel, but bugzilla.kernel.org is still down :-/ what's a good place to file bugs in the meanwhile? LKML? or the per-subsystem mailing lists? what are other people doing about this? [15:31] pitti: ty, I have been ignoring Vcs- tasks up until now. :-P [15:31] hi all, I'm trying to follow the packaging guide and pbuilder isn't working for me: http://pastebin.com/0Rzk8PCt [15:32] something about an invalid release file... I'm sure I just missed something though. [15:32] awsoonn: where did archive.canonical.com come from? that should be archive.ubuntu.com === tkamppeter_ is now known as tkamppeter [15:33] cjwatson: from as far as I can tell, the default /etc/pbuilderrc file [15:33] I'll change it and see if that gets me anywhere. :) [15:34] Which virtualization software are you using? I use qemu-kvm and virtual machine manager on Oneiric abd the Ctrl key does not work for the guests. [15:34] Jup, That did the trick. Thank you cjwatson [15:35] awsoonn: are you sure it was the default, rather than something in the guide you followed? I'd be really very surprised if it were the default [15:35] archive.canonical.com only has the partner repository on it, not any of Ubuntu itself [15:36] cjwatson: /var/lib/dpkg/info/pbuilder.config tries to cleverly construct pbuilderrc based on your sources.list (mine lists my local mirror, and I know I've never configured pbuilder, cause I don't even use it). [15:36] oh ouch [15:37] so the problem is that awsoonn's system has archive.c.c first in sources.list (which isn't the default, but still) [15:38] * infinity nods. [15:38] https://bugs.launchpad.net/ubuntu/+source/pbuilder/+bug/621169 [15:38] Launchpad bug 621169 in pbuilder (Ubuntu) "Incorrect mirror in /etc/pbuilder/pbuilderrc" [Medium,Confirmed] [15:52] ping kenvandine, re: bug #874501 - right now we are blocked on completely unrelated bug. Can we omit it from current SRU and add this later on? [15:52] Launchpad bug 874501 in gnome-keyring (Ubuntu Oneiric) "couldn't prepare to write out keyring" [High,Confirmed] https://launchpad.net/bugs/874501 [15:53] pitti, can you look at bug 874501 [15:53] Launchpad bug 874501 in gnome-keyring (Ubuntu Oneiric) "couldn't prepare to write out keyring" [High,Confirmed] https://launchpad.net/bugs/874501 [15:55] kenvandine, the patch for multiple entries may come in later, if we find out some apps are breaking this way (which i highly doubdt, since usually apps drop/re-create entries) [15:56] rye, lets get another response from someone on the SRU team [15:58] kenvandine: right, I wasn't sure about the ordering behaviour change, that sounds like a potential regression which is utterly hard to detect [15:58] kenvandine: so perhaps we can backport that one patch [15:58] pitti, yeah... but i think it is more likely to fix some hard to reproduce bugs... [15:58] i can revert that one [15:59] I see how it is beneficial [15:59] but _if_ a user is in that situation of having multiple keys, and the older one happens to be the correct one, then it'll regress for him [15:59] i just think it is more likely to help than hurt [15:59] certainly [15:59] pitti: i think regression potential is low; it's certainly not reintroducing any old/broken behavior [15:59] but "fixes bugs for more people than it regresses for" is not an acceptable SRU criterion [16:00] pitti, ok, i'll revert that [16:00] kenvandine: the other bits looked fine indeed [16:00] thanks! [16:00] afaik, you would have to explicitly write broken code, for that case to even happen [16:00] pitti, thanks for weighing in :) [16:01] dobey: right; but the fix applies to those very applications [16:01] so if we would assume that there are none, we wouldn't need the fix in the first place :) [16:01] well the fix fixes other issues [16:02] assuming there are no applications broken in that way doesn't impact that [16:02] dobey, but nothing we have a bug reference for [16:02] kenvandine: does it not fix a bug filed upstream? [16:02] nope [16:02] nothing listed [16:02] anyway, I don't have a hard veto against this, it just seems utterly hard to verify and the fix isn't that important for an SRU [16:03] oh :-/ [16:03] bad upstreams! :) [16:03] I'd rather get the other fix into -updates to unblock U1 [16:03] yeah [16:03] * kenvandine will make it so [16:04] maybe it was a bug report only filed in stefw's head; "oh this is broken bad, i'll fix it" :) [16:07] ... which is great :) === nenolod_ is now known as nenolod === hallyn is now known as mes === mes is now known as ck === ck is now known as mes === mes is now known as ck === ck is now known as hallyn === bregma__ is now known as bregma [16:33] cjwatson: Hmm grub fails to install on an ext4 /boot here (configured to install on /dev/sda2 ext4 instead of MBR); is this a bug? [16:33] (I know it's documented as fragile to start with) [16:35] lool: possibly a bug, depending on the nature of the failure [16:35] the fragility is normally in terms of staying installed rather than being installed in the firt place, though [16:35] cjwatson: I didn't find the error in the debug messages going to syslog [16:36] actually the error is that it can't read /grub/core.img correctly [16:36] in French [16:36] /usr/sbin/grub-setup : erreur : impossible de lire `/grub/core.img' correctement. [16:36] -vv [16:37] err, that was a bit terse [16:37] use grub-install --debug to find the grub-setup command it's running, then run that with the -vv option added [16:37] it may indicate a bug in grub's ext4 code [16:38] cjwatson: http://paste.debian.net/147319/ [16:39] from LC_ALL=C /usr/sbin/grub-setup -vv --directory=/boot/grub --device-map=/boot/grub/device.map /dev/sda2 [16:40] hm, that's not what I expected [16:40] add --force [16:41]