[05:21] <Hobbsee> cody-somerville: yes
[05:21] <Hobbsee> a few days late, i suspect
[05:22] <superm1> yay contentless pings from 2 days ago
[05:24] <Hobbsee> yup
[05:25] <ajmitch> good to see that you're still alive though
[05:26]  * Hobbsee quickly dies
[05:27] <ajmitch> oh dear
[05:28] <pitti> Good morning
[05:28] <ajmitch> morning pitti
[05:28] <ion> hi
[05:32] <RAOF> 'Tis a pitti.  Hello!
[05:33] <pitti> hey RAOF, how are you?
[05:33] <pitti> is it just me, or is resuming very crashy in maverick these days?
[05:33] <RAOF> Depending on what you mean by “very”, I think it might be just you.
[05:34] <pitti> I either get kernel freezes or X crashes
[05:34] <RAOF> I mean, resuming for me has failed once or twice over the last month, which is I think _slightly_ more frequently than in Lucid.
[05:34] <RAOF> But it's difficult to tell at that frequency.
[05:34] <pitti> ok, then I'll have a closer look next time
[05:51] <pitti> slangasek: the upstart SRU has had lots of verification, and I haven't heard about regressions, so for the sake of 10.04.1 I'm fine with releasing it early
[05:52] <slangasek> pitti: right; there seem to be a number of other SRUs that also need processing if we're to use the current ISOs for .1, I'm working on verifying the samba fix now
[05:56] <pitti> slangasek: d-i is fine, I asked cjwatson to copy this (since it needs some manual fiddling)
[05:57] <pitti> so that leaves scim, xorg-server, and casper AFAICS?
[05:57] <pitti> slangasek: I'll test casper
[05:57] <slangasek> pitti: ibus-anthy, libvirt?
[05:58] <pitti> oh, we carry libvirt, too? ok
[05:58] <slangasek> I don't know for sure; it's in main
[05:58] <slangasek> far too much manual effort to check these things
[05:58] <slangasek> yes, libvirt is on the server CD
[05:59] <slangasek> erm, so is sane-backends, which is verification-failed?
[06:00] <slangasek> not on the server CD, it's on alternate
[06:00] <slangasek> and on desktop :(
[06:00] <pitti> slangasek: right, we can't move sane, I'm afraid
[06:00] <slangasek> which means we need to punt it and respin
[06:01] <pitti> slangasek: we could remove it from -proposed and rebuild test CDs?
[06:01] <slangasek> yes
[06:01]  * pitti removes
[06:01] <pitti> good time, 2 mins before publisher
[07:12] <slangasek> pitti: hmm, sane-backends still in -proposed, an hour later
[07:13] <pitti> slangasek: trying again, checking LP this time
[07:13] <slangasek> pitti: saw your follow-up to 591207; what do you think we should do with casper?
[07:13] <pitti> https://edge.launchpad.net/ubuntu/+source/sane-backends/+changelog
[07:14] <pitti> slangasek: ^ this claims that it was removed already, hmm
[07:14] <pitti> slangasek: ibus-anthy verified (moving to -updates now), casper causes some trouble
[07:14] <pitti> slangasek: not sure why my dist-upgrade failed, but it gets a little further with the -proposed version
[07:15]  * pitti checks hte USB stick whether initramfs was updated/untouched/destroyed
[07:16] <pitti> -rw-r--r-- 1 martin martin   9837789 2010-08-16 07:47 initrd.lz
[07:16] <pitti> -rw-r--r-- 1 martin martin    413696 2010-08-16 06:03 initrd.lz.new
[07:16] <pitti> hmm
[07:17] <pitti> slangasek: followed up
[07:17] <slangasek> ok
[07:17] <pitti> slangasek: so the net result of all this is that it's now writing an additional broken file to the USB stick :/
[07:18] <pitti> slangasek: my gut feeling is that we should pull it from -proposed, since we have to respin anyway; this would avoid the new broken file
[07:19] <pitti> slangasek: what do you think?
[07:22] <pitti> slangasek: hm, I also removed ifupdown from -proposed (standard cleanup), and it's still published
[07:22]  * pitti wonders whether there's something wrong with removals in general
[07:42] <slangasek> pitti: the casper bug seems like a rather bad one to not have included in .1, but it wasn't milestoned, so yeah, I guess we should pull it
[07:42] <slangasek> pitti: can I leave it to you to figure out why -proposed removals aren't working, and respin the world once you have that figured out?  I'll mark the images appropriately in the tracker
[07:43] <pitti> slangasek: yes, that's fine (so that you can go to bed now :) )
[07:43] <slangasek> either way, I need to get some sleep, yeah; so if you can't get to it today, I'll look at it myself in the morning
[07:43] <pitti> slangasek: if it still doesn't get removed in 20 mins, I'll prod soyuz guys
[07:43] <slangasek> ack, thanks
[08:06] <pitti> slangasek: ah, got removed now
[08:21] <dholbach> good morning
[08:22] <ion> hi
[08:37] <pitti> slangasek, cjwatson: I copy d-i to -updates, so that the alternates will be ok; we still need to copy the netboot bits, though
[08:40] <pitti> kirkland: could you give the proposed .deb in bug 571093 some testing? we need to move it to -updates soon
[08:41] <lanoxx> i have merged a bzr branch into my local working copy, how can i go back to the master branch?
[08:41] <lanoxx> how can i switch branches in bzr?
[08:42] <pitti> lanoxx: check it out separately, or overwrite your local copy with bzr pull lp:<mastername> --overwrite
[08:44] <lanoxx> pitti, if i overwrite it, then i need to check out the other branch again right?
[08:44] <pitti> lanoxx: if you need both branches, it's generally easier to just keep them checked out separately
[08:46] <lanoxx> pitti, how do i check them out seperately
[08:46] <lanoxx> pitti, sorry i have not much experience with bzr, im use to git
[08:47] <RAOF> lanoxx: You *can* use “bzr switch” in pretty much the same way as “git checkout”, but it's probably not what you want to do.
[08:49] <Hobbsee> ScottK: you around?
[08:49] <lanoxx> RAOF, can i check out the master branch again and then switch between my current branch and the master branch?
[08:49] <RAOF> lanoxx: The way I generally deal with it is to have one directory per branch.  So, you have your current tree, which is a branch of trunk with another branch merged in.  If you wanted to keep that branch, and also get a checkout of the master branch, you'd go up a directory and run “bzr branch lp:whatever”
[08:49] <lanoxx> RAOF, ah ok. i will do that
[08:50] <RAOF> lanoxx: You can, with a little set up, make it so that you switch between branches in the same directory.  It's probably much less effort to just have one directory per branch :)
[08:50] <RAOF> If you're going to do that, then “bzr init-repo .” in the directory containing your branches is a good performance optimisation to do.
[08:50] <lifeless> --no-trees too
[08:51] <RAOF> lifeless: I wasn't thinking of the bzr switch dance there :)
[08:51] <lanoxx> does bzr have an option like format-patch?
[08:51] <lanoxx> or should i just use bzr diff?
[08:52] <RAOF> “bzr bundle” does a similar thing to format-patch.
[08:52] <RAOF> Man.  “buffers” is one of those words that just get more and more weird the longer you stare at them.
[08:53] <lifeless> RAOF: bzr send please, not bundle
[08:54] <RAOF> lifeless: Ah, sorry.  -EHAZY.  bzr send attaches a bundle, right?
[08:56] <lifeless> yeah
[08:57] <ogra> pitti, vala seems to have landed in universe (breaking a rebuild of libindicate on armel)
[08:57] <pitti> ogra: hm, that was called vala-0.10
[08:57] <pitti> and was in NEW
[08:57] <ogra> http://ports.ubuntu.com/ubuntu-ports/pool/universe/v/vala/
[08:57] <ogra> valac-0.10
[08:57] <pitti> we now have two different vala versions as it seems; I asked Robert about it, but I'm not clear yet how the final result should look like
[08:58] <ogra> hmm, k
[08:58] <pitti> oh, the source is still vala?
[08:58]  * pitti checks
[09:00] <pitti> ogra: promoted
[09:00]  * ogra hugs pitti
[09:01] <ogra> now there is only zeitgeist that breaks image builds left :)
[09:02] <pitti> ogra: already promoted this morning
[09:02] <ogra> ah, cool
[09:27] <pitti> hehe, did anybody look at a Debian bug today?
[09:28] <pitti> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582113
[09:28] <pitti> 17 years birthday?
[09:29] <ogra> cute
[10:10] <seb128> why do people want every crack in the universe to go in Ubuntu
[10:10] <seb128> shrug
[10:11] <seb128> I will no reply on the list, seems there is already lot of noise in that discussion
[10:11] <Laney> it is called universe ;-)
[10:11] <pitti> TBH it's what we wanted to in warty, but I agree that we need to stop doing this
[10:11] <seb128> well, that's one of the complain we get atm
[10:11] <pitti> Laney: so it's a matter of definition, I guess
[10:11] <pitti> universe == all stuff you can find, or universe == some sanity/maintenance involved
[10:11] <seb128> quality is not egual and people misjudge ubuntu on some of the broken things they find
[10:12] <seb128> we should lower the number of sources in the official archive and improve quality
[10:12] <Laney> making this stuff more visible in s-c isn't going to cause people to think it's not part of Ubuntu though
[10:12] <seb128> we should not aim at pushing every crack application nobody will keep working on 6 months later in universe
[10:12] <seb128> well it's easy to message that this entry is not ubuntu
[10:12] <seb128> and why people keep arguing to use backports
[10:12] <seb128> that just doesn't work
[10:12] <pitti> Laney: we certainly get some responsibility, but it's a matter of presentation IMHO
[10:13] <pitti> people don't blame Apple or Google for every broken Android/iPhone app either
[10:13] <seb128> backport require the source to be the same in the new distro
[10:13] <seb128> ie you can't enable build using new gdbus or whatever
[10:13] <pitti> well, maybe they do, but at this point we can't help it any more
[10:13] <seb128> or you need to start tweaking your packaging to have different builds in backports
[10:13] <seb128> that makes no sense
[10:14] <Laney> anyway I think that maintaining stuff in universe is something we are terrible at too
[10:14] <seb128> right
[10:14] <Laney> not arguing for that
[10:14] <seb128> I think we should clean universe
[10:14] <pitti> well, terrible -> it's a manpower issue
[10:14] <pitti> it's a helluva job
[10:14] <Laney> sure, of course
[10:14] <seb128> we are just lying when we pretend to be able to maintain that amonth of softwares
[10:14] <seb128> we should aim for better quality
[10:15] <Laney> luckily we don't have to actively maintain most of it
[10:15] <seb128> I'm not sure why people want to turn universe to get as many crack non maintain as we can
[10:15] <seb128> still there is lot unmaintained in debian as well
[10:15] <seb128> or upstream
[10:15] <Laney> I think there's a lot of scope for us to improve the automated QA
[10:15] <Laney> people seem to work well when there's lists
[10:16] <seb128> we should perhaps be agressive in clean things which rot
[10:16] <seb128> or are buggy
[10:16] <Laney> yes
[10:16] <Laney> the binary removal thing which happened in Lucid was a good idea IMHO
[10:16] <Laney> "fix this stuff or it won't be in the release"
[10:17] <seb128> well why fighting the noise
[10:17] <seb128> we could probably make a list of issues on all those packages nobody use
[10:17] <seb128> but wouldn't we spend efforts in a better way trying to improve what users actually run
[10:17] <Laney> apart from the 5 or 6 people that it's absolutely essential for
[10:17] <seb128> rather than fixing un-used packages to be compliant with new policy or whatever
[10:18] <seb128> or build softwares that didn't change for 3 years to build with a gtk update
[10:19] <seb128> session restart brb
[10:32] <diwic> Hi, I have some trouble trying to build a package with pbuilder (with arch=i386 on an AMD64 machine)
[10:32] <diwic> the error message is "linux-headers-2.6.32-24-generic is a virtual package"
[10:43] <directhex> diwic, is your pbuilder up to date?
[10:50] <cjwatson> Laney: ubuntu-cli-mono-dev> yes, it should - done
[10:50] <Laney> should?
[10:50] <Laney> oh, ubuntu-dev, yeah —­thanks!
[10:51] <cjwatson> superm1: EFI> this thing called "holiday" ... I'm still tracking it, only reason it didn't land earlier was that I had problems getting 64-bit GRUB to boot my test machine, so I'll be getting back to that this week
[10:52] <pitti> hey cjwatson, welcome back! had a nice holiday?
[11:00] <cjwatson> pitti: I've copied d-i/lucid-proposed to -updates now (pending next publisher run); FWIW the procedure has been documented in https://wiki.ubuntu.com/ArchiveAdministration#Special%20case:%20debian-installer%20updates for a while
[11:00] <pitti> cjwatson: ah, thank you!
[11:17] <Riddell> pitti: are you the force behind the mysterious appearance of lucid .1 images?
[11:17] <pitti> Riddell: yes; we need to respin due to some failed SRUs
[11:17] <pitti> see discussion with slangasek here this morning
[11:22] <cjwatson> pitti: yep, much less frazzled now :)
[11:23] <cjwatson> pitti: FWIW am respinning lucid server now - it broke on a locking issue I hadn't previously thought of, now fixed in bzr
[11:23] <diwic> directhex, hmm, interesting point, I should probably add lucid-updates and lucid-security to my pbuilder...
[11:23] <pitti> cjwatson: ah, thanks
[11:23] <cjwatson> very rare locking issue though - it only happened if two parallel builds completed at almost exactly the same time
[11:24] <pitti> I'm respinning kubuntu desktop lucid, then the set should be complete again
[11:24] <cjwatson> (so I haven't bothered rolling out the fix yet)
[11:25] <pitti> cjwatson: marked server for rebuild in the tracker
[11:34] <cjwatson> pitti: my respin was only based on the assumption that it was already rebuilding, and that somebody wanted the previous build this morning to succeed :)
[11:35] <pitti> cjwatson: http://cdimage.ubuntu.com/ubuntu-server/lucid/daily/20100816.2/ looks like your respin?
[11:35] <pitti> it has the reverted sane-backends, so it's good
[11:36] <pitti> and reverted casper, too
[11:36] <baptistemm> hi there
[11:36] <cjwatson> pitti: yes
[11:37] <pitti> cjwatson: added to tracker; I'll add kubuntu desktop once they finish, then "the world" is rebuilt
[11:38] <geser> could a core-dev please give back: shotwell rrdtool. Both are in reality DEPWAITs and resolved now.
[11:38] <pitti> doing
[11:38] <geser> thanks
[11:40] <baptistemm> heh, seb128 updated bluez for maverick previous week
[11:40] <baptistemm> why didn't he merged from debian ?
[11:48] <diwic> directhex, do you know how to add lucid-updates and lucid-security to the lucid chroot?
[11:49] <directhex> set a pipe-delimited value for OTHERMIRROR in ~/.pbuilderrc, and run "pbuilder update --override-config"
[11:51] <diwic> directhex, OTHERMIRROR="lucid|lucid-updates|lucid-security"? I mean, that's not exactly a mirror
[11:51] <pitti> slangasek, cjwatson: all lucid CDs rebuilt and added to tracker; they picked up the failed SRU rollbacks
[11:51] <directhex> diwic, no, that's not a mirror
[11:51] <diwic> directhex, I'll read the manpage
[11:52] <diwic> directhex, and come back if I still have a question :-)
[11:52] <directhex> diwic, OTHERMIRROR="deb http://security.ubuntu.com/ubuntu lucid-security main restricted universe multiverse|deb http://mirror.ox.ac.uk/sites/archive.ubuntu.com/ubuntu/ lucid-updates main restricted universe multiverse" is more mirror-flavoured
[11:55] <diwic> directhex, hey it seems to be working and you saved my day :-)
[11:55] <directhex> diwic, the --override-config flag is needed for any changes to your mirror variables to actually be set
[11:55] <diwic> directhex, I wrote it as OTHERMIRROR="deb $MIRRORSITE $DIST-security $COMPONENTS" though, out of lazyness :-)
[11:56] <directhex> diwic, i could not guarantee that you had those vars defined
[11:56] <diwic> directhex, anyway thanks for the help :-)
[11:57] <ara> pitti, are Ubuntu 20100816.1 images ready to test? or are we waiting for .2 ?
[11:57] <pitti> ara: all images ready to test and on the tracker
[11:58] <ara> pitti, thanks
[11:58] <pitti> ara: kubuntu desktop and server are .2, rest .1
[13:22] <shadeslayer> dholbach: around?
[13:22] <dholbach> shadeslayer: just about to head out for lunch - how can I help=
[13:22] <dholbach> ß
[13:23] <dholbach> ?
[13:23] <shadeslayer> dholbach: can you retry kdenetwork?
[13:23] <shadeslayer> please :)
[13:23] <shadeslayer> https://edge.launchpad.net/ubuntu/+source/kdenetwork
[13:23] <dholbach> shadeslayer: almost anyone could have clicked that button for you! :)
[13:23] <shadeslayer> the other builds failed because libsrtp wasnt in main, i64 builds because it was moved when it built
[13:24] <shadeslayer> dholbach: i know, i dont know who else is allowed to push that button tho :P
[13:25] <cjwatson> anyone who can upload a package can retry it
[13:27] <dholbach> shadeslayer: done
[13:27] <shadeslayer> dholbach: thanks :D
[13:27]  * dholbach → late lunch
[13:27] <shadeslayer> cjwatson: the package was sponsored :P
[13:28] <pitti> shadeslayer: retried
[13:28] <shadeslayer> lol.. :D
[13:28] <pitti> shadeslayer: NB that ia64 and sparc will be removed soon anyway
[13:28] <shadeslayer> pitti: thanks anyways :D
[13:29] <shadeslayer> pitti: dont care about them ^_^
[13:29] <pitti> someone beat me to it anyway
[13:29] <shadeslayer> just noticed that i64 built
[13:29] <pitti> ah, dholbach
[13:29] <shadeslayer> yep
[13:30] <shadeslayer> pitti: most packages on sparc are ftbfs anyways :/
[13:30] <shadeslayer> they need special love
[13:31] <StevenK> *sparc* needs special love
[13:33] <cjwatson> shadeslayer: that doesn't change the accuracy of my statement ...
[13:34] <shadeslayer> cjwatson: i can retry the build ? really?
[13:34] <cjwatson> that means you can't retry.  but you said "I don't know who else is allowed to push that button", and I told you
[13:34] <cjwatson> you can't upload the package yourself, so you can't retry it yourself
[13:34] <shadeslayer> ohh
[13:34] <cjwatson> but anyone who could have sponsored it for you could also have retried it
[13:34] <shadeslayer> got it now .. anyone who can upload can retry
[13:54] <superm1> cjwatson, ah okay, i was just a little worried it wasn't there at FF, i wasn't aware you were on holiday for a while.  cool, hope it was a good time off :)
[14:01] <apw> is there an approved way to remove a PPA and un-upgrade all the packages?   i see xorg-edgers has a ppa-purge thingy that does it.  should something akin to that be available to mirror apt-add-respository ?
[14:07] <pitti> apw: ppa-purge is in universe now
[14:08] <apw> pitti, so it is, thats better than nothing
[14:13] <ScottK> Hobbsee: Around now.
[14:32] <ahasenack> hey guys, do you know when 10.04.1 is scheduled to be released? Is it tomorrow?
[14:33] <pitti> ahasenack: if all goes well, yes
[14:33] <ahasenack> pitti: thanks
[14:36] <akgraner> mdz, do you have 5 mins right quick?
[14:37] <mdz> akgraner, sure
[14:59] <hallyn> general bug question - when i have a bug that's reported as affecting 3-5 projects, is it normal to change the priority/status for each project?  Or just one, bc that's enough info?
[14:59] <hallyn> and also, is marking it invalid against a particular project considered ok (if it has nothing to do with that package)?
[15:15] <bigon> do you think that gobject-introspection could be updated to the version in experimental? 0.6.15~git20100713-1 ?
[15:15] <bigon> this version is needed for gnome-shell
[15:42] <seb128> the gobject-introspection in maverick is newer than that
[15:42] <seb128> it got 0.9
[15:53] <asac> is anyone here who understands this gnome-sessio hack that uses X-Gettext-Domain or sometihng in .desktop file to select a specific gnome-session variant?
[15:53] <asac> seb128: ?
[15:59] <seb128> asac, the gettext domain is not for variants?
[15:59] <seb128> asac, what do you call variants?
[15:59] <asac> seb128: efl vs unity vs plain gnome
[16:00] <asac> seb128: look at their desktop files. they all use "gnome-sessioN", but use a X-Gettext-Domain hack to choose which variant (e.g. xdg autostart dir)
[16:00]  * sebner waves at asac :)
[16:01] <seb128> asac, hum, it's a hack from didrocks I think but he's away 2 weeks
[16:03] <asac> seb128: yeah i know thats why i wondered if anyone else knows about that. i wasnt able to spot the code that does that :((
[16:03] <seb128> it's probably in gdm
[16:03] <seb128> review the distro changes there
[16:05] <asac> already did briefly ... let me look agian
[16:05] <asac> wow we have a bunch of patches ;)
[16:06] <ebroder> kaushal: Did you see someone already replied to your e-mail?
[16:06] <asac> seb128: dont see it there using grep
[16:06] <asac> lets look in gnome-session
[16:07] <asac> not there either :/
[16:07] <seb128> asac, let me check
[16:07] <asac> it really feels like he is reusing some existing code ... otherwise he probably wouldnt have reused this awful Gettext thing ;)
[16:15] <seb128> hum
[16:15] <seb128> asac, 15_default_session.patch in gdm?
[16:16] <seb128> asac, /etc/X11/Xsession.d/60xdg_path-on-session
[16:23] <seb128> asac, I don't think X-Gettext-Domain is used for the default session
[16:23] <seb128> asac, it's just the gettext domain for translations
[16:26] <asac> hmm
[16:27] <asac> seb128: so in /etc/X11/Xsession.d/60xdg_path-on-session there needs to be GDMSESSION set to "efl" somehow ... how is that working?
[16:27] <asac> let me look at 15_default_session.patch
[16:28] <seb128> asac, the etc change is changing the session parameter according to what you select in gdm
[16:28] <seb128> asac, it's not what selects the session though
[16:28] <seb128> asac, GDMSESSION has the value of the .desktop you select
[16:29] <seb128> ie une.desktop will have GDMSESSION=une
[16:29] <seb128> asac, those -une paths have special gconf keys and autostart etc
[16:29] <asac> seb128: thats strange because the efl .desktop is called "une-efl.desktop", but the xdg path is: xdg-efl ... so where is the une- stripped ;)?
[16:29] <asac> oh
[16:29] <asac> wait
[16:30] <asac> might be i am just looking at old (not cleaned up conffiles) here
[16:30] <asac> seb128: kk ... all fine ;)
[16:30] <asac> still feels hackish ;)
[16:30] <seb128> ok
[16:30] <asac> thanks
[16:30] <seb128> np
[16:30]  * asac has to think about this to understand what this means for his uxlaunch plans
[16:31] <seb128> asac, /usr/share/gconf/une/mandatory/20_une-gconf-mandatory
[16:31] <seb128> asac, see that for example
[16:32] <asac> seb128: so to understand our efl session autostarts whatever is in /etc/xdg/autostart + /etc/xdg/xdg-une-efl/autostart ?
[16:32] <seb128> asac, you might want to set the wm and the panel to what you want use
[16:32] <asac> e.g. both?
[16:32]  * asac checks that too
[16:32] <asac> seb128: ok, but thos  /desktop/gnome/session/required_components/panel values etc are read by gnome-session, right?
[16:32] <seb128> yes
[16:33] <asac> e.g. if gnome-session starts with right XDG dirs all should be fine?
[16:33] <asac> (given that all the gconf stuff is also there)
[16:33] <seb128> asac, you don't use gnome-session?
[16:33] <seb128>   XDG_CONFIG_DIRS="$DEFAULT_XDG_CONFIG_DIRS"/xdg-"$GDMSESSION":"$XDG_CONFIG_DIRS"
[16:33] <seb128> asac, in the xsession.d
[16:33] <asac> seb128: we use it. thats why i think i dont have to bother about /usr/share/gconf/une/mandatory/20_une-gconf-mandatory that much
[16:34] <seb128> asac, ie it appends the path, so you get both yes
[16:34] <asac> seb128: yeah. all fine. i will come back if i end up with issues
[16:34] <seb128> asac, well what us uxlaunch?
[16:34] <seb128> us -> is
[16:34] <seb128> some sort of panel you want to run?
[16:34] <asac> seb128: replacement for gdm
[16:34] <seb128> oh ok
[16:34] <asac> that doesnt have all the login stuff etc.
[16:34] <asac> just a single user that auto logs in
[16:34] <seb128> why do you want to use that?
[16:35] <seb128> I guess you want to use lightdm next cycle
[16:36] <asac> seb128: probably. we dont have requirement to select a different session in UI nor do we want to display any log-in on our images
[16:36] <asac> and we want to be lightweight ;) ... might be we end up using gdm anyway. just wanted to try
[16:37] <seb128> asac, just export GDMSESSION then in your script ;-)
[16:37] <seb128> asac, we might switch to lightdm for ubuntu next cycle
[16:38] <seb128> asac, but that's for next cycle...
[16:38] <asac> yeah
[16:38] <asac> seb128: is lightdm already in the archive?
[16:38] <asac> i am happy to feature non-production-quality software in linaro images ;)
[16:39] <seb128> hehe
[16:39] <seb128> asac, no, but robert_ancell has a ppa
[16:39] <seb128> not sure if he wanted to upload it to universe this cycle
[16:39] <seb128> I think he does
[16:40] <asac> seb128: robert is lagging on vacation right now?
[16:40] <asac> or just timezone aka bed like weaknesses?
[16:40] <seb128> he's still there for 2 or 3 weeks
[16:40] <seb128> it's 2am for him
[16:40] <asac> thanks
[16:41] <asac> right. thats a weakness ;)
[16:41] <seb128> so I guess he's sleeping
[16:41] <asac> jk
[16:41] <seb128> ;-)
[16:41] <seb128> drop him an email maybe
[16:43] <lfaraone> barry: re your message on
[16:43] <lfaraone> barry: re your message on "Place for DDs and DMs to request syncs", you're talking about sort of a web interface to submittodebian?
[16:43] <barry> lfaraone: hi!  yep
[16:44] <barry> lfaraone: i don't know how feasible that is though
[16:44] <lfaraone> barry: hm, that'd be interesting to write. would you know someone who'd want to design the UI for that?
[16:45] <lfaraone> barry: well, we already have patches.ubuntu.com. We could pull from that and have a editor which would allow you to cherrypick from the diffs, with checkboxes or something, and generate a mail which LP sends to the BTS.
[16:45] <barry> lfaraone: the launchpad folks have good designers for this kind of thing.  we should put it on lifeless's radar.  i don't know enough about submittodebian; would you be interested in submitting a lp bug report on this?
[16:46] <lfaraone> barry: sure, I'll get on that.
[16:46] <barry> lfaraone: that sounds pretty good
[16:46] <barry> lfaraone: thanks!  send me the bug # and i'll ping lifeless (who's probably asleep right now :)
[16:47]  * lfaraone 's just got a few things to finish up, but I'll get that done today.
[17:32] <kenvandine> cjwatson, can you give ~ubuntu-desktop upload rights for libgwibber (currently in universe)?
[17:42] <cjwatson> kenvandine: done
[17:42] <kenvandine> cjwatson, thx!
[20:08] <cnd> cjwatson, some of us in #ubuntu-touch are having issues with our radeon laptops
[20:09] <penguin42> cnd: I'm curious what issues?
[20:09]  * penguin42 runs a Radeon desktop
[20:09] <cnd> we've found a workaround by setting GRUB_GFXPAYLOAD_LINUX=text
[20:09] <cnd> penguin42, X never comes up
[20:09] <penguin42> ah that one
[20:09] <cnd> you might already know about it :)
[20:09] <cnd> just thought I'd mention it
[20:09]  * penguin42 tries to find the bug number
[20:10] <penguin42> cnd: Bug 605614
[20:11] <penguin42> the failures you get from it can be a bit weird - mostly X not starting, but one boot it just failed all over with a random pile of apparmor errors and crud - I guess it's just a random corruption somewhere
[20:37] <geser> cnd: I just noticed that we have gesturetest and utouch-gesturetest in the archive. It looks like the later is the correct source package name we want to keep, right? If yes, could you please request the removal of the wrong one.
[20:42] <cnd> geser, how do I do so?
[20:42] <cnd> and yes, utouch-gesturetest is the correct one
[20:43] <geser> cnd: file a bug against gesturetest requesting its removal and subscribe ubuntu-archive
[20:43] <cnd> ok, will do
[20:43] <cnd> thanks!
[21:13] <penguin42> Is there a right way to mark a bug that I think is a pretty serious regression in the current maverick alphas; I've done a nominated for maverick; it's bug 604087
[21:13] <penguin42> using the (newer) debian package works, so in one way it's an easy fix
[21:14] <jono> is anyone having problems with maverick upgrades
[21:14] <jono> I get a tonne of dependency issues
[21:14] <jono> it looks like gconf is causing many of them
[21:15] <prefrontal> i'm creating 32/64 bit packages, each of which depends on two other packages that i created. the 32 bit packages are all working, but on 64 bit I get "Depends: * which is a virtual package"
[21:15] <prefrontal> (aptitude gives that error output) it works fine on 32 bit, and i'm confused now..
[21:16] <prefrontal> you can see the output here: http://pastey.net/139656
[21:19] <prefrontal> on 32 bit `apt-cache depends emergent' shows libodeemergent and libquarter as real packages, but on 64 bit it shows them as virtual
[21:23] <geser> jono: I updated my maverick just a few minutes ago without any problems
[21:24] <geser> prefrontal: and you built the library as 64bit packages too?
[21:26] <jono> geser, think I have it fixed now, thanks!
[21:33] <cjwatson> cnd: please bring it up with the kernel team - grub is triggering it, but they're kernel issues that we need to have fixed
[21:33] <prefrontal> geser, they are built in a 64 bit virtual machine
[21:38] <cnd> cjwatson, ok, thanks
[21:39] <cjwatson> cnd: (I'm willing to back out the grub change pre-release if need be, but I want to give the kernel team as much time as possible to fix things)
[21:40] <cnd> cjwatson, whichever way is fine with me
[21:40] <cnd> I just wanted to mention it in case you hadn't seen it before
[21:40] <cjwatson> not with me, I'd much rather the kernel got fixed because then I can do shiny boot graphics
[21:40] <cjwatson> cnd: oh, I've seen it LOTS
[21:40] <cjwatson> had some long discussions with kernel folks at the sprint
[21:40] <penguin42> cjwatson: I guess it's most Radeon users?
[21:40] <cjwatson> penguin42: varies
[21:41] <cjwatson> penguin42: I can't make any quantitative assertions with any accuracy, and I suspect neither can you. ;-)
[21:41] <penguin42> cjwatson: Indeed
[21:42] <geser> prefrontal: I guess you put your debs into a repository (as apt-cache works). Did you update it with your 64bit debs?
[21:43] <prefrontal> geser, yes, i use this command, essentially the same as is used for 32 bit: cd /usr/local/ubuntu && dpkg-scanpackages dists/lucid/main/binary-amd64 /dev/null | grep -v -E 'Depends:[^a-z]$' > dists/lucid/main/binary-amd64/Packages && gzip dists/lucid/main/binary-amd64/Packages
[21:44] <prefrontal> but, i appear to have fixed the problem ;-)
[21:44] <prefrontal> somehow i passed -arch i686 to 64 bit for the last 4-5 major ubuntu releases, and my packages always worked.. switched it to -arch amd64 and it now works
[21:59] <cjwatson> penguin42: iscsitarget> I'll deal with that
[21:59] <penguin42> cjwatson: Thanks
[22:00] <cjwatson> thanks for raising it
[22:00]  * penguin42 has a nice little kvm iscsi server/client test setup - one kvm guest iscsi boots off another kvm guest running an iscsi server
[22:00]  * penguin42 should think of something crueller to do to kvm
[22:08] <cjwatson> penguin42: may take a little while, the 1.4.20.1 packaging is broken in some ways and 1.4.20.2 userspace doesn't work with 1.4.20.1 kernelspace
[22:08] <cjwatson> penguin42: plus, 1.4.20.1 has a security vulnerability open against it anyway
[22:08] <cjwatson> penguin42: so I think I'll ask the kernel team to bump to 1.4.20.2
[22:08] <penguin42> cjwatson: There's also a bit of a mess in that we seem to have an iscsi kernel module in our kenrels, yet we still have an iscsitarget-source package
[22:09] <cjwatson> penguin42: I'm OK with that, it's been the case in the past and I can imagine it being a useful get-out sometimes
[22:09] <cjwatson> penguin42: having as much as possible provided in our stock kernel packaging is kind of deliberate
[22:10] <penguin42> cjwatson: Yeh I'm ok with it being in the stock kernel, I'm not sure keeping the iscsitarget-source package is a good idea - I initially filed a bug complaining that it wouldn't build, but it's just not needed if it's in the kernel
[22:10] <cjwatson> I'd prefer not to introduce extra divergence from Debian
[22:10] <cjwatson> the less we diverge, the easier it is to merge
[22:11] <penguin42> ok fair enough
[22:14] <cjwatson> hallyn: re bug 606068, if you work on this, please be sure to do so against lp:ubuntu/iscsitarget in bzr, and note bug 604087 for why it can't be uploaded straight away
[22:19] <hallyn> cjwatson: hm, ok, thanks
[22:20] <penguin42> sorry, it was one of those days for a little flurry of bugs on the same package
[22:35] <lool> lamont: Mind creating that build record for glib2.0/sparc?
[22:37] <mathiaz> cjwatson: hi - where can I find the mkisofs command used to build the -server isos?
[22:38] <mathiaz> cjwatson: I'd like to know which options are used
[22:39] <lamont> lool: meh. ok
[22:42] <cjwatson> mathiaz: you can extract it from lp:~ubuntu-cdimage/debian-cd/ubuntu, but it's tedious enough to extract it from the code that I just have it saved.  mkisofs -r -V 'Ubuntu 10.10 i386' -o foo.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table /path/to/iso/tree
[22:43] <mathiaz> cjwatson: great - thanks
[22:43] <mathiaz> cjwatson: have the options changed over the releases?
[22:43] <mathiaz> cjwatson: or they're quiet stable (since hardy+)?
[22:43] <cjwatson> very little
[22:43] <mathiaz> cjwatson: great - thanks again
[22:43] <cjwatson> I don't think those have changed since something like dapper
[22:43] <cjwatson> or maybe even earlier
[22:44] <cjwatson> amd64 likewise; other architectures are different and less stable in places
[23:09] <Jordan_U> I'd like to make a proposal for simplifying the process of recovering grub after installing windows. What's the best way to go about this? Create a wiki page, create a blueprint, send a message to a mailing list?
[23:12] <sladen> robbiew: just for future reference, it might be better to _link_ to the IRC meeting log URL (rather than attaching 100kB of HTML)
[23:14] <robbiew> it's only 100K...geez
[23:18]  * sladen blinks
[23:20] <robbiew> :)
[23:22] <geser> robbiew: while we are at that topic: would it be possible to attach a plain text version instead of HTML?
[23:22] <sladen> geser++
[23:25] <sladen> perhaps a plain text attachment and a link to  http://irclogs.ubuntu.com/2010/08/16/%23ubuntu-meeting.html#t18:00  for the HTML would do it
[23:25] <sladen> two birds with one stone
[23:36] <jdong> fellow archive admins... bringing up sagemath again; is it possible to simply remove a package from jaunty and karmic?
[23:37] <jdong> speaking with the Debian maintainer and upstream, the package was in an utterly broken state when it was auto-synced from Sid, and upstream has been getting quite irritated with users finding this package and concluding sagemath is broken
[23:38] <jdong> I originally was thinking of doing a SRU, but the maintainer has no immediate plans to begin the undertaking of fixing the package
[23:38] <cjwatson> afraid not - it would involve rewriting the Packages files in the release pocket which we try really really really hard not to do
[23:38] <jdong> ah
[23:38] <micahg> jdong: why not upload stub packages
[23:38] <jdong> that's what I was going to ask next
[23:39] <jdong> what's the next-most-preferred way of preventing users from installing the package?
[23:39] <jdong> maybe better worded as "making upstream happier"
[23:39] <cjwatson> I'm not sure, they all suck.  stub packages would be not entirely dreadful I suppose
[23:40] <jdong> stubbed in what way, install it and nothing shows up?
[23:40] <cjwatson> empty package with suitable descriptiveness
[23:40] <jdong> yeah, I suppose that might be the next best compromise.
[23:40] <ajmitch> so people had had sagemath installed would get it replaced with this empty package
[23:40] <micahg> jdong: I just did empty packages for enigmail-locales (granted, I did a replaces on enigmail, but the emptiness is the same)
[23:41] <ajmitch> assuming that's what you wanted
[23:41] <jdong> mmm ok, I'll pass the word on to upstream and see if they want to proceed with that route
[23:42] <ajmitch> it'd be nice if there was some way in the package to tell users about what happened, maybe with the notifier or NEWS file that gets shown
[23:42] <jdong> right
[23:43] <ebroder> What about having /usr/bin/sage or whatever be a 2-line shell script that echos "This package sucks. Please go actually get sage from http://[...]"
[23:45] <jdong> haha
[23:45] <jdong> can we replace /usr/bin/emacs with "this editor sucks, please go actually get vim....
[23:45] <jdong> kidding!
[23:46] <ebroder> Only if we replace /usr/bin/vim with "this editor sucks, please go actually get nano..." :-P
[23:46]  * ajmitch lights up some torches & finds the pitchforks
[23:47] <jdong> *groans* in other news, is there a "preferred" way of making an upstart job that starts as a non-root user?
[23:48] <jdong> yes yes, insert rant about how the daemon should drop root itself
[23:48] <ebroder> I think I filed a bug about that...
[23:48] <jdong> doing a su hack is just simply ugly!
[23:48] <ebroder> bug 586942
[23:49] <jdong> cool
[23:49] <jdong> I guess for an internal-user package I'll just su it :)
[23:50] <jdong> while waiting for someone to do it correctly ;-)
[23:50] <cjwatson> use start-stop-daemon
[23:51] <cjwatson> you can just avoid using the features of s-s-d that are done better in upstart (like pidfiles)
[23:52] <jdong> oh okay
[23:52] <jdong> for some reason I thought start-stop-daemon was a sysvinit-ism
[23:54] <cjwatson> nope, it's a dpkg tool to supplement init systems with what packages actually need
[23:55] <jdong> ok gotcha, I'll use that then