[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.   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?


[04:09] <tenach> Hello.  I've started importing my project code from git and it does not link them to me under "Recent revisions".  It is linking to the other contributor, though.
[04:09] <wgrant> tenach: Which branch is this?
[04:09] <tenach> The main branch for my project, scrib.
[04:11] <wgrant> tenach: Have you recently added that email address to your Launchpad account? If you have, it may take up to 24 hours for the revisions to be linked.
[04:11] <tenach> Ah, that would probably explain it.  I added it maybe an hour ago.
[04:12] <tenach> wgrant, Thank you. I am still learning how to use launchpad.
[04:12] <wgrant> tenach: Once the daily cron job runs, all existing revision will be fixed up, and all future ones will be linked immediately.
[04:13] <tenach> That is pretty cool.
[07:08] <nigelb> someone says LP timesout when trying to file a bug
[07:08] <nigelb> known issue?
[07:12] <doctormo> nigelb: It happens sometimes, launchpad is one of those odd services with weird errors sometimes.
[07:12] <doctormo> nigelb: Did it report an oops-id?
[07:14] <nigelb> doctormo: dunno..  I was helping somone file a bug
[07:15] <wgrant> There's been a lot of work done in that area in the last couple of weeks.
[07:15] <doctormo> nigelb: Ah ok, when launchpad produces an error it should give an oops id which can be given to the devels here.
[07:15] <wgrant> I'm not sure how much of the fix is on edge, though.
[07:16] <nigelb> I'm not sure if this was on edge or not though
[07:16] <wgrant> Try to get an OOPS ID.
[07:16] <nigelb> maybe I should just ask her to do a -noredirect
[07:17] <wgrant> noredirect will be even worse.
[07:18] <nigelb> no I meant for filing a bug directly without using apport
[07:56] <FullFlannelJacke> Why is stuff taking so long to build on Launchpad?  I've got a package thats been waiting 40+ hours
[07:57] <nigelb> because there are a lot of builds scheduled?
[07:58] <wgrant> And Ubuntu Maverick Alpha 3 testing has taken some of the builders.
[08:06] <lifeless> I wonder if that hits us twice
[08:06] <doctormo> wgrant: How hard is it to set up your own ppa/builder and such on your own server?
[08:07] <wgrant> doctormo: Not impossible.
[08:08] <doctormo> wgrant: Ah, it's like that. Like time travel, but possibly harder.
[08:08] <wgrant> Heh.
[08:09] <wgrant> Well, I worked it out a year ago and documented it, so it's no longer terribly hard.
[08:09] <doctormo> wgrant: Something that could be packaged/scripted for easy setup on ubuntu servers?
[08:09] <wgrant> No.
[08:10] <wgrant> It's not thaaat easy.
[08:10] <doctormo> wgrant: Surely there is something automatable about the process? I thought computers were meant to do all my work without me even asking!
[08:11] <wgrant> LP just isn't easily forceable into a package like that.
[08:11] <wgrant> Yet.
[08:11] <doctormo> wgrant: Oh I didn't mean the entire of launchpad, just the building and posting of a ppa for example.
[08:12] <wgrant> At the moment that means you need Launchpad in its entirety.
[08:13] <doctormo> wgrant: There is something about that requirement which reduces my confidence in the launchpad codebase. Shoudn't modularity be the watchword of any modern programmer?
[08:13] <doctormo> Although then again, zope did it.
[08:14] <wgrant> doctormo: One would think so. Work is ongoing to split it up, for reasons somewhat similar to your request.
[08:15] <lifeless> also you have to rebrand it
[08:15] <lifeless> but you could do that once
[08:15] <lifeless> LP is modular in some ways
[08:16] <wgrant> And really not modular in most of the others.
[08:16] <lifeless> but there's still a dependency chain on services
[08:16] <lifeless> e.g. PPA wants to know about users/groups, about CoC signing as external interfaces
[08:17] <lifeless> wgrant: given LP's /job/ is to integrate things horizontally, to join-the-dots, I think one needs to things carefully about what modularity really means for it
[08:18] <wgrant> lifeless: LP's job is, yes.
[08:18] <wgrant> Vostok's probably isn't.
[08:19] <lifeless> vostok doesn't know what vostoks job is
[08:19] <wgrant> No.
[08:19] <doctormo> lifeless: That depends, trust signing and all that could probably have been done better as an interface that a dep.
[08:20] <lifeless> doctormo: it is, a required interface is a dep
[08:23] <doctormo> other things could implement the same interface.
[08:23] <lifeless> thats true
[08:23] <lifeless> however
[08:23] <lifeless> the integration point for the interface is currently 'in the same database'
[08:23] <lifeless> changing that without creating a huge mess is, I suspect, a fair chunk of work
[08:26] <lifeless> I'd like us to do that eventually, because of the scaling and robustness properties it brings, if nothing else.
[09:30] <JoshBrown> Is it possible to put a branch on multiple sites, allowing people to make commits using different version control systems?
[09:31] <JoshBrown> (e.g. GitHub+git, Launchpad+bzr, SourceForge+svn, etc)
[09:41] <nigelb> all the best with that
[09:41] <nigelb> it sounds like a nightmare waiting to happen
[09:42] <nigelb> (personal opinion only)
[09:43] <jpds> I agree with nigelb, sounds chaotic.
[09:47] <JoshBrown> Okay, I'll give it up - to be honest, I didn't hold much hope anyway.
[11:42] <d34df00d> Hi!
[11:42] <d34df00d> I've got a small question regarding translations in Launchpad.
[11:43] <d34df00d> When I upload a new version of .po file which contains new strings for translation as well (and some of them are translated already via other means than Launchpad), they are only marked as suggestions.
[11:43] <d34df00d> I upload them to my own project, so I have full permissions for it.
[11:43] <d34df00d> How could I make them be used by default, whithout clicking through and selecting them all manually?
[14:54] <Sia-> hi
[14:55] <Sia-> can you approve my .po file wordpress for CKB.po?
[15:41] <Sorceress> i need help with getting the ubuntu cd
[15:57] <[Dmitry]> Hello. Tell me what happened to the farm Launchpad (PPA)?
[15:58] <[Dmitry]> I already wrote a second time during assembly - Start 2010-08-03
[15:58] <[Dmitry]> о_О
[15:59] <[Dmitry]> Many times I was building packages, but this place I see for the first time
[16:25] <shadeslayer> [Dmitry]: i think alot of machines are down for maintainence or something
[16:25] <shadeslayer> specially 32 bit ones
[16:25] <X3> ah
[16:26] <rockstar> shadeslayer, [Dmitry], we're seeing increased load in the builders recently.
[16:26] <shadeslayer> rockstar: err.. not many builders for 32 bit as well.. see only 4 of them
[16:27] <[Dmitry]> over 900 jobs...
[16:27] <rockstar> shadeslayer, yeah, the ubuntu team usually lets us borrow some of their builders when they aren't using them.  They're using them currently.  :)
[16:28] <shadeslayer> hehe :D
[16:28] <shadeslayer> rockstar: so there are only 4 PPA builders in total ? :O
[16:29] <shadeslayer> for 32 bit builds
[16:29] <rockstar> shadeslayer, yeah, we're aware of the problem, and are getting new hardware soon.
[16:29] <shadeslayer> awesome :)
[16:29] <rockstar> shadeslayer, source package recipes (a new feature) also use the x86 builders, and they're starting to be used more.
[16:29] <shadeslayer> yeah .. i used them for a ppa :P
[16:31] <X3> hey peeps
[16:31] <X3> https://code.launchpad.net/~x3lectric/xbmc/svn-trunk
[16:31] <X3> that trunk revision is wrong
[16:32] <X3> the svn trunk is at 32381 the code import is 24263
[16:32] <X3> that isnt right
[16:43] <thopiekar> hi.. just a short question.. is there a reason why my packages will be build in 3days for maverick? are there so much packages in the quere?
[16:43] <thopiekar> ppa:canola/playground
[16:44] <shadeslayer> thopiekar: yep too much pressure :P
[16:44] <geser> thopiekar: apparently, see https://edge.launchpad.net/builders/
[16:45] <thopiekar> wow
[16:46] <thopiekar> and another thing.. I deleted own ppa's but they are just marked as "going to be removed" for weeks, maybe a month now..
[16:46] <thopiekar> https://launchpad.net/~thopiekar
[16:47] <kklimonda> I love how chromium daily builds use over a half of builders right now :/
[16:49] <thopiekar> kklimonda: can't they just remove "outdated" builds that are in the quere?
[16:50] <thopiekar> and: is there a way to add builders?
[16:50] <thopiekar> maybe add a chroot on my machine and help out?
[16:50] <thopiekar> just a offer :P
[16:52] <shadeslayer> thopiekar: i dont think thats possible ( wrt helping out :P )
[16:53] <thopiekar> ;)
[16:54] <thopiekar> in my case there are lot of arch independent packages can't you switch to use a x64 builder for that?
[16:56] <thopiekar> or armel? there are no jobs, at the moment..
[16:57]  * [Dmitry] While the launchpad busy, had gone build packages to https://build.opensuse.org
[19:15] <sebi_`> Hi, how would I remove a registered project (that has been registered by me)?
[19:21] <sebi_`> looks like removing all the data, branches, owners etc already takes care of that. I'm still open for help, though.
[20:06] <ion> This is most likely a known issue, but https://edge.launchpad.net/ubuntu/maverick timeouts for me. Error ID: OOPS-1673EC3932
[20:09] <shadeslayer> ion: seems to work for me
[20:10] <ion> Works now for me, too.
[20:36] <alkisg> Hi, just out of curiosity, I uploaded something to my ppa and the i386 build is starting at ...4 days! Why are the servers so much loaded? PartnerUploadDeadline?
[20:42] <[Dmitry]> alkisg: I already asked this question today.
[20:42] <alkisg> And? Did you get any answers?
[20:43] <Cepheus> alkisg: Possibly, or a batch of updates.
[20:43] <[Dmitry]> alkisg: Alternatively, you can go drink beer with friends:)
[20:43] <alkisg> That sounds like a good plan... 4 days of beers should be fine :P
[20:43] <[Dmitry]> :D
[20:43] <alkisg> Thanks [Dmitry] :)
[20:43] <[Dmitry]> np )
[20:45] <[Dmitry]> alkisg: In fact, I was told that it will soon add a server. And sometimes canonical provide servers for building. But they are now engaged
[20:46] <alkisg> https://launchpad.net/builders/ ==> i386          4 builders                                      819       jobs               (three days)
[20:46] <[Dmitry]> alkisg: So the best plan, that go to drink beer:)
[20:46] <alkisg> I wonder if they could easily move some of the 7 amd64 builders to become i386 builders
[20:47] <[Dmitry]> alkisg: When I sent the package, there were more than 950 tasks, so it's unloaded:)
[20:48] <alkisg> Phew, ok, because I wouldn't have enough money for beer while waiting for 950 tasks... with 819 I think I can manage :P
[20:48] <[Dmitry]> haha )
[20:49] <[Dmitry]> alkisg: my scor is 2505
[20:50] <[Dmitry]> score*
[20:50] <alkisg> Woah
[20:50] <[Dmitry]> alkisg: And you have how many?
[20:51] <[Dmitry]> alkisg: https://launchpad.net/~itmages/+archive/software/+build/1898891 :)
[20:52] <alkisg> The same, 2505 - what's that? https://launchpad.net/~ts.sch.gr/+archive/proposed/+build/1898731
[20:52] <alkisg> Is it possible that we both have the same number of jobs ahead of us?
[20:52] <[Dmitry]> alkisg: https://help.launchpad.net/Packaging/BuildScores :)
[20:52] <alkisg> Ah, got it
[20:53] <alkisg> So if we packaged it as "emergency", we'd get down to 2490
[20:54] <[Dmitry]> alkisg: Points can be improved slightly honest way, for example in changelog to indicate urgency= > low
[20:54] <[Dmitry]> :)
[20:54] <[Dmitry]> But I do not, I have nowhere to hurry:)
[20:55] <alkisg> Me neither, that's why I was just asking out of curiosity :)
[21:22] <shadeslayer> private ppa++ :P
[21:22] <[Dmitry]> cost?
[21:23] <shadeslayer> [Dmitry]: idk.. i have access to a team private ppa
[21:23] <shadeslayer> probably free for the team as well :)
[21:23] <shadeslayer> because we use it to test KDE packages for kubuntu
[21:43] <doctormo> shadeslayer: How do private ppas work?
[21:49] <[Dmitry]> $$$ :)
[21:50] <shadeslayer> doctormo: well the only difference is that, only specific people are granted access
[21:50] <shadeslayer> and that builds get a score of 12505
[21:51] <doctormo> I wonder why that number
[21:51] <shadeslayer> and you need apt-transport-https to access builds from that ppa
[21:51] <shadeslayer> doctormo: 10000 + 2505
[21:51] <shadeslayer> 2505 is the usual score for ppa's
[21:53] <shadeslayer> and thats about it :P
[21:53] <shadeslayer> oh and you get 10 GB of space
[21:53] <doctormo> shadeslayer: Limited by group access?
[21:53] <shadeslayer> instead of 2GB
[21:54] <shadeslayer> doctormo: yes.. only the team admins can allow access
[21:54] <doctormo> shadeslayer: I mean, can the tam admins allow access to another team?
[21:55] <shadeslayer> doctormo: ah.. i would guess so
[21:55] <shadeslayer> for eg. when i was granted access to the private ppa, i also go upload rights to other kubuntu ppa's
[21:56] <shadeslayer> so probably yes
[22:03] <shadeslayer> hmm ive forgotten how to create a custom dput entry :S
[22:03] <shadeslayer> whats the ppa name for : ppa:foo/ppa
[22:04] <shadeslayer> foo? foo/ppa? whut?
[22:06] <crimsun> fqdn = ppa.launchpad.net\nmethod = sftp\nincoming = ~foo/ppa/ubuntu\nlogin = you
[22:13] <wgrant> shadeslayer: Why are you creating a custom dput entry? There's one built-in to Ubuntu.
[22:13] <shadeslayer> wgrant: no for a PPA :P
[22:14] <shadeslayer> i have access to mutiple ppa's... i want to upload a package to one of them
[22:15] <wgrant> shadeslayer: In the last few Ubuntu releases, just 'dput ppa:username/ppaname something.changes'
[22:15] <wgrant> It's builtin.
[22:15] <shadeslayer> :o
[22:15] <shadeslayer> wgrant: im on maverick so will test that
[22:15] <shadeslayer> which is prett awesome
[22:15] <shadeslayer> *pretty
[22:15] <wgrant> It's been that way for several releases. that's why the PPA page to says to do it that way...
[22:16] <shadeslayer> ive never noticed.. i always do it the .dput.cf way :p
[22:17] <shadeslayer> but since it was a long time since i added a entry to dput.cf ive forgotten :)
[22:21] <shadeslayer> oh my...
[22:25] <doctormo> shadeslayer: Oh my yes
[22:25] <wgrant> Oh my?
[22:25] <shadeslayer> doctormo: apparently my cowbuilder has only /etc :P
[22:27] <doctormo> shadeslayer: Don't have a cow?
[22:27] <doctormo> Bad news that
[22:27] <shadeslayer> doctormo: fresh maverick install :P
[22:27] <shadeslayer> downloading kdegames 4.5 to package :P
[22:27] <doctormo> shadeslayer: Ah, maverick is going all sleek and modern by just having an etc directory?
[22:28] <shadeslayer> hehe
[23:02] <c_korn> hello. are the i386 PPA builders shut down or busy ? normally I see an estimated start time if a build has been queued: https://launchpad.net/~c-korn/+archive/ppa/+build/1897834
[23:02] <[Dmitry]> Haha
[23:02] <[Dmitry]> hot topic :D
[23:03] <c_korn> I have read the topic. it was not mentioned. so cannot be that hot :)
[23:03] <[Dmitry]> c_korn: read http://paste.ubuntu.com/471622/
[23:07] <c_korn> [Dmitry]: thanks. so the builders are just busy.
[23:07] <[Dmitry]> very busy
[23:08] <c_korn> problem is that in my vlc PPA the amd64 packages are already built. and they depend on arch independent packages which will get there with the i386 build. so updating currently fails…
[23:09] <wgrant> The builders are busy, mostly because lots of them have been taken for maverick alpha 3 testing.


[02:32] <bachler> http://users.laggarbo.net/~alexander/breezy/breezy_monoply_1600.jpg
[12:29] <klepas> anyone awake?
[03:31] <henrik> hi everyone
[03:35] <henrik> I filed a bug concerning the bundled themes in ubuntu: http://bugzilla.ubuntu.com/show_bug.cgi?id=17228
[03:36] <henrik> and I was told this was the kind of thing the art team could work on
[03:36] <henrik> is updating the bundled themes for dapper a realistic task?
[03:37] <henrik> I'm just thinking it would allow ubuntu to include humility, tango, nuoveXT, gperfection, etc. without getting into the whole "NEW DEFAULT THEME" debate
[03:39] <henrik> so yeah :)