[00:03] <stgraber> slangasek: bug 1086612
[00:06] <stgraber> slangasek: as for ureadahead, it attempts to write to debugfs which isn't allowed in containers (/sys/kernel/debug/tracing/events/fs/do_sys_open/enable). We're not allowing that path for obvious reasons as kernel tracing from a container would let the user access everything that's going on on the host and any other containers.
[00:06] <slangasek> stgraber: ta, will see what I can figure out there
[00:07] <slangasek> stgraber: right, but ureadahead should also fail gracefully with minimal impact on the system, shouldn't it?
[00:08] <stgraber> slangasek: sure, none of the failures I'm trying to fix are causing breakage or we'd have fixed them a while ago. I'm just trying to get /var/log/upstart into a reasonable state on a clean container :)
[00:09] <stgraber> as currently we're getting errors in there at every boot because of those various jobs failing
[00:09] <slangasek> stgraber: heh, I don't even have that clean on a real system :P
[00:11] <stgraber> slangasek: well, I'm certainly ignoring the usual ones (networking, procps, ...) where the output is actually useful to have and those jobs are actually working :)
[00:12] <slangasek> stgraber: I'm certainly ok with improving the code to not output spurious errors, I just am reluctant to see this done by adding further complexity to the job start rules
[00:21] <slangasek> stgraber: please make lxc-create fail when given a --dir argument pointing to an already-existing directory :P
[00:57] <stgraber> slangasek: oh, interesting, I never looked at the "dir" backingstore plugin but yeah, it's definitely broken, will add that to my todo unless hallyn beats me to fixing it (as I believe that's his code ;))
[00:58] <slangasek> stgraber: heh :)
[00:59] <stgraber> it's the first time I use any of the fancy alternate backingstore, I tend to just use the default, which happens to properly check for existing rootfs :)
[01:35] <ikepanhc> @pilot in
[01:38] <penguin42> ikepanhc: If you fancy a nice simple 1 line change (+ comment) bug 1033250 I've got a branch against
[01:44] <ikepanhc> penguin42: that looks nice, let me try that first
[01:45] <penguin42> ikepanhc: There's a bzr branch against it I made marked for review
[04:08] <ikepanhc> @pilot out
[08:07] <dholbach> good morning
[08:15] <rbasak> ogra_: I can't check highbank due to a separate issue, but flash-kernel-installer appears fixed for armadaxp at least. Do you have SRU plans?
[08:23] <dholbach> Amaranth, happy birthday! :)
[08:23] <Amaranth> dholbach: Thanks! :)
[08:24] <dholbach> didrocks, you are a hero!
[08:24] <didrocks> hey dholbach ;)
[08:24] <didrocks> dholbach: please install from the ppa and keep me posted how it goes :)
[08:24] <didrocks> (and thanks)
[08:42] <pitti> Good morning
[09:20] <ev> bdmurray: https://launchpad.net/~ev/+archive/whoopsie-daisy/+build/4037968
[09:37] <mpt> pitti, bdmurray, xnox, ev: bug 1072854
[09:58] <bdmurray> pitti, ev: https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fshare%2Fapport%2Fapport-gtk%3AOSError%3A%3Cmodule%3E%3Arun_argv%3Arun_crashes%3Arun_crash%3Amark_report_upload
[10:12] <ev> xnox: https://docs.google.com/a/canonical.com/document/d/1BWOIRdJvUueJa4cWV68UEY3nlmHgAVJY6aNGo6YSCQg/edit#heading=h.kqe6vo42l0y7
[10:17] <pitti> hm, is dput/ftp upload broken for anyone else than me?
[10:28] <ev> bdmurray: https://errors.ubuntu.com/api/1.0/most-common-problems/?limit=0&release=Ubuntu%2012.10&format=json
[10:31] <ev> bdmurray: https://errors.ubuntu.com/api/1.0/most-common-problems/?limit=100&release=Ubuntu%2012.10&period=day&callback=YUI.Env.DataSource.callbacks.yui_3_5_0_3_1354703350440_3040
[10:31] <bdmurray> ev: https://errors.ubuntu.com/api/1.0/most-common-problems/?limit=0&release=Ubuntu%2013.04&format=json
[10:37] <blackz> can someone please reject my ppa-purge upload to precise-proposed? thanks
[10:57] <bdmurray> blackz: I'll do it
[10:57] <blackz> bdmurray: thanks
[11:18] <pitti> bdmurray: python -c 'from apport.crashdb import get_crashdb; db=get_crashdb(None); r=db.download(1070952); r.write(open("/tmp/foo.crash", "wb"))'
[11:20] <mpt> mvo, in June someone with Launchpad karma of 6 marked bug 975320 as fixed. Today it's the most common error reported for all Ubuntu users, so I suspect it isn't fixed at all.
[11:29] <ev> pitti: we're talking about https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/979278 specifically
[11:33] <mlankhorst> will the quantal nexus7 ppa still receive updates or is it all going to be for raring?
[11:36] <bdmurray> pitti: modified_since is the searchTasks parameter
[11:43] <mpt> ev, pitti: bug 1086754
[11:52] <mlankhorst> ugh the raring image is corrupting crazily :P
[12:01] <mvo> mpt: oh, thanks! let me have a look
[13:04] <mdeslaur> @pilot in
[13:04] <seb128> can somebody reject https://code.launchpad.net/~andrikos/ubuntu/quantal/xserver-xorg-video-intel/fix-ati-hybrid/+merge/132956 ?
[13:04] <seb128> pitti, stgraber: ^
[13:09] <seb128> mdeslaur, since you do reviewing, what do you think about the popularity-contest 1 liner changes in the queue?
[13:10] <mdeslaur> I was just about to take a look at them, one sec
[13:10] <seb128> mdeslaur, I wonder if that should be || true rather than || exit 0... if no conffile is shipped it's probably not required (or the package should ship one)?
[13:13] <pitti> seb128: done
[13:13] <mdeslaur> seb128: the package installs the file in the postinst
[13:14] <seb128> pitti, danke
[13:14] <mdeslaur> seb128: it's an ec2 problem because of a bug in the script: http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/revision/524
[13:14] <mdeslaur> seb128: I don't think this is actually needed
[13:14] <seb128> mdeslaur, oh, doh, I was looking at the deb content, I didn't think it was coming from the postinst
[13:15] <seb128> mdeslaur, I see, that explains it, thanks ;-) you are going to close it with a pointer on the ec2 fix then?
[13:15] <mdeslaur> seb128: yes
[13:15] <seb128> mdeslaur, thanks
[13:15] <mdeslaur> seb128: are you patch piloting? why were you looking at that?
[13:17] <seb128> mdeslaur, I'm trying to help to clean a bit the queue recently, since quite some people don't do their shifts and things just stack ...
[13:17] <seb128> mdeslaur, but I'm done for now so don't worry about conflicts ;-)
[13:17] <mdeslaur> ok, cool, thanks
[13:18] <seb128> mdeslaur, I was also a bit annoyed by those populary-contest 1 liners taking 3 slots in the queue for over 1 month and being ignored ... seems like a trivial "|| exit 0" should be reviewable by any pilot...
[13:21] <mdeslaur> yeah
[13:22] <mdeslaur> I get the feeling people only look at packages they are familiar with
[13:22] <mdeslaur> not that I'm not guilty of doing that myself sometimes
[13:24] <pitti> tseliot: hey Alberto, how are you?
[13:24] <pitti> tseliot: still remember bug 1054458?
[13:24] <pitti> tseliot: this has been the #1 issue reported by users for a while
[13:24] <pitti> tseliot: tedg submitted a patch in https://code.launchpad.net/~ted/ubuntu/raring/ubuntu-drivers-common/nvidia-experimental-number/+merge/137754
[13:24] <pitti> tseliot: do you think you can look at this to ensure it's DTRT and commit/upload?
[13:38] <herton> @pilot in
[13:38] <bdmurray> mpt: bug 1086796
[13:49] <rbasak> ogra_: I can't check highbank due to a separate issue, but flash-kernel-installer appears fixed for armadaxp at least. Do you have SRU plans please?
[13:51] <pitti> ev: juju ssh errors/0 -L 8081:localhost:80
[13:52] <ev> pitti: \o/
[14:05] <tseliot> pitti: sure, I'll have a look at it
[14:06] <seb128> tseliot, hey, did you look at the fglrx requests from the queue I pointed the other day as well?
[14:14] <ogra_> rbasak, trying to get that done before end of the week, there are other f-k SRU bits i want in the same upload too
[14:14] <rbasak> ogra_: OK, thanks!
[14:25] <rickspencer3> good morning all
[14:28] <shadeslayer> evening rickspencer3
[14:28] <rickspencer3> :)
[14:32] <didrocks> hey rickspencer3
[14:33] <rickspencer3> bonjour didrocks
[14:35] <seb128> salut rickspencer3
[14:37] <rickspencer3> bonjour seb128
[14:48] <herton> @pilot out
[15:03] <infinity> Aaaan, APR cross-builds, but drops symbols along the way.  Fun.
[15:03]  * infinity compares native/cross configure output.
[15:08] <cjwatson> seb128: hey, are you already on top of the gnutls26 merge?  You're down as TIL via sponsorship.  I'd like to fix its build failure but perhaps if I'm doing that I should merge at the same time (though unstable's package fails in the same way)
[15:08] <seb128> cjwatson, I was trying to avoid it in hope somebody else would steal it, so if you want to grab it please do ;-)
[15:09] <cjwatson> heh, ok
[15:09] <infinity> And Colin once again accidentally ends up TIL on the entire archive.
[15:10] <infinity> cjwatson: Oh, do you want me to steal dpkg back from you, by the way?
[15:10] <vibhav> I was doing a merge for gnome-pp and saw that the Debian version had added wvdial to Build-Depends
[15:10] <vibhav> This was a fix for the armel architecture
[15:11] <vibhav> Should I include this fix? armel is obsoleted in raring
[15:11] <infinity> vibhav: Merges should be as close to Debian as possible.
[15:11] <mdeslaur> vibhav: that's a useless merge, don't do it
[15:11] <mdeslaur> vibhav: aren't you supposed to ask me first, since I TIL?
[15:11] <infinity> (Also, what's "gnome-pp", no such source package exists)
[15:12] <mdeslaur> gnome-ppp
[15:12] <vibhav> mdeslaur: yes, I was sending off an email to you
[15:12] <vibhav> :P
[15:12] <vibhav> infinity: gnome-ppp
[15:13] <vibhav> s/sending off/writing/
[15:13] <vibhav> Anyways, thanks mdeslaur
[15:13] <infinity> vibhav: For added bonus, even when we had armel, that patch did nothing for us.
[15:13] <infinity> Cause wvdial works on Ubuntu/armel.
[15:13] <mdeslaur> vibhav: there's plenty of other stuff I TIL that you can steal though :)
[15:14]  * vibhav takes a look
[15:14] <vibhav> infinity: ah yes
[15:14] <infinity> vibhav: Anyhow, the general rule of thumb is to not waste time on merges that do nothing at all, but if you were talking about a merge that also had other useful changes, yes, you should include the "do nothing" changes too, to keep the delta low.
[15:16] <vibhav> But there are not any changes, we can wait for a new version
[15:16] <vibhav> Thanks infinity
[15:25] <cjwatson> infinity: Yeah, if you could steal that back from me that'd be great
[15:28] <infinity> cjwatson: Will do.
[15:36] <dholbach> can somebody please moderate ubuntu-devel-announce?
[15:36] <cjwatson> dholbach: done
[15:36] <dholbach> thank you cj
[15:36] <dholbach> thank you cjwatson
[15:37] <dholbach> (sorry)
[15:39] <mpt> ev, bug 1086850
[16:23] <infinity> pitti: Sweet merciful ARGH.  Why is /usr/bin/pg_config a binary instead of a script?
[16:28] <arges> hello
[16:28] <infinity> Hi!
[16:28] <infinity> arges: bug 943502, why are you doing backports there instead of just cherrypicking the correct TLD lookups?
[16:29] <arges> ok looks like its working
[16:29] <arges> infinity, i think that was my initial approach... trying to remember why I didn't do that
[16:30] <smoser> infinity, so what is the correct policy for the un-namespaced "needs-verification" tag when there are multiple -prposed uploads
[16:30] <arges> infinity, let me give that a shot again
[16:30] <infinity> arges: tld_serv_list seems pretty straightforward.
[16:30] <smoser> ie, as in bug 1078926
[16:31] <infinity> smoser: Keep verification-needed set, but add verification-done-precise (or whatever) for the ones verified.
[16:31] <infinity> smoser: The little tag box should autocomplete those.  I think.
[16:32] <smoser> ah. ok.
[16:32] <infinity> smoser: This may not be the right advice for that specific bug, I'm just saying in general.  -needed while some task skill needs verification, and -done-$foo for the series that have been done.
[16:33] <infinity> smoser: This all falls apart miserably on bugs with multiple packages too. :/
[16:33] <smoser> right.
[16:33] <infinity> (The SecureBoot metabug is going to be a nightmare)
[16:34] <infinity> Gaze upon bug 1075181 and weep.
[16:34] <cjwatson> I'm pretty sure that's "wait for it all to work, and promote all at once" ...
[16:34] <infinity> cjwatson: Yeahp, but we need to go through each task and double-check it's all sane, then promote in a batch.  Will be fun.
[16:34] <smoser> could someone on SRU please look at my cloud-init upload in -proposed?
[16:34] <cjwatson> Because, you know, how else are you going to know :)
[16:34] <smoser> https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=cloud-init
[16:38] <barry> jodh, slangasek give me just a couple of minutes... if now is a good time
[16:38] <slangasek> barry: wfm
[16:38] <hallyn> stgraber: slangasek: update to refuse --dir option which already exists to lxc-create sent to the mailing list, thanks.
[16:38] <slangasek> hallyn: thank you :-)
[16:38] <hallyn> funny thing, I see I wrote it, but I don't remember doing the --dir...  oh well.
[16:39] <stgraber> hallyn: :) I'll take a look at the patch and apply it
[16:39] <hallyn> thanks both
[16:39] <hallyn> now back to my qemu packaging disaster
[16:43] <barry> slangasek, jodh okay, i have the machine in the stalled state, and i'm ssh'd in.  the last thing i see on the console is "Stopping save kernel messages".  twisty maze and all that. :)
[16:44] <slangasek> barry: yep.  what's the output of 'sudo initctl list', and if the rc job is still running, what does ps fxwa show for its children?
[16:45] <tseliot> seb128: yes,
[16:45] <barry> slangasek: http://paste.ubuntu.com/1412816/
[16:45] <tseliot> seb128: yes, but I haven't merged them yet
[16:46] <seb128> tseliot, ok, do you plan to merge them soon? we are trying to clean the sponsoring queue and they are sitting there for some weeks...
[16:47] <slangasek> barry: please run 'sudo chvt 1'
[16:48] <barry> slangasek: i'm on vt1 w/ login prompt on console
[16:48] <tseliot> seb128: I have more urgent changes to work on but I can do it next week
[16:48] <slangasek> barry: right - so now you're seeing what you're expecting?
[16:48] <jodh> barry: what are all those '*.sh' jobs?
[16:48] <seb128> tseliot, ok, thanks, I though those would be trivial and like 15min to merge ignore, no worry
[16:48] <slangasek> jodh: those are mountall being enhanced to neuter sysvinit in Debian
[16:48] <barry> slangasek: yes, this is what i'd expect by changing the vt
[16:49] <slangasek> (runtime neuter)
[16:49] <barry> jodh: dunno ;)
[16:49] <slangasek> barry: ok, so would it be fair to characterize this bug as "console is left on wrong VT at end of boot"?
[16:49] <slangasek> barry: or is there still another bug?
[16:49] <barry> slangasek: well, i would expect the greeter
[16:50] <slangasek> oh, you have lightdm installed
[16:50] <barry> slangasek: yep. and when the boot doesn't stall, i see the expected greeter screen
[16:50]  * slangasek points barry in the direction of the desktop team, then :)
[16:51] <slangasek> barry: it's either a kernel or an X bug; doesn't appear that the plumbing is doing anything wrong here
[16:51] <barry> slangasek: we've ruled out kernel
[16:52] <barry> slangasek: okay. if you're sure the plumbing is working properly, i'll retarget it against x and see what they say ;)
[16:53] <seb128> stgraber, pitti: can you reject those?
[16:53] <slangasek> barry: well, I'm also not sure why neither the lightdm nor the failsafe-x jobs are running
[16:53] <seb128> https://code.launchpad.net/~utlemming/popularity-contest/quantal.lp707311/+merge/131877
[16:53] <seb128> https://code.launchpad.net/~utlemming/popularity-contest/precise.lp707311/+merge/131876
[16:53] <pitti> oui, je peux
[16:53] <jodh> barry/slangasek: this might be bug 969489.
[16:53] <slangasek> barry: do you have any suggestive logs under /var/log/upstart?
[16:53] <pitti> seb128, stgraber: done
[16:53] <seb128> pitti, danke
[16:53] <barry> jodh: i'll look at that bug in a sec
[16:55] <barry> slangasek: % ls -lt *.log
[16:55] <barry> -rw-r----- 1 root root 2747439 Dec  5 11:36 ureadahead.log
[16:55] <barry> -rw-r----- 1 root root     105 Dec  5 11:35 hybrid-gfx.log
[16:55] <barry> -rw-r----- 1 root root     180 Dec  5 11:35 alsa-restore.log
[16:55] <barry> -rw-r----- 1 root root    3774 Dec  5 11:35 modemmanager.log
[16:55] <barry> -rw-r----- 1 root root    1071 Dec  5 11:35 procps-static-network-up.log
[16:55] <barry> -rw-r----- 1 root root      90 Dec  5 11:35 kmod.log
[16:55] <barry> -rw-r----- 1 root root      90 Dec  5 11:35 module-init-tools.log
[16:55] <barry> -rw-r----- 1 root root     256 Dec  5 11:35 rsyslog.log
[16:55] <barry> -rw-r----- 1 root root     192 Dec  5 11:35 dbus.log
[16:55] <barry> -rw-r----- 1 root root     138 Dec  5 11:35 container-detect.log
[16:55] <barry> -rw-r----- 1 root root    1071 Dec  5 11:35 procps-virtual-filesystems.log
[16:55] <barry> -rw-r----- 1 root root     129 Dec  5 11:35 console-setup.log
[16:55] <barry>  
[16:55] <slangasek> barry: and that's the time the machine booted?
[16:56] <barry> slangasek: no, it's in the stalled state right now
[16:56] <dholbach> didrocks, You're a hero!
[16:56] <slangasek> barry: er, the machine is booted, it just doesn't have lightdm running
[16:56] <didrocks> dholbach: I wasn't alone, but thanks :)
[16:56] <dholbach> awesome
[16:56] <barry> slangasek: sorry, yes, correct
[16:56] <ogra_> dholbach, two heros !
[16:56] <ogra_> (he is)
[16:57]  * didrocks hugs dholbach and ogra_
[16:57] <dholbach> :-)
[16:57]  * dholbach hugs you all
[16:57] <barry> slangasek, jodh: there's nothing in the upstart logs that standout to me
[16:57] <slangasek> barry: did timestamps on /var/log/lightdm/* or /var/log/Xorg.* update?
[16:59] <barry> slangasek: lightdm logs all show 11:35 or :36 today, so in line with upstart logs
[16:59] <slangasek> barry: hmmm.  and the contents of those logs?
[16:59] <barry> same with xorg
[16:59] <barry> slangasek: yep, looking now
[16:59] <slangasek> barry: best to attach them to the bug report
[17:00]  * barry nods
[17:05] <mdeslaur> @pilot out
[17:09] <slangasek> barry: mmm, you don't have this set to autologin or something?
[17:09] <barry> slangasek: nope
[17:10]  * dholbach hugs mdeslaur
[17:10] <slangasek> barry: and the lightdm.log that's attached is definitely from this latest boot?
[17:10] <barry> slangasek, jodh: interestingly, re bug 969489.  if i chvt 1 then sudo start lightdm, i get the greeter window
[17:10] <slangasek> barry: because at +3.62s, there's something interesting happening
[17:10] <barry> slangasek: definitely
[17:11] <slangasek> barry: yes, I would fully expect 'sudo start lightdm' to work; that's not dispositive of it being related to bug #969489
[17:11] <barry> do you mean the "greeter start authenitication for barry" and beyond bit?
[17:12] <barry> slangasek: ^^
[17:12] <slangasek> yes
[17:13] <slangasek> oh, I bet "start" just means that's the user that was last selected, and whose password box is popped up
[17:13] <barry> that makes more sense (and is what happens)
[17:15] <slangasek> barry: can you show the output of this command, please: grep -l 'start on runlevel .2345' /etc/init/*
[17:16] <barry> slangasek:
[17:16] <barry> /etc/init/acpid.conf
[17:16] <barry> /etc/init/alsa-restore.conf
[17:16] <barry> /etc/init/anacron.conf
[17:16] <barry> /etc/init/apport.conf
[17:16] <barry> /etc/init/atd.conf
[17:16] <barry> /etc/init/cron.conf
[17:16] <barry> /etc/init/dmesg.conf
[17:16] <barry> /etc/init/irqbalance.conf
[17:16] <barry> /etc/init/pulseaudio.conf
[17:16] <barry> /etc/init/whoopsie.conf
[17:16] <barry>  
[17:16] <barry> mine never drops into low-graphics mode, but it might be worth playing with some of the lightdm start hacks mentioned in bug 969489
[17:26] <slangasek> barry: hmm, how about this: grep -l 'start on runlevel .2345' /etc/init/* | xargs grep -lE 'kill|stop'
[17:26] <barry> slangasek: oops, i just rebooted it (but i saved the state, so hang on a sec)
[17:27] <slangasek> er, wait, that one's not useful
[17:27] <slangasek> grep -l '^start on runlevel .2345' /etc/init/* | xargs grep -l kill
[17:31] <barry> slangasek: i'm back in the stalled state.  that command returns nothing
[17:32] <slangasek> barry: ok. what it comes down to, I think, is that something non-standard is killing lightdm that shouldn't be; /var/log/lightdm.log gives us enough info to know the pid of what's doing the killing, but not the name.  Given that at and cron have just started, it *could* be a strange cronjob or at job; it's more likely to be something called from an upstart job; booting with --verbose and cross-referencing that output against the 'initctl
[17:32] <slangasek> ... and the /var/log/lightdm.log from the same boot *may* help isolate this
[17:33] <slangasek> barry: is this a pristine install of quantal?  no chance of extra or modified jobs in /etc/init/
[17:33] <slangasek> ?
[17:33] <barry> slangasek: it's running raring, but probably upgraded from quantal->precise->raring
[17:33] <slangasek> ok
[17:34] <slangasek> so you've said it's not reproducible with a clean precise userspace; have you checked with a freshly installed raring userspace?
[17:34] <barry> slangasek: i haven't but that's a good thing to try
[17:34] <barry> slangasek: can you (or i will) paste your longer message above into the bug?
[17:36] <barry> slangasek: so i think at this point, it's worth bringing up a fresh raring and seeing what happens.  i'll follow up on the bug report once i've done that.  for now... lunch :)
[17:37] <slangasek> barry: dumped that to the bug, along with some further thoughts
[17:38] <barry> thanks!
[18:34] <jono> is anyone else experiencing random lockups in raring?
[18:34] <jono> Unity seems to lock up
[18:35] <jono> and if I switch to a virtual terminal and back it is fine
[18:35] <seb128> jono, when did that start?
[18:35] <jono> seb128, I noticed it at the end of last week
[18:35] <jono> I do get a "I detected a lockup" error
[18:35] <seb128> not sure what changed around that time but it's not a known issue afaik
[18:35] <jono> and I mention it happens a few times a day
[18:35] <seb128> seems like an #ubuntu-x question/issue
[18:35] <jono> but then I am not sure if that data goes anywhere
[18:36] <jono> seb128, will mention in there
[18:36] <seb128> jono, the data should go to errors.ubuntu.com
[18:36] <jono> seb128, ok, there doesnt seem to be confirmation that the data was sent
[18:37] <seb128> jono, no, there is none, I think it's a design decision to get out of the user way as much as possible, it's a fire and forget dialog
[18:37] <jono> I see
[18:37] <jono> np
[18:38] <jono> thanks seb128
[18:38] <seb128> jono, yw!
[18:44] <seb128> jono, you can try to run: firefox 'http://errors.ubuntu.com/user/'$(printf $(sudo cat /sys/class/dmi/id/product_uuid) | sha512sum)
[18:45] <seb128> jono, that should open a page showing all the issues you reported, it's not sorted in an useful way though ...
[18:54] <jono> thanks seb128
[19:01] <marrusl> Hello.  I'm having some trouble with multi-arch dependencies.  I understand apt and dpkg understand :any for build-deps, but do they understand :any for regular depends?  I am not having luck with this.
[19:01] <marrusl> the depended-on package is marked "multi-arch: allowed"
[19:05] <exilarch> http://vbox7.com/play:4c0c38de34
[19:08] <jtaylor> isn't the :any implicit if the dependency is allowed?
[19:13] <marrusl> jtaylor, i think that would be the case if the depended-on package was marked "multi-arch: foreign", but with "m-a: allowed" I think the :any is needed.
[19:13] <marrusl> or else a 32-bit package depending on it will still insist on :i386
[19:14] <jtaylor> right allowed is only for arch all
[19:15] <marrusl> so in this case i'm testing gdb which is in -proposed now with "m-a: allowed" (it was explained to me that "foreign" wouldn't be correct for something like gdb)
[19:16] <marrusl> and when I create a dummy 32 bit package that depends on gdb:any, it's not working.
[19:16] <marrusl> i may retry on raring or quantal.  though this is intended for precise.
[19:19] <micahg> AIUI, binary :any is only recognized on raring+
[19:21] <marrusl> micahg, aha.  that could be it.  i'll recheck on raring.  thanks!
[19:37] <slangasek> marrusl, jtaylor: :any is intended only for use with packages that are M-A: allowed (and has nothing to do with whether the package is Arch: all).  This should work with apt and dpkg as for back as oneiric.
[19:37] <slangasek> whether it's *allowed* in the archive is another question
[19:38] <slangasek> micahg: do you have a source for the claim that :any is only recognized post-raring?  This was supposed to have been supported all along
[19:38] <marrusl> slangasek, oh no, no worries.  we know it's not going there.  :)
[19:38] <micahg> slangasek: oh, hrm, I thought dpkg had issues with it and that was the problem
[19:38] <slangasek> yeah - but it should *definitely* work in precise
[19:38] <marrusl> I must be doing something wrong.  I have to run afk for a bit, but I'll go back over it when I get back.
[19:38] <slangasek> micahg: not that I was aware
[19:39] <slangasek> marrusl: right, so I'm not sure why you're having the problem that you are; it was on my radar to try to test this locally but I haven't gotten to it yet
[19:40] <marrusl> slangasek, ok.  I'll catch up with you later after I retry.
[19:40] <marrusl> thanks
[21:08] <phillw> Hi folks, is there a way to pull in a release from debian/unstable? https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1086974/comments/2
[21:11] <tumbleweed> phillw: it needs to be merged. xnox touched it last, prod prod
[21:11] <phillw> thanks tumbleweed
[21:14] <infinity> We're already up to date on libguestfs, unless it was mismerged.
[21:16] <tumbleweed> ah, I saw ubuntuX and didn't look at the version
[21:17] <phillw> infinity: I'm on Package: libguestfs-tools 1:1.18.5-2 the newer one is 1.18.5-3
[21:18] <tumbleweed> phillw: 1:1.18.10-1ubuntu2 is published
[21:18] <infinity> phillw: Oh, you're running Quantal.
[21:18] <slangasek> phillw: the new version is merged in raring, not in quantal
[21:18] <phillw> I'm on quantal, do I need to grab this from raring?
[21:19] <slangasek> if you're requesting that this be fixed in quantal in particular, you'll need to 'nominate for release' on the bug.  But if you just want to test, yes, you should be able to grab the package from raring.
[21:20] <phillw> I'm okay with temp allowing raring to test. which deb would it be? (universe / main etc..) So I can add it, then disable to confirm it works for Q
[21:21] <slangasek> phillw: you can find the .deb in launchpad by browsing https://launchpad.net/ubuntu/+source/libguestfs/
[21:21] <slangasek> (click on version; click on architecture; find .deb file on page and click)
[21:27] <phillw> slangasek: sorry to be pain, I'm on https://launchpad.net/ubuntu/+source/libguestfs/1:1.18.10-1ubuntu2/+build/3960859 in order to get all the updates which should I choose?
[21:28] <infinity> phillw: dpkg -l \*guestfs\* | awk '/^i/ {print $2}'
[21:29] <infinity> ... Which won't get guestfish.  What a silly name.
[21:29] <infinity> phillw: dpkg -l \*guestf\* | awk '/^i/ {print $2}'
[21:37] <phillw> infinity: ooh.. depedency hell :P Let me have a play.
[21:55]  * infinity facepalms as he realises that the linux32 personality for aarch64 is armv8l instead of armv7l.
[21:55] <infinity> That's remarkably... Useless.
[21:56] <infinity> But at least they have a 32-bit personality to fix.
[21:58] <slangasek> armv8l - that's just the name, yes?
[22:17] <infinity> slangasek: It's what "linux32 uname -m" produces on an aarch64 kernel.
[22:17] <infinity> slangasek: About as useless as if x86_64 said "i786" instead of the much more pleasant lie of "i686".
[22:17] <slangasek> right
[22:19] <infinity> Anyhow, I think I'll bug someone about that, since the most obvious use-case for "linux32" most of the world over is "building brain-dead software on a 64-bit host", all of which has configure scripts looking for armv7l. :P
[22:42] <phillw> slangasek: how do I add a 'nominate for release' to the bug? https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1086974/comments/3
[22:42] <phillw> zero regression risk, as it didn't use to work :D
[22:48] <mwhudson> that's the "upstream developer thinks ubuntu is stupid" bug?
[22:59] <slangasek> phillw: there should be a link with that as its title; or maybe 'Target to release'
[23:00] <cjwatson> You only get either if you're in at least ubuntu-bugcontrol
[23:03] <slangasek> ah
[23:03] <slangasek> right, I assumed phillw was
[23:03] <phillw> cjwatson: slangasek I'll go a hunting 'TheLordOfTime" in that case :) But, it does work and I hope I've put enough information on there for you guys to allow it into 'Q'.
[23:03] <phillw> slangasek: I'm only bug-squad, not bug-control :)
[23:55] <arosen> Anyone know off hand if there is a way to make debchange not prompt for input in an editor?
[23:56] <sarnold> arosen: try unsetting TERM first?
[23:56] <sarnold> (there's surely a better way, but I've seen some of those scripts say "TERM unset, <skipping something>"
[23:57] <arosen> sarnold: nope it says Error opening terminal: unknown.
[23:59] <maxb> arosen: In what mode?