[01:13] <ScottK> True.  I suppose the semantics are slightly different.
[01:14] <ScottK> But it's, as you say, not helpful to have it explicitly not a goal for the release.
[05:26] <RAOF> @pilot in
[05:26] <didrocks> good morning
[05:29] <nigelb> Morning!
[06:53] <fhd> I've asked this before, but: How do I keep the unity panel from restarting?
[06:53] <fhd> I've been told that the dbus daemon does that, but I wasn't able to figure out how to make it stop. Except stopping the dbus daemon, but I have learned that this is something I do not want to do again
[06:54] <RAOF> fhd: Why do you want to?  This might influence what I recommend.
[06:56] <fhd> RAOF: I'm working on Unity 2D, so I want to launch my own panel
[06:57] <RAOF> I'd generally drop the executable bit from the unity-panel binary you don't want running.
[06:57] <fhd> RAOF: So far, I've renamed /usr/bin/unity-2d-panel
[06:57] <fhd> RAOF: Oh, is there no nicer way?
[06:57] <RAOF> You could *probably* drop a dbus service file somewhere to override the autospawner.
[06:58] <RAOF> I'm not sure if that would disrupt the panel that you want to run, though.
[06:58] <fhd> RAOF: brb
[07:15] <broder> unity-panel is session bus, right? does d-bus look at ~/.share/dbus-1 or something?
[07:16] <RAOF> I think it might look in ~/.local/share/dbus-1, yeah.
[07:16] <RAOF> Then again, it might not.  It's evil like that.
[07:18] <broder> ugh, this code is illegible, but it does seem like it supports *something* like that
[07:20] <broder> ~/.local/share/dbus-1/services would be my best guess - you could try dropping .service files in there
[07:24]  * RAOF wonders why “apt-get install libwayland0:i386” fails because it can't find an install candidate for emacs23.
[07:26] <mvo> RAOF: try -o Debug::pkgDepCache::AutoInstall=true and -o debug::pkgProblemResolver=true
[07:30] <RAOF> Ah.  Ok.  At least part of the problem is libwayland isn't Multi-Arch: same.
[07:32] <fhd> RAOF: Okay, so it seems I better not mess with dbus, eh?
[07:32] <RAOF> Messing with dbus can lead to sorrow.  So much sorrow.
[07:33] <fhd> RAOF: Last time I seriously fiddled with Linux development, it wasn't there. I felt safer then.
[07:35] <broder> aww, i <3 dbus
[07:36] <broder> mostly because it's nice to have a typed, automatically marshalled ipc mechanism you don't have to think about
[07:51] <RAOF> *I* like dbus.  But lots of other people like dbus, too, so messing with it is likely to make all sorts of things unhappy.  Like init :).
[07:54] <fhd> I get the impression that dbus is pretty much anti unix philosophy
[07:55] <fhd> It does many things (interprocess communication, autospawning and other stuff that seriously messes up my session if I stop the daemon) and does them in an (at least partly) undocumented way
[07:57] <fhd> Not inteded as a flame, I don't really know how dbus works and what it does.
[08:05] <RAOF> Nah; it basically does only one thing: IPC, and it's generally not badly documented in my experience.
[08:05] <RAOF> But stopping it will indeed make one's session blow up.  Lots of things expect IPC to work!
[08:38] <RAOF> @pilot out
[10:54] <AnAnt> would someone sponsor: LP 812120
[10:55] <AnAnt> also LP 819692
[10:56] <AnAnt> LP 815861
[11:39]  * micahg wonders why AnAnt doesn't know the archive is frozen
[11:57] <doko> please could an archive admin promote the eglibc and gcc-4.6 binaries seen in component mismatches (don't have my keys today)
[12:07] <ogra_> didrocks, argh ! .... since when does unity-2d depend on nux ?
[12:08] <didrocks> ogra_: since this release, with unitycore dep
[12:08] <ogra_> hrm
[12:09] <ogra_> also does anyone know if unity-greeter is supposed to work at all ?
[12:09] <seb128> it's working yes
[12:09] <ogra_> seems lightdm simply ignores it
[12:10] <ogra_> i only get lots of errors in the log that it cant find the gtk greeter
[12:10] <seb128> did you set it as to use in your config?
[12:10] <ogra_> i tried that too
[12:10] <ogra_> but it ignores the config completely
[12:10] <ogra_> no matter what i set
[12:10] <seb128> do you have an old conffile?
[12:10] <seb128> the format changed in 0.9
[12:10] <ogra_> well, i touched it once
[12:11] <seb128> if you edited your config before that you might have an old format leftover
[12:11] <ogra_> hmm
[12:11] <seb128> no editing in the old keys will work
[12:11] <ogra_> well, the file is mostly commented, there are about 5-10 lines that arent
[12:12]  * ogra_ tries to remember the dpkg setting to force conffile overwriting
[12:12] <seb128> --force-confnew
[12:12] <ogra_> heh, found it that second, thanks !
[12:14]  * ogra_ diffs the file ...
[12:14] <ogra_> no differences it seems
[12:14] <ogra_> hmm, it didnt overwrite it
[12:14] <ogra_> grmbl
[12:15] <seb128> [SeatDefaults]
[12:15] <seb128> greeter-session=unity-greeter
[12:15] <seb128> something like that should work
[12:15] <ogra_> ogra@horus:~/tmp$ dpkg -x /var/cache/apt/archives/lightdm_0.9.2-0ubuntu4_armel.deb .
[12:15] <ogra_> ogra@horus:~/tmp$ ls etc/lightdm/
[12:15] <ogra_> users.conf
[12:15] <ogra_> that doesnt seem right
[12:16] <ogra_> or is lightdm.conf obsolete ?
[12:16] <seb128> it's not, but it's not required by default I think
[12:17] <ogra_> hmm, let me delete it and restart lightdm
[12:17] <seb128> so maybe copy the source one over if you need a config
[12:17] <seb128> well, lightdm default to the gtk greeter
[12:17] <ogra_> but the .conf isnt shipped at all
[12:17] <seb128> well it's not needed
[12:17] <seb128> you only need to create one if you want to tweak
[12:18] <ogra_> then i shouldnt need it either
[12:18] <seb128> ogra_, what are you trying to do?
[12:18] <seb128> it default to gtk, not unity
[12:19] <seb128> didn't you say you want to try the unity greeter?
[12:19] <ogra_> but the gtk greeter was removed with my last update
[12:19] <seb128> no
[12:19] <seb128> the binary was renamed
[12:19] <seb128> you should have lightdm-gtk-greeter
[12:19] <ogra_> i'm just trying to get a running system after an upgrade
[12:19] <seb128> the -example in the name was dropped
[12:19] <ogra_> which removed the gtk greeter and left me stuck with a black screen after boot
[12:19] <seb128> dpkg -l |  lightdm-gtk-greeter
[12:20] <seb128> dpkg -l | grep lightdm-gtk-greeter
[12:20] <ogra_> yes, i installed that manually to actually get an x session up
[12:20] <ogra_> (since startx doesnt work anymore)
[12:20] <seb128> but lightdm doesn't start still?
[12:20] <ogra_> the upgrade installed unity-greeter and removed lightdm-gtk-example-greeter
[12:21] <ogra_> it starts now that i manually installed the gtk greeter
[12:21] <seb128> hum
[12:21] <ogra_> i was just assuming that the removal means we default to the unity-greeter now
[12:21] <seb128> I think you had the unity-greeter installed manually before
[12:21] <ogra_> yes
[12:21] <ogra_> but never used it
[12:21] <seb128> no, lightdm depends on lightdm-gtk-greeter | lightdm-greeter
[12:21] <seb128> where lightdm-greeter is a virtual package provided by all greeters
[12:22] <seb128> so you didn't get lightdm-gtk-greeter because you had a greeter already installed, the unity one
[12:22] <ogra_> why wasnt the lightdm-gtk-greeter package pulled on my disk then ?
[12:22] <seb128> it's a bit of a corner case we didn't consider in upgrades
[12:22] <ogra_> ah
[12:22] <ogra_> now it starts to make sense
[12:22] <seb128> because unity-greeter that you install provide lightdm-greeter
[12:22] <seb128> installed
[12:22] <ogra_> right
[12:22] <seb128> you could have tweaked your config for it and wanted to use it instead of the gtk one
[12:23] <seb128> in which case you are allowed to uninstall the gtk one
[12:23] <ogra_> and for that i need to create a lightdm.conf ?
[12:23] <seb128> yours is a bit of a corner case due to the rename of the gtk greeter in oneiric
[12:23] <ogra_> yeah
[12:23] <seb128> I though you wanted to use the unity greeter
[12:23] <ogra_> yes
[12:24] <seb128> [SeatDefaults]
[12:24] <ogra_> so i need to create a lightdm.conf
[12:24] <seb128> greeter-session=unity
[12:24] <ogra_> yeah, with the values you gave above, i got that
[12:24] <seb128> it's "unity", not "unity-greeter"
[12:24] <seb128> before I gave you the wrong name
[12:25] <ogra_> ah, k
[12:25] <ogra_> will try it in a sec
[12:26] <seb128> in fact you might need
[12:26] <seb128> [LightDM]
[12:26] <seb128> [SeatDefaults]
[12:26] <seb128> greeter-session=unity
[12:28]  * ogra_ crosses fingers
[12:32] <ogra_> seb128, thanks, works ... !!
[12:33] <ogra_> greeter-session=unity-greeter was the right setting btw
[12:33] <seb128> ogra_, great, yw ;-)
[12:33] <seb128> ok
[12:33] <ogra_> just unity doesnt work
[12:33] <ogra_> now on to the rest of my broken desktop :/
[12:34] <ogra_> hmpf, overlay-toolbars are clearly completely broken
[12:35] <ogra_> if i hover over the scrollbar, the two arrows appear just fine, but moving the mouse to actually use them makes them disappear before i can reach them
[12:35] <ogra_> not so helpful
[12:37] <ogra_> didrocks, is there a chance that we make unity-2d (the metapackage) depend on nux too ?
[12:37] <didrocks> ogra_: I don't think so
[12:37] <ogra_> didrocks, my desktop is totally screwed because half of the elements are missing, seems the launcher was upgraded but i still have the old panel
[12:37] <ogra_> which crashes immediately
[12:38] <didrocks> ogra_: I'll try to separate nuxcore from nux
[12:38] <didrocks> ogra_: hum?
[12:38] <ogra_> well, whatever gets me a proper upgrade on arm
[12:38] <didrocks> ogra_: not sure that influence it TBH
[12:38] <ogra_> your upload of nux breaks the archive for two days
[12:38] <ogra_> for arm
[12:38] <ogra_> thats normal ...
[12:38] <ogra_> it didnt affect unity-2d until the nux dep was there
[12:39] <didrocks> ogra_: how come for two days?
[12:39] <didrocks> do you mix 2 discussions there?
[12:39] <didrocks> can we try to focus on one please:)
[12:39] <ogra_> well, until everything is build, published and all the packages are given back
[12:39] <didrocks> ogra_: so, I pushed nux yesterday evening
[12:39] <didrocks> not two days again
[12:39] <ogra_> its the same discussion
[12:39] <didrocks> I was still there around midnight
[12:39] <didrocks> and see that armel platform wasn't working
[12:40] <ogra_> right, tomorrow or later tonight unity will be installable again
[12:40] <didrocks> the build FTBFS because of the buildd being screwed
[12:40] <didrocks> a give back was done few hours before
[12:40] <didrocks> https://launchpad.net/ubuntu/+source/nux/1.0.8-0ubuntu1
[12:40] <ogra_> well, that just adds up to the time
[12:40] <didrocks> it's now build
[12:40] <ogra_> yes
[12:40] <didrocks> 14:38:38     ogra_ | your upload of nux breaks the archive for two days
[12:40] <didrocks> the fact that:
[12:41] <ogra_> my prob is that unity-2d-launcher was upgraded, but not the other buts
[12:41] <ogra_> *bits
[12:41] <didrocks> unity-2d deps on unity, which deps on nux
[12:41] <didrocks> I raised the issue with dx
[12:41] <didrocks> they ignored it
[12:41] <didrocks> sorry, please, talk to upstream about that
[12:41] <ogra_> ??
[12:41] <didrocks> I can't magically patch their software
[12:41] <didrocks> and remove that dep
[12:41] <ogra_> i just want it packaged in a way that everything gets updated at the same time
[12:42] <didrocks> ogra_: it is?
[12:42] <ogra_> so i dont sit here with a non functional desktop if you upload a new nux
[12:42] <didrocks> unity-panel deps on latest libunitycore and latest libnux
[12:42] <ogra_> it isnt, i have the new launcher here and everything else crashes
[12:42] <didrocks> what issue do you have? how did you end up with a semi working?
[12:42] <ogra_> i ran update-manager
[12:42] <seb128> seems like some upgrade should Breaks unity-2d <<
[12:43] <ogra_> thats what i mean
[12:43] <didrocks> ogra_: ah, for that upgrade, yeah…
[12:43] <ogra_> i just want all components upgraded at the same time
[12:43]  * didrocks thoughts about next one, as there is a nux (>= …, <<) and unity (>=, <<)
[12:43] <ogra_> so either everything is broken or everything works :)
[12:43] <seb128> if apt didn't block it then a breaks is required
[12:43] <didrocks> but forgot about that transition
[12:44] <seb128> ok, let's move on then, this one is done and the next one will work
[12:44] <seb128> thanks didrocks ;-)
[12:44] <ogra_> yeah
[12:44] <ogra_> thanks :)
[12:44] <didrocks> sorry for that, just thought about the normal case, with new unity-2d with the dep
[12:44] <didrocks> didn't thought about no dep -> dep
[12:44] <didrocks> I can still fix it in a future nux upload, not sure that worth it though
[12:44] <seb128> no worry, we can't think about everything ;-)
[12:45] <ogra_> nah, its fine
[12:45] <didrocks> ok, sorry ogra_ ;)
[12:45] <ogra_> why ? i run the development version, i'm supposed to expect such issues ;)
[12:46] <ogra_> no need to feel sorry
[12:46] <didrocks> ogra_: yeah, but we try to minmize them :)
[12:51] <ogra_> hmm, the unity-greeter is really slow
[12:52] <ogra_> takes about 20sec to scroll the users behind the login element if i switch
[12:52] <ogra_> (20sec to scroll from my account to the guest session or "other")
[12:52] <seb128> works fine here
[12:53] <ogra_> well, you dont use a framebuffer based xserver i would guess
[12:53] <ogra_> :)
[12:53] <seb128> indeed not
[12:53] <ogra_> which is the default on arm
[12:53] <seb128> note that the unity greeter is not default yet for a reason ;-)
[12:53] <ogra_> no accel, not even 2d
[12:53] <ogra_> yeah, i tought that, i'm just scared it will use clutter or other GL stuff
[12:56] <seb128> ogra_, that's not planned
[12:56] <seb128> ogra_, we would have to do a non-gl greeter and deal with fallback if we were to do that
[13:04] <infinity> So, uhm.  Is compiz meant to work right now? :P
[13:04] <infinity> I seem to be stuck at a console at this conference.
[13:06] <seb128> infinity, it should work yes
[13:07] <doko> should or does?
[13:07] <seb128> doko, well it's not know to be broken, i.e works for others and no bug report yet
[13:07] <infinity> seb128: Looks like I have #819739  Same trace.
[13:08] <doko> seb128, on armel?
[13:08] <seb128> oh, that's unity, not compiz ;-)
[13:08] <infinity> This is on 686.
[13:08] <seb128> doko, isn't armel using unity-2d?
[13:08] <infinity> seb128: armel can use 3d on some platforms, but usually 2d.
[13:09] <seb128> dunno about compiz on armel sorry
[13:09] <seb128> infinity, but yeah, unity seems to be broken on intel video cards today
[13:09] <seb128> dx is working on it
[13:09] <infinity> seb128: Special.  Oh well, good thing I travel with 3 laptops, and one of the three still works. ;)
[13:12] <doko> didrocks, seb128: nux is still broken on powerpc
[13:13] <didrocks> doko: yeah, I pinged a week ago dx about it
[13:15] <doko> as long as build failures are seen as noise ...
[13:23] <doko> seb128, could you promote the eglibc and gcc-4.6 binaries (http://people.canonical.com/~ubuntu-archive/component-mismatches.txt) don't have my keys today
[13:23] <seb128> doko, ok
[13:23] <doko> thanks
[13:23] <seb128> yw
[13:27] <seb128> doko, done
[14:08] <persia> infinity, Just to keep track of it, I've filed bug #819802
[14:10] <infinity> persia: THanks.
[14:11] <persia> Were there any others that were pointlessly obvious to you, except you didn't have time to look at them yet?
[14:12] <infinity> persia: Not off the top of my head, but I'll go through the list again when I get some free time.
[14:12] <persia> infinity, No special impetus: just wanted to make sure I hadn't missed something you said before.
[14:14]  * infinity nods.
[14:46] <micahg> Riddell: since you're still listed as having an archive day today, can you do a sync for me?
[14:47] <Riddell> micahg: I could if you ask nicely
[14:47] <Riddell> although I'm not doing regular archive admin for the moment
[14:47] <micahg> Riddell: could you please sync goffice 0.8.17-1 from sid?
[14:47] <micahg> Riddell: you might want to remove your name from here than: https://wiki.ubuntu.com/ArchiveAdministration#Archive_days
[14:50] <Riddell> micahg: synced
[14:50] <micahg> Riddell: thanks!
[14:52] <doko> infinity: compiz/nux crashes (on x86), but at least xubuntu does work
[14:53] <micahg> doko: BTW, do you have any specific interest in the binutils in universe (z80, avr)?  can I update them?
[15:03] <ScottK> micahg: Why?
[15:03] <ScottK> They are for archs we don't build.
[15:04] <micahg> ScottK: I thought they were cross compilers
[15:04] <micahg> they're built on arch: any
[15:04] <ScottK> Perhaps,  I thought not, but don't mind me.
[15:31] <cyphermox> mdeslaur: back about g-k-d; setcap fails with operation not permitted on the livecd
[15:31] <mdeslaur> right...so file caps aren't supported on the livecd filesystem, and ubiquity just copies all the files directly to the hard disk when installing
[15:32] <mdeslaur> cyphermox: if we want filecaps, we need to ask ev about adding something to ubiquity to set it after copying the files
[15:34] <cyphermox> mdeslaur: I can still try to apply the commits that will let it start for now, even if it's with insecure memory
[15:34] <mdeslaur> cyphermox: yes, please do...and I'll add ubiquity to the bug also
[15:34] <cyphermox> ok
[15:35] <stgraber> mdeslaur: I remember a session about it back at UDS Brussels. Basically the situation back then was that squashfs doesn't support them and tar doesn't either unless it's patched. An idea would have been to make dpkg handle that and then have some way to re-run that part of the package installation (ubiquity would do that)
[15:37] <mdeslaur> stgraber: right...until proper filecaps are implemented all over, I think ubiquity needs to manually handle this case
[15:37] <mdeslaur> ev: can I assign bug #813755 to you?
[15:39] <seb128> mdeslaur, cyphermox: why is that issue only showing up in oneiric?
[15:39] <ev> mdeslaur: why can't the package in question call setcap in the postinst?
[15:39] <mdeslaur> seb128: gnome-keyring never needed file caps before
[15:39] <mdeslaur> ev: it does
[15:39] <seb128> ev: that's what it does
[15:39] <ev> so then why does anything need to be done in ubiquity?
[15:40] <mdeslaur> ev: oh, I think my knowledge of how ubiquity works is incomplete
[15:40] <mdeslaur> ev: ubiquity will actually install the package? and not copy it over from the livecd?
[15:40] <ev> mdeslaur: ubiquity is a fancy version of cp
[15:41] <ev> it copies from the read-only copy of the squashfs
[15:41] <ev> the mounted squashfs*
[15:41] <mdeslaur> ev: squashfs doesn't handle file capabilities
[15:41] <seb128> ev: <mdeslaur> right...so file caps aren't supported on the livecd filesystem, and ubiquity just copies all the files directly to the hard disk when installing
[15:41] <ev> ah
[15:41] <ev> rubbish
[15:41] <mdeslaur> +1
[15:41] <mdeslaur> :)
[15:42] <mdeslaur> ev: ideally, we'd have a nice solution for file capabilities, but for now, it's a single file in a single package that needs it, AFAIK
[15:44] <ev> so the package in question should carry a script in /usr/lib/ubiquity/target-config to set things up properly
[15:44] <ev> see jockey for an example
[15:44] <cyphermox> oh, awesom
[15:44] <mdeslaur> oh, cool
[15:44] <cyphermox> thanks ev!
[15:45] <ev> sure thing
[15:45] <mdeslaur> thanks ev
[15:45] <ev> no problem
[15:46] <seb128> ev: do you plan an ubiquity upload?
[15:47] <seb128> ev: can you drop the libcheese-gtk-dev build-depends with the next upload? we demoted cheese to get the new version to build and ubiquity is bring a ton of clutter, mx, gstreamer, etc packages on component mismatch with that build-depends
[15:47] <ev> seb128: soon. I'm trying to land the pygi branch, but I'm still sorting out libtimezonemap (libmap extracted from indicator-datetime)
[15:48] <ev> seb128: so is there a version of cheese in main?
[15:48] <seb128> ev: no
[15:48] <seb128> ev: we can discuss bringing it back but somebody will need to open mirs for that stack of universe depends and make a case for the CD space use
[15:48] <ev> seb128: I'm confused. We had a conversation a few weeks ago where I said I needed it for the installer.
[15:49] <seb128> ev: well, we had a depwaiting version of cheese not building for weeks so we couldn't keep it like that
[15:50] <seb128> ev: somebodyhas to do the mirs and do the case for the extra CD use I'm afraid
[15:50] <ev> depwaiting on mx, presumably?
[15:50] <seb128> clutter-gst, clutter, mx
[15:50] <seb128> we will likely need clutter and clutter-gst for other things
[15:51] <seb128> (empathy, totem)
[15:51] <ev> I was just going to say :)
[15:51] <ev> so it's just mx then
[15:51] <ev> right, will sort
[15:51] <seb128> ev: another issue is that cheese use camerabin which is in one of the gstreamer universe sets
[15:51] <seb128> not sure which one now
[15:51] <ev> right
[15:51] <seb128> so we will need to sort that in some way
[15:51] <seb128> kenvandine suggested to maybe distro patch camerabin to -good as we do for others
[15:52] <ev> okay
[15:53] <seb128> ev: sorry about the demotion but the undefined depwaiting status was benefiting to nobody, I prefer to have clearly showing on component mismatch and have the issue tracked
[15:53] <seb128> ev: we will try to get the clutter stack mir filed from the desktop side
[15:54] <ev> it's okay, I entirely understand your action given the depwait
[15:58] <slug> hi, i cannot seem to be able to use ccache with pbuilder, any thoughts?
[16:00] <ScottK> slug: See debian bug 606687
[16:05] <slug> ScottK: interesting. can't i just set DEBBUILDOPTS="--prepend-path=/usr/lib/ccache" ?
[16:08] <cyphermox> ev: for the target-config script, I should use in-target or something and consider we're outside the installed system right?
[16:10] <ev> cyphermox: correct
[16:10] <cyphermox> ok, thanks
[16:15] <slug> ScottK: dpkg-buildpackage: unknown option or argument --prepend-path=/usr/lib/ccache. I guess not :)
[16:16] <slug> ScottK: thanks for the heads up!
[17:26] <EagleScreen> take a look to this, please https://bugs.launchpad.net/ubuntu/+source/user-setup/+bug/793792
[17:54] <SpamapS> slangasek: I see you have some minor changes staged for upstart.. I also have a few small changes. Alright to push them into the branch (and delay the upload until after A3 freeze?)
[19:15] <kees> archive admins around? who is publishing the maverick kernel update?
[19:47] <jono> wow, I am getting some serious screen tearing
[19:47] <jono> is this a known issue?
[19:47] <jono> I notice it particularly when using Thunderbird
[19:47] <jono> this is in 11.10
[20:56] <slangasek> SpamapS: yes, those changes follow the rule "suitable for the archive but not worth an upload on their own"
[20:57] <SpamapS> slangasek: ok, I pushed them to the bzr tree after concluding just that. :)
[20:57] <SpamapS> slangasek: of course, now we've gotten the branch out of sync ... as jhunt uploaded a fix .. but I will fix that w/ import-dsc
[21:00] <slangasek> SpamapS: oh sigh :)
[21:03] <SpamapS> AttributeError: 'DistributionBranch' object has no attribute 'pristine_tar_source'
[21:03] <SpamapS> double sigh
[22:06] <RAOF> SpamapS: Re: w-scan in the natty-proposed unapproved queue - when there's a second upload to -proposed superceding an existing upload in -proposed we want the changes file to contain the changelog for both, right? So, in this case, both -1ubuntu0.1 and -1ubuntu0.2?
[22:15] <TheMuso> RAOF: I think thats what has usually happened, but don't quote me on that. I have seen proposed uploads with more than one changelog entry.
[22:16] <RAOF> TheMuso: Yeah.  I know it would be correct to have both, but I don't know if our tools will break if we *don't* have both. :)
[22:17] <TheMuso> Right.
[22:51] <TheMuso> Can anybody tell me where I can find the patch pilot calendar? I suspect I am on this week at some point, but don't know for sure. Daniel usually sends out invites, but since he is away, and I didn't receive one, I don't know where I stand for this month.
[22:53] <ajmitch> TheMuso: https://www.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok@group.calendar.google.com&ctz=Europe/Berlin&gsessionid=OK
[22:53] <ajmitch> linked from the PatchPilot page
[22:55] <TheMuso> oh right, thanks
[22:58] <Daviey> TheMuso: You'll have a fun Friday, with everyone pushing their stuff post freeze :)
[22:59] <TheMuso> Daviey: Not exactly, bare in mind that my Friday is before most others, i.e since I am in Sydney, I will be dealing with the end of Thursday for those in Europe/US.
[23:00] <Daviey> TheMuso: bah.
[23:01] <ajmitch> with feature freeze next week, I guess there'll be a bit to get in
[23:01] <Daviey> ajmitch: please don't scare me, i know how much we still need to do :)
[23:02] <ajmitch> Daviey: I won't count down the seconds for you then :)
[23:02] <Daviey> ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
[23:04] <micahg> about 160 requests for upgrades still along with the unmerged stuff (with some overlap)
[23:05] <Daviey> The AA queue will unleash a world of changes :/
[23:06] <Daviey> ugh, i've had a sync request waiting since 2011-07-20.
[23:06] <micahg> there's that too :) I hope we get normal sync runs after alpha3 again
[23:08] <ajmitch> we just have to find a friendly AA
[23:10] <SpamapS> RAOF: generally yes, though I prefer to avoid two uploads as it binds the two SRU's together
[23:11] <micahg> if it's in unapproved, the version can be reused
[23:11] <RAOF> SpamapS: In this case the second SRU is “fix the build”, so there's a certain amount of unavoidable tying :)
[23:12] <SpamapS> micahg: there's one already in proposed, and this is a new one.
[23:12] <micahg> ah
[23:12] <SpamapS> For the record, I think its silly that our tools don't do this automatically every time. :-P
[23:12] <SpamapS> I know that some do
[23:12] <SpamapS> but not all
[23:12] <micahg> -v?  supposedly bzr-builddeb has something to do it now
[23:13] <SpamapS> merge-package does, I don't know about bzr bd.
[23:13] <Daviey> micahg: ah, interesting.. i can throw my crappy shell script away then!
[23:14] <RAOF> It'd be pretty nice to have a wrapper that checks what the current version in the archive is and adds an appropriate -v, yeah.
[23:15] <micahg> idk, jelmer was using it
[23:16] <Daviey> RAOF: Ready to cry? http://pb.daviey.com/OR61/
[23:17] <RAOF> Daviey: Looks pretty sane to me.  You need to special case uploads to -proposed, though :)
[23:17] <Daviey> RAOF: patches^D rewrite welcome
[23:17] <RAOF> Well, and the -sa bit is moderately wrong :)
[23:18] <SpamapS> Hrm.. upstart is missing upstream-1.3
[23:25] <SpamapS> I wonder if we should back out the changes and re-run the import-dsc's to get the upstream versions sorted
[23:26] <SpamapS> otherwise I think the package import will be broken forever.
[23:31] <micahg> SpamapS: maybe talk to the importer folks
[23:36] <SpamapS> Yeah I need to understand how it works
[23:41] <Daviey> SpamapS: Unless it's borked, if a UDD commit differs from what is in the archive.. it should pop it off, and import the package from the archive.
[23:41] <Daviey> so i imagine it will do the right thing.
[23:42] <Daviey> But i tend to have too much confidence in stuff working :)
[23:42] <SpamapS> Daviey: hrm