=== cinerama_ is now known as cinerama [00:45] so https support is added to apt finally... [00:46] ... about a week after I manage to get an exception made in the stupid websense firewall at work for one ubuntu mirror [00:46] oh well. should simplify adding other apt lines. [00:46] (they ignored https since they could sniff it very effectively) [00:47] they *could* request same file and make a deny decision based on that, but they fortunately don't [00:52] nemo: er? apt has had https support for years [00:55] oh? huh. I guess none of the mirrors have support [00:55] I'd tried a bunch of 'em w/o success [00:55] was just reading through latest updates to apt on natty, and one was about adding https as a transport [00:55] supporting it in deb lines [00:56] oh well, I got 'em to open up mirror.anl.gov (picked it because it was short and official sounding) [00:56] so hopefully no more stupidity with websense [00:56] I also complained to websense, but that went absolutely nowhere [01:14] i need to package something up that uses a postgresql database and opens up a particular user to the world [01:14] is there some kind of includes folder for the pg_hba.conf settings? [01:16] hi all, anybody had any luck making a puppet 2.7.1 package? === asac_ is now known as asac === poolie_ is now known as poolie [02:28] can anyone point me towards some information about packaging applications that use postgres? [02:28] or examples? [02:33] echosystm: i might take a look at http://people.debian.org/~seanius/policy/dbconfig-common-using.html/ but i don't know how official that is [02:36] thanks [04:19] Good morning [04:20] hi [04:21] apw: thanks! I'll send it to Gustavo and prepare a new release [05:05] pitti: Re: bug #790145 - I'm pretty sure that the fixes for bug #786941 that were in the -proposed but not verified 0.12.3+noroms-0ubuntu9.7 package aren't in the new 0.12.3+noroms-0ubuntu9.10 that's now in proposed. [05:05] Launchpad bug 790145 in qemu-kvm (Ubuntu Maverick) "kvm husb: ctrl buffer too small" [Medium,Fix committed] https://launchpad.net/bugs/790145 [05:05] Launchpad bug 786941 in qemu-kvm (Ubuntu Lucid) "Cannot boot from non-existent NIC" [Low,Fix committed] https://launchpad.net/bugs/786941 [05:05] RAOF: right, I thought that was the idea? [05:06] I thought the idea was that the 0.12.3+noroms-0ubuntu9.8 which had the fixes for both bugs had been superceded by the 9.9 from -security, so the proposed version needed to have the 9.9 changes folded in? [05:06] yay! there, working editmoin heading archivewards [05:08] Oh, hai. 82% swap usage? Maybe that's why things are stuttering every now and then :) [05:09] RAOF: in https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/790145/comments/24 Serge said that they will only re-attempt that other SRU on request [05:09] Ubuntu bug 790145 in qemu-kvm (Ubuntu Maverick) "kvm husb: ctrl buffer too small" [Medium,Fix committed] [05:12] So, at minimum what should happen is the 786941 should lose the ‘fix committed’ status. I would have thought that we didn't want fixes dropping out of the package like that, but I guess the unverified status makes things different. [05:22] RAOF: at least they shouldn't block other fixes to go in, yes [05:25] Oh, arse. Why did I think that would work? [05:30] pitti: I think bug #804655 should be fixed for A2, and it's got a simple and cringeworthy fix. It's not too late to upload mesa, right? [05:30] Launchpad bug 804655 in mesa (Ubuntu) "r300 loading instead of r300g" [High,Confirmed] https://launchpad.net/bugs/804655 [05:31] RAOF: we can re-roll CDs; I need to go through the tracker still, but right now I'm not aware of any other major breakage [05:31] RAOF: so please upload away [05:31] Thanks. [06:46] good morning [06:58] good morning [07:00] RAOF: how big of an issue is 804655? does it cause the live CD to fail on these devices? [07:01] RAOF: once jibel is up, I'll ask whether we can do another round of testing, but I'd like to know more about how bad it is [07:01] pitti: It causes unity to fail to work properly on the live CD. [07:01] shouldn't it fall back to unity-2d? [07:01] It should, yes. [07:02] It's not a horrific problem, and if you'd prefer it to miss A2 it certainly can. [07:02] it doesn't change the "should be uploaded now" part, of course [07:02] (then upgrades will get the fix, and if we need to respin for other reasons, we'll grab it) [07:03] Aha! [07:03] RAOF: ok, thanks; so let's see what jibel says [07:04] Waiting for the test build to finish to ensure I haven't made any other braindead mistakes :/ [07:14] pitti, hi! [07:15] hey poolie, how are you? [07:15] good thanks, a little tired [07:15] about the bzr 2.3.3 natty sru [07:15] first, thanks for accepting it into proposed [07:15] there is a regression in it, bug 786980 [07:15] Launchpad bug 786980 in Bazaar 2.3 "bzr: ERROR: bzrlib.errors.ReadOnlyError: A write attempt was made in a read only transaction" [High,Confirmed] https://launchpad.net/bugs/786980 [07:16] so, we should cancel the SRU [07:16] it's not a catastrophic regression but still it shouldn't go in [07:16] i'm not quite sure where to formally say that - on one of the SRU bugs? [07:17] poolie: yes, on any of those would be good [07:17] and i guess mark it 'verification-failed'? not actually true but might have the right effect [07:22] poolie: right; I was going to do that, but feel free to do it yourself [07:23] done, thanks [07:26] hmm...does the version of grub2 in maverick not support usb 3.0 boot? [07:26] i would have sworn i had tried this when i was prepping bug #565047, but i can't seem to make it past grub now [07:26] Launchpad bug 565047 in initramfs-tools (Ubuntu Maverick) "Unable to install off USB 3.0 port (HP Envy 15 Laptop)" [Undecided,Fix committed] https://launchpad.net/bugs/565047 === eitch0000 is now known as eitch === eitch_ is now known as eitch [08:42] dupondje: courier> no [08:43] dupondje: feel free === hunger_ is now known as hunger [08:54] cjwatson: prepared one (https://bugs.launchpad.net/ubuntu/+source/courier/+bug/803176) [08:54] Ubuntu bug 803176 in courier (Ubuntu) "courier version 0.65.0-3ubuntu4 failed to build on i386" [Medium,New] [08:57] cjwatson, oh, back from holiday ? i thought you were out the whole week [08:59] broder: grub doesn't have EHCI yet, no. somebody posted a patch for it to grub-devel a week or two ago [08:59] ogra_: no, just one day [08:59] cjwatson, the code live-build uses for ext2/3/4 creation doesnt come from livecd-rootfs, right ? seems resizing got massively slow with the way these images are formatted [08:59] a 4G SD card takes about 25min here (used to be 20-30sec with livecd-rootfs generated images) [09:00] ogra_: no, it's separate, the livecd-rootfs code had accreted various weirdnesses and I didn't see a particular reason to keep it [09:00] it's basically just mkfs.ext3 and copy stuff in [09:00] well, i think we adjusted the inode count or some such to make resizing faster [09:00] I thought I mirrored that [09:00] but feel free to patch it [09:00] * ogra_ will have to check the code ... [09:01] I'm not going to look at it any further at this point [09:01] k, will do [09:18] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Archive: Alpha-2 soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: zul, pitti [09:20] grmbl ... live-build ... [09:20] * ogra_ curses [09:20] so it seems i get a broken sources.list on ports ... [09:27] * ogra_ wonders why he sees irqbalance running all the time, i though that should only start once on boot and kill itself again [09:29] * dholbach hugs pitti [09:29] * pitti hugs back dholbach [09:29] quite sizable queue this morning :) [09:30] yeah, there's quite a lot going on [09:30] thanks to a week of rally with no sponsoring [09:30] I sponsored a few :) [09:31] but not too many [09:31] I just cleaned a few as well [09:31] nice [09:31] well, I tend to do desktop sponsoring often but those don't show up on the queue [09:31] just on our versions page [09:31] * dholbach nods [09:50] Whats the default umask on launchpad builders ? [09:51] dupondje: hey [09:51] dupondje: I had expected 022 as well [09:51] infinity, lamont ^ do you know? [09:52] it's about https://launchpad.net/ubuntu/+source/courier/0.66.1-1ubuntu1/+build/2611450/+files/buildlog_ubuntu-oneiric-i386.courier_0.66.1-1ubuntu1_FAILEDTOBUILD.txt.gz which complains about the buildd umask [09:52] Nothing changed in that part of the code neither, so before it was 022 [09:53] Well, the umask changed in Oneiric, didn't it? [09:53] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-June/000862.html [09:54] Why would the buildd's be different? [09:54] soren: it only affects users with a private user group [09:54] pitti: Which the buildd user is. [09:55] pitti: buildd:buildd [09:55] if the buildd user falls into that case, then the umask would be 002 [09:55] dupondje: ^ [09:55] infinity, you are talking in your sleep ! [09:55] infinity: thanks [09:55] ogra_: Too hot here, keep waking up. :/ [09:56] dupondje: To be fair, a test for an EXACT umask in a build system is daft. [09:57] No. [09:57] soren: Yes? :) [09:57] What is daft is to require a specific umask, but not just set it, but rather complain when it's wrong. [09:57] soren: well, yes, that too. [09:57] Now *that* is daft. [09:57] soren: But you're still doing something wrong if you need to set a umask to build things, IMO. [09:57] dupondje: so I suppose debian/rules should call "umask 022" before calling build? [09:58] yep [09:58] infinity: Generally, yeah. [09:58] fixing that now [09:58] You could just remove the test too. [09:58] Since whatever it wants the umask set for (make install, probably) will just get fixed later by dh_fixperms [09:59] debhelper: working around broken upstreams for over a decade. [09:59] It has been introduces here: [09:59] * check umask in debian/rules because Courier requires umask 022 for [09:59] installation (Closes: #157149) [09:59] Err. [10:00] Wait, that was in debian/rules, not the upstream makefiles? [10:00] I didn't even look. [10:00] Now that's EXTRA broken. [10:00] This is the part where I back away slowly before I NMU the Debian package in a fit of rage. [10:00] * infinity goes to try to sleep some more. [10:01] infinity: I hope you don't get any nightmares from this [10:03] infinity: I'm trying to visualise you trying to fall asleep in a fit of rage. [10:03] infinity: It doesn't look easy. [10:11] pitti: I added new patch now [10:16] dupondje: uploaded, thanks! You might want to send that to Debian as well [10:27] * dupondje doesn't get it anymore now [10:34] hey, I just noticed that Debian asks derivatives to add a popcon url, rather than replacing theirs with ours. Why don't we do this? http://wiki.debian.org/Derivatives/Guidelines#Popularity_Contest === dholbach_ is now known as dholbach [10:35] Laney: isn't our popcon around 10* higher than debian? [10:37] (I mean, debian wolud need a way to distinguish between the two) [10:37] they ask for it. [10:38] I think it's not supposed to be 'how many debian users use this package' [10:38] (see the page I linked) [10:39] Laney: yeah, I know, but I still think Ubuntu is a little different from other derivatives here [10:39] I don't see why it's not relevant [10:40] dupondje: wah, failed again :/ [10:40] as long as you use the data wisely, of course [10:40] https://launchpadlibrarian.net/74640246/buildlog_ubuntu-oneiric-i386.courier_0.66.1-1ubuntu2_FAILEDTOBUILD.txt.gz [10:41] dupondje: did you actually try to build this under a 002 umask? (so that it would fail before) [10:41] I did a testbuild here. worked fine [10:42] Laney: I'd want to know waht the popcon maintainers in debian think, and why we never submitted to them in the first place (was it just because we predated http submission?) [10:42] Its strange, umask gets set without errors, but still its broken somehow [10:43] sure, that's why I asked [10:47] dupondje: Err. You can't set the umask in a makefile like that. [10:48] dupondje: Every call in make is a forked shell, it will inherit the umask of the parent (make), not the previous shell call. [10:48] dupondje: Are you positive the package will actually FTBFS if you just remove the silly check? [10:49] * infinity notes that the check was added 9 years ago, a lot may have changed... [10:52] The check is still in the Makefile [10:52] to check if umask is 022 [10:52] In which Makefile? [10:52] The upstream one? [10:52] Laney: -> debian-derivatives? [10:53] Makefile.in: @test `umask | sed 's/^0*//'` = 22 && exit 0; \ [10:54] dupondje: perhaps try something like [10:54] - && $(MAKE) LIBTOOL=/usr/bin/libtool && touch stamp-build; \ [10:54] + && umask 022 && $(MAKE) LIBTOOL=/usr/bin/libtool && touch stamp-build; \ [10:54] and drop the umask check before? [10:55] It only checks on make install [10:55] Which makes some sense. [10:55] (Still broken for Debian, but makes sense for tarball dists) [10:56] dupondje: perhaps try something like [10:56] - && $(MAKE) LIBTOOL=/usr/bin/libtool && touch stamp-build; \ [10:56] + && umask 022 && $(MAKE) LIBTOOL=/usr/bin/libtool && touch stamp-build; \ [10:56] and drop the umask check before? [10:56] I'll test that :) [10:56] (sorry if that came through twice, DSL reconnect) [10:56] :) [10:56] tumbleweed: already did [10:56] You can also export INSTALL_IGNORE_UMASK=1 to skip the check. [10:57] actually there was (as is often the way) a fizzled out thread there already [10:57] dupondje: pitti's patch won't do you any good. [10:57] infinity: why not? it's the same shell? [10:58] dupondje: Either export INSTALL_IGNORE_UMASK=1, or set the umask before each $(MAKE) call in the install target in debian/rules. [10:58] pitti: It's install that checks for umask, not the build. [10:58] pitti: (which makes sense, for tarballs distribution) [10:58] pitti: Makes less sense for Debian. :P [11:00] first fixing pbuilder-dist now on my build system, so I can try different tests :D [11:00] cause debootstrap seems broken somehow :s [11:02] Laney: ah right, that's where I saw it. pere seemed to discourage it for distros who deviate from debian a bit [11:04] dupondje: http://paste.ubuntu.com/638828/ [11:04] dupondje: That should do it. [11:04] thanks, will try it out [11:05] (It will actually work if you only umask the first install call, but doing both is more in the spirit of what upstream wanted. :P) [11:05] Their install-perms target in Makefile.in should depend on install-check-umask, but doesn't. [11:06] The package is not the cleanest one around indeed :( [11:06] Nope. [11:24] cjwatson, ev: could you drop the ubiquity libcheese-gtk-dev build-depends next time you upload it? [11:24] infinity: https://launchpadlibrarian.net/74642842/umask_fix2.debdiff === MacSlow is now known as MacSlow|lunch [11:27] seb128: sure [11:30] ev: thanks [11:30] ev: I want to demote cheese since the current version doesn't build and we will need a bunch of mirs, if we need it in main we should handle it properly and not let it depwaiting as it's doing [11:31] it will need mir and gst components from the universe sets [11:37] pitti: uploaded new fix. Should do the trick now [11:43] dupondje: Looks correct. [11:45] build fine also :) [12:04] dupondje: Uploaded for you. [12:05] thx [12:39] pitti: did you see bug 800700? I noticed that yesterday on a lucid system. Apparently half the langpacks are still in -proposed... [12:39] Launchpad bug 800700 in language-pack-gnome-fr (Ubuntu) "Lucid: package language-pack-gnome-fr cannot be upgraded" [Undecided,Confirmed] https://launchpad.net/bugs/800700 === MacSlow|lunch is now known as MacSlow [12:40] stgraber: I didn't; thanks for pointing out! checking [12:49] stgraber: fixed [12:49] pitti: thanks! [12:49] thanks muchly for pointing out [13:18] pitti, do you know who promoted fsl-imx51, i am told it missed having its overrides applied [13:18] (and thus ended up in universe) [13:19] I don't know, no [13:19] it's not even in oneiric? [13:20] only lucid [13:20] oh, do you mean linux-fsl-imx51 in lucid? [13:20] pitti, sorry yes, that [13:20] so that was me [13:21] the current kernel sru workflow doesn't really involve a step of setting overrides [13:21] pitti, note this information is second hand, and it is being fixed by someone, just wondering if we're missing a step [13:21] apw: oh, it is? I'm currently changing it [13:22] apw: direct PPA->archive copying is circumventing the binary NEW procedure [13:22] so I guess we'll need to make "log into cocoplum and fix the componetn after copying" a part of the procedure :/ [13:23] apw: moved tomain [13:23] to main [13:23] pitti, ok cool. thats unfortuante that its a manual step === _LibertyZero is now known as LibertyZero [14:07] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Archive: Alpha-2 soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: zul [14:07] zul: I think you might want to @pilot out, too :) [14:07] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Archive: Alpha-2 soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [14:07] geez.. [14:11] could someone look over why the mythbuntu livefs cron job decided to not even try yesterday? the others have logs, but nothing in http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/mythbuntu/ [14:13] pitti \o/ [14:13] (sponsoring queue down to 61!) [14:13] just sent the report :) [14:14] superm1: cron jobs are off for alpha-2 RM [14:14] superm1: just poke me if you need another build [14:14] pitti, ah, yeah then could you do another build for me? [14:14] but they seem to have failed since July 2 [14:14] superm1: yes, running [14:15] thanks [14:15] there were eglibc troubles over the weekend [14:15] superm1: so, let's see what this log will say [14:15] barry, hey [14:29] https://launchpad.net/ubuntu/+source/vinagre/3.1.3-0ubuntu1/+build/2611478 [14:29] launchpad says build failed, but the logfile shows that build was successfull ... [14:29] dupondje: look at the very end [14:30] dupondje, the amd64 builder breaks build when the log has implicit conversions [14:30] ehh looked over that [15:06] superm1: http://cdimage.ubuntu.com/mythbuntu/daily-live/20110706/ [15:06] superm1: added to tracker [15:09] pitti, thanks [15:21] Hello all! :-) [15:22] ogra_, janimo: bigon fixed the json-glib build issue on debian so will be fixed in ubuntu once it's synced [15:22] will do that later when it's published in debian [15:22] bigon, thanks ;-) [15:23] np :) [15:23] barry: could you commit your dh_python2 changes to the vcs for the packages you upload? [15:23] barry, gnome-python-desktop gnome-applets gnome-menus gedit at least are outdated [15:23] seb128, nice, I could not figure out what it was when I looked [15:23] barry, which means either the next upload will get rejected or your change will be dropped [15:24] seb128: will do [15:24] if people don't notice you uploaded without updating the vcs that's it [15:24] barry, thanks [15:24] I'm quite a newbie but if someone has a minute to give me a little direction I would really appreciate it! (patching) [15:24] barry, you might want to check other things you uploaded, and debcheckout is your friends to checkout a source ;-) [15:25] seb128: i wonder if the udd guidelines should be updated, or whether the tools themselves should be modified. i'm not sure what the correct procedure should be though [15:26] barry, well "udd guidelines" are for udd use, reality is that we don't use udd in a consistant way [15:26] so ubuntu guideline != udd guideline [15:27] seb128: any new for cheese (and the required mir?) [15:28] seb128: yeah, but i guess my question is this: if you grab a udd branch, how do you know you should ignore that and use the vcs branch? [15:28] bigon, no [15:28] bigon, i've asked ev to drop the ubiquity build-depends on libcheese so we can demote it [15:28] at the moment, you have to find that out before deciding to grab the udd branch, realistically [15:28] seb128: well cheese could become a hard dep for empathy [15:29] bigon, well, we will patch it out [15:29] cjwatson: really? what's the best way to do that? [15:29] bigon, it's a no way until the gstreamer parts it needs are in good or base [15:29] $ debcheckout -p gedit [15:29] bzr https://code.launchpad.net/~ubuntu-desktop/gedit/ubuntu [15:29] seems reasonable enough to me ... [15:29] barry, cjwatson: we should teach debcheckout to get the udd vcs if it doesn't do yet [15:29] if there is no other vcs [15:30] (for an authenticated checkout, drop -p and add -a) [15:30] you should teach update-maintainer to drop the debian xs-vcs then [15:30] that as well [15:30] s/drop/move to XS-Debian-Vcs-/ [15:30] yes [15:31] or teach debcheckout to favorite launchpad vcs-es on ubuntu when several are listed [15:32] which is a bit hackish but should do what we want most of the time [15:32] adding XS-Ubuntu-Vcs and preferring that is another solution [15:32] mvo - has update-manager been switched to pygi/gtk3 yet? [15:32] then it would also allow us to specify non-launchpad branches too ... (e.g. I have some git branches on alioth for Ubuntu packages that it'd be nice if people used) [15:33] * cjwatson would prefer not having massive churn in everything that already has Vcs-blah in Ubuntu [15:33] I don't see anything wrong with having an Ubuntu-specific Vcs-Git header [15:33] brendand: no, not yet [15:34] no there wouldn't be, if I could specify branches there [15:34] well first step would be to suggest in the documentation to use debcheckout or to check for non UDD vcs-es [15:35] seems some people read the UDD documentation and assume that UDD is the standard way to do things which is not the case... [15:35] but i'm missing something. what exactly would that "check for non UDD vcs-es" be? a non-launchpad or non-bzr url? or something else? iow, how would i know whether it's safe to use the udd branch? [15:36] barry, apt-cache showsrc and search for Vcs lines [15:36] $ apt-cache showsrc gedit | grep Vcs [15:36] Vcs-Bzr: https://code.launchpad.net/~ubuntu-desktop/gedit/ubuntu [15:36] or use debcheckout... [15:36] seb128: so, you mean if there are any vcs lines at all, you cannot use the udd branch? [15:37] debcheckout can't tell if Vcs is for Debian or Ubuntu [15:37] how common is using debcheckout for desktop packages, though? The majority of packages are not going to have launchpad Vcs lines, so I don't think I've ever used debcheckout on ubuntu [15:38] an explicit Vcs line indicates that the maintainer is doing something outside of UDD [15:38] so just unconditionally using that isn't enough [15:38] tumbleweed: pretty much all GNOME related packages have them [15:38] assuming it's for Ubuntu; Laney is right that there are wrinkles [15:38] most installer packages have Vcs-Bzr too [15:39] cjwatson: right, but checking for Vcs-Bzr is a narrower test [15:39] one of these days I'll get round to pushing them to lp:ubuntu/... and moving everything over, but a million and one things to do etc. [15:39] barry: I have Debian packages with Vcs-Bzr; no reason to assume it's Ubuntu-specific [15:39] which is part of the reason for suggesting XS-$Vendor-Vcs; then you are indicating that this is the location to use for $Vendor [15:39] cjwatson: no question, there will be false matches [15:39] if you just change it in the merge you aren't giving the tools enough information [15:40] well, as 95% heuristics it could always check for the word "ubuntu" in the branch [15:40] barry: designing something that minimised them would be kind of nice though :) [15:40] all desktop package branches are named "ubuntu", and most of them should be owned by ~ubuntu-{desktop,core-dev} [15:40] well we could say that ubuntu modified package that to keep only the ubuntu Vcs info [15:40] "have to keep" [15:40] i'm just looking for some criteria other than saying "if there's a vcs-* line, don't use udd" because i'm afraid it will make udd basically unusable [15:41] the (not machine-readable) criteria should be "if there's a vcs-* line that looks like it's explicitly maintained by Ubuntu people, prefer that to UDD" [15:41] let's say "if there's a Vcs- line, check first"? [15:41] that's your criterion - now figure out how to make that machine-readable [15:42] cjwatson: :) [15:42] pitti's heuristic certainly isn't a bad one [15:42] you can use "if the revision has an ubuntu number and the control a Vcs use that, otherwise use UDD" [15:42] yes, but "check first" means? ask someone, inspect the vcs branch, something else? [15:42] then we just need to make sure we clean debian vcs infos when we modify sources in ubuntu [15:42] cjwatson: wait, does that mean that grub2 shouldn't currently work with usb 3.0 drives, or doesn't work with usb 3 drives in usb 2 ports? Because I definitely did the latter with natty last week, but can't seem to get it working with maverick [15:43] seb128: that matches much closer to what i was thinking [15:43] barry: the naming/ownership of the branch sohuld generally make it clear whether it's the ubuntu one [15:43] broder: I expect I mean the controller rather than the drive [15:43] broder: maverick - no idea, too long ago :) [15:43] but what pitti said, checking for ubuntu in the vcs url should work for most cases [15:43] barry: like lp:~ubuntu-core-dev/pkgname/ubuntu obviously is [15:43] seb128: and the ubuntu packages without ubuntu in the version? [15:44] tumbleweed, out of some special case of native ubuntu packages those are synced from debian [15:44] tumbleweed: even upstart has an ubuntuish version number now, and udev too [15:44] yeah, I'm talking about the special cases :) [15:44] tumbleweed: do we still have these? frankly, we should fix those packages to have ubuntuish versions and stop trampling Debian's namespace [15:44] well, 95% if better than nothing [15:44] is [15:45] even if we have a few corner cases which has confusing [15:45] the other thing to remember is the process is different too, iow, you'll have to create a branch and do a mp against the vcs branch [15:45] but usually things maintained in ubuntu are full source and packaging in bzr [15:45] pitti: I agree with that, but I still see people using them because "the package is blacklisted" or "ubuntu-only, no such package in debian" [15:45] so they can easily be on lp:ubuntu namespace [15:45] tumbleweed: for those you can still check Vcs-Bzr:, just as you'd do (or not) right now.. [15:45] barry: right, but for now, that's inevitable [15:46] cjwatson: yep, agreed [15:46] pitti: honestly I can't see a reason to change e.g. ubiquity's version number [15:46] okay, i think i have enough to at least start a discussion on the udd mlist. [15:46] pitti: if the heuristic is "ubuntu" in version: use Vcs, else use UDD then those need to be special cased (but yes, there aren't many) [15:47] tumbleweed: or maybe -0ubuntuX ? [15:47] tumbleweed: more specifically, use Vcs-Bzr [15:47] especially for a native package it's annoying and makes it look like it's a branch from Debian when it isn't [15:48] superm1: just saw your mythbuntu-default-settings upload; do you want that for a2? [15:48] having an XS-$Vendor-Vcs-* certainly helps to override all the special cases, whatever heuristic is used [15:49] tumbleweed: yeah, I think I agree [15:49] mvo: I've been seeing a number of cases recently where changelogs.ubuntu.com isn't up to date; the most recent I noticed was isc-dhcp-client 4.1.1-P1-17ubuntu3. Could there be a systemic problem here? [15:49] right, but any change to Vcs-Bzr: structure will take a cycle to implement [15:51] cjwatson: let me check [15:51] * barry -> lunch, but i'll open a thread on udd afterward [15:53] barry: thanks; the non-UDD branches are not going to go away anytime soon, so any improvement for the current situation is appreciated [15:53] unless we can retarget the lp:ubuntu/pkgname branches to the Vcs-Bzr: ones [15:56] umm, the lp:ubuntu/foo branches still serve a purpose even if the branch for making changes is elsewhere, I don't think they should not be available [15:57] in theory at least, it lets one look at upstream changes over time === beuno is now known as beuno-lunch [16:08] cjwatson: thanks for the pointer, there is indeed something broken on changelogs, seems to be caused by the recent machine upgrade, I am on it [16:09] great, thanks [16:15] cjwatson: dunno if you got time to look at https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/805886 ? [16:15] Ubuntu bug 805886 in debootstrap (Ubuntu) "/proc does not get umounted after debootstrap" [Undecided,New] === ximion2 is now known as ximion [16:21] kirkland`, you wanted the latest mongodb from debian didn't you? [16:21] I did a hacky patch to pull-lp-source, to do vcs checkouts, using the "ubuntu" in Vcs-Bzr + X-Vcs-$Vendor-Bzr heuristics: lp:~stefanor/ubuntu-dev-tools/udd-checkout if that interests anyone [16:22] dupondje: not yet, no. it certainly surprises me since that always used to be unmounted [16:22] dupondje: I was on holiday yesterday and am still catching up. === ximion1 is now known as ximion [16:25] cjwatson: hehe ok :) no stress :D [16:39] * ogra_ hugs bigon [16:39] thanks ! [16:42] barry: did something change in python-imaging or related package(s) in oneiric? I'm getting this error when building a package on oneiric that works just fine all the way down to lucid: IOError: decoder zip not available [16:45] bdmurray: where should I hook into apport to collect additional info if /var/cache/debconf/config.dat is mentioned in an upgrade log? [16:48] slangasek: probably data/general-hooks/generic.py [16:49] slangasek: in apport ... [16:49] bdmurray: ack [16:57] cr3: i think one of the launchpad guys got hit by this in dublin but i never found out what the issue was [17:03] dupondje: can't reproduce this with a bare debootstrap run [17:04] * cjwatson tries with the invocation from the Debian bug === beuno-lunch is now known as beuno [17:10] doko: so bug 756028 ended up being tagged multiverse as the source is multiverse although the binary is in universe. Does that seem reasonable? [17:10] Launchpad bug 756028 in opendrim-lmp-powermanagement (Ubuntu Oneiric) "opendrim-lmp-powermanagement version 1.0.0-0ubuntu1 failed to build on i386" [High,In progress] https://launchpad.net/bugs/756028 [17:12] pitti, we're skipping a2, lots of other issues right now [17:12] we'll start with a3 === dendro-afk is now known as dendrobates [17:43] dupondje: can't reproduce this with the debootstrap line in the debugging output from the Debian bug either. Can you please show me a way I can reproduce this with plain debootstrap? [18:01] barry: do you think the problem is likely to be ephemeral and will resolve itself somehow? [18:02] cr3: unknown at this point, sadly. i wonder if it could be a multiarch related problem. does it happen only on oneiric? [18:02] cr3: unfortunately too, PIL isn't being maintained upstream anymore afaik [18:03]