[00:24] <straemer> Hey, I'm trying to build ubuntuone-android-music, and am getting a build error
[00:24] <straemer> BUILD FAILED
[00:24] <straemer> /home/stephen/.android-sdk-linux/tools/ant/build.xml:574: ../../ubuntuone-android-sso/ubuntuone-android-sso resolve to a path with no project.properties file for project /home/stephen/Programs/ubuntuone-android-music
[00:43] <dobey> xnox: software-center pkg import has been broken for quite some time.
[00:56] <kenvandine> @pilot out
[01:33] <fdfdfd> HI ALL
[01:33] <fdfdfd> anyone here
[01:34] <sarnold> fdfdfd: 300+ .. though who is awake and around may vary.
[01:35] <fdfdfd> sarno;d may i quayr you please it a lot earier for me
[01:36] <sarnold> fdfdfd: it'd be best to ask questions in the channel, that way other people can learn, or correct me if I'm wrong :)
[02:43] <fdfdfd> i got a quick question sence i reinstall windows xp on to my computer will and from linux be on my computer now
[02:43] <fdfdfd> STILL
[02:43] <fdfdfd> opps caps on still LOL
[02:43] <fdfdfd> sorry
[02:44] <straemer>  fdfdfd: I think you want the #ubuntu channel
[02:44] <fdfdfd> ths is unbuntu channle
[02:44] <straemer> no, this is #ubuntu-devel
[02:45] <fdfdfd> you cant get help from here
[02:46] <straemer> well the ubuntu channel is dedicated to support, so you'd have better luck there
[02:47] <fdfdfd> in this room youall just caht about bull s ****
[02:49] <fdfdfd> and talk about what ever
[02:49] <fdfdfd> ok thank you streamer
[03:52] <pitti> Good morning
[05:44] <mlankhorst> gday!
[06:30] <dholbach> good morning
[06:40] <caribou> slangasek: infinity: thanks for expediting the rsyslog regression fix
[06:42] <jdoles> How can I backport a package?
[06:48] <maxb> jdoles: Need more context - to build locally, to build in a PPA, or the process for getting something into raring-backports etc.
[06:49] <jdoles> maxb: locally
[06:50] <Versable> Hey, vala troubles
[06:50] <Versable>  Package `webkitgtk-3.0' not found in specified Vala API directories or GObject-Introspection GIR directories
[06:50] <Versable> I know to cp webkit-1.0.vapi to webkitgtk-3.0.vapi  and  webkit-1.0.deps to webkitgtk-3.0.deps
[06:50] <Versable> But I am trying to package, what's the workaround
[06:50] <jdoles> maxb: I installed backportpackage, but that doesn't do anything useful when used in the obvious way.
[06:50] <maxb> jdoles: Well, that's a very very broad question. It's easy to answer "modify the package source appropriately and build it", but that's not very helpful to you
[06:51] <maxb> Ah, you mean in reference to a specific helper scirpt
[06:51] <jdoles> maxb: https://wiki.ubuntu.com/UbuntuBackports#Building_a_Backport
[06:51] <jdoles> maxb: I am just following instructions.
[06:51] <jdoles> maxb: and they don't work.
[06:52] <maxb> I think they work, they just aren't as detailed as you'd like
[06:52] <jdoles> maxb: I don't see why I can't just run a tool which downloads the right source package, drops me in a directory where I can run make buildpackage and then get a deb out.
[06:53] <jdoles> maxb: as detailed? The program tells me that I need to specify an upload target or something else.
[06:53] <jdoles> maxb: both options are not applicable.
[06:53] <jdoles> maxb: hence, the program has a bug.
[06:53] <jdoles> maxb: since the wiki is wrong, I ask here.
[06:56] <maxb> I get that you're frustrated, but it doesn't help to claim the instructions are wrong when they're not
[06:57] <maxb> They identify a specific helper script, with the expectation that users will refer to its help and/or manpage
[06:57] <jdoles> Usage: backportpackage [options] <source package name or .dsc URL/file>
[06:58] <jdoles> Source package name: I choose bc.
[06:58] <jdoles> backportpackage bc
[06:58] <jdoles> backportpackage: error: Please specify either a working dir or an upload target!
[06:58] <jdoles> Documentation is simply wrong.
[06:58] <jdoles> maxb: why do you make up excuses?
[06:58] <maxb> So now you actually go read the help message and specify one of those things (-w or -u options)
[06:59] <jdoles> maxb: it's -U
[06:59] <maxb> No it isn't
[06:59] <jdoles> maxb: and the USAGE doesn't say I need to specify it.
[06:59] <jdoles> maxb: ok, so indeed it's -u, but still irrelevant.
[07:00] <jdoles> maxb: so, whoever wrote USAGE was plain unambiguously WRONG.
[07:00] <jdoles> maxb: you should talk to whoever wrote that script, because it wastes the time of people.
[07:00] <jdoles> maxb: you should *not* point at me saying that I did something wrong.
[07:01] <maxb> You say "wrong" I say "omitted a small detail which you easily discover via a reasonably helpful error message on first use"
[07:01] <jdoles> I frankly don't get why you even endorse such broken programs.
[07:01] <jdoles> But then again, you also developed Unity.
[07:01] <maxb> I frankly don't get why you seem to think it's worth typing this diatribe.
[07:02] <jdoles> maxb: the error message is *not* helpful.
[07:02]  * maxb stops feeding the troll
[07:02] <jdoles> maxb: I have no idea what to do, because I matched the required inputs.
[07:02] <jdoles> maxb: I read USAGE, gave valid values and the program returns an error.
[07:03] <jdoles> That means that the problem is on the side of the author of said program.
[07:04] <Versable> Ouch
[07:04] <jdoles> I am now doing it via a different method, a less high-level approach such that I don't need to work with this broken sh*t.
[07:06]  * maxb wonders if ubuntu-dev-tools really needs to recommend debian-keyring (what with it being a 42MB .deb)
[07:06] <jdoles> I managed to get the broken program to sort of work, but I don't want to upload anything.
[07:06] <jdoles> maxb: yes, it does.
[07:08] <maxb> Hmm, Move debian-keyring from Suggests to Recommends (LP: #717245)
[07:12] <pitti> yolanda: FYI, the squid3 autopkgtest keeps timing out; it's accessing some network sites, which mostly doesn't work from the DC
[07:13] <pitti> yolanda: would be better to rewrite it using a local apache/ftp server or something like that
[07:13] <yolanda> hi pitti
[07:13] <yolanda> ok, i'll take a look
[07:13] <pitti> yolanda: accessing www.ubuntu.com is probably okay (jibel?), but not the more elaborate stuff
[07:14] <yolanda> pitti, i just took the code from QA there, is ok if i modify that only in the package then?
[07:15] <pitti> yolanda: sure
[07:15] <pitti> yolanda: I guess it's still worth keeping the current tests somewhere, though
[07:15] <pitti> they can run on a local box without a restrictive firewall/proxy in front of it
[07:15] <pitti> and with that it's more useful for actually testing security updates and the like
[07:17] <jibel> yolanda, *.ubuntu.com,  *.canonical.com, *.launchpad.net and few others are ok
[07:17] <yolanda> great
[07:18] <pitti> jibel: but only http, right?
[07:18] <pitti> the test also uses ftp and perhaps other
[07:18] <pitti> s
[07:23] <jibel> pitti, right http and https. I used ftp and smb servers  inside the lab for JDK testing, we could setup one for autopkgtest
[07:33] <yolanda> jibel, pitti, so it's better to enable ftp and leave the tests like that?
[07:34] <yolanda> the other tests under http or https are just under ubuntu.com
[07:34] <pitti> yolanda: the ftp or some other test makes the whole test hang forever, and adt kills it
[07:34] <pitti> I can't say for sure as I don't get logs from these
[07:35] <yolanda> mm, how can we confirm it?
[07:36] <pitti> yolanda: I'll try running it in the DC, to see what's hanging
[07:38] <yolanda> ok
[07:53] <pitti> yolanda: oh, I get http://paste.ubuntu.com/5738082/
[07:53] <pitti> yolanda: I'm not sure why the test is hanging forever, that seems to be a bug in our adt scripts
[07:54] <yolanda> pitti, and you also get this error locally?
[07:54] <pitti> yes, I do
[07:54] <pitti> and the hang, too
[07:55] <pitti> run-adt-test -s squid3
[07:56] <pitti> /etc/init.d/squid3 ← this doesn't exist
[07:56] <pitti> yolanda: ah, it was converted to an upstart script, so the tests need to be adjusted to use "start squid3" and the like
[07:56] <pitti> yolanda: I'll check why run-adt-test hangs forever in the meantime, ok?
[07:56] <yolanda> mm, i tested that locally before pushing anything and that worked, is that a recent change?
[07:57] <yolanda> ok
[07:57] <pitti> I was fairly sure I tested it as well (always do when sponsoring)
[07:57] <pitti> I don't see it as a recent change
[07:57] <yolanda> i'll test it again
[08:20] <sil2100> jamesh: ping
[08:20] <jamesh> sil2100: pong
[09:17] <ogra> hmm, is /etc/fstab.d supposed to work ?
[09:18]  * ogra sees it in saucy, but files i put there done seem to be respected at all
[09:19] <ogra> oh, upstream removed it from mount .... how helpful
[09:19] <pitti> removed? perhaps it's in a less ancient util-linux?
[09:21] <ogra> sadly it has no reference to the discussion http://askubuntu.com/questions/168290/why-cant-mount-read-files-in-etc-fstab-d
[09:21] <ogra> the answer is from 2012 ... i dont really want to roll back that far :)
[09:22] <ogra> (on the phone where we ship fstab snippets it would be extremely helpful to have it working)
[09:23] <xnox> dobey: lp:ubuntu/software-center is now up to date.
[09:34] <apw> pitti, yo ... we have a boot speed regression and we think udevd is to blame
[09:34] <apw> pitti, (the systemd version) ... having poked it a bit the initrd seems to have bloated by likr 14Mb
[09:35] <pitti> apw: oh? it's actually supposed to be faster now, as it drops all those external programs
[09:35] <apw> pitti, 16104k freed -> 30508k freed
[09:35] <apw> pitti, yeah i don't doubt it is quicker in the real world but the initrd has become massive and loading and unpacking it is eating a lot more time
[09:36] <apw> pitti, i am assuming it is not meant to be 14M of new code
[09:36] <pitti> apw: certainly not
[09:36] <pitti> sounds like a new dependency crept in or so
[09:36] <apw> in better news, QAs boot charts found it, in not so better news we only noticed the regression by luck
[09:37] <pitti> I'm still fighting with vala, will look after that
[09:37] <apw> pitti, oh and i think it may have gotten a bit better a couple of days ago
[09:37] <apw> pitti, will confirm for you
[09:37] <xnox> apw: where are the bootcharts?
[09:39] <apw> xnox, reports.qa.ubuntu.com, and hit the Bootspeed tab
[09:39] <apw> pitti, ok confirmed, two days back it dropped back from 30m to 23m which has recovered about 1/2 the regression
[09:41] <pitti> hm, 202-0ubuntu10 was the last thing to really change the initramfs, but that was from May 29 already
[09:41] <pitti> apw: anyway, I'll dissect the initramfses and compare
[09:41] <apw> pitti, i have both here, so while you are looking at vala, i'll see what i can see
[09:47] <pitti> apw: indeed, my initrd.img-3.9.0-2-generic is 31 MB, initrd.img-3.9.0-3-generic is 23
[09:47] <pitti> initrd.img-3.9.0-2-generic is from May 28, thus before udev 202-0ubuntu10
[09:47] <apw> pitti, that was the shrink which gives us back half of it
[09:48] <pitti> apw: 14 MB was from raring?
[09:49] <apw> pitti, hmm that is hard to tell with qa's stuff
[09:49] <xnox> apw: so in my -2, there is icu added, which was an unwanted temporary dependancy of harfbuzz & pango. But that was fixed. (harfbuzz build without icu)
[09:49] <pitti> apw: filed bug 1188108 to track, FYI
[09:49] <apw> pitti, thanks
[09:49] <xnox> apw: the regression was noted by d-i team, since sudently icu-udebs were required.
[09:50] <apw> xnox, yeah ... good
[09:50] <xnox> 1/2 the regression is revert of extra icu baggage.
[09:50] <xnox> (recovery)?!
[09:51] <xnox> cause icudata is ~19MB unpacked.
[09:51] <apw> pitti, oh yeah so locally my 16M ones are raring yes, so that is likely true for QA
[09:51] <apw> pitti, so ... we have an initial delta 16->30 from raring->saucy, and 30->23 from fixing icu
[09:51] <apw> ugg
[09:53] <pitti> $ diff -Nur <(zcat initrd.img-3.9.0-2-generic | cpio -t | sort -u | sed 's/3.9.0-2/3.9.0-3/') <(zcat initrd.img-3.9.0-3-generic | cpio -t | sort -u)
[09:53] <pitti> indeed, that's the removal of icu and libstdc++.so.6
[09:53] <pitti> but it added +usr/lib/x86_64-linux-gnu/libgraphite2.so.3
[09:54] <apw> pitti, by the looks of it we have a heap more kernel modules in the new ones, like possibly all of them
[09:54] <pitti> apw: I think libgraphite2-3 is a dep of libharfbuzz0a is a dep of libpangoft2-1.0-0 is a dep of plymouth
[09:55] <apw> pitti, i think we have a modules issue primarily
[09:55] <pitti> so at least there isn't anything udev-ish between -2 and -3
[09:55] <pitti> apw: yeah
[09:57] <apw> 5.2MAc/lib/modules
[09:57] <apw> 31MBc/lib/modules
[09:57] <apw> pitti, not good
[09:57] <apw> pitti, so not all of them, but a heck of a lot more of them
[09:58] <pitti> apw: so is that due to udev somehow?
[09:58] <apw> pitti, seems unlikely to me
[09:59] <apw> pitti, you were fingered cause the one which was small was udev, and the one which was big was systemd-udev, but actually that might be raring -> saucy cut over ..
[10:00] <apw> pitti, let me poke it for a bit, and update the bug while you vala yourself to death
[10:00] <pitti> heh; effing buildds..
[10:01] <apw> what did the eff ever do to you :)
[10:03] <pitti> not reproduce in sbuild or debuild
[10:03] <pitti> so I keep banging new versions onto the buildds until they submit
[10:11] <apw> pitti, so if i rebuild an old kernel it expands, kmod, initramfs-tools and the kernel (in that case) are all identicle ... this is going to be 'fun'
[10:14] <apw> pitti, ok my 16M ones are actuall made with MODULES=dep in /etc/initramfs-tools/initramfs.conf
[10:14] <apw> pitti, can you confirm whether you have like /etc/initramfs-tools/initramfs.conf.dpkg-old on the machine you checked
[10:14] <apw> pitti, as my other raring machine they are all 31M
[10:17] <apw> pitti, did your machine by any chance have the kmod stuff installed on it, the early kmod testing we did
[10:19] <apw> pitti, and the problem with that is i cannot account for how the initrd on a virgin install would be 16M on raring
[10:19] <apw> (in the QA scenario
[10:20] <pitti> apw: re
[10:21] <pitti> so with "if i rebuild an old kernel it expands,.." you mean that if you build raring's kernel in current saucy you get a big (23 MB) or small (16 MB) initrd?
[10:21] <apw> pitti, i get a 23 M one now indeed
[10:21] <pitti> apw: ok, so it's not the new kernel then
[10:21] <apw> pitti, and that is because i got a new initramfs-tools, which switched my conf from =dep to =most
[10:22] <apw> pitti, now that was cause i had a test kmod one on, on this other machine i have it was =most all the time, and is 30M for raring as well
[10:22] <pitti> /usr/sbin/mkinitramfs:# MODULES=most is default
[10:22] <pitti> /usr/sbin/mkinitramfs:echo "W: mkinitramfs: Falling back to MODULES=most."
[10:22] <apw> pitti, so the confusing thing is how this test box was _ever_ 16M
[10:22] <apw> pitti, right ... i know, and that worries me about the machine which did the testing
[10:22] <apw> pitti, in reality i think we have had 31M initrd's for raring, and your recent fix for ics has made it 23, win
[10:23] <apw> and there is no regression, but i am going to chat to QA to confirm the older results
[10:23] <apw> pitti, but you have a 16M one as well and want to confirm you got that with =dep somehow
[10:23] <pitti> on that note, what happened to the really useful automatic creation of initramfs .bak files by update-initramfs ?
[10:23] <apw> that your machine is a poor example as mine is
[10:24] <pitti> apw: 9554231 Jun  6 12:23 initrd.img-3.9.0-3-generic
[10:24] <apw> pitti, i don't recall ever seeing those, though it does sound useful
[10:24] <pitti> that's with "dep" in /etc/initramfs-tools/initramfs.conf
[10:24] <pitti> but I just changed that
[10:24] <apw> yep so nice and small
[10:24] <pitti> apw: I didn't have a 16 MB one on my machine; it's all saucy
[10:24] <pitti> apw: I was just quoting your number
[10:24] <apw> ok, so 16M in the bug, was my number, ok, so that is a false number, just happening to match nearly exactly QAs
[10:25] <apw> but i am now suspicious of
[10:25] <pitti> apw: so either /etc/initramfs-tools/initramfs.conf really had "dep" at some point, or someone poked that into the QA machine?
[10:25] <apw> their number ... right ... so ... off to qa to ask
[10:25] <pitti> apw: you had manually configured that as well?
[10:25] <apw> pitti, yeah seemingly when i was doing the kmod testing
[10:25] <apw> i probabally change it to confirm i had done the right thing in the merge i did for initramfs tools for that
[10:25] <apw> (one we didn't use in the end) and tested both modes, and left it in the wrong one, sigh
[10:27] <pitti> well, "dep" doesn't seem exactly "wrong", but it might indeed not be enough if you use root on a network fs
[10:27] <pitti> (but yuck)
[10:27] <pitti> having all those HID and network drivers in initramfs seems like a waste
[10:27] <pitti> at least if update-initramfs sees that the root fs is on a local disk
[10:28] <apw> pitti, is is so concidentally similar (the size in the testing) and the size my machine has for =dep that i am deeply suspicious of the results on this machine
[10:28] <apw> pitti, yeah this is the disk portability problem, i have long argued (and probabally should implement) that we should build two, one thin (=dep) and one fat (=most) and use the thin for 'normal' boots and 'fat' for recovery
[10:29] <apw> so you can recover in a disk moved to different h/w scenario
[10:30] <pitti> apw: I was just speaking about the network drivers, but indeed we could downsize the block drivers, too
[10:36] <apw> pitti, ahh i see what you mean, make the decision that the disk is only portable as a disk
[10:36] <apw> which makes a lot more sense
[10:36] <pitti> apw: I was thinking to not include any network stuff if your root dev is on any /dev/
[10:36] <pitti> as opposed to some nfs device or so
[10:37] <apw> pitti, yeah i think that makes sense, and doesn't break the main point, unscrew disk move to new machine screw in disk
[10:37] <pitti> (I have no idea how that would look like; the whole idea of having your system partition on a network device seems crazy and utterly slow to me)
[10:37] <pitti> apw: yes, I fully support having at least the most common disk drivers in the initramfs
[10:38] <pitti> lib/firmware/matrox/g200_warp.fw
[10:38] <pitti> lib/firmware/r128/r128_cce.bin
[10:38] <pitti> lib/firmware/radeon/PITCAIRN_mc.bin
[10:38] <pitti> wow, we have a lot of stuff in our initramfs
[10:39] <pitti> (for KMS, I guess)
[10:42] <pitti> apw: so we ship 9.9 MB of network drivers
[10:42] <pitti> that's a third of the size of drivers/net
[11:22] <hrw> does someone here use saucy? pulseaudio (in pauvcontrol) lists no sound cards
[11:26] <xnox> does for me on saucy/amd64
[11:27] <hrw> xnox: saucy/amd64 here as well but no cards ;(
[11:29] <hrw> xnox: heh.. I am not in audio group
[11:35] <ogra> hrw, the audio group shouldnt be used unless you dont use a DM
[11:35] <ogra> i assume there is a bug in systemd-logind
[11:35] <ogra> (or in pluse talking to it)
[11:35] <hrw> ogra: DM?
[11:35] <zul> cjwatson:  ping is it possible for you to de-binary new python3-mimeparse please?
[11:35] <ogra> displa/login manager
[11:35] <hrw> ah
[11:36] <hrw> ogra: kdm is broken, lightdm+kde-greeter not yet work for me - working on it now
[11:41] <cjwatson> zul: done
[11:41] <zul> cjwatson:  thanks
[12:04] <ogra> so i have this  upstart job http://paste.ubuntu.com/5738554/
[12:05] <alexbligh1> If a package I am installing requires the en_GB locale to be installed (always), then should it Depend: on language-pack-en or language-pack-en-base?
[12:05] <ogra> it doesnt start on boot at all, even though syslog shows
[12:05] <ogra> Jun  6 12:00:11 ubuntu-phablet upstart-file-bridge[460]: Job got added /com/ubuntu/Upstart/jobs/_2fdata_2fubuntu/ofon
[12:05] <ogra> does anyone have an idea why ?
[12:05] <ogra> the file is there (and the syslog entry actually reacts to it)
[12:06] <ogra> running "start ofono" manually works fine too
[12:08] <ogra> i have the feeling that "on started dbus" doesnt do what it should
[12:21] <xnox> ogra: can you increase debugging, to get the full log of all events? that way it should be easier to see why it's not starting.
[12:22] <ogra> hmm
[12:22] <xnox> add "--debug" to kernel command-line
[12:22] <ogra> that needs cmdline changes
[12:22] <ogra> thats fiddly
[12:23] <xnox> or add a very early job to "exec initctl log-priority debug"
[12:24] <ogra> ah, it seems the file i wait for is created twice in a row
[12:24] <ogra> (which is weird
[12:24] <ogra> )
[12:24] <xnox> start on (starting file-bridege and starting dbus) or something like that.
[12:25] <ogra> additionally to file FILE= ?
[12:25] <xnox> upstart-file-bridge emits event if the file added event, and then again if it's changed/added/removed.
[12:25] <xnox> ogra: no, that was start on condition for a job that does "initctl log-priority" tweak.
[12:25] <ogra> oh, i could look for the added event
[12:26] <xnox> ogra: yeah, so there is FILE= which is path to file and EVENT= which is create|modify|delete
[12:27] <ogra> right ...
[12:27] <ogra> i'm not 100% that i dont have a dangling file there before it gets newly created
[12:27] <ogra> so lets see if that helps
[12:28] <ogra> sigh ...
[12:28] <ogra> if rebooting would only work reliably
[12:28] <xnox> ogra: does /dev/socket exist when file-bridge starts? see limitations on recursive inotify watches in upstart-file-bridge manpages....
[12:29] <ogra> oh, it might not
[12:29] <ogra> not sure when the file bridge starts, let me take a look
[12:30] <ogra> ah. well, "emits file"
[12:30] <ogra> so i should be starting before it
[12:30] <ogra> *shouldnt
[12:31] <ogra> sigh
[12:31] <ogra> so now i see it starting and then stopping
[12:31] <xnox> ogra: did "stopping dbus" kick in?!
[12:32] <ogra> i dont see why it woould on boot
[12:32] <ogra> i removed it
[12:32] <ogra> heh, now it doesnt start at all
[12:32]  * xnox is not sure why you have "stop on stopping dbus" there at all though.
[12:33] <ogra> because ofonod needs dbus
[12:34] <ogra> if thats gone we want to go away as well
[12:34] <xnox> ogra: but when dbus comes back, ofono will not come back.
[12:34] <ogra> thats true for the file too ... i added a stop sequence for it
[12:34] <xnox> ogra: since a file event for the socket will not be emitted ever again.
[12:35] <ogra> let me drop the on stop line
[12:36] <ogra> hmm, nope
[12:36] <ogra> doesnt start at all anymore
[12:37] <ogra> even if it cant find dbus it should just respawn ... i dont see it doing that either
[12:38] <ogra> all i get is
[12:38] <ogra> Jun  6 12:37:33 ubuntu-phablet upstart-file-bridge[337]: Job went away /com/ubuntu/Upstart/jobs/ofono
[12:38] <ogra> Jun  6 12:37:33 ubuntu-phablet upstart-file-bridge[337]: Job got added /com/ubuntu/Upstart/jobs/ofono
[12:38] <ogra> Jun  6 12:37:33 ubuntu-phablet upstart-file-bridge[337]: Job went away /com/ubuntu/Upstart/jobs/_2fdata_2fubuntu/ofono
[12:38] <ogra> Jun  6 12:37:33 ubuntu-phablet upstart-file-bridge[337]: Job got added /com/ubuntu/Upstart/jobs/_2fdata_2fubuntu/ofono
[12:38] <ogra> why does it have that "_2fdata_2fubuntu/ofono"! thing there ?
[12:39] <xnox> ogra: i really want "--debug" output from upstart =) can you divert init -> init.real and make init a shell script "/sbin/init.real --debug" ?
[12:39] <ogra> well, let me fiddle with the cmdline
[12:39] <ogra> just takes a bit
[12:40] <xnox> ogra: above are just funny upstart-file-bridge logs which are "things that file-bridge is tracking / watching / emited / finished dealing with"
[12:40] <ogra> well, i dont get why there seems to be a proper "ofono" job but also the two others
[12:42]  * ogra wonders why pastebinit hangs
[12:44] <ogra> ah, well, 200000 lines was probably a bit much
[12:44] <ogra> http://paste.ubuntu.com/5738646/
[12:46] <xnox> ogra: i see dbus running, yet no starting nor started dbus events?!
[12:46] <ogra> weird
[12:47] <xnox> init: Error while reading from descriptor: Bad file descriptor
[12:47] <xnox> looks scary.
[12:48]  * ogra wonders where that might come from
[12:48] <xnox> ogra: can I see output of `dmesg` ?
[12:49] <ogra> hmm, thats filled with trash already ... i can get you /var/log/dmesg
[12:49] <xnox> ogra: | grep init
[12:49] <ogra> http://paste.ubuntu.com/5738654/
[12:50] <ogra> there is no init: in it anymore ...
[12:50] <ogra> if the ringbuffer is full dmesg deletes
[12:54] <xnox> ogra: create a "custom logger" =))) http://paste.ubuntu.com/5738665/
[12:55] <xnox> ogra: and then /var/log/upstart/customlog.log will have just the events we are interested in, and we will notice if ofono started or not.
[12:55] <xnox> ogra: also add "or started/starting/stopped/stopping ofono" if you want to notice those as well.
[12:55] <xnox> ditto dbus.
[12:57] <ogra> ugh
[12:57] <ogra> /bin/sh: 0: Can't open /proc/self/fd/9
[12:57] <ogra> all over the place
[13:01] <ogra> http://paste.ubuntu.com/5738679/
[13:01] <jbicha> should packagekit-qt be removed also? (it unfortunately migrated out of -proposed)
[13:02] <ogra> i see 4 create events for the file
[13:13] <xnox> ogra: weird, but the ofono job should be running then. Was that booted two times? as dbus/file-bridge are started twice.
[13:14] <ogra> yeah
[13:17]  * ogra tries something els
[13:17] <ogra> e
[13:46] <tedg> mardy, Hey, is there a way to turn off UOA in Evolution?
[13:47] <mardy> tedg: open the account in the System Settings, there should be switches next to the various services
[13:48] <tedg> mardy, With Google I have photo search, shotwell, empathy and Google Drive plugin.  But no Evolution.
[13:54] <seb128_> tedg, mardy: not sure if you got that before
[13:54] <seb128_> mardy, that's not listed evolution, Laney mentioned that there was an error about no matching .desktop yesterday iirc
[13:55] <Laney> eds should supply a .desktop file for it
[13:55] <tedg> Yeah, I also just did a dist-upgrade and I'm getting an account-plugin-google.
[13:55] <tedg> Curious if part of my problems were that I didn't have the right provider.
[13:56] <Laney> it's basically broken with accounts that require 2fa
[13:57] <Laney> https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/1187699
[13:58] <ogra> xnox, so dropping the file stuff and instead depending on the job that creates the file makes it work reliable
[13:59] <ogra> the file is a symlink to a socket which originally lives in /proc ... i guess the file bridge doesnt really get along with that
[14:01] <xnox> ogra: ah. there is a socket bridge as well, but it's reverse, to start a job when something starts talking to the socket.
[14:02] <ogra> xnox, yeah, that wont help, the thing talking to the socket is the thing i'm starting :)
[14:02] <xnox> ogra: to be honest i'd only use file-bridge to track _regular_ files on _normal_ filesystems, and not things in /dev, /proc and etc. But I guess that's not everyone's prerogative.
[14:03] <ogra> well, ofono needs the link to be there to start properly
[14:03] <ogra> else it cant talk to the daemon inside the container
[14:03] <xnox> i see.
[14:07] <zul> how long does it take to get somehting out of -proposed?
[14:08] <tumblewed> it needs to be installable
[14:15] <jdoles> Does anyone know how the cc_version is determined in this string (avahi output for distcc)? txt = ["cc_machine=x86_64-linux-gnu" "cc_version=4.7" "gnuhost=x86_64-pc-linux-gnu" "distcc=3.1" "cpus=2" "txtvers=1"]
[14:15] <xnox> zul: fully build on all arches, it previously managed to build on. + does not cause more packages to be uninstallable. See http://people.canonical.com/~ubuntu-archive/proposed-migration/
[14:16] <jdoles> In particular why does it select just one number when multiple compilers are installed on the system?
[14:16] <xnox> jdoles: my guess it comes from the compiler it self. and whichever one is the "cc" or "gcc" compiler?!
[14:16] <jdoles> xnox: the compiler being?
[14:16] <jdoles> xnox: (there is no 'the')
[14:16] <xnox> jdoles: type $ cc --version
[14:17] <jdoles> xnox: unless you mean that it has been hardcoded to use cc.
[14:17] <xnox> jdoles: that's the default c-compiler on any system (hence "cc") you can update that symlink if you wich.
[14:17] <xnox> wish.
[14:17] <xnox> and I'm sure distcc can be configured to use alternative compilers.
[14:18] <jdoles> xnox: after apt-get install gcc-4.7, I don't have a gcc-4.7 on my path. Why not?
[14:19] <xnox> jdoles: i do. what's your path?! =)
[14:19] <xnox> zul: unless you are talking about SRUs verification from $stable-proposed -> $stable-updates ?!
[14:19] <zul> xnox:  nah im good thanks
[14:20] <jdoles> xnox: the default PATH + some site specific ones.
[14:21] <jdoles> xnox: actually I only have gcc-4.7-base.
[14:21] <jdoles> xnox: and that is a very small package which doesn't seem include an actual compiler.
[14:22] <ev> pitti: is there a historical reason why we don't include a timestamp in the apport report path? Otherwise we're replacing whatever crash already existed every time, even if they're crashes in different places.
[14:22] <ev> tedg is running into this right now with recoverable problems
[14:22] <ev> why this didn't occur to me sooner, I have no idea
[14:22] <ev> I noticed that bzr does the right thing here for its crashes
[14:23] <xnox> jdoles: dlocate /usr/bin/gcc-4.7 tells me you want: gcc-4.7: /usr/bin/gcc-4.7
[14:23] <xnox> jdoles: as in $ apt-get install gcc-4.7
[14:23] <jdoles> xnox: I did that.
[14:24] <jdoles> xnox: Note, selecting 'gcc-4.7-base' for regex 'gcc-4.7'
[14:25] <jdoles> xnox: alternatively, how can I make distcc use an older compiler?
[14:28] <dobey> xnox: thanks for fixing the software-center package branches!
[14:28] <jdoles> xnox: is your other nickname nox?
[14:28] <xnox> jdoles: no.
[14:29] <xnox> (not for more than 12 years now anyway)
[14:29] <apw> pitti, ok after much poking, we seem to have gotten the right initrds off the machine.  the 16m size is right becuase that machine has no plymouth, and indeed when it jumps to 23 it is plymouth appearing in there that did it
[14:29] <pitti> aah
[14:29] <pitti> apw: so cryptsetup and the like
[14:30] <pitti> that would drop a lot indeed
[14:30] <apw> pitti, there is also some cryptsetup in there, so it seems that something in the recent image is pulling that in
[14:30] <apw>                                                               > lib/libcryptsetup.so.4
[14:30] <apw> is added in the later image
[14:30] <apw> (in its initrd)
[14:30] <xnox> jdoles: install whichever compiler you want, and adjust your path appropriatly for it to be called as "cc" and distcc will use that. if there are problems, try googling. I don't use distcc at all myself.
[14:31] <apw> pitti, how the heck would one figure that out
[14:31] <xnox> pitti: apw: whilst images have cryptsetup, the default unencrypted/lvm-less desktop shouldn't have cryptsetup in the initramfs.
[14:31] <dobey> does distcc not support doing "CC=/usr/bin/foo-cc distcc" or something?
[14:32] <apw> xnox, as soon as cryptsetup is installed we will add plymouth and junk into the initramfs
[14:32] <xnox> dobey: i mostly saw it use wrappers & diverts everytime I had to use distcc.
[14:32] <apw> xnox, regardless of whether it is used for root or not
[14:32] <xnox> apw: sure. which I was meant to fix, and only add it if "/" and/or "/usr" is encrypted.
[14:33] <apw> xnox, ok but as things are has cryptsetup been added to the default images
[14:33] <apw> as in the last two weeks the sizes of the initrd's have jumped
[14:33] <xnox> apw: in quantal we added full-disk encryption to the desktop image, but it should be removed from the installed system at the end of installation if one chose defaults and is not using encrypted rootfs.
[14:34] <apw> xnox, ahhh, so this could be a bug in the bit which removes it then
[14:34] <xnox> apw: .... if for example initramfs is last regenerated before and not after removing packages.
[14:35]  * apw goes find something to scratch install
[14:36] <cjwatson> jdoles: If apt falls back to regex search, it must be because gcc-4.7 isn't available.  'apt-cache policy gcc-4.7' does a lower-level check
[14:36] <xnox> apw: but i don't think we touched that code since.... quantal. So it doesn't explain regression from a few weeks ago.
[14:36]  * xnox is checking daily saucy.
[14:36] <apw> xnox, nope, but i should scratch this test box and see if it stays on, and eliminate it
[14:37] <jdoles> cjwatson: that only shows the base (this is precise-updates)
[14:37] <apw> and if it is there find out what is holding it on
[14:37] <jdoles> cjwatson: I think it's simply not in precise.
[14:38] <xnox> jdoles: yeah, quantal and up.
[14:38] <cjwatson> Indeed.  GCC 4.7.0 was released in March 2012, only barely before precise released.
[14:40] <cjwatson> gcc-4.7-base is there because there was a gccgo-4.7 source package in precise that built it, because people wanted to experiment with the Go compiler early.
[14:42] <pitti> rbasak: ugh, that became a loong reply :)
[14:46] <ev> tedg: give this a bash: http://paste.ubuntu.com/5738948/
[14:46] <tedg> ev, Sorry, catching up.  I figured that that's what the "1000" was for.
[14:46] <ev> that's the uid
[14:46] <tedg> Ah, I thought it was a counter :-)
[14:47] <ev> I *think* the intent was to keep the reports to a minimum, back in the day
[14:47] <ev> but with errors.ubuntu.com, it seems like we're just potentially overwriting some problems (assuming an application can crash twice before the first report is processed)
[14:48] <ev> which would be fairly easy with recoverable_problem. Harder with Crash ProblemTypes
[14:50] <tedg> ev, Can you just send me the whole file?  I've hacked it too much for debugging... diffs won't apply :-)
[14:50] <ev> tedg: sure
[14:51] <ev> http://paste.ubuntu.com/5738958/
[14:57] <tedg> ev, Hah, was trying to figure out what happened.  It wrote multiple files, but in my home directory :-)
[14:57] <ev> :)
[14:57] <ev> any idea why?
[14:58] <tedg> ev, I'm guessing reportfile there needs an "/var/crash" in front of it.
[14:59] <ev> hmm, so it does :)
[14:59] <ev> os.path.join(report_dir, reportfile)
[15:01] <tedg> ev, Woot! I can make lots of crash files ;-)  http://paste.ubuntu.com/5738984/
[15:02] <ev> heh, I'm working on a variant that uses a short hash of the crash/duplicate signature
[15:03] <ev> which would at least not break "ignore future problems of this type" box
[15:03] <tedg> That makes more sense.  Each type once.
[15:03] <ev> yeah
[15:05] <barry> bdmurray: ping
[15:05] <bdmurray> barry: hey
[15:07] <didrocks> barry: hey, do you know why python-support is in universe?
[15:07] <barry> didrocks: it's deprecated in debian.  ubuntu is a little farther ahead in switching to dh_python2, but we really don't want anyone using py-support or (even worse) py-central any more
[15:07] <barry> didrocks: it's usually pretty easy to switch to dh_py2
[15:08] <barry> didrocks: http://wiki.debian.org/Python/TransitionToDHPython2
[15:08] <cjwatson> die die die python-support
[15:08] <didrocks> barry: ok, I need gtester2xunit in main
[15:08] <didrocks> barry: which build-dep on python-pyruntest
[15:08] <cjwatson> didrocks: somebody needs to convert it then
[15:08] <didrocks> which build-dep on subunit
[15:09] <didrocks> cjwatson: yeah, but for sure, everything is melt down and it seems people don't care about that to have touch and unity 7 in distro
[15:09] <cjwatson> we very carefully went to the effort of converting everything in main that used python-central or python-support to dh_python2
[15:09]  * didrocks *sigh*
[15:09] <cjwatson> they have to care, python-support is not going back into main :)
[15:09] <didrocks> I know, why I'm asked
[15:09] <didrocks> asking*
[15:10] <cjwatson> python-pyruntest doesn't build-dep on subunit here though
[15:10] <didrocks> cjwatson: wrong line copied: python-junitxml,
[15:11] <cjwatson> Nor does subunit use python-support
[15:11] <cjwatson> Right, python-junitxml needs to be converted
[15:12] <didrocks> cjwatson: yeah, I copied the wrong line when pasting here :)
[15:12] <cjwatson> It's usually about a 15-minute job.  Want me to have a look then?
[15:13] <Laney> I heard the maintainer's a nice guy
[15:13] <cjwatson> He is, but he might also like to take patches rather than doing it himself :)
[15:13] <didrocks> cjwatson: seeing the christmas period that is my IRC right now, I'll greatly appreciate :)
[15:13] <didrocks> (thanks for the offer)
[15:15] <Laney> was suggesting that he'd probably be quite willing to take them :P
[15:23] <apw> xnox, ok a clean install with todays saucy iso, selecting a normal install, leave cryptsetup installed
[15:24] <apw> xnox, whats the best way to find out why it is still on
[15:25] <dobey> anyone have any idea why the branch import of a package would have succeeded for saucy-proposed, but doesn't seem to have gotten copied to saucy, even though the package has already been copied over, and there's nothing on the branch imports status page for it?
[15:26] <xnox> apw: it's installed because it gets copied across like everything else. It is left on the install either because it's in whitelist, dependancy of something in whitelist, explicetly "marked" to be install with apt-install.
[15:26] <apw> xnox, ok so this was a default install all options defaulted, and its still on there, so is the information on why still on the system so i can find out
[15:26] <xnox> apw: I can take from here, and hunt it down. Also it's a good excuse to simply implement "do not pull cryptsetup+plymouth+friends into initramfs, unless root partition is encrypted".
[15:27] <apw> xnox, i would love to see that for my purposes as i use cryptsetup in that mode, not for /
[15:27] <apw> xnox, ok thanks, there is a bug out there, which is currently against, systemd
[15:28] <apw> xnox, LP#1188108
[15:28] <apw> bug #1188108
[15:41] <slangasek> caribou: just doing our duty ;)
[15:42] <jdoles> Are you also switching to systemd now?
[15:43] <jdoles> Switching initialization system every release seems like not so fruitful idea.
[15:43] <jdoles> +a
[15:44] <seb128> jdoles, we don't plan to use systemd init no
[15:45] <cjwatson> The mention of systemd above is because we're using some pieces of systemd (e.g. udev is built out of that tree now), but not the actual init daemon
[15:46] <barry> bdmurray: actually, let me ask cjwatson and/or slangasek if they know whether update-motd scripts can generally write to stderr.  the manpage is a bit silent on that although it does say: "MOTD fragments must be scripts in  /etc/update-motd.d,  must  be  executable, and must emit information on standard out."
[15:47] <cjwatson> I think that would be up to pam_motd
[15:47]  * cjwatson punts to slangasek
[15:48] <barry> slangasek: context is bug #982082
[15:49] <Laney> h
[15:50] <barry> what we think is happening is that something mysterious is breaking lsb_release causing it to exit non-zero.  not sure what that is, but if that *does* happen, then check-new-release will write an error message to stderr, but stderr doesn't exist and we get the IOError.  that gets run under an update-motd.d script so the guess is that stderr isn't available to those scripts
[15:50] <slangasek> barry: the pam_motd integration doesn't capture stderr to the motd (which it shouldn't); it also doesn't redirect it anywhere, which may be a bug since it means the scripts can pollute the stderr of the invoking service
[15:50] <slangasek> barry: so arguably, pam_motd should redirect stderr to /dev/null unconditionally, but I'm not sure if that helps you
[15:51] <cjwatson> didrocks: pyjunitxml done
[15:51] <barry> slangasek: it does somewhat.  the question is whether to fix this bug we should really install a more general fix to pam_motd.  the other options are narrower, e.g. either redirect stderr to stdout in this specific motd.d script, or fake stderr in the python bits that get invoked
[15:52] <jdoles> I managed to get distcc --show-hosts to show proper output, but when I run a compilation it doesn't actually use multiple hosts :/
[15:52] <jdoles> Anyone with an idea what can still be wrong?
[15:52] <didrocks> cjwatson: thanks a lot! we're doing sphinx on the same base right now :)
[15:52] <barry> slangasek: the narrower fixes are safer for an sru, and also probably easier to test and complete ;)
[15:53] <bdmurray> barry: I'd imagine saucy is still affected though
[15:53] <barry> bdmurray: could be, yes.  probably the easiest/quickest fix is to redirect stderr in the motd script
[15:55] <slangasek> barry: wasn't there some suggestion in the other master lsb_release bug that invoking lsb_release itself with stderr closed was causing failures?  Maybe fixing lsb_release to handle that case kills two birds with one stone?
[15:56] <barry> slangasek: i don't think this is directly related to lsb_release writing to stderr.  the problem happens because lsb_release exits non-zero and it's the do-release-upgrader code that then tries to write a message to stderr in that case.
[15:57] <barry> slangasek: we have seen cases where lsb_release can exit non-zero, which is why we sru'd the -Es shebang line fix.  i am requesting more information in the bug about that, which would be the root cause (and about the only reason why lsb_release would exit non-zero)
[15:57] <slangasek> ok
[15:57] <slangasek> well, except if lsb_release is raising an unhandled exception because stderr is closed (which is the reported symptom in that bug), wouldn't that also translate to exiting non-zero?
[15:58] <slangasek> and if do-release-upgrader's stderr is closed, that obviously triggers this path
[16:00] <barry> slangasek: for precise, lsb_release will only write to stderr if it crashes or gets bogus command line options.  in the context of the tracebacks i've seen, the latter isn't happening, so it has to be the former, which leads to the guess that they don't have the -Es fix.
[16:00] <barry> lsb_release will obviously write to stdout in normal usage, but that's okay
[16:01] <caribou> slangasek: I was a bit annoyed to let that regression in; never saw any issue with my own tests
[16:01] <pitti> apw: so should we move #1188108 to ubiquity/confirmed then?
[16:03] <slangasek> barry: are we talking about bug #1094218 here (or rather, https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Flsb_release%3AIOError%3A%3Cmodule%3E%3Amain%3Acheck_modules_installed%3Agetoutput%3Agetstatusoutput)?  that bucket clearly shows that lsb_release *does* have the -Es fix, and the invocation is a correct one; so this all adds up to "lsb_release crashes reliably when stderr is closed".  Have you tried to run lsb_release with stderr
[16:03] <slangasek> ... see what happens?
[16:04] <barry> slangasek: let's try it! :)
[16:12] <barry> slangasek: okay, so yes, this will crash:
[16:12] <barry> lsb_release -a exec 2>&-
[16:12] <barry> slangasek: but here's the difference: in the context of the original bug, it's only running `lsb_release -c -s` which *doesn't* crash when stderr is closed
[16:13] <barry> slangasek: so i'll claim this is two different bugs :)
[16:14] <barry> hmm, actually, no i ran this in two different ways.  maybe it does crash
[16:14] <barry> okay, so that explains the root cause
[16:15] <apw> pitti, perhaps so for the moment, xnox is in the frame right now; it may move somewhere else when we figure out what it really is but yes i think so
[16:17] <slangasek> barry: ok :)
[16:18] <barry> slangasek: so, short of doing $something w/stderr in pam_motd, perhaps we should just redirect stderr to stdout in the update-mod.d script
[16:19] <barry> slangasek: anyway, i'm going to get some lunch and ponder some more :)
[16:20] <slangasek> barry: lsb_release needs to be fixed to not fail when stderr is closed, because that's a legitimate way to invoke it and the cause of our *top* crasher on errors
[16:20] <slangasek> barry: if we fix lsb_release to not fail in this case, does that fix all the knock-on effects?
[16:22] <barry> slangasek: it probably will, although there will still be a lurking bug here because if for some other reason lsb_release fails, check-new-release will still try to print to stderr under update-motd
[16:22] <slangasek> right
[16:22] <rbasak> pitti: np. Thanks :)
[16:22] <slangasek> barry: so I think pam_motd redirecting 2>/dev/null, and fixing lsb_release, should cover us
[16:23] <cjwatson> I'm not arguing against making lsb_release robust against this, but I don't think that "stderr closed" is a legitimate way to invoke any process, maybe with some special-purpose exceptions between cooperating processes
[16:23] <cjwatson> (as opposed to "stderr redirected to /dev/null", of course)
[16:24] <barry> cjwatson: you have a point, in that we can't expect to make every command robust against stderr being closed
[16:24] <slangasek> cjwatson: well, ok.  In practice, this seems to be the environment teamviewer is giving us, leading to that top crash in question :P
[16:24] <cjwatson> Is pam_motd actually closing stderr itself, or is that the fault of something further up the stack?
[16:24] <cjwatson> teamviewer
[16:24] <cjwatson> Christ
[16:24] <stgraber> barry: wow, so you finally managed to track that bug down? that took a while ;)
[16:24] <slangasek> cjwatson: pam_motd doesn't close stderr, but even if stderr *isn't* closed, I don't think we want these scripts' output leaking to the pam service's stderr
[16:24] <cjwatson> slappity slap buggy proprietary software :-/
[16:25] <cjwatson> We should let the teamviewer people know about this, since we have no way to fix it - I don't think we should omit that part since it might bite some other innocent process later
[16:25] <slangasek> how do you mean, no way to fix it?
[16:26] <cjwatson> no way to fix teamviewer
[16:26] <slangasek> lsb_release can simply reopen stderr as /dev/null to work around
[16:26] <slangasek> oh
[16:26] <cjwatson> we can fix the collateral damage
[16:26] <cjwatson> but this is definitely teamviewer doing an invalid thing
[16:26] <slangasek> well, AFAIK lsb_release is the only tool it's invoking
[16:26] <slangasek> ok
[16:26] <barry> but wait.  teamviewer might be the culprit in bug #1094218 but i don't think it is in bug #982082
[16:26] <slangasek> barry: correct
[16:27] <slangasek> so I don't know how do-release-upgrade is being invoked there
[16:27] <barry> slangasek: from update-motd
[16:27] <slangasek> barry: there's no top-level tool called update-motd any more
[16:27] <slangasek> the question is, who closed stderr :)
[16:28] <barry> slangasek: on precise, what runs /etc/update-motd.d/* scripts?
[16:28] <slangasek> barry: pam_motd
[16:29] <slangasek> so some /service/ must invoke it
[16:29] <slangasek> and the only obvious candidates are login and sshd
[16:29]  * slangasek bounces the bug back to cjwatson ;)
[16:30] <cjwatson> pam_open_session doesn't do any generalised fd fiddling?
[16:30] <barry> slangasek: so i think i misunderstood your earlier comment about pam_motd and stderr.
[16:32] <cjwatson> I'm reasonably sure that sshd never closes stderr - it would make its own debug output unusable which would be a pretty obvious thing
[16:32] <cjwatson> and do_pam_session is post-auth, ruling out the really weird stuff that goes on with the pre-auth network monitor
[16:33] <barry> i think this is happening at login not ssh
[16:33] <barry> https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/982082/comments/3
[16:34] <cjwatson> login doesn't seem to close much of anything
[16:35] <cjwatson> Shame we don't have a process tree here
[16:36] <rbasak> Do we have any kind of policy of when we move a Debian package to upstart by adding an upstart job in our delta?
[16:36] <rbasak> Whenever anyone's prepared to write one? Only when we have a reason and a delta anyway? Etc.
[16:37] <cjwatson> Mostly when it's possible and somebody's prepared to write one
[16:37] <cjwatson> But we should be forwarding all those deltas now :)
[16:38] <rbasak> So we'd prefer to an upstart job for all daemons, even when we have to maintain deltas just for that?
[16:38] <rbasak> (including universe?)
[16:38] <cjwatson> I'm finding it really unlikely that 982082 is sshd, based on the bug description.  Are we sure there's no desktopy thing that would be using pam_motd there?
[16:38] <cjwatson> Well, it's been a tradeoff of benefit vs. cost of maintaining the delta
[16:38] <cjwatson> Now that we have a way to get such jobs into Debian, hopefully the tradeoff will tilt
[16:38] <barry> cjwatson: i concur about sshd.  no clue about the desktop thing
[16:39] <cjwatson> Or something that's running update-motd in some other way?  It used to be a bit more ad-hoc ...
[16:39] <rbasak> I'm not sure I understand the benefit for random daemons in universe that don't need to interact with anything else for startup (ie. there's no other enumerated reason)
[16:40] <cjwatson> Management (upstart will keep it running more reliably); consistency across the system
[16:41] <rbasak> OK, thanks
[16:43] <barry> slangasek, cjwatson well, wouldn't this pastebin be a stupidly horrible way to at least verify whether stderr-being-closed is the problem?  http://paste.ubuntu.com/5739278/  maybe that's even A Fix (if not a particularly good one)
[16:46] <cjwatson> It would avoid that particular problem.  I think the only thing that qualifies as a true fix is not starting the process in that state, though :)
[16:47] <cjwatson> (As I say, given that it's a top crasher, I don't object to workarounds)
[16:47] <barry> cjwatson: agreed on both counts ;)
[16:47] <slangasek> cjwatson: pam_open_session() definitely doesn't fiddle fds
[16:48]  * cjwatson evilly wonders how much he could confuse everyone by writing something that launches processes with an envp pointing out of their mapped memory space
[16:48] <slangasek> rbasak: why should you have to maintain a delta for an upstart job now?  These should all be upstreamable to Debian
[16:48] <cjwatson> Or maybe just one of the pointers in argv
[16:48] <yolanda> pitti: https://code.launchpad.net/~yolanda.robla/ubuntu/saucy/squid3/fix-squid3-startstop/+merge/167804
[16:49] <barry> cjwatson: that sunny disposition never fooled me.  i knew you had an evil streak. :)
[16:49] <cjwatson> O:-)
[16:49] <rbasak> slangasek: I was asking in response to review a debdiff to introduce an upstart job in our delta, to override an init.d from Debian. bug 1187742. mvo doesn't appear to be here right now.
[16:50] <rbasak> slangasek: I can ask that he send this up to Debian, of course.
[16:50]  * barry -> lunch
[16:50] <slangasek> rbasak: right, it should definitely be sent there in parallel
[16:50] <cjwatson> It's a pretty recent development that it's possible to upstream these; mvo may just not be aware of it
[16:50] <cjwatson> (Well, possible sanely, as opposed to the crazy thing openssh used to do)
[16:53] <rbasak> yolanda: ^^ led me to look at your dep8 test. Would it be an idea to package and include testlib.py somewhere, rather than include it in every test individually? Or are we intentionally duplicating the code here in every test for some reason?
[16:54] <yolanda> rbasak, we were talking about that with jdstrand, we agreed that at the moment we will pack it in every file
[16:54] <rbasak> yolanda: OK, fair enough. Good to know - thanks.
[16:54] <yolanda> because testlib.py wasn't intented to be a production code
[16:54] <yolanda> and to package it, more tests and verification is needed
[16:55] <rbasak> slangasek, cjwatson: thanks. I'm much clearer on what do with upstart jobs now.
[16:58] <cjwatson> Is there some kind of main promotion or something needed for http://people.canonical.com/~ubuntu-archive/testing/precise-updates_probs.html ?
[17:05] <slangasek> cjwatson: hmm, the maas SRU seems to have been published before its dependencies
[17:05] <slangasek> these were SRUs of new packages
[17:06] <slangasek> so... let's see about getting celery published
[17:09] <slangasek> cjwatson: ok, celery promoted to -updates; python-pyparsing and freeipmi-tools look like they need a copy to precise-updates & promotion to main?
[17:10] <jcastro> slangasek: cjwatson: thanks for sorting this, maas has been a real pain point for users
[17:14] <slangasek> roaksoax: can you please remind me what the expected outcome for the maas SRU was wrt python-pyparsing, python-txtftp, freeipmi-tools?  Did we have agreement to retroactively promote these to main for 12.04 and have them security supported?
[17:15] <slangasek> these are each obviously in main in quantal and later, but I don't see that these were explicitly discussed as part of the maas SRU... I want to make sure the security team knows about this before I pull the trigger on promoting
[17:15] <slangasek> mdeslaur: ^^
[17:16] <mdeslaur> uh...what now? is there a bug# for that SRU?
[17:17] <slangasek> mdeslaur: this is wrt bug #1109283
[17:20] <roaksoax> slangasek: howdy! it was my understanding that these were discussed long ago and agreed upon
[17:21] <roaksoax> mdeslaur: more specifically, bug #1020267
[17:21] <slangasek> roaksoax: it's possible that this was all discussed, I just want to make sure I know where since it's the security team picking up the tab here, not me ;)
[17:22] <roaksoax> IIRC, we initially intended to do this for precise, but since we were not gonna be able to release maas as fast, we re-targetted to quantal
[17:22] <mdeslaur> ok, since it gets rid of cobbler, I'm ok with those being promoted
[17:22] <mdeslaur> I'll comment in #1020267
[17:22] <roaksoax> mdeslaur: thanks! :)
[17:25] <mdeslaur> slangasek, roaksoax: ok, commented in 1020267. I'm ok with promoting them since it gets rid of embedded cobbler code. Thanks for the ping.
[18:04] <smb> infinity, <pester>Could you have a look (and sponsor) at chinstrap:~smb/4infinity for saucy</pester>
[18:05] <infinity> smb: Maybe.  I'm trying to salvage some kernel PPA messes right now.
[18:06] <smb> infinity, Ok, yeah. Just remembered that yesterday I forgot your/my daily pester-ilence
[18:20] <smoser> xnox, ping
[18:20] <smoser> bug 1124384
[18:24] <smoser> never mind
[21:06] <shadows> How to fix a kernel panic when Bluetooth DUN disconnects?
[21:06] <shadows> is there a procedure to bisect for Ubuntu...  what do I do
[21:10] <infinity> shadows: -> #ubuntu-kernel
[21:13] <infinity> jbicha: I take it you didn't test-build your gdm FTBFS fix? :P
[21:23] <shadows> thanks infinity
[21:26] <shadows> infinity: topic fail btw, http://bit.ly/lv8soi is 404
[21:59] <dobey> wgrant: ping. are you around now? wondering if you could take a quick look at some udd branch import weirdness for me. thanks
[22:04] <wgrant> dobey: What needs fixing?
[22:07] <dobey> wgrant: lp:ubuntu/ubuntuone-control-panel doesn't seem to have been updated, though saucy-proposed branch was updated. and there is nothing on the import status page about it
[22:13] <bdmurray> mpt: could you have a look at bug 1186376 again?
[23:12] <wgrant> dobey: That's fixed.
[23:16] <slangasek> cjwatson, infinity: so with this maas stuff, it seems that copying these packages from precise to precise-updates and change-override'ing them to main is insufficient.  I guess we need no-change SRUs?
[23:23] <wgrant> slangasek: What's insufficient about it?
[23:26] <infinity> slangasek: Hrm, what?
[23:27] <infinity> slangasek: Did I miss something exploding?
[23:28] <infinity> E: Package 'freeipmi-tools' has no installation candidate
[23:28] <infinity> E: Package 'python-celery' has no installation candidate
[23:28] <infinity> Oh, that. Fun.
[23:28] <wgrant> Ah, promoting stuff post-release?
[23:29] <wgrant> That usually works fine...
[23:29] <infinity> Why wouldn't it work?
[23:29] <wgrant> Exactly.
[23:29] <infinity> slangasek: Where's the evidence that this doesn't work?
[23:29] <wgrant> AFAIK it works.
[23:29] <wgrant> Don't see why it wouldn't.
[23:30] <infinity> slangasek: It just looks to me like none of it's been promoted, that's all.
[23:30] <infinity> slangasek: I'd fix, but not if you've been mucking with overrides in the same publisher cycle.
[23:32] <infinity> slangasek: Let me know if your finger's removed from the pie, and I'll fix it.
[23:49] <straemer> anyone here have experience getting ubuntuone-android-music to build?


[03:09] <lamont> doko_: is icedtea-java7 bound for gutsy for sure, or might it wind up being hardy?
[03:09] <lamont> and how many architectures did you give me enough to bootstrap on?
[08:52] <doko> lamont: amd64, i386, lpia, pending review from cjwatson
[02:41] <lamont> doko: ok.  once the source is in the archive, I can actually work on bootstrapping it.
[05:05] <lamont> doko: if you're bored, feel free to look at the mlton build failures for 20070826-1... ICE * 2
[05:11] <doko> lamont: maybe not now ...
[05:13] <lamont> doko: it's on my "What Evah" list.  I really don't care one bit about it
[09:05] <lamont> doko: will icedtea-java7 be main or universe?
[09:05] <doko> lamont: universe
[09:05] <lamont> good
[09:06] <lamont> then it doesn't need to make a special trip through universe on its way to main or some such...
[09:06] <lamont> :-)
[09:06] <doko> or maybe multiverse, depends on cjwatson's analysis, but I'd say universe
[09:06] <lamont> (my bootstrapping archive is in sources.list.universe, you see...)
[09:06] <lamont> ah, good point... I'll add the bootstrap archive to sources.list.multiverse too
[09:31] <doko> lamont: is gutsy buildd chroot debootstrapple now?
[09:31] <lamont> doko: gutsy/hppa is _INSTALLABLE_
[09:31] <lamont> note that without people.u.c/~lamont/hppa/gutsy-stage0, you won't be able to resolve most build-dependency graphs
[09:32] <lamont> if you find packages that you need, that aren't in the ports.u.c archive, and launchpad.net has no build record for hppa/gutsy, holler
[09:32] <lamont> doko: there's a little bug in launchpad, you see... it'll be fixed for hardy.
[09:33] <lamont> in the meantime, some packages didn't get build records when we lit up hppa... the workaround for gutsy is to upload a new copy
[09:33] <lamont> which will get us network install and pretty much the entire toolchain
[09:33] <lamont> I decided that I didn't care about gcc-3.3 (which is one of the aflicted)
[11:04] <arthur-> doko: upload to gutsy would be a merge of gdc -17 upload if it were uploaded, can I call it -17ubuntu1 then? (fakemerge)
[11:46] <arthur-> doko: http://people.dunnewind.net/arthur/lutin/gdc-4.1_0.25-4.1.2-17ubuntu1.dsc
[11:46] <arthur-> sleep time, goodnight


[07:27] <acoc> cjwatson, I've been looking over cdimage and was wondering if you had any experience running the daily cron using another server's pool instead of rsyncing it locally
[07:27] <acoc> or if that's even possible
[07:48] <acoc> I'm going to get some sleep, I'll try you tomorrow
[09:43] <davmor2> cjwatson: What's the major fail with i386 on the cd builds do you know?
[09:45] <davmor2> live only
[10:35] <cjwatson> acoc: it's not possible with debian-cd as it stands
[10:36] <cjwatson> davmor2: more detail please, I just got up
[10:46] <davmor2> cjwatson: sorry afk
[10:48] <davmor2> I386 desktop doesn't show up here http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/intrepid/ubuntu/20080926/ at all which is why I'm guessing it is using the 23rd image but because it's not showing up I don't know why?  So I'm assuming a major failure of build being as amd64 is there...
[10:48] <davmor2> daily alternate seems to be up to date though
[10:51] <cjwatson> looks like the livefs build machine got stuck on a lock
[10:52] <cjwatson> I've cleaned up antimony's side of it and asked our sysadmins to fix terranova
[10:52] <davmor2> cjwatson: Okay cool just throw me when it didn't show up at all :)
[14:01] <persia> cjwatson: StevenK and I were looking at how to add the local installation pool to the ubuntu-mid images, and got a little lost in the debian-cd internals.  Would you be able to provide any guidance?
[14:02] <StevenK> I got very lost in debian-cd :-(
[14:05] <cjwatson> persia: do you have a separate archive already, or do you just want to throw in a few .debs?
[14:05] <cjwatson> err. I'm not actually sure what you mean, thinking about it
[14:05] <cjwatson> "local installation pool"?
[14:06] <StevenK> cjwatson: Like pool and dists on the Live CD
[14:06] <persia> On the live CD, there's a directory /pool/ in the VFAT, containing a local archive snapshot.  We'd like to do the same sort of thing.
[14:06] <StevenK> Where persia says VFAT, he means ISO9660 :-P
[14:07] <persia> Indeed :)
[14:07] <xivulon> is there any desire to add mythbuntu or other flavors that provide ubiquity live CD to wubi?
[14:08] <persia> xivulon: I'm interested, but I'm not sure about the timing for the ubuntu-mobile flavour.
[14:11] <xivulon> persia, as we discussed at UDS, I am a big fan of any flavor which can be used as a platform for providing a simplified desktop for young/elderly users
[14:13] <persia> xivulon: There's one big outstanding bug to hit first, but as soon as that gets hit, I'd love to look at how to make it work with wubi.  I don't have any windows though.
[14:14] <xivulon> don't need one for that I can provide a script to loopinstall onto another ntfs/ext3 partition for testing purposes, also in vm, (which is my testing rig)
[14:15] <cjwatson> persia: ok, I'll take a look ...
[14:15] <cjwatson> now *I'm* lost in build-mobile*.
[14:15] <persia> StevenK: Please provide guidance.
[14:16] <cjwatson> is there any tool to recursively copy a filesystem tree into a vfat image using mtools?
[14:16] <StevenK> Not that I've found.
[14:17] <cjwatson> OK, I suppose that could be hacked up with find+xargs
[14:17] <StevenK> cjwatson: Ignore build-mobile, it essentially does download-live-filesystems and publishing, build-mobile-img is the script that creates the vfat. I suspect you've already discovered this.
[14:17] <cjwatson> ok, um, so. I think the first thing you need to do is to bin build-mobile and integrate its functionality into build-image-set.
[14:17] <cjwatson> because you're going to need nearly all of build-image-set anyway in order to make this work
[14:18] <StevenK> But build-image-set scares me
[14:18] <cjwatson> yes. but it's doing the work you need.
[14:18] <cjwatson> you need the whole sync-an-archive and call ./build_all.sh stuff
[14:18] <cjwatson> not to mention running germinate
[14:18] <StevenK> ... We do?
[14:18] <cjwatson> yes, you do
[14:19] <cjwatson> that's what builds pool/ and dists/, ultimately
[14:19] <StevenK> Oh, right
[14:19] <cjwatson> otherwise where are you going to get it from?
[14:19] <StevenK> We call build-image-set for the dailies actually, we just drop out early.
[14:20] <cjwatson> where's that?
[14:20] <cjwatson> oh dear god
[14:20] <cjwatson> that's horrible. doesn't count. :)
[14:20] <xivulon> persia, can mid be run as a desktop on standard PCs?
[14:20] <StevenK> Oh yeah. We use it for setting up mail and then we jump to build-mobile.
[14:21] <persia> xivulon: -mid might be a little funny, but ought work on newer machines.  -mobile *definitely* can run as a desktop on regular PCs.
[14:21] <cjwatson> no, I meant using it properly
[14:21] <cjwatson> build-mobile isn't really all that different - you should just need to set IMAGE_TYPE=mobile or something and then key off that
[14:21] <StevenK> cjwatson: Hm. Maybe I shouldn't have pointed that out. :-)
[14:22] <cjwatson> and you've already got $PROJECT set
[14:22] <xivulon> persia: looks intersting will play with that in coming days
[14:22] <xivulon> superm1: what are your thoughts to have mythbuntu in wubi?
[14:22] <cjwatson> so you can make run-germinate check that to decide which seed collections to use, and germinate-to-tasks can pick out the right seeds from that and select the right set of packages
[14:23] <persia> xivulon: Thanks.  Please let me know if you need anything.
[14:23] <StevenK> cjwatson: But it looks like all of the heavy lifting is done in build_all.sh, which is ... odd code
[14:23] <cjwatson> oh, and list-seeds would need to spit out the right set of top-level seeds
[14:23] <cjwatson> StevenK: don't worry about build_all.sh for now
[14:23] <xivulon> ps is there any plan to do a livecd for gobuntu?
[14:23] <cjwatson> actually, it will largely just do what you tell it
[14:23] <cjwatson> xivulon: no, we aren't building Gobuntu any more
[14:23] <StevenK> cjwatson: From my reading of it, it eats small children.
[14:23] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-June/000434.html
[14:24] <cjwatson> StevenK: honestly, most of cdimage is dedicated to setting up debian-cd so that you can just point it in the right direction and say "eat that *very specific* small child over there"
[14:24] <StevenK> Heh
[14:24] <cjwatson> you are going to have to use it if you want pool/ and dists/
[14:24] <cjwatson> otherwise you'll have to reinvent it
[14:25] <xivulon> cjwatson: thx had missed that, didn't notice the "Free Software Only" option (also because I am mostly in automatic mode)
[14:25] <StevenK> cjwatson: So, I can see where you're going, I can leave CDIMAGE_LIVE set and have download-live-filesystems run. Maybe then I have a check for CDIMAGE_MOBILE and run build-mobile-img
[14:26] <cjwatson> right, that's sort of what I was thinking
[14:26] <persia> And as a bonus, we can have proper tracking of preseed files with debian-cd.
[14:26] <cjwatson> I never liked build-mobile being a separate script anyway :)
[14:28] <StevenK> So I'm probably going to have to set IMAGE_TYPE, which I've sort of ignored up till now
[14:31] <StevenK> cjwatson: Mind you, I like the new build-mobile a lot more than the old one
[14:32] <superm1> xivulon, they would have to be dedicating a significant amount of space to do so
[14:32] <superm1> xivulon, for recordings and such
[14:32] <superm1> i think if the frontend only mode were activated however, its doable
[14:32] <superm1> and quite interesting then
[14:33] <cjwatson> StevenK: I think you ought to. IMAGE_TYPE defines the "form factor" of the image, and should be used when you're creating a different type of object - d-i CD vs. live CD vs. DVD vs. VFAT mobile image
[14:34] <cjwatson> PROJECT is supposed to control the contents of the image (list of packages it contains, preseed files, particular live filesystem to fetch, etc.)
[14:34] <StevenK> cjwatson: Yes, I'm guessing I'm also going to have to either do strange things to cron.daily-live or write cron.daily-mobile
[14:34] <cjwatson> cron.daily-mobile would be fine
[14:34] <cjwatson> the cron.* scripts are all just thin wrappers to encapsulate setting environment variables and stuff
[14:34] <xivulon> superm1 would anything prevent users from storing stuff on ntfs directly?
[14:35] <xivulon> users can allocate a "normal size" (~10GB) but still access rw all of the host disk (/host)
[14:35] <superm1> xivulon, performance would be questionable i think
[14:35] <superm1> xivulon, but otherwise i suppose not..
[14:36] <xivulon> hmm /host access is native ntfs no loopfile involved
[14:36] <StevenK> cjwatson: Right, so aside from looking at how publish-daily works (meaning publish-mobile dies too), I need to do what to ./build_all.sh ?
[14:37] <superm1> xivulon, well at least implementing the frontend only portion would be more feasible to start and see how that goes
[14:37] <superm1> xivulon, additional questions would have to be asked once ubiquity took over though or asked during wubi
[14:39] <xivulon> superm1: the options are a) we preseed those questions, b) we show them in wubi interface (unlikely and certainly not in intrepid), c) we ask them after reboot (not nice)
[14:40] <superm1> xivulon, well at this point there are a few that are "critical" to be asked -
[14:40] <xivulon> It would be possible to show a few profiles in wubi and preseed from there
[14:41] <superm1> xivulon, the ones i'm referring to tell the machine the user/pass of the backend it connects to
[14:41] <superm1> and the hostname/database
[14:42] <superm1> i think it'd be fine to just ask them after reboot during --automatic mode though
[14:42] <xivulon> I'd guess it might be passable to leave that blank and have a dialog after rebooting
[14:42] <superm1> yeah
[14:42] <superm1> xivulon, let me find the preseed that i was using for enabling --automatic this summer
[14:43] <xivulon> We could have one profile for frontend only and one frontend + backend
[14:43] <xivulon> evand/cjwatson any view on the above?
[14:43] <superm1> yeah, develop frontend first and then frontend+backend after proving frontend first works
[14:44] <xivulon> for me it is only a matter of changing the configuration file, and add a new preseed template
[14:44] <xivulon> there should be no change in code
[14:44] <superm1> well in theory it should just "work" w/ the ubiquity changes i did this summer too
[14:45] <superm1> so if you can throw something together, i'll throw a windows vm together and give it a shot
[14:45] <superm1> http://paste.ubuntu.com/50877/
[14:45] <superm1> so that should be all the possible questions that get asked
[14:45] <cjwatson> StevenK: you should do nothing at all to build_all.sh itself. Leave it alone.
[14:46] <superm1> xivulon, so of the mythbuntu specific ones, would need to preseed the advanced_install, install_type, and the mythbuntu summary page
[14:46] <xivulon> cool will play with that today, will try to setup a backend first (yesterday attempts failed as my only desktop has only tv out which did not work...)
[14:46] <superm1> the rest would be optional
[14:46] <cjwatson> StevenK: the only things you should need to edit are tools/boot/intrepid/boot-* (either to make the image bootable in whatever's the appropriate way, or to skip it and let build-mobile-img do it), tools/add_live_filesystems (to add mobile instead), and perhaps preseed files in data/intrepid/preseed/
[14:47] <superm1> xivulon, oh the proprietary driver installation stuff is fixed in ubiquity trunk, but broken in our alpha6 disk
[14:47] <superm1> if that's where things went wrong
[14:47] <superm1> (if you didnt see it during install, that's a different problem)
[14:47] <xivulon> yep I thought that was the issue, it's an nvidia video with tv out
[14:47] <cjwatson> xivulon: I have too much to do the week before beta to help with adding new features which should have landed several weeks ago in order to be ready for 8.10 ...
[14:48] <superm1> xivulon, if this just "works" without too much effort, then i'm for it and will get some people on my team to help test it, but if we run into a handful of problems, lets defer to jaunty okay?
[14:49] <xivulon> cjwatson I appreciate that, but as mentioned this should only involve a change of configuration files, and we would go through the feature freeze exception approval anyway
[14:49] <xivulon> superm1 that is what I had in mind
[14:49] <persia> xivulon: Don't do an FFe just on account of ubuntu-mobile support.  Many of the target devices come with linux anyway.
[14:49] <cjwatson> xivulon: superm1 is much better placed to figure out what to do with mythbuntu than I am. I'd have to educate myself about it all from scratch
[14:50] <StevenK> cjwatson: build-mobile-img already deals with preseed files
[14:50] <superm1> cjwatson, yeah i'll work with xivulon to look at this
[14:50] <cjwatson> StevenK: ideally, those ought to move into data/intrepid/preseed/, IMO
[14:50] <cjwatson> the way it is now is just really awkward NIHJ
[14:50] <cjwatson> NIH
[14:51] <cjwatson> I can understand why you did it that way, but if you're reengineering things anyway, might as well bring it into sync
[14:51] <StevenK> I did it that way because build-image-set and friends made me go "OMG, my head is exploding"
[14:51] <persia> StevenK: I'd rather have the preseed files live someone accessible.
[14:52] <StevenK> cjwatson: So if build_all.sh is going to build the filesystem, what needs to be changed so it knows how?
[14:53] <cjwatson> I suspect making it actually build the entire filesystem is a little optimistic for now. However, you could make it build the filesystem tree and then bundle that into VFAT in build-mobile-img
[14:53] <StevenK> That works
[14:55] <cjwatson> edit the bin-images target in debian-cd/Makefile, and stick an extra case at the top of the if [ "$(DOJIGDO)" = "0" ] block to cover the "don't build an ISO at all" case
[14:56]  * StevenK is currently trying to determine where the checkout of debian-cd lives
[14:56] <cjwatson> BTW, what are you planning to put in pool/?
[14:56] <cjwatson> sftp://antimony/srv/cdimage.ubuntu.com/bzr/debian-cd/
[14:57] <StevenK> I was hoping persia could tell me.
[14:57]  * StevenK is also thinking that IMAGE_TYPE=mobile doesn't appeal
[14:57] <StevenK> Since that turns up in the published path
[14:58] <persia> I wanted to put in the DKMS-enablement stuff and some alternate networking for people with devices where the network didn't work out of the box (like mine).
[14:58] <cjwatson> published path?
[14:58] <StevenK> cjwatson: http://cdimage.u.c/....
[14:58] <cjwatson> oh, just special-case publishing *shrug*
[14:59] <cjwatson> the primary purpose of IMAGE_TYPE is to control form factor; publishing URLs are secondary and it's OK to special-case those
[15:00] <StevenK> Oh my god, my eyes.
[15:01] <StevenK> Who wrote this?
[15:01] <StevenK> Oh, Raphaël. That explains so much
[15:01] <cjwatson> err, yeah, don't look at the Makefile too hard
[15:01] <cjwatson> various people have had a go at rewriting bits, and I think it's more sane in Debian now, but I can't face the merge
[15:02] <StevenK> cjwatson: I think you'd need to be *completly* smashed to start it ...
[15:04] <superm1> persia, if these are "extra" modules that don't conflict with anything, it shouldnt be too late to add them to the kernel though i'd think?
[15:04] <cjwatson> I haven't been that drunk for some time
[15:04] <StevenK> cjwatson: Reminds me of code at $OLD_WORK. "# eyes closed now. <40 lines or so of evil TeX> # okay, you can open your eyes. If you can read this, you were cheating!"
[15:04] <cjwatson> heh
[15:05]  * StevenK re-reads cjwatson's comment, trying to apply it to the code
[15:05] <persia> superm1: For modules, I'm working with kernel devs, but I'm thinking of the same stuff that comes from the ship-live seed.
[15:06] <superm1> persia, so these would be NEW packages then?
[15:06] <cjwatson> persia: right, this is the sort of thing that the live CD does
[15:07] <StevenK> cjwatson: I'm guessing I want ifeq ($(CDIMAGE_MOBILE),1) and else and endif around that block, but that breaks the like 50 lines that are \'d
[15:07] <cjwatson> so the live CD is a sensible model
[15:07] <cjwatson> StevenK: no, use if in shell
[15:07] <cjwatson> if [ "$(CDIMAGE_MOBILE)" = 1 ]; then ...
[15:07] <persia> superm1: No.  Just existing packages on the CD.  For the modules, I've been told that it's just a matter of understanding why they aren't loaded.
[15:08] <StevenK> cjwatson: If I have to follow the coding style, I may claw my eyes out in sheer self-defense. :-P
[15:09] <StevenK> I want else; \ or else \ ?
[15:09] <StevenK> I hardly ever collapse if's to one-line
[15:11] <cjwatson> ok, you can stop going on about how awful everything is now. :)
[15:11] <cjwatson> if [ ... ]; then \
[15:11] <cjwatson>         ...
[15:11] <cjwatson> elif [ ... ]; then \
[15:12] <StevenK> cjwatson: So, in that bit, I want to make my filesystem tree under $(BDIR)/CD$$n ?
[15:12] <cjwatson> err, I think you misunderstood me
[15:12] <cjwatson> debian-cd will make the filesystem tree under $(BDIR)/CD$$n
[15:12] <cjwatson> in bin-images, you just have to arrange *not* to call mkisofs - you don't have to build anything
[15:16] <acoc> cjwatson, do you happen to know about how much space would be required for a single dist pool sync
[15:17] <cjwatson> acoc: for which components and which architectures?
[15:17] <acoc> for i386 and sorry what were components again
[15:18] <cjwatson> main, restricted, universe, multiverse
[15:18] <acoc> just main
[15:18] <StevenK> cjwatson: Oh, right
[15:19] <StevenK> cjwatson: Do I also want the $(jidgo_cleanup) bit?
[15:20] <cjwatson> StevenK: yeah, you might need to guard that too
[15:21] <cjwatson> I can't remember, check what the called script does
[15:22] <cjwatson> acoc: a bit over 6GB
[15:22] <acoc> cjwatson: oh yeah that's not bad at all thanks
[15:23] <StevenK> cjwatson: Meh, it's dealing with .jigdo, don't care
[15:32] <StevenK> cjwatson: Is there anything I need to do in that Makefile?
[15:33] <StevenK> Er. Anything *else*
[15:35] <cjwatson> not that I can think of right now, but consider this an iterative process ;-)
[15:35]  * StevenK grins
[15:36] <StevenK> preseed file added, too
[15:36] <persia> speaking of iterative processes, I've added branches for bugs 274781 and 274785, if there's any chance of a review.  This is more lpia bits for grub-installer and ubiquity.
[16:37] <kirkland> evand: hiya, i tried usb-creator, and it doesn't appear to be working for me
[16:37] <cjwatson> persia: you don't seem to have pushed to the branch for 274781 properly
[16:37] <kirkland> evand: i should be able to point kvm to it, and test it that way, right?
[16:37] <evand> kirkland: Did it crash or is it just not booting?
[16:37] <kirkland> evand: not booting
[16:38] <kirkland> evand: i got the install to succeed
[16:38] <cjwatson> kirkland: server CD?
[16:38] <kirkland> cjwatson: no, kubuntu-desktop-amd64
[16:38] <evand> kirkland: That;s probably my recently discovered bug of it not properly setting the boot flag.
[16:38] <cjwatson> ok, I'll shut up :)
[16:38] <kirkland> evand: i was just about to try and change that in fdisk
[16:38] <evand> kirkland: fdisk /dev/whatever, a, partition number, w; done
[16:38] <kirkland> evand: thought i'd ask first
[16:38] <kirkland> evand: yeah, i just wanted to check
[16:38] <persia> cjwatson: Sorry.  repushing now/
[16:39] <kirkland> cjwatson: :-)  i suppose i should test the server
[16:39] <evand> Speaking of which, anyone know a reliable way of dermining the partition number that a block device represents, given the knowledge of it and its parent?
[16:39] <kirkland> i'm just not a kubuntu user, but i wanted to see what all the kde4 hype was about
[16:39] <cjwatson> kirkland: won't work yet, bug 234185
[16:39] <kirkland> ah
[16:39] <cjwatson> evand: /sys/block?
[16:40] <kirkland> evand: cool, that fixed it (bootable partition)
[16:40] <kirkland> evand: very nice
[16:42] <evand> cjwatson: can you be more specific?  I thought the device's minor number corresponded to the partition number, but apparently I'm very wrong.
[16:42] <cjwatson> it should do, sure. I'm not sure I understood your question
[16:44] <evand> I need to be able to pass parted a partition number to mark as bootable, but the utility works in device nodes, so I need to go from "/dev/sdb1" to "1".
[16:45] <evand> I could take the difference of /dev/sdb and /dev/sdb1, given the knowledge of both of them, but that seems hackish.
[16:45] <cjwatson> see how grub-installer does it
[16:45] <cjwatson> it is hackish :-)
[16:45] <evand> ah, good point.  Will do
[16:45] <evand> hah
[16:45] <cjwatson> or, hang on
[16:46] <cjwatson> hmm, no, /sys/block doesn't have it
[16:46] <cjwatson> you pretty much just have to subtract the parent device name, but note that some devices use a leading "p" before the partition number
[16:47] <cjwatson> evand: lilo-installer might involve less bonkers code to copy from
[16:47] <evand> wow that's a lot of sed
[16:48] <cjwatson> but if you are using grub-installer, it's the make_active_partition function
[16:48] <evand> ok, thanks
[16:50] <cjwatson> evand: are you going to be able to fix the grey partition thing by beta?
[16:50] <cjwatson> I was hoping to do an upload today assuming I can fix 182004
[16:51] <evand> cjwatson: I'm not sure I can fix it by end of business today, but I can surely have it done by the end of the weekend.
[16:51] <cjwatson> is it just a change of some constant somewhere?
[16:51] <evand> oh, sorry, I'm mixing bugs.
[16:51] <evand> That I can fix quickly
[16:51] <evand> and yes, it is
[16:51] <cjwatson> ok, cool
[16:51] <evand> on it now
[16:52] <evand> (thought you were talking about the rendering issues previously)
[16:52] <cjwatson> ah, no
[16:53] <persia> Which is the rendering bug?
[16:56] <evand> http://launchpadlibrarian.net/17699770/install1.png
[16:57] <evand> from https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/271512 and possibly others
[16:58] <persia> Oh good.  That was one of the more minor things on my list, and I was hoping it wasn't -mid specific.  Thanks for the reference.
[17:04] <kirkland> evand: okay, now i'm trying to boot from the usb stick on real hardware, and i'm stuck at the SYSLINUX bootloader boot: prompt
[17:05] <cjwatson> what happens if you press enter?
[17:05] <kirkland> Could not find kernel image: linux
[17:05] <kirkland> i've dorked around with bios, trying to rearrange the drives
[17:05] <kirkland> i suspect it's booting off of one drive, looking for a kernel on another?
[17:05] <evand> ...curious
[17:06] <persia> cjwatson: LP doesn't seem to want to display the branch despite a refresh.  I've attached a diff to 274781
[17:06] <evand> hrm
[17:07] <persia> Differences between syslinux.cfg and isolinux.cfg ?
[17:10] <CIA-50> grub-installer: cjwatson * r747 ubuntu/ (debian/changelog debian/control grub-installer): Add support for lpia (LP: #274781)
[17:10] <evand> kirkland: hrm, I cannot reproduce this.  Are /syslinux and /syslinux.cfg present on the root of the disk?
[17:11] <kirkland> evand: yes, and yes
[17:11] <kirkland> evand: i strongly suspect something funny in my bios
[17:11] <kirkland> evand: unfortunately, i overwrote the working DSL i had installed on this device :-)
[17:13] <evand> kirkland: Could you try running usb-creator with -s?
[17:13] <kirkland> evand: sure, i'll dork around with it a bit more
[17:19] <CIA-50> ubiquity: evand * r2851 ubiquity/ (aclocal.m4 configure configure.ac): Bump to 1.9.20
[17:20] <cjwatson> maybe 1.10.0 since we're approaching beta? (historically I bumped minor just before beta)
[17:20] <evand> ah, will do
[17:21] <CIA-50> ubiquity: evand * r2852 ubiquity/ (configure configure.ac): Bump to 1.10.0
[17:23] <CIA-50> ubiquity: evand * r2853 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py):
[17:23] <CIA-50> ubiquity: Use a normal color for the partition bar when use entire disk is
[17:23] <CIA-50> ubiquity: selected (LP: #273271).
[17:23] <evand> Hooray, usb-creator is in main.
[17:26] <StevenK> evand: That can be fixed :-P
[17:27] <evand> heh
[17:28] <cjwatson> evand: ooh
[17:32]  * evand will be quite happy when bug 232429 is fixed (auto marking fix committed).
[17:38] <cjwatson> that's more about projects than source packages, I think, though I added a comment about the latter
[17:40] <evand> ah, thanks
[17:52] <CIA-50> tasksel: cjwatson * r1374 ubuntu/ (debian/changelog ubuntu-seeds.pl):
[17:52] <CIA-50> tasksel: Work around a bug when checking out ubuntustudio seeds into a
[17:52] <CIA-50> tasksel: repository.
[17:59] <CIA-50> ubiquity: cjwatson * r2854 ubiquity/ (debian/changelog ubiquity/components/partman.py):
[17:59] <CIA-50> ubiquity: Don't mark partman questions as seen when we expect them to be asked
[17:59] <CIA-50> ubiquity: again (LP: #182004).
[18:03] <persia> \o/
[18:03] <CIA-50> ubiquity: cjwatson * r2855 ubiquity/ (debian/changelog gui/glade/ubiquity.glade): Set GtkAdjustment page_size to zero in Glade files too.
[18:05] <CIA-50> tasksel: cjwatson * r1375 ubuntu/ (5 files in 3 dirs):
[18:05] <CIA-50> tasksel: * Build mobile-* tasks.
[18:05] <CIA-50> tasksel: * Update Ubuntu tasks from seeds, adding mobile-mid, mobile-mobile (ahem),
[18:05] <CIA-50> tasksel:  and virt-host tasks.
[18:06] <CIA-50> tasksel: cjwatson * r1376 ubuntu/debian/changelog: releasing version 2.73ubuntu9
[18:16] <CIA-50> ubiquity: cjwatson * r2856 ubiquity/ (debian/changelog scripts/install.py): merge from lp:~persia/ubiquity/lpia-grub
[18:17] <cjwatson> persia: BTW if you use debcommit then bzr will know about the bug-fix metadata
[18:17] <persia> cjwatson: Thank you.  That ought sort everything for the -mid installs.
[18:18] <persia> Oh.  That saves the frustratingly annoying duplicate typing.  Thank you.
[19:04] <cjwatson> evand: (feel free to upload ubiquity at some point, I'm done for today and probably happy with it for beta)
[19:04] <evand> cjwatson: noted, will do


[02:22] <wgrant> cjwatson: Hm, latest by DS.id should be quick and easy, but latest by DS.version is not. I guess that latest (non-zero size?) on disk would work
[02:23] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/destroy-pppd/+merge/172945 , now with far more destruction
[02:24] <StevenK> wgrant: And thanks for the prod -- that branch pulls PDJ and its infra down to -2 from +104
[02:24] <wgrant> Will look at reviews in a sec
[02:25] <wgrant> Been vaguely up since 4am, so not entirely alive all day
[02:25]  * StevenK peers at wgrant