=== Guest32914 is now known as ogasawara
=== ogasawara is now known as Guest89782
[08:43] <LocutusOfBorg1> hi, can I ask here for a vala-0.26 MIR? it is preventing ibus from being built
[08:43] <seb128> LocutusOfBorg1, wrong channel I guess, and we probably don't need a MIR, it's just a new version of vala which is already in main
[08:43] <LocutusOfBorg1> #1386776 :) don't know if I need to do something
[08:43] <seb128> Laney was looking at transitioning to it I think
[08:43] <LocutusOfBorg1> seb128, it is in universe 0.26
[08:43] <seb128> right
[08:43] <seb128> it doesn't mean it needs paperwork
[08:44] <seb128> just an archive admin to promote it
[08:44] <LocutusOfBorg1> ok thanks! I was wondering about something from my side
[08:44] <LocutusOfBorg1> so waiting :D
[08:45] <seb128> LocutusOfBorg1, well, we don't want a stack of versions in main, so if we decide to promote 0.26 we should port the other main packages to it
[08:45] <seb128> or we should make ibus use the current "default" version
[08:45] <seb128> that being 0.24 or whatever is default atm
[09:22] <LocutusOfBorg1> seb128, which packages needs porting? I can have a look, debian has already a 0.24-rm transition
[09:22] <Laney> I think everything just uses valac now
[09:22] <Laney> only anjuta depends on libvala-XX-dev and that has a version in proposed
[09:23] <seb128> Laney, so we just need to change the default?
[09:23] <Laney> already has happened in fact
[09:26] <Laney> (because vala-0.26 was autosynced)
[09:27] <Laney> (if you build with universe on)
[09:33] <LocutusOfBorg1> so just trying to understand, remove 0.24 and promote 0.26 is the solution? (sorry for the dumb question, trying to learn)
[09:34] <Laney> should be
[09:34]  * Laney retries anjuta
[12:44] <arges> cjwatson: infinity : hey guys, i was sru-releasing some trusty packages and I got the following email after the fact: Import problem - Spanish (es) - glib20 in Ubuntu Trusty package "glib2.0" . rmadison shows the correct package version in -updates, but I'm not sure what to do about this error.
[12:45] <arges> I can pastebin/fwd the full email if that helps
[12:49] <cjwatson> arges: I'd ignore it - it's not your problem, it's not SRU-fatal, and the uploader should have been told about it too.
[12:49] <cjwatson> It just indicates that Launchpad was unable to import some translation files.
[12:49] <arges> cjwatson: ok thanks, just making sure I'm not missing something.
[12:50] <cjwatson> It doesn't affect the actual package release.
=== charles_ is now known as charles
[15:27] <ogra_> stgraber, hey ... so i tried to improve your password check in livecd-rootfs like that http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-touch/hooks/99zz-check-uid-gid.chroot ...
[15:28] <ogra_> stgraber, so i get the complete info i need to update all the files in the next upload  .... but somehow it never gets past line 20 there ...
[15:28] <ogra_> do you see anything i dont see ?
[15:28] <ogra_> or infinity ^^
[15:38] <stgraber> not seeing anything obviously wrong with it... my first guess was a typo in a variable name which would have trigger the set -u but I'm not seeing any
[15:38] <ogra_> right
[15:38] <ogra_> but the output definitely stops after line 20 .... as if i had kept the original exit 1 ewhere the ERRCNT now is
[15:39] <ogra_> i wonder if diff somehow doesnt exit 0
[15:39] <stgraber> yep, that's it
[15:40] <stgraber> Exit status is 0 if inputs are the same, 1 if different, 2 if trouble.
[15:40] <stgraber> so the exit calls actually weren't needed until then because of -e :)
[15:40] <stgraber> so just || true the diff calls and you should be fine
[15:40] <ogra_> yeah
[15:40]  * ogra_ slaps forehead 
[15:40] <ogra_> stgraber, thanks for making me think :)
[15:41] <stgraber> well, clearly I didn't expect diff to do that either otherwise I wouldn
[15:41] <stgraber> 't have bothered with the exit 1 in there :)
[15:41] <ogra_> my brain still floats somewhere over the atlantic
[16:48] <Laney> Would someone please remove clutter-1.0 from vivid-proposed so I can upload a lower version?
[16:50] <infinity> Laney: Things depend on it.
[16:50] <Laney> Versioned?
[16:50] <infinity> Laney: Yes.
[16:51] <Laney> Let's see what
[16:51] <infinity> Possibly just mutter.
[16:51] <infinity> But why are we trying to roll it back?
[16:51] <ogra_> because it clutters vivid ?
[16:51] <ogra_> SCNR
[16:51] <Laney> Because breaks mutter
[16:52] <infinity> Laney: So, we should remove both clutter and mutter?
[16:53] <infinity> Laney: Or is the way forward not, perhaps, forward, with a mutter merge?
[16:55] <Laney> I would rather not take another transition on, even if it is small
[16:56] <infinity> Laney: It's the first week of a new series, transitions are pretty much inevitable.
[16:56] <Laney> Thanks for your feedback.
[16:57] <infinity> (base)adconrad@cthulhu:~$ reverse-depends -b src:mutter
[16:57] <infinity> Reverse-Build-Depends
[16:57] <infinity> =====================
[16:57] <infinity> * gnome-shell                   (for libmutter-dev)
[16:57] <infinity> (base)adconrad@cthulhu:~$ reverse-depends -b src:gnome-shell
[16:57] <infinity> No reverse dependencies found
[16:57] <infinity> I'd say "small" is an understatement.
[16:59] <Laney> Do you know if current gnome-shell works with new mutter?
[16:59] <Laney> And mutter requires a new gsettings-desktop-schemas.
[17:00] <infinity> New mutter is a new SONAME, so it's at least a rebuild, possibly an API break.
[17:00] <Laney> I know.
[17:00] <infinity> Given their tight integration, I'd guess they want to go lock-step.
[17:01] <infinity> Poke someone UbuntuGNOMEish about doing it and wash your hands of it? :P
[17:01] <Laney> You see where I'm coming from
[17:01] <Laney> and new gnome-shell requires new GTK+, so yeah
[17:02] <infinity> I can remove clutter/mutter from proposed, but I won't blacklist them, so the next clutter upload to sid will get synced again.
[17:02] <infinity> If that potentially tiny window is enough to get what you wanted done, then cool.
[17:02] <infinity> Or if you want to introduce an Ubuntu delta in clutter just to block syncs. :P
[17:05] <Laney> Yeah, I have an ubuntu1 version to port 1.18 to new libinput
[17:05] <infinity> Laney: Alright.  Removing away.
[17:06] <Laney> Ta
[17:06] <Laney> darkxst can unpick this at his leisure
[17:06] <infinity> Laney: What are our plans for the new GTK+?  I assume we're not going to (unintentionally) hold the UbuntuGNOME guys hostage on progress there?
[17:06] <Laney> Well, next week after we get gtk3 3.14
[17:06] <infinity> Oh, good, you answered while I asked. :)
[17:07] <Laney> It's packaged, just waiting for the mir backend and some testing & the inevitable theme fixes
[17:07] <Laney> Depending on how bad those are we could do it in-archive, probably
[17:08] <infinity> Laney: Removals done, pending publication.
[17:09] <infinity> Laney: Your upload should be allowed now, though.
[17:10] <Laney> Ore sum
[17:23]  * xnox must test ubiquity
[17:23] <xnox> Laney: where is the new gtk?
[17:24] <Laney> xnox: Umm larsu has a branch, I think lp:~larsu/gtk/gtk-3-14
[17:24] <xnox> Laney: thanks.
=== adam_g_gone is now known as adam_g
[21:07] <darkxst> Laney, infinity, mutter and gnome-shell need to be updated in lockstep
[21:12] <darkxst> and probably require a few other 3.14 bits to land first, gsettings, gtk, the new icon theme maybe gnome-desktop etc
[21:13] <darkxst> its should be fine to do the clutter transition before that though
[21:23] <infinity> darkxst: The claim was that clutter broke mutter, which is why we reverted it.
[21:23] <infinity> darkxst: So, I think it's all going to have to happen together once the new GTK is in.
[21:23] <darkxst> infinity, but I uploaded a fixed mutter
[21:24] <darkxst> but that was blocked by zenity for some reason
[21:25] <infinity> darkxst: Yeah, I reverted both clutter and mutter.  Hopefully we can get this all going again soon.
[21:25] <infinity> darkxst: PS: yell at Laney, I'm just the messenger. ;)
[21:28] <darkxst> infinity, yes will do
[21:28] <darkxst> mutter will probably need upower first as well
[21:28] <toobaz> Hello, I promise I will not insist (unless I'm told to insist). https://release.debian.org/jessie/freeze_policy.html says "For packages which missed the freeze only for reasons outside of the control of the maintainers, we might be generous". Now my stupidity, leading me to think that freeze rules applied only starting from the freeze day, is _not_ outside my control. But bug #767198 and the upload it is about (and bug #767199 too, but it is less i
[21:28] <ubot2> bug 761386 in aptdaemon (Ubuntu Oneiric) "duplicate for #767198 Unkown exception with broken encoding" [High,Fix released] https://launchpad.net/bugs/761386
[21:28] <toobaz> mportant) were done from Bamako, Mali, where I am spending two weeks for some research project, and where my Internet connection, which is inactive several hours a day and very rarely goes faster than 10 kB/s, made pbuilds (necessarily over ssh+screen) very slow and painful (and I don't know of better Internet connections in the city, although there certainly are). That was pretty much outside my control, and I frankly didn't imagine it would be so
[21:28] <ubot2> bug 764041 in gconf-cleaner (Ubuntu) "duplicate for #767199 gconf-cleaner crashed with SIGABRT in raise()" [Medium,Confirmed] https://launchpad.net/bugs/764041
[21:29] <toobaz> . That's all. Well, no... if I have only a one-time generosity attempt, another package of mine which will be probably sponsored in a matter of hours is even more important.
[21:29] <infinity> toobaz: This is #ubuntu-release, not #debian-release.
[21:29] <toobaz> Wow
[21:30] <toobaz> This was outside my control ;-)
[21:30] <toobaz> bye