[00:15] <bryceh> rsalveti, yeah
[00:16] <rsalveti> bryceh: for the debootstrap issue I published my test result with multstrap at the merge request
[00:16] <rsalveti> this will at least make it possible to create images again
[01:32] <bryceh> @pilot out
[01:39] <slangasek> bryceh: right, we should certainly fix this ASAP, but if that doesn't fix it I don't know what will do the job
[02:32] <pook1e> I'm trying to create an oneiric environment using pbuilder, but I keep getting stuck at "W: Failure trying to run: chroot /var/cache/pbuilder/build/1422/. dpkg --force-depends --install /var/cache/apt/archives/libc_2.13-9ubuntu2_amd64.deb"
[02:32] <pook1e> Has anyone else experienced this problem?
[02:32] <nigelb> I think pbuilder on oneiric is currently broken. I remember someone saying that yesterday.
[02:38] <ScottK> It's actually base-files that's broken, but that's not unexpected.
[04:08] <RoAkSoAx> serge_afk: it was the kernel
[04:21] <pitti> Good morning
[04:22] <pitti> debfx: kubuntu seed branch> oh, did I commit something to the wrong place?
[04:22] <ajmitch> morning pitti
[04:22] <pitti> RoAkSoAx: nothing to do with udev, it's because there's an incomplete /run transition -- just remove /run/*, and it will work again
[04:26] <slangasek> pitti: to the contrary, people have been saying today that removing /run is insufficent
[04:26] <slangasek> er, no, I may have that wrong
[04:27] <slangasek> people have been saying that adding /var/run and /var/lock compatibility links doesn't fix it
[04:27] <slangasek> I guess the advertised workaround is to remove /run/udev
[04:27] <slangasek> so, why does that work?
[04:27] <slangasek> that would seem to have *everything* to do with udev :)
[04:30] <pitti> slangasek: worked for me
[04:31] <pitti> sudo rm /run/* and rebooting helps
[04:31] <pitti> then udev consistently uses /dev/.udev/ again
[04:31] <pitti> slangasek: I followed up to bug 807306 explaining what happens
[04:31] <slangasek> pitti: ok, ta
[04:31] <pitti> I hit it myself yesterday
[04:31] <slangasek> pitti: we do want udev to be using /dev/.udev/ though, so I'd like to get this properly fixed
[04:31] <pitti> slangasek: it's because the initramfs starts its own udev instance, which uses /dev/.udev (as initramfs doesn't have a /run yet)
[04:32] <slangasek> ok, so it's initramfs-tools where we need to fix it?
[04:32] <pitti> slangasek: do we? why does base-files create a /run then?
[04:32] <slangasek> sorry
[04:32] <pitti> if we want to move to /run, initramfs needs to have it as well IMHO
[04:32] <slangasek> I mean "we don't want udev to be using /dev/.udev" :)
[04:32] <pitti> ah :)
[04:33] <pitti> slangasek: do you know if someone is already on this? or shall I have a look?
[04:34] <slangasek> pitti: I think it's best if you do - bryce and rsalveti were looking but hit a dead end when readding /var/{lock,run} to base-files didn't fix it
[04:34] <slangasek> I'm taking care of sysvinit already fwiw
[04:34] <pitti> oh, is there another problem with /var/lock and /var/run, too?
[04:34] <rsalveti> I thought this was fixed at debian already
[04:34] <slangasek> yes, that's the bug that prevents oneiric from bootstrapping at the moment
[04:35] <pitti> rsalveti: oh, does Debian use /run/ already?
[04:35] <slangasek> yes
[04:35] <rsalveti> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620995
[04:35] <pitti> slangasek: ah, much appreciated; that'll fix the libc6 install error?
[04:35] <slangasek> pitti:
[04:35] <rsalveti> let me check what was the fix
[04:35] <slangasek> pitti: yes
[04:35] <slangasek> pitti: and I'll probably need to do coordinated uploads of sysvinit+mountall+base-files, at least
[04:35] <pitti> * [259ad09] mkinitramfs: creat /run initramfs directory.
[04:35] <rsalveti> pitti: https://code.launchpad.net/~rsalveti/ubuntu/oneiric/base-files/run-transition/+merge/67444
[04:36] <rsalveti> this is for the debootstrap issue
[04:36] <pitti> yeah, I wasn't quite sure why Keybuk did it that way -- we create /run, but nothing actually makes it a tmpfs
[04:36] <pitti> that would be mountall, I figure?
[04:36] <pitti> (and might be covered in slangasek's work)
[04:37] <slangasek> keybuk *didn't* do it that way, someone else uploaded changes he had partially staged in bzr ;)
[04:37] <rsalveti> ouch :-)
[04:37] <slangasek> yes, mountall will need to take care of the tmpfs mounting
[04:42] <rsalveti> debian includes a fix at udev that makes it only use /run when it's a tmpfs
[04:43] <rsalveti> seems the right fix even during the transition
[04:44] <pitti> right, I'll check that
[04:44] <rsalveti> that will cover bug 807306
[04:45] <rsalveti> pitti: http://paste.ubuntu.com/642376/, but you can just merge/check the patch from the debian src package
[04:45] <rsalveti> problem is that udev will always use /run if the directory is there
[04:45] <rsalveti> even if it's not a valid /run (not mounted as tmpfs)
[04:46] <rsalveti> as we had the directory there, when udev restarted, it got broken
[04:46] <pitti> rsalveti: right, trying to find the udev patch; thanks for the pastebin!
[04:54] <rsalveti> pitti: so to make it all work again we'll need both fixes
[04:54] <rsalveti> the bootstrap related one, and this udev update
[06:47] <e_t_> Why does ubuntu-minimal depend on iputils-ping?
[06:48] <infinity> Why shouldn't it?
[06:48] <infinity> It certainly fits with the package description.
[06:50] <e_t_> I mean, why does it depend only on that implementation? inetutils-ping works the same, though it has a much nicer --help.
[06:51] <infinity> e_t_: because inetutils-ping is in universe.
[06:53] <infinity> e_t_: File a bug on ubuntu-meta, we could conceivably mangle it to depend on "iputils-ping | ping", which would still get the supported one by default, but let you swap without losing the metapackage.
[06:54] <e_t_> infinity: Thank you.
[06:57] <rsalveti> pitti: to fix the debootstrap issue we also need the base-files fix
[06:58] <pitti> rsalveti: right
[06:58] <rsalveti> at least while slangasek is merging the sysvinit package change
[06:58] <pitti> rsalveti: I understood slangasek was going to handle that
[06:58] <pitti> I'm currently working on merging initramfs-tools
[06:58] <pitti> to get proper /run handling
[06:58] <rsalveti> cool
[06:58] <pitti> the udev bandaid fix is uploaded
[06:58] <rsalveti> yeah, just saw it
[06:58] <rsalveti> thanks for fixing it
[06:59] <pitti> np, thanks for pointing it out
[07:23] <pitti> slangasek: hm, initramfs 0.99 already creates a /run tmpfs and mounts it over to the running system; do we actually need that in mountall still?
[07:25] <slangasek> pitti: for the tmpfs-less case, yes
[07:25] <slangasek> er
[07:25] <slangasek> initramfs-less case
[07:25] <pitti> ah
[07:25]  * pitti tests initramfs merge
[07:26] <dholbach> good morning
[07:26] <pitti> hey dholbach
[07:27] <dholbach> hey pitti
[07:30] <geser> good morning dholbach, pitti
[07:30] <pitti> hey geser
[07:30] <dholbach> hey geser
[08:19] <evfool> ping barry
[08:20] <mvo> hey evfool, he is probably still sleeping (us timezone)
[08:21] <evfool> thanks mvo, didn't know that
[08:21] <evfool> mvo: do you know anything about update-manager in natty-proposed with the apport-hook (bug 797894)
[08:22] <mvo> evfool: let me check
[08:22] <evfool> barry and raof have been talking about that, but now it's not in proposed, not in updates, and the bug's still there
[08:22] <mvo> evfool: thankss for your update-manager merge btw :)
[08:22] <mvo> evfool: eh, branch I mean
[08:23] <evfool> mvo: just trying to check for useful patches attached to bugs and convert them into merge requests, because patches attached tend to get lost
[08:24] <mvo> evfool: yeah, that is unfortunately true :/ thanks a bunch for going throught them, I find this really helpful
[08:24] <mvo> evfool: it looks like the u-m proposed version got uploaded without bzr-buildpackage so it includes the .bzr dir, I will do a reupload
[08:24] <evfool> thx mvo
[08:29] <pitti> yay, workign /run/udev/
[08:38] <pitti> slangasek: initramfs-tools working well now, thrown oneiric-wards
[08:57] <ogra_> GRRR
[08:57] <ogra_> who brike update-manager
[08:57] <ogra_> *broke
[08:58] <seb128> ogra_, wfm
[08:58] <ogra_> partial upgrade ?
[08:59] <seb128> ogra_, without details on what is broken it's hard to say
[08:59] <seb128> ogra_, try #ubuntu for "doesn't work" questions ;-)
[08:59] <ogra_> i'm getting a partial upgrade offered which then starts fine ... during "preparing to upgrade" a white contentless window pops up
[08:59] <pitti> works fine here
[08:59] <seb128> oh, I didn't try to do partial upgrades
[08:59] <ogra_> sadly without and windo buttons too ... so i cant close both windows (second one seems transiaent)
[09:00] <ogra_> all i can do is kill from cmdline
[09:00] <ogra_> its reliably reproducable but doesnt spit out a thing if i fire u-m off from cmdline
[09:01]  * ogra_ goes back to apt being not able to get any debugging info
[09:02] <pitti> hm, I just did a full upgrade cycle with current u-m for testing
[09:03] <seb128> can't try here, I've no "partial upgrade"
[09:03] <seb128> normal upgrades work fine
[09:03] <seb128> there might be a bug in the gir transition with the partial upgrade dialog dunno
[09:03] <seb128> check with mvo
[09:03] <ogra_> might be arm specific or so, in any case i dont get any debugging output
[09:03] <pitti> seb128: currently there's a partial upgrade, as the evo binaries are held back
[09:03] <ogra_> on arm there are the new indicators
[09:04] <seb128> ogra_, oh, we had that transition a week ago on other archs
[09:04] <seb128> pitti, it already built on i386 ;-)
[09:04] <seb128> but not published yet, I guess I will have the partial upgrade as well if I refresh, let's try
[09:04] <ogra_> seb128, yeah, you had json-glib :)
[09:09] <mvo> ogra_: hmmm, that is probably the gtk3 port, if the window is still there, could you please do a ps afx and paste the output?
[09:10] <ogra_> mvo, phew, thats timing, apt-was just ready downloading :)
[09:10] <mvo> apachelogger: software-properties trunk has your dbusworker stuff now (plus tests for them). thanks again for the initial work, no changes on the ui yet though
[09:14] <ogra_> mvo, http://paste.ubuntu.com/642494/
[09:18] <mvo> ogra_: hm, looks pretty normal, so there is a white window? could I see a screenshot maybe? any activity still? anything interessting in one of the logs /var/log/apt/{term.log,history.log} ?
[09:19] <RAOF> evfool: That package got rejected pending a new upload without the .bzr and .bzr-builddeb cruft.
[09:19] <evfool> thanx RAOF
[09:20] <ogra_> mvo, "Log ended: 2011-07-08  18:37:07" ... doesnt seem to get to apt
[09:20] <ogra_> history.log ends also at that time
[09:21] <mvo> ogra_: anything /var/log/dist-upgrade/* that looks relevant?
[09:21] <seb128> does anyone know where is usb_dev_handle is defined in the linux sources?
[09:22] <ogra_> mvo, hmm, now i cant reproduce it anymore, the "partial upugrade" window just closes, let me check that logfile
[09:25] <cjwatson> e_t_: FWIW I've always wontfixed bugs asking for alternative dependencies in ubuntu-* metapackages - the *purpose* of those metapackages is to make opinionated choices
[09:25] <cjwatson> e_t_: people can always remove the metapackages if they want to make a different choice
[09:26] <cjwatson> I appreciate that that doesn't make everyone happy
[09:26] <cjwatson> mvo: working on https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations - wgrant asked whether we should be generating Translation-C rather than Translation-en.  What does apt do in the LANG=C case?
[09:27] <e_t_> cjwatson: Since ubuntu-minimal recommends not to remove it, I was hesitant to do so.
[09:28] <ogra_> mvo, there we go http://paste.ubuntu.com/642501/
[09:29] <mvo> cjwatson: it will not download anything for LANG=C currently
[09:30] <mvo> ogra_: woah
[09:31] <ogra_> yeah, looks evil
[09:36] <cjwatson> mvo: should it?
[09:36] <mvo> cjwatson: I'm not really sure if it makes sense to have Translations-C, conceptual its nice because it means we can have "real" description in -C and "translated" description in -en (translated in the sense that it allows out-of-band description overwrites and typo fixes). but it would also mean that the -C would have to be downloaded all the time in addition to the -en one
[09:36] <cjwatson> I'm not sure why you'd have to download it in addition
[09:37] <cjwatson> just the translated one would be fine
[09:37] <mvo> the -en one?
[09:37] <cjwatson> sure, if it had basically all the same data
[09:38] <mvo> right, that would be fine. the only remaining issue is that the ddtp stuff is (much) less often updated at least currently
[09:38] <cjwatson> my concern is for sysadmins who use LANG=C and still want 'apt-cache show' to be useful
[09:38] <mvo> so -C would be more fresh then -en most of the time
[09:38] <mvo> yeah, the LANG=C is a good point
[09:39] <mvo> we could simply provide both (even via a symlink)
[09:39] <cjwatson> a symlink could work, yes
[09:40] <cjwatson> though that gets me into more complicated bits of the publisher :-/
[09:40] <mvo> :(
[09:40] <cjwatson> so far my patch is fairly straightforward
[09:41] <mvo> alternateively I can make it download Translations-en if you run LANG=C as a fallback
[09:42] <mvo> cjwatson: uhh, sorry, I was wrong, its actually already taking care of this
[09:42] <mvo> cjwatson: so "C" will simply queue Translations-en for download
[09:43]  * mvo notes that it helps to look at the right spot of the code…
[09:45] <cjwatson> mvo: oh, excellent
[09:45] <cjwatson> mvo: can you point me to the right spot?  I did look but failed to find it
[09:46] <mvo> apt-pkg/aptconfiguration.cc, there is a envShort == "C" test in it
[09:46] <mvo> cjwatson: in getLanguages()
[09:46] <mvo> cjwatson: the code is a bit hard to follow unfortunately
[09:47] <cjwatson> mvo: perfect, much appreciated thanks
[09:47] <mvo> yw
[09:47] <cjwatson> this will require downtime to deploy AIUI, but the wheels are now in motion
[09:48] <mvo> great, thanks a bunch for driving this :)
[10:43] <cjwatson> mvo: I think we'll need a backport of apt to lucid to add LongDescription support.  Could you take care of it?
[11:03] <cjwatson> mvo: if it isn't appropriate for lucid-updates (I guess it might not be), https://launchpad.net/~launchpad/+archive/ppa ought to be fine
[11:05] <cjwatson> mvo: so I guess that's at least 1327.52.28, 1327.52.29, 1327.65.10, and maybe 1327.84.57?
[11:24] <davmor2> hey guys I had the same issue as before with the kernel update last night on oneiric in that the keyboard and mouse don't function once x is started,  works fine if I go into safe mode from grub but stops the minute I start lightdm or startx
[11:25] <ara> mvo, the page about verifying SRUs: https://wiki.ubuntu.com/StableReleaseUpdates#Verification
[11:25] <ara> mvo, it says that the SRU team will test the -proposed packages
[11:25] <ara> but I guess that actually anyone can test them, am I wrong?
[11:25] <ara> if that's the case, the wiki is a bit confusing
[11:39] <mvo> cjwatson: hi, I just came back from lunch. apt> I need to check, but I'm happy to do it (unless you cherry-picked the patches already
[11:39] <mvo> ara: yeah, anyone can
[11:39] <cjwatson> mvo: I haven't, hands still a bit full with LP bits
[11:40] <cjwatson> trying to set up to QA your python-apt backport
[11:41] <mvo> cjwatson: great, I will do the cherry pick now then
[11:42] <cjwatson> thanks - I think I have a basic setup suitable for validating it
[11:42] <cjwatson> though outside the context of P
[11:42] <cjwatson> LP
[11:54] <RAOF> davmor2: bug #807306 is your winner.
[11:55] <cjwatson> mvo: hmm, I wonder if it'll break anything that this causes 'apt-cache show' to display Description-en fields rather than Description
[11:55] <davmor2> RAOF: Thanks
[12:11] <soren> I thought there was supposed to be a /var/lock symlink to /lock for backwards compatibility in Oneiric?
[12:12] <pitti> soren: ITYM s/lock/run/; that's what slangasek is working on
[12:12] <soren> My sbuild complains: E: Can't create lock file /var/lib/schroot/mount/oneiric-amd64-abf2953c-aa36-4fa9-bd6a-311004445b44/var/lock/sbuild: No such file or directory
[12:12] <soren> Hmm...
[12:13] <pitti>   * debian/1777-dirs: remove /var/lock (replaced by /run/lock on tmpfs)
[12:13] <pitti> ^ base-files 6.3ubuntu3
[12:13] <pitti> i. e. this transition is incomplete
[12:13] <pitti> soren: sorry, you are right
[12:13] <pitti> soren: same answer, though
[12:13] <soren> Ah :)
[12:13] <soren> Had me confused there for a little bit.
[12:14] <RAOF> soren: Yeah; just create /var/run in your chroot and it'll work again.
[12:14] <soren> Ok, if the fix is in the works, that's great. I'll ninja my way out of it for now.
[12:16] <soren> Yay. sbuild is all smiles and giggles again now. \o/
[12:39] <kirkland> barry: ping
[12:43] <barry> kirkland, pong
[12:43] <kirkland> barry: so i dug through all the Ubuntu code I have in my /local/source/* directory
[12:44] <kirkland> barry: the *only* way i could see that an .ecryptfs dir *might* have been removed is if you tried to deluser with the --remove-home option
[12:44] <kirkland> barry: i don't know if you would have done that in your chroot
[12:45] <kirkland> barry: but your report bothered me sufficiently that I had to do some digging
[12:46] <barry> kirkland, no, i definitely didn't do that.  thanks for digging into it though.  very strange.  i'm going to rebuild the machine today
[12:46] <barry> kirkland, but i found a spare disk, so i'll make a backup.  i can't see submitting a bug report since i don't even know for sure it's a bug (or where)
[12:47] <kirkland> barry: cool
[12:56] <mvo> cjwatson: https://launchpad.net/~mvo/+archive/apt-ftparchive-lucid <- that ppa has the backport, should work, I verified it with lp:~mvo/+junk/apt-ftparchive-testsuit
[13:11] <RoAkSoAx> pitti: yeah did that already! Thanks!
[13:20] <davmor2> Man thunderbird is heavy on CPU  90-132% usage :(  on oneiric
[13:22] <dupondje> 2 - 4% here
[13:22] <dupondje> average
[13:23] <davmor2> dupondje: I think it's just the importing, I'm going to check it again, once it's finished.
[13:24] <mdeslaur> pitti: hi! did you get my email about ubuntu-sru?
[13:35] <pitti> hey mdeslaur
[13:36] <pitti> mdeslaur: I did, just didn't answer yet, sorry; the queues are empty right now, so we need to let them fill again
[13:36] <pitti> before we can do some examples
[13:36] <mdeslaur> pitti: ah, cool...no rush :) thanks!
[13:39] <dupondje> http://paste.ubuntu.com/642025/ => could this be a kernel bug? Or surely hw issue ?
[13:58] <cjwatson> mvo: looks like we need 1327.95.5 as well for data.tar.xz support (bug 619152)
[13:59] <cjwatson> actually I guess that's bug 805389
[14:03] <mvo> cjwatson: hm, the python-apt bits I uploaded to lucid-proposed iirc
[14:04] <cjwatson> mvo: yes, but there's a bit in apt-inst too
[14:04] <cjwatson> I have your python-apt bits installed
[14:04] <mvo> cjwatson: ok, I have a look now
[14:05] <cjwatson> this is at least going faster now that I have a working LP dev VM
[14:07] <tomreyn> does it qualify for a bug if a process exits instead of either refreshing its configuration files or ignoring the signal on 'kill -1'?
[14:08] <cjwatson> tomreyn: I would say a wishlist bug.  It might be convenient, but there's no rule for what processes must do on SIGHUP
[14:09] <cjwatson> and the default for SIGHUP is to terminate the process, which is appropriate for things that aren't long-running
[14:11] <tomreyn> thank you.
[14:16] <Sweetshark> somebody knowing by chance the deeper meaning of --dynamic-list-cpp-new --dynamic-list-cpp-typeinfo?
[14:41] <ahasenack> hi guys, quick recipe question if I may: can a recipe file work with local branches or do they have to be lp: style branches? I tried putting a local path in there instead of an lp: branch and it failed
[14:41] <ahasenack> I'm using bzr dailydeb
[14:45] <dholbach> ahasenack, abentley and james_w probably know best
[14:45] <james_w> ahasenack, it should work with local branches
[14:45] <james_w> ahasenack, but obviously such a recipe isn't suitable for LP :-)
[14:46] <ahasenack> james_w: oh, I think this is a pbkac
[14:47] <ahasenack> james_w: dholbach; sorry, I had the wrong paths in my recipe
[14:47] <ahasenack> and jumped to conclusions
[14:48] <dholbach> no worries :)
[14:48] <dholbach> as long as you figured it out now it's all good :)
[14:49] <ahasenack> ofcourse, I'm getting another error now, but I will really read through it before posting it here :)
[15:02] <cjwatson> mvo: your previous ftparchive backport for LongDescription looks good
[15:03] <ahasenack> so bzr build doesn't actually build, it just puts the requested branches in place, ready for a build
[15:04] <mvo> cjwatson: great, I'm looking into the xz stuff now
[15:04] <ahasenack> I don't know what it does to the version/release the recipe specified, the debian/changelog is pristine from the branch
[15:04] <mvo> cjwatson: I suppose you want the full support, right? including everything that ftparchive is doing?
[15:04] <cjwatson> I think LP might need that yes
[15:05] <mvo> ok
[15:05] <mdeslaur> pitti: is there a way to bypass the apport "This is not a genuine Ubuntu package" error for testing purposes?
[15:07] <pitti> mdeslaur: a slightly hackish one: let it complain, then edit the .crash file and remove the UnreportableReason:, then run the crash file through apport-bug again
[15:07] <mdeslaur> pitti: ah, cool, that'll work thanks
[15:08] <pitti> mdeslaur: package hooks can decide to skip the check, too
[15:08] <pitti> if that's closer to your use case
[15:08] <pitti> by setting somethign like report['CrashDB'] = 'ubuntu'
[15:10] <mdeslaur> pitti: thanks
[15:12] <ahasenack> james_w: hi, sorry to ping directly, I'm getting this error: bzr: ERROR: Invalid deb-version: {debupstream}+14-0ubuntu0+2: Could not parse version: {debupstream}+14-0ubuntu0+2    Pastebin here: http://pastebin.ubuntu.com/642701/
[15:13] <james_w> I think your bzr-builder is too old for {debupstream}
[15:14] <ahasenack> oh
[15:14] <ahasenack> I got it from the ppa
[15:14] <ahasenack> dailydebs-team-bzr-builder
[15:15] <ahasenack> only oneiric has 0.7
[15:16] <james_w> hmm
[15:16] <ahasenack> but I'm on lucid, yes
[15:16] <ahasenack> my bzr is 2.4.0~beta4-1~bazaar1~lucid1
[15:16] <james_w> I thought that newer versions also told you want the valid substitutions were, and your error message doesn't contain that
[15:16] <ahasenack> (also from a ppa)
[15:16] <james_w> hmmm
[15:17] <james_w> I don't know why the ppa wouldn't have got a newer version
[15:17] <ahasenack> james_w: what is launchpad using, do you know?
[15:17] <ahasenack> eventually I want to try this out there, I'm just ironing out some obvious bugs locally first
[15:18] <james_w> it's using something recent enough, I don't know the exact version thoguh
[15:18] <ahasenack> I remember using recipes in LP several weeks ago, and I used debupstream without problems
[15:19] <ahasenack> maybe I have some typo or subtle syntax error here
[15:19] <mvo> cjwatson: I uploaded a new version with the cherry pick of the xz stuff to https://launchpad.net/~mvo/+archive/apt-ftparchive-lucid please let me know if it looks good, did only very light testing this time
[15:21] <ahasenack> james_w: I now tried with just "deb-version 0.1.0-1~{revno}", and got:
[15:21] <ahasenack> bzr: ERROR: No such tag: upstream-0.1.0
[15:37] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 2 starting in 23 minutes in #ubuntu-classroom
[15:50] <james_w> ahasenack, double odd, as I think that's a brand new bit of code that would give that error :-)
[15:50] <ahasenack> james_w: the tag one?
[15:50] <james_w> yeah
[15:50] <ahasenack> james_w: maybe it leaked into that ppa then
[15:51] <ahasenack> james_w: fwiw, I uploaded the recipe to lp and am building there now, it seems to be working: https://code.launchpad.net/~landscape/+recipe/landscape-txstatsd-daily-test
[15:51] <ahasenack> james_w: except for the "2h to build" part :(
[15:51] <ahasenack> that's why I wanted to try locally too
[15:51] <james_w> ahasenack, yeah, it's on trunk, so should be in the PPA, but it's odd that one error suggests you are using really old code, and the other error suggests really new code :-)
[15:51] <james_w> I must be misremembering
[15:52] <james_w> ahasenack, try with --allow-fallback-to-native to get around the "no upstream tag" error
[15:54] <ahasenack> james_w: worked with 0.1.0-1~{revno}: https://pastebin.canonical.com/49640/
[15:54] <james_w> cool
[15:54] <james_w> should work on LP then
[15:55] <ahasenack> james_w: but broke again once I used {debupstream}
[15:55] <ahasenack> bzr: ERROR: Invalid deb-version: {debupstream}-1~14: Could not parse version: {debupstream}-1~14
[15:56] <james_w> hmmmmmmmm
[15:56] <james_w> and it doesn't say "here are the valid substitutions?"
[15:56] <ahasenack> same cmdline, with --allow-stuff
[15:56] <ahasenack> james_w: full output: http://pastebin.ubuntu.com/642724/
[15:56] <ahasenack> I just replaced 0.1.0 in the recipe with {debupstream}
[15:57] <james_w> ok, give me two minutes
[15:57] <ahasenack> ok
[16:00] <james_w> ah debupstream is excluded from the "here are the valid substitutions" code for some reason
[16:01] <apw> cjwatson, who is the right person to talk to to figure out why a package is getting built on architectures not mentioned in its control file; its causing issues with our tooling
[16:02] <apw> (that is building in a PPA)
[16:02] <james_w> ahasenack, try {debupstream:packaging}
[16:02] <ahasenack> ok
[16:03] <ahasenack> james_w: no go: bzr: ERROR: Invalid deb-version: {debupstream:packaging}-1~14: Could not parse version: {debupstream:packaging}-1~14
[16:03] <slangasek> apw: abstractly, #ubuntu-devel :-)
[16:03] <ahasenack> still using that --allow switch
[16:03] <cjwatson> apw: what issues does it cause?  it should just harmlessly fail
[16:03] <james_w> ahasenack, ok, please file a bug
[16:03] <ahasenack> james_w: ok
[16:03] <apw> cjwatson, yeah but the tooling is seeing the errors and reporting the failure back instream of moveing the package on, now we could bodge the tools but it'd be nice to fix it if we can
[16:03] <cjwatson> apw: (but anyway, LP, perhaps bigjools)
[16:03] <james_w> probably two in fact, one about you not being able to get {debupstream} to work, and the other about the error not being at all helpful
[16:04] <ahasenack> james_w: do you know the project name by memory perhaps?
[16:04] <james_w> ahasenack, bzr-builder
[16:04] <ahasenack> of course :)
[16:05] <infinity> apw: Out of curiosity, which PPA and package?
[16:07] <apw> infinity, the canonical-kernel-team PPA and the lts-backports-* packages
[16:07] <apw> cjwatson, thanks will ask in that direction
[16:08] <infinity> Architecture: any
[16:08] <infinity> apw: ^-- Not seeing how you expect LP to do what you want there.
[16:09] <cjwatson> ha
[16:09] <apw> infinity, Architecture: any mean arch-independant doesn't it ?
[16:09] <infinity> That would be "all".
[16:09] <apw> which means essentially 'i386' no ?
[16:10] <apw> oh have we borked it ?
[16:10] <infinity> What you want is "amd64 i386", if that's all you support.
[16:10] <infinity> "any" means "build on everything".
[16:10]  * apw looks foolish and goes figure out why thats not either i386/amd64 or all ... thanks
[16:10] <infinity> It definitely shouldn't be all.
[16:10] <infinity> Unless lts-backports has no compiled code. :P
[16:11] <cjwatson> we haven't borked anything, any and all have always had these meanings
[16:11] <ahasenack> james_w: #809412 files, thanks for the debugging session :)
[16:11] <ahasenack> filed
[16:11] <infinity> cjwatson: I think he meant "we" as "the kernel team".
[16:11] <cjwatson> aha
[16:11] <apw> cjwatson, no i meant ... yeah what he said
[16:11] <apw> thanks all
[16:11]  * ahasenack -> lunch
[16:11] <cjwatson> yep, sorry, misread
[16:43] <Laney> can someone do a no-change rebuild of gmime2.4 please?
[16:44] <Laney> for mono transition
[16:45] <seb128> Laney, should we just sync the current version from debian?
[16:47] <Laney> seb128: no, that got accidently made native
[16:49] <seb128> Laney, ok, can do the no change rebuild
[16:50] <Laney> thanks
[16:50] <seb128> yw
[16:54] <pitti> skaet: seems the natty-backport lucid kernel got acked by kernel team (https://bugs.launchpad.net/bugs/806586) -- want to try?
[16:55] <skaet> pitti,  yes,  lets see what happens this time.
[16:57] <skaet> pitti,  same failure on the assert, I'm afraid.
[16:57] <pitti> skaet: weird -- I'm afraid that requires a launchpad guru at this point :/
[16:58] <skaet> pitti,  ack, will go and see if someone can help figure it.
[17:01] <seb128> janimo`, thanks for the gnome-utils build fix, do you plan to send it to upstream as well?
[17:55] <Phr3d13> the vt6410 pci raid/ide card doesn't work in ubuntu 10.10
[17:58] <pitti> good night everyone
[17:59] <dupondje> nite
[18:21] <patrickmw> mvo: ping
[18:25] <Phr3d13> has anyone ever gotten a pci vt6410 raid/ide card to work in ubuntu 10.10?
[18:25] <dupondje> Phr3d13: whats not working? Tried 11.04 ? Do you find anything on google about it ?
[18:26] <Phr3d13> ubuntu sees the card, but not any drives attached to it, and i have googled, but can't find any confirmed or unconfirmed fixes
[18:26] <Phr3d13> any info i found is really ol
[18:26] <Phr3d13> d
[18:27] <dupondje> can you pastebin info of lspci -vvv ?
[18:28] <Phr3d13> http://pastebin.com/pRSx2w6a
[18:29] <Phr3d13> line 213 is the controller
[18:30] <dupondje> it is supported ?
[18:30] <dupondje> pata_via is loaded for it
[18:31] <Phr3d13> i'm not totally sure
[18:31] <Phr3d13> another reason i'm asking in the devel room
[18:33] <dupondje> can you pastebin dmesg ?
[18:33] <dupondje> cause card seems supported
[18:35] <Phr3d13> i couldn't get it all
[18:35] <janimo`> seb128, filed https://bugzilla.gnome.org/show_bug.cgi?id=654498
[18:35] <Phr3d13> http://pastebin.com/9wAr6Jkt
[18:38] <dupondje> Phr3d13: and there are how many disks attached ?
[18:38] <Phr3d13> just to make it clear, it's a pci addon card, not onboard
[18:38] <Phr3d13> two, a hard drive and a dvdrw
[18:38] <Phr3d13> the other two hard drives are connected to the on board connector that works
[18:40] <Phr3d13> and it works when i boot into windows
[18:41] <Phr3d13> dunno if that info helps
[18:41] <mvo> patrickmw: hello
[18:44] <dupondje> Phr3d13: weird, as its supported by pata_via
[18:44] <dupondje> I would try to upgrade to newer version 11.04
[18:45] <Phr3d13> but last time i tried that unity borked on me
[18:47] <Phr3d13> are some of the unity bugs fixed? cause i couldn't even use the gnome classic as unity would run there too
[18:48] <dupondje> most should work
[18:49] <Phr3d13> ok, one last question, should i go with the update manager update, or boot an 11.04 cd and update from there
[18:50] <seb128> janimo`, thanks
[18:51] <seb128> janimo`, btw better to attach the patch to bugzilla that to point to an ubuntu diff.gz
[18:52] <seb128> janimo`, you might get a sneaking comment asking you to add a proper patch if they reply this way
[18:53] <seb128> janimo`, i.e bugzilla will not mark the bug as having a patch since it doesn't, it just has an url as a comment so it's likely that they will overlook it, and if they don't it's likely that they will not be wanting to clean an ubuntu debdiff to get the patch and will ask you to update with a proper one
[18:56] <dupondje> Phr3d13: do-release-update normally
[18:56] <dupondje> :)
[18:58] <Phr3d13> do-release-upgrade?
[19:02] <janimo`> seb128, I am not sure I mean this as a real patch against upstream, just one of the possible workarounds. They could as well disable -Wcast-align, or use some other code changes. I filed it mostly they get notified and maybe ask for details. I am not sure this fix is the best that can be done
[19:03] <Phr3d13> dupondje, fingers crossed, process started
[19:06] <seb128> janimo`, ok, your description doesn't make that clear
[19:07] <seb128> janimo`, let's see what they do, thanks anyway for sending it there ;-)
[19:07] <janimo`> seb128, np, I hope they react in some way
[19:07] <janimo`> I wish LP did this whole thing with a single click both for Debian, GNOME and other upstreams
[20:13] <serue> NMinker: hi.  i was compiling open-vm-tools by setting up a oneiric schroot as per https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment, and doing fakeroot debian/rules build
[20:14] <serue> doh
[20:20] <barry> kirkland, so i was thinking.  why not store wrapped-passphrase in U1?
[20:21] <kirkland> barry: you could back it up there, of course
[20:21] <kirkland> barry: but you might not want it exclusively there, like maybe when you're on a plane
[20:22] <barry> kirkland, true.  could still be a helpful prompt once you set up u1
[20:22] <barry> kirkland, that's all you'd need though, right, just the wrapped-passphrase file?
[20:22] <kirkland> barry: right
[20:22] <barry> kirkland, and that's encrypted with your login passphrase, so it should be safe-ish to just copy that there
[20:22] <kirkland> barry: some users might not trust their wrapped-passphrase to U1
[20:23] <kirkland> barry: so it'd need to be opt-in, i suspect
[20:23] <kirkland> barry: exactly, safe-ish
[20:23] <kirkland> barry: which is fine by most people, i suspect
[20:23] <barry> kirkland, yep.  i guess if you're really paranoid, you could gpg encrypt that file locally before copying it to u1
[20:23] <kirkland> barry: for a better experience, it would be good to sync all of ~/.ecryptfs
[20:23] <kirkland> barry: exactly
[20:24] <barry> kirkland, cool.  i'll play with that and maybe file a wishlist to u1
[20:24] <kirkland> barry: sounds great
[20:24] <kirkland> barry: excellent idea, btw
[20:25] <barry> kirkland, as the tai chi masters say: invest in loss ;)
[20:25] <kirkland> barry: funny you say that ...  that's actually *why* i got invovled in ecryptfs in the first place :-)  loss of a laptop
[20:26] <barry> kirkland, :-D
[20:26] <barry> well, not about your lost laptop
[20:26] <kirkland> barry: i knew what you meant ;-)
[20:26] <barry> kirkland, phew!
[20:31] <barry> kirkland, bug 809549
[20:32] <kirkland> barry: subscribing ...
[20:49] <seb128> infinity, hey, you are not interested by take the current telepathy-glib versions for debian and reapply your armel workaround by any chance? I synced whatever was current but today updates was not ready to sync yet it seems, and it still fails on armel it seems
[20:49] <seb128> infinity, is there any chance you could get your armel workaround upstream or in debian otherwise? would be nice to be able to sync directly ;-)
[20:54] <slangasek> if I recall the bug, it's not really suitable for upstream
[20:55] <slangasek> and probably not needed in Debian unless the toolchain there has the exact same bugs
[20:57] <seb128> slangasek: the natty -O1 workaround was dropped since the toolchain got fixed, the current diff is a "increase the timeout of a test in the testsuit because the builders are slow"
[20:57] <slangasek> oh, ok
[20:57] <seb128> which would probably be fine for debian...
[20:58] <slangasek> true
[20:58] <slangasek> I'm surprised if they haven't needed it already
[20:58] <seb128> yeah, not sure ;-)
[21:11] <jamespage> cjwatson: sorry - the situation was entirely my fault - I was aware that 0ubuntu1 was in the NEW queue and had requested its removal prior to requesting the sync from Debian
[21:11] <jamespage> however I neglected to ensure that had actually happened
[21:15] <infinity> slangasek: Meh, seb left, but yeah, the current Ubuntu local patch isn't suitable for upstream.  It relates to lp_buildd being slow, not armel.
[21:15] <infinity> slangasek: (I upstreamed a patch with slightly increased timeouts for armel, which works fine for Debian, and then had to include a ridiculously long timeout patch just for us)
[21:15] <infinity> slangasek: There's a bug against lp-buildd to fix our own local problem.
[21:16] <slangasek> heh, ok
[21:16] <cjwatson> jamespage: ah, right, we maybe weren't quite responsive enough to all the archive requests in sequence then :-/
[21:18]  * infinity goes about reapplying his patch to the current package...
[21:18] <jamespage> cjwatson: a note on the sync request would have helped tho :-)
[21:18]  * jamespage makes a mental note just in case this crops up again
[21:27] <cjwatson> jamespage: yeah, I probably should have done
[21:28] <cjwatson> .orig.tar.* in-sync-ness is a general thing people need to be ultra-careful of when uploading new upstream versions, unfortunately - easy to shoot oneself in the foot
[23:16]  * infinity engages in cranial-furniture violence as he sees telepathy-glib succeed on every Debian architecture, and fail to build in Ubuntu.