[00:43] -queuebot:#ubuntu-release- New binary: rustc [arm64] (cosmic-proposed/universe) [1.25.0+dfsg1+llvm-0ubuntu3] (no packageset)
[00:49] -queuebot:#ubuntu-release- New: accepted python-os-service-types [amd64] (cosmic-proposed) [1.2.0-0ubuntu1]
[00:49] -queuebot:#ubuntu-release- New: accepted rustc [arm64] (cosmic-proposed) [1.25.0+dfsg1+llvm-0ubuntu3]
[00:49] -queuebot:#ubuntu-release- New: accepted rustc [i386] (cosmic-proposed) [1.25.0+dfsg1+llvm-0ubuntu3]
[00:49] -queuebot:#ubuntu-release- New: accepted rustc [s390x] (cosmic-proposed) [1.25.0+dfsg1+llvm-0ubuntu3]
[00:50] -queuebot:#ubuntu-release- New: accepted rustc [amd64] (cosmic-proposed) [1.25.0+dfsg1+llvm-0ubuntu3]
[00:50] -queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (cosmic-proposed) [1.25.0+dfsg1+llvm-0ubuntu3]
[00:50] -queuebot:#ubuntu-release- New: accepted rustc [armhf] (cosmic-proposed) [1.25.0+dfsg1+llvm-0ubuntu3]
[01:42] -queuebot:#ubuntu-release- New binary: python-zunclient [amd64] (cosmic-proposed/universe) [1.3.0-0ubuntu1] (no packageset)
[01:56] -queuebot:#ubuntu-release- Unapproved: ssh-import-id (bionic-proposed/main) [5.7-0ubuntu1 => 5.7-0ubuntu1.1] (ubuntu-desktop, ubuntu-server)
[02:11] -queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20180129+dfsg1-0ubuntu1~14.04.0 => 20180510+dfsg1-0ubuntu3~14.04.0] (ubuntu-cloud)
[03:19] <tsimonq2> cjwatson, slangasek: So, I want to make a change (well, propose one) to debian-cd for some adjustments in Lubuntu's image. However, I don't see tools/boot/cosmic to be able to edit... can I get a hand please? (Probably needs copying over or something.)
[03:22] <tsimonq2> Namely, I want to add Lubuntu to the conditionals on lines 422 and 453.
[03:22] <tsimonq2> (of "bionic/boot-amd64")
[03:25] <tsimonq2> ((soon to be "cosmic/boot-amd64"))
[03:42] <slangasek> tsimonq2: pushed the prod branch to the public branch now
[03:42] <tsimonq2> slangasek: Thanks!
[03:48] <tsimonq2> slangasek: https://code.launchpad.net/~tsimonq2/debian-cd/lubuntu-cosmic-changes/+merge/345717
[03:49] <tsimonq2> slangasek: It's unclear to me if doing an MP that way is the right workflow, but feel free to grab my diff nonetheless.
[03:49] <tsimonq2> slangasek: (Assuming it looks sane to you, ofc.)
[03:50] <tsimonq2> Uhh, that looks messy.
[03:50] <tsimonq2> This: https://bazaar.launchpad.net/~tsimonq2/debian-cd/lubuntu-cosmic-changes/revision/1993
[03:51] <tsimonq2> For future ref, what's the Right Thing here?
[03:59] <krytarik> tsimonq2: Wrong MP target, should be "debian-cd/ubuntu" instead.
[04:14] -queuebot:#ubuntu-release- Unapproved: ssh-import-id (bionic-proposed/main) [5.7-0ubuntu1 => 5.7-0ubuntu1.1] (ubuntu-desktop, ubuntu-server)
[06:22] <slangasek> cjwatson: is it time to unblacklist ghc/haskell?
[06:35] <ginggs> slangasek: thanks, I'll look at seqan2
[06:58]  * sil2100 is reviewing the KDE stack for bionic now
[07:02] <wxl> sil2100: any chance of waiving the minimum aging on https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1764399 ?
[07:15] <sil2100> wxl: looking
[07:15] <wxl> sil2100: thx
[07:17] <sil2100> wxl: what about cosmic? Has the dependency been added there already?
[07:17] <wxl> sil2100: yes, cosmic was already resolved. we did some drastic changes to our cosmic seed as a result of switching from lxde to lxqt and managed to resolve that in the process.
[07:18] <sil2100> Ok
[07:21] <sil2100> wxl: I don't see any direct dependency for launchpadlib there, I assume it's pulled in through dependencies though? Anyway, just make sure the same issue doesn't appear in cosmic - I'll release the bionic SRU now
[07:23] <wxl> sil2100: yeah, if you check the manifest it's on there. one of the "drastic changes" is also not excluding recommends, so that kind of helps. thank you!
[08:10] -queuebot:#ubuntu-release- Unapproved: accepted bluedevil [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[08:10] <sil2100> acheronuk[m]: hey! You around?
[08:13] <sil2100> acheronuk[m]: I'm reviewing the KDE bionic SRUs now - there's a lot of packages that have only a version bump and/or only translation fixes in them
[08:13] <sil2100> acheronuk[m]: since those are basically governed by your team - do you want those to all go in with the update?
[08:15] <sil2100> acheronuk[m]: I'm asking since there's no real blocker for getting those in and I guess that's what we did for zesty (and all is super fine with that), but accepting even those no-change uploads does always generate an update for the user in the end
[08:16] <sil2100> acheronuk[m]: not a big deal, but users will have to download packages and update even if the actual contents did not change
[08:16] <sil2100> acheronuk[m]: so question: is that something you're concerned about as a flavour or not?
[08:17] <acheronuk> sil2100: I would prefer users to see Plasma as a whole update, rather than just some packages and not others. especially where they have had version updates from us in the past via our PPAs, that is what they expect to see, and what tends to happen elsewhere
[08:17] <sil2100> acheronuk: that's fine with me then
[08:18] <sil2100> Thanks!
[08:18] <acheronuk> thank you!
[08:18] <seb128> acheronuk, do you get each package to go through testing/SRU verification?
[08:18] <seb128> because even no change rebuild can contain issues, sometime toolchain or something else changed since the previous build
[08:18] <seb128> it seems tedious to test a stack of packages just to bump a changelog :/
[08:19] -queuebot:#ubuntu-release- Unapproved: accepted drkonqi [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
[08:19] <sil2100> Yeah, every package needs to be tested, I guess that's one of the reason why verification of KDE updates always takes so long
[08:19] <sil2100> I remember the zesty one hanging around for quite a while
[08:20] <acheronuk> hopefully will be quicker this time
[08:22] <sil2100> acheronuk: ok, so the decision to accept them all still stands, right? Just making sure ;)
[08:23] <seb128> (seems a waste of mirrors/user data/testing resources from here, just to bump a changelog version :/)
[08:24] <acheronuk> sil2100: yeah. dependencies (build and otherwise) have been set so we could abandon the not strictly bug fix updates should that become the better option
[08:28] <sil2100> acheronuk: so maybe let's do it like this for now, some middle grounds - I'll be accepting those that have only translation updates but not those that just bump the changelog, we can decide later how many of those are there and if it really makes sense to have those
[08:28] <sil2100> Translation updates are anyway something we'd like before .1
[08:29] -queuebot:#ubuntu-release- Unapproved: accepted breeze [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[08:30] <acheronuk> sil2100: sounds reasonable.
[08:31] -queuebot:#ubuntu-release- Unapproved: accepted kactivitymanagerd [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
[08:32] -queuebot:#ubuntu-release- Unapproved: accepted kde-cli-tools [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[08:35] -queuebot:#ubuntu-release- Unapproved: accepted kde-gtk-config [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[08:39] <cjwatson> slangasek: I blacklisted ghc/haskell on request; LocutusOfBorg, can you comment on whether it can be unblacklisted now?  (presumably it'd want to be "controlled sync of at least the first few layers and then unblacklist", to avoid unnecessary rebuilds)
[08:40] -queuebot:#ubuntu-release- Unapproved: accepted kdeplasma-addons [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[08:41] -queuebot:#ubuntu-release- Unapproved: accepted kgamma5 [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[08:42] -queuebot:#ubuntu-release- Unapproved: accepted khotkeys [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[08:44] -queuebot:#ubuntu-release- Unapproved: accepted kinfocenter [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[08:45] -queuebot:#ubuntu-release- Unapproved: accepted kmenuedit [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[08:46] -queuebot:#ubuntu-release- Unapproved: accepted kscreen [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[08:47] -queuebot:#ubuntu-release- Unapproved: accepted kscreenlocker [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
[08:48] -queuebot:#ubuntu-release- Unapproved: accepted ksysguard [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[08:51] -queuebot:#ubuntu-release- Unapproved: accepted kwin [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[09:04] <LocutusOfBorg> cjwatson, I asked if I could manually sync ghc few days ago
[09:04] <Laney> juliank / sil2100: either of you got any spare time to look into bos01/s390x?
[09:04] <LocutusOfBorg> so, I agree with you, please let me manually do this stuff
[09:04] <Laney> things seem to be dying in weird ways
[09:05] <juliank> they are?
[09:05] <Laney> ubuntu@juju-prod-ues-proposed-migration-machine-11:~$ tail -1 /tmp/autopkgtest-work.kevt6uoh/out/log
[09:05] <LocutusOfBorg> [10:11:40] <LocutusOfBorg> Release Team, the Debian haskell transition should be mostly over, and I would like to drop llvm 3.7 from our world...
[09:05] <LocutusOfBorg> [10:12:09] <LocutusOfBorg> can you please tell me when it is convenient to do my manual syncs? (please don't whitelist it right now, I prefer to sync in the right order to avoid useless rebuilds and infra time)
[09:05] <Laney> tar: ./debian/.debhelper/libkf5kiofilewidgets5/dbgsym-root/usr/lib/debug/.build-id/f1/e44922cfe0fa00af06436c65a97c5403912ac0.debug: Wrote only 2560 of 10240 bytes
[09:05] <Laney> or just hanging or whatever
[09:05] <LocutusOfBorg> this was my request, so let me sync it *now*
[09:05] <LocutusOfBorg> (you will need to process some haskell new queue, new packages might be around 10~15
[09:05] <cjwatson> LocutusOfBorg: this sounds like consensus that you can go ahead, to me :)
[09:06] <LocutusOfBorg> syncpackage: Error: Source package ghc is blacklisted.
[09:06] <LocutusOfBorg> can you pleeeeeeeeeeeeeeease :) ?
[09:06] <cjwatson> that's what copy-package is for
[09:06] <LocutusOfBorg> ack
[09:06] <LocutusOfBorg> sounds good to me
[09:06] <sil2100> Laney: I could take a look after my sru shift
[09:07] <sil2100> Laney: ah, it's the thing Steve mentioned, right?
[09:07] <cjwatson> just remember that you need to explicitly copy to cosmic-proposed
[09:07] <Laney> dunno
[09:07] <cjwatson> or you could locally hack the blacklist check out of syncpackage if you prefer
[09:07] <LocutusOfBorg> 	ghc 8.2.2-3 in sid
[09:07] <LocutusOfBorg> Candidate copy target: https://api.launchpad.net/devel/ubuntu/+archive/primary
[09:07] <LocutusOfBorg> Copy [y|N]? y
[09:07] <LocutusOfBorg> 1 copy requested.
[09:07] <LocutusOfBorg> nah, done! thanks!
[09:08] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/ghc/8.2.2-3
[09:08] <LocutusOfBorg> it is there...
[09:08]  * LocutusOfBorg hides in a cave
[09:08] <Laney> juliank / sil2100: filed https://trello.com/c/WnlpdF4t/16-investigate-bos01-s390x-instances-not-working-properly
[09:08]  * Laney goes back to meson.build :-)
[09:09] <seb128> looks like the gnome-software bionic SRU was missing the SRU info on one of the bugs and that has been fixed now, should be good to re-review/let in
[09:09] <juliank> odd
[09:09] -queuebot:#ubuntu-release- Unapproved: accepted libksysguard [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[09:11] -queuebot:#ubuntu-release- Unapproved: accepted milou [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[09:12] <sil2100> seb128: thanks! I'll look at it once I go through those KDE packages
[09:13] -queuebot:#ubuntu-release- Unapproved: accepted oxygen [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[09:14] <juliank> Laney, sil2100 I'm rerunning the kio test in debug, and I can notice that the open takes about 20 seconds, but it does not hang indefinitely.
[09:15] <juliank> Let's wait for it to finish
[09:15] <Laney> look in the journal
[09:15] <Laney> you can see tons of bos01-s390x-* dying
[09:15] <juliank> yes
[09:15] <juliank> Well no, i don't see them dying
[09:16] <juliank> but i might be missing the lines where they do
[09:16] <sil2100> acheronuk: looking at plasma-desktop, a bit curious why the build-dependency to breeze-dev has been bumped, since actually the breeze package had only translation updates
[09:16] <sil2100> acheronuk: do you know?
[09:16] <juliank> oh I see, there are no error messages inside the testbed, they just stop
[09:17] <Laney> you don't always get the end of the log for some reason
[09:19] <juliank> Should we systemctl stop<EMAIL_ADDRESS>them for now?
[09:20] <sil2100> acheronuk: hope nothing went missing from the breeze upload in that case? Since build-depends are usually bumped if we're actually depending on something from the newer version
[09:21] <Laney> juliank: can do, & disable or the script will bring them back
[09:21] <acheronuk> sil2100: because the cmake in plasma-desktop looks for an internally versioned breeze build dep of the same version
[09:21] <Laney> if it ends up being disabled for a while, I'd document that cowboy in the local config-changed copy on the node
[09:22] <seb128> thx Lucasz :)
[09:22] <acheronuk> sil2100: if it doesn't find it, it doesn't set the breeze window deco as the default for the build
[09:22] <sil2100> acheronuk: ah, good to know!
[09:24] -queuebot:#ubuntu-release- Unapproved: accepted plasma-desktop [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[09:24] <acheronuk> sil2100: the build deps I did bump were as a result of seeing what went missing in my staging builds, and correcting those
[09:25] <juliank> Laney: done that. we also might want to try just starting less workers and see if that helps things, maybe it's overloaded somehow
[09:29] <Laney> could be, that short write looks suspicious
[09:47] -queuebot:#ubuntu-release- Unapproved: accepted plasma-discover [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
[09:48] -queuebot:#ubuntu-release- Unapproved: accepted plasma-integration [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
[09:49] -queuebot:#ubuntu-release- Unapproved: accepted plasma-nm [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[09:50] -queuebot:#ubuntu-release- Unapproved: accepted plasma-pa [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[09:52] -queuebot:#ubuntu-release- Unapproved: accepted plasma-sdk [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[09:53] -queuebot:#ubuntu-release- Unapproved: accepted plasma-vault [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
[09:56] -queuebot:#ubuntu-release- Unapproved: accepted plasma-workspace [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[09:59] -queuebot:#ubuntu-release- Unapproved: accepted polkit-kde-agent-1 [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[10:01] -queuebot:#ubuntu-release- Unapproved: accepted powerdevil [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[10:03] -queuebot:#ubuntu-release- Unapproved: accepted sddm-kcm [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[10:07] -queuebot:#ubuntu-release- Unapproved: accepted systemsettings [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[10:08] -queuebot:#ubuntu-release- Unapproved: accepted user-manager [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[10:10] <sil2100> acheronuk: ok, I guess I approved all that mattered - could you take a look at the list of packages that have been left unapproved and see if you want those approved or rejected?
[10:10] <sil2100> acheronuk: there's like around 11 of those
[10:14] <acheronuk> sil2100: looks sensible to me. thanks
[10:15] <sil2100> acheronuk: I'm leaving the decision up to you - we're trying not to rebuild stuff if not needed as seb mentioned, since it's counter-productive - but I think we didn't care about that last time
[10:19] <acheronuk> sil2100: I think I'm happy with this middle ground at the moment. I just 'aimed high' preparing them all, but practicalities here say that was a bit much
[10:20] -queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (bionic-proposed) [3.28.1-0ubuntu<IP_ADDRESS>]
[10:20] <sil2100> It's better this way than missing something, I'll reject them now - we can always bring them back from the rejected queue easily
[10:21] <acheronuk> ok
[10:26] -queuebot:#ubuntu-release- Unapproved: rejected breeze-grub [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
[10:26] -queuebot:#ubuntu-release- Unapproved: rejected breeze-plymouth [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
[10:26] -queuebot:#ubuntu-release- Unapproved: rejected ksshaskpass [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[10:26] -queuebot:#ubuntu-release- Unapproved: rejected kwrited [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[10:26] -queuebot:#ubuntu-release- Unapproved: rejected plasma-workspace-wallpapers [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[10:26] -queuebot:#ubuntu-release- Unapproved: rejected xdg-desktop-portal-kde [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
[10:26] -queuebot:#ubuntu-release- Unapproved: rejected breeze-gtk [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
[10:26] -queuebot:#ubuntu-release- Unapproved: rejected kwayland-integration [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[10:26] -queuebot:#ubuntu-release- Unapproved: rejected plymouth-kcm [source] (bionic-proposed) [5.12.5-0ubuntu0.1]
[10:26] -queuebot:#ubuntu-release- Unapproved: rejected kdecoration [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[10:26] -queuebot:#ubuntu-release- Unapproved: rejected libkscreen [source] (bionic-proposed) [4:5.12.5-0ubuntu0.1]
[10:32] <sil2100> apw: you shephearding those snapd updates, yes? Like, the ones in -proposed as well?
[10:34] <apw> sil2100, yes ... i have a .9 coming to replace the .5s because the testing is broken, but the testing is sick for that too
[10:35] <sil2100> apw: ouch
[10:42] <apw> sil2100, it is becoming "fun" that is for sure
[10:53] -queuebot:#ubuntu-release- Unapproved: accepted python-pyvmomi [source] (xenial-proposed) [<IP_ADDRESS>7.5-0ubuntu1~16.04.1]
[11:05] -queuebot:#ubuntu-release- Unapproved: gdm3 (bionic-proposed/main) [3.28.0-0ubuntu1 => 3.28.0-0ubuntu1.1] (ubuntu-desktop)
[11:32] <slashd> o/ sil2100, could you please approve the Trusty upload for 'initramfs-tools' ?
[11:32] <slashd> For LP: #1771557 ^
[12:01] <juliank> rbasak: In bug 1771345, the script did not add the verification-needed-* tags when you accepted the packages, odd. Adding -done-* tags now
[12:16] <ahasenack> hi, could an archive admin please reject my apache2 upload that is in cosmic-proposed?
[12:18] <acheronuk> sil2100: typical. sigh. https://community.kde.org/Plasma/5.12_Errata
[12:18] <acheronuk> "Plasma Discover in 5.12.5 was updated on 17 May 2018 with a <IP_ADDRESS> version. <IP_ADDRESS> includes a fix for https://bugs.kde.org/show_bug.cgi?id=394048"
[12:32] <acheronuk> sil2100: do you want to replace 5.12.5 with that as if it didn't happen in updates?
[12:34] <acheronuk> I have an additional changelog item on the current upload which would need to be appended to the new one if done like that
[15:04] <sil2100> bdmurray: hey! If anything I'm still doing some SRU work for the nearest 1.5 hour, working on gce-compute-image-packages now
[15:07] <bdmurray> sil2100: okay
[15:08] <acheronuk> how do we persuade britney not to see removing autotests as a regression? e.g. if we want to follow debian and remove some that are too broken
[15:20] <slangasek> acheronuk: force-badtest hints
[15:22] <acheronuk> slangasek: thanks.will they need to keep being updated, or would britney 'forget' after a few times
[15:23] <Laney> no, this is supposed to be handled
[15:23] <Laney> which package?
[15:24] <acheronuk> Laney: kdepim-runtime is one: https://salsa.debian.org/qt-kde-team/kde/kdepim-runtime/commit/6bfa589c1d0982048b3588e184416e3b2f2101e1
[15:24] <acheronuk> there are some others I saw in debian changes emails
[15:25] <acheronuk> some just removed. some set to run at build time instead
[15:25] <Laney> acheronuk: Can you point me to a specific upload that ran its tests after dropping debian/tests/*?
[15:27] -queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (bionic-proposed) [20180510+dfsg1-0ubuntu2~18.04.0]
[15:28] <acheronuk> Laney: not seen any recently. if britney has been changed so that no longer flags as a regression, then that will help me when I merge these debian changes properly :)
[15:28] <Laney> I think we did that quite a while ago
[15:29] <acheronuk> I must have missed the memo
[15:29] <Laney> commit 41d51369f54d695153fcd71043b511883392a5bf (dropped-tests)
[15:29] <Laney> Author: Iain Lane<EMAIL_ADDRESS>[15:29] <Laney> Date:   Wed Jan 11 10:43:30 2017 +0000
[15:29] <Laney>     autopkgtest: Accept packages which have dropped their tests in unstable
[15:29] <acheronuk> oooh
[15:29] <Laney> I mean, it could be broken, that's why I ask for a link
[15:30] <Laney> So let me know after you've uploaded one if it doesn't work
[15:30] <acheronuk> well, I don't have one. I was just assuming the old behaviour would stand. if it does not, then great. thank you
[15:31] <sil2100> rbalint: regarding the gce packages - I see you pushed ubuntu3 to cosmic that was removing the Breaks/Replaces of irqbalance to cosmic, does that also apply for the other series like bionic?
[15:37] <rbalint> sil2100, yes, none of them should break/replace
[15:38] <sil2100> rbalint: hm, ok, so I guess we'll need new uploads for b/a/x/t?
[15:38] <sil2100> rbalint: I accepted the bionic one already sadly so it'll have to be overriden
[15:39] <sil2100> rbalint: since I saw bionic and artful at least break/replace still
[15:39] <rbalint> sil2100, hm
[15:39] <rbalint> sil2100, let me check
[15:40] <sil2100> rbalint: they're all based on ubuntu2 and there was no added changes for that, at least per the debdiffs I see
[15:47] -queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (artful-proposed/universe) [20180129+dfsg1-0ubuntu1~17.10.0 => 20180510+dfsg1-0ubuntu3~17.10.0] (ubuntu-cloud)
[15:47] -queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20180129+dfsg1-0ubuntu1~16.04.0 => 20180510+dfsg1-0ubuntu3~16.04.0] (ubuntu-cloud)
[15:47] -queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20180129+dfsg1-0ubuntu1~14.04.0 => 20180510+dfsg1-0ubuntu3~14.04.0] (ubuntu-cloud)
[15:48] -queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (bionic-proposed/universe) [20180510+dfsg1-0ubuntu2~18.04.0 => 20180510+dfsg1-0ubuntu3~18.04.0] (ubuntu-cloud)
[15:48] <sil2100> rbalint: thanks! Rejecting the old ones and handling those
[15:50] -queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (artful-proposed) [20180510+dfsg1-0ubuntu2~17.10.0]
[15:51] -queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (trusty-proposed) [20180510+dfsg1-0ubuntu3~14.04.0]
[15:51] -queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (xenial-proposed) [20180510+dfsg1-0ubuntu2~16.04.0]
[15:53] -queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (bionic-proposed) [20180510+dfsg1-0ubuntu3~18.04.0]
[15:58] -queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (artful-proposed) [20180510+dfsg1-0ubuntu3~17.10.0]
[16:00] -queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (xenial-proposed) [20180510+dfsg1-0ubuntu3~16.04.0]
[16:04] -queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20180510+dfsg1-0ubuntu3~14.04.0]
[16:13] <rbalint> sil2100, thanks, i had the earlier ones prepared for upload then during testing I decided to update them but accidentally uploaded the earlier ones at late night
[16:23] <sil2100> yw!
[16:32] -queuebot:#ubuntu-release- New binary: uwsgi [s390x] (cosmic-proposed/universe) [2.0.15-11] (no packageset)
[16:33] -queuebot:#ubuntu-release- New binary: uwsgi [ppc64el] (cosmic-proposed/universe) [2.0.15-11] (no packageset)
[16:54] <slangasek> seb128: hi, network-manager-gnome now depends on ayatana-appindicator instead of libappindicator.  ~dx-packages is defunct; should desktop own ayatana-appindicator in main?  This shouldn't need an MIR since it's a straight swap of the same code under a new source package name
[16:55] <slangasek> curious how autopkgtest sees instances that are stalled for 12h+, but the moment the cronjob goes to delete them, they've disappeared
[16:59] <jbicha> slangasek: seb128: (same for libindicator > libayatana-indicator)
[17:00] <tsimonq2> slangasek: bug 1770146
[17:01] <slangasek> "appindicator is dead, we should move it to universe" yeah that's not how universe works ;)
[17:02] <slangasek> as I said, we don't need an MIR, we need a team subscriber
[17:03] <tsimonq2> ¯\_(ツ)_/¯
[17:03] <tsimonq2> Just thought I'd link it.
[17:04] -queuebot:#ubuntu-release- New binary: uwsgi [amd64] (cosmic-proposed/universe) [2.0.15-11] (no packageset)
[17:05] -queuebot:#ubuntu-release- New binary: uwsgi [i386] (cosmic-proposed/universe) [2.0.15-11] (no packageset)
[17:12] -queuebot:#ubuntu-release- New binary: uwsgi [arm64] (cosmic-proposed/universe) [2.0.15-11] (no packageset)
[17:13] -queuebot:#ubuntu-release- New binary: uwsgi [armhf] (cosmic-proposed/universe) [2.0.15-11] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: libsfml [s390x] (cosmic-proposed/universe) [2.5.0+dfsg-2] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: libsfml [ppc64el] (cosmic-proposed/universe) [2.5.0+dfsg-2] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: autopep8 [amd64] (cosmic-proposed/universe) [1.3.5-2] (kubuntu)
[17:20] -queuebot:#ubuntu-release- New: accepted uwsgi [amd64] (cosmic-proposed) [2.0.15-11]
[17:20] -queuebot:#ubuntu-release- New: accepted uwsgi [armhf] (cosmic-proposed) [2.0.15-11]
[17:20] -queuebot:#ubuntu-release- New: accepted uwsgi [ppc64el] (cosmic-proposed) [2.0.15-11]
[17:20] -queuebot:#ubuntu-release- New: accepted uwsgi [arm64] (cosmic-proposed) [2.0.15-11]
[17:20] -queuebot:#ubuntu-release- New: accepted uwsgi [s390x] (cosmic-proposed) [2.0.15-11]
[17:20] -queuebot:#ubuntu-release- New: accepted uwsgi [i386] (cosmic-proposed) [2.0.15-11]
[17:20] -queuebot:#ubuntu-release- New binary: libsfml [amd64] (cosmic-proposed/universe) [2.5.0+dfsg-2] (no packageset)
[17:22] -queuebot:#ubuntu-release- New binary: libsfml [i386] (cosmic-proposed/universe) [2.5.0+dfsg-2] (no packageset)
[17:26] -queuebot:#ubuntu-release- New binary: python-transliterate [amd64] (cosmic-proposed/none) [1.10.1-1] (no packageset)
[17:26] -queuebot:#ubuntu-release- New binary: python-sexpdata [amd64] (cosmic-proposed/none) [0.0.3-1] (no packageset)
[17:32] -queuebot:#ubuntu-release- New binary: libsfml [arm64] (cosmic-proposed/universe) [2.5.0+dfsg-2] (no packageset)
[17:32] -queuebot:#ubuntu-release- New binary: libsfml [armhf] (cosmic-proposed/universe) [2.5.0+dfsg-2] (no packageset)
[17:45] -queuebot:#ubuntu-release- New binary: libfixposix [s390x] (cosmic-proposed/universe) [1:0.4.3-1] (no packageset)
[17:47] -queuebot:#ubuntu-release- New binary: libfixposix [ppc64el] (cosmic-proposed/universe) [1:0.4.3-1] (no packageset)
[17:47] -queuebot:#ubuntu-release- New binary: libfixposix [amd64] (cosmic-proposed/universe) [1:0.4.3-1] (no packageset)
[17:47] -queuebot:#ubuntu-release- New binary: libfixposix [i386] (cosmic-proposed/universe) [1:0.4.3-1] (no packageset)
[17:49] -queuebot:#ubuntu-release- New binary: libfixposix [arm64] (cosmic-proposed/universe) [1:0.4.3-1] (no packageset)
[17:49] -queuebot:#ubuntu-release- New binary: libfixposix [armhf] (cosmic-proposed/universe) [1:0.4.3-1] (no packageset)
[18:10] -queuebot:#ubuntu-release- New: accepted autopep8 [amd64] (cosmic-proposed) [1.3.5-2]
[18:10] -queuebot:#ubuntu-release- New: accepted libfixposix [arm64] (cosmic-proposed) [1:0.4.3-1]
[18:10] -queuebot:#ubuntu-release- New: accepted libfixposix [i386] (cosmic-proposed) [1:0.4.3-1]
[18:10] -queuebot:#ubuntu-release- New: accepted libfixposix [s390x] (cosmic-proposed) [1:0.4.3-1]
[18:10] -queuebot:#ubuntu-release- New: accepted libsfml [arm64] (cosmic-proposed) [2.5.0+dfsg-2]
[18:10] -queuebot:#ubuntu-release- New: accepted libsfml [i386] (cosmic-proposed) [2.5.0+dfsg-2]
[18:10] -queuebot:#ubuntu-release- New: accepted libsfml [s390x] (cosmic-proposed) [2.5.0+dfsg-2]
[18:10] -queuebot:#ubuntu-release- New: accepted python-transliterate [amd64] (cosmic-proposed) [1.10.1-1]
[18:10] -queuebot:#ubuntu-release- New: accepted libfixposix [amd64] (cosmic-proposed) [1:0.4.3-1]
[18:10] -queuebot:#ubuntu-release- New: accepted libfixposix [ppc64el] (cosmic-proposed) [1:0.4.3-1]
[18:10] -queuebot:#ubuntu-release- New: accepted libsfml [armhf] (cosmic-proposed) [2.5.0+dfsg-2]
[18:10] -queuebot:#ubuntu-release- New: accepted python-sexpdata [amd64] (cosmic-proposed) [0.0.3-1]
[18:10] -queuebot:#ubuntu-release- New: accepted libfixposix [armhf] (cosmic-proposed) [1:0.4.3-1]
[18:10] -queuebot:#ubuntu-release- New: accepted libsfml [ppc64el] (cosmic-proposed) [2.5.0+dfsg-2]
[18:10] -queuebot:#ubuntu-release- New: accepted libsfml [amd64] (cosmic-proposed) [2.5.0+dfsg-2]
[18:10] -queuebot:#ubuntu-release- New: accepted python-zunclient [amd64] (cosmic-proposed) [1.3.0-0ubuntu1]
[18:11] -queuebot:#ubuntu-release- Unapproved: rejected ssh-import-id [source] (bionic-proposed) [5.7-0ubuntu1.1]
[18:11] -queuebot:#ubuntu-release- Unapproved: x11-xkb-utils (bionic-proposed/main) [7.7+3 => 7.7+3ubuntu<IP_ADDRESS>] (desktop-core)
[18:11] -queuebot:#ubuntu-release- Unapproved: rejected x11-xkb-utils [source] (bionic-proposed) [7.7+3ubuntu1]
[18:16] -queuebot:#ubuntu-release- Unapproved: accepted x11-xkb-utils [source] (bionic-proposed) [7.7+3ubuntu<IP_ADDRESS>]
[18:20] -queuebot:#ubuntu-release- Unapproved: accepted gnome-system-monitor [source] (bionic-proposed) [3.28.2-0ubuntu1]
[18:37] <seb128> slangasek, whoever did that change should revert it, we want to check that the ayatana- components are indeed better codebases and see if we need a coordinated transition or if we can mix apps using both the old and new libraries
[18:37] <seb128> LocutusOfBorg, ^ that would be you
[18:38] <slangasek> seb128: ok, thanks
[18:39] <slangasek> seb128: to be fair, I think it's probably better to migrate to it just to not be islanded on a dead-upstream branch, and deal with any issues along the way; but I'll sit on my hands for now
[18:40] <seb128> slangasek, I've little visibility on the roadmap/direction that ayatana-* want to take at this point and I'm not confident it's compatible with what we do/want to do
[18:40] <seb128> it's probably fine but I don't want to handwave accept it without checking
[18:41]  * slangasek nods
[18:42] <seb128> (and I still find how that project has been handled pretty stupid, they should have taken over the existing projects but that's another topic)
[18:42] <slangasek> ok; I haven't followed the politics there
[19:15] <tsimonq2> seb128: Please do correct me if I'm wrong, but I wouldn't be quick to blame LocutusOfBorg . There are some Debian packages, notably transmission, who switched themselves.
[19:16] <tsimonq2> This doesn't seem to be a delta we're carrying.
[19:16] <tsimonq2> (For all the packages I've been dealing with, personally.)
[19:16] <tsimonq2> I won't take a side on the politics, but people are adopting it.
[19:17] -queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (bionic-proposed) [3.28.2-0ubuntu1]
[19:20] -queuebot:#ubuntu-release- Unapproved: accepted gdm3 [source] (bionic-proposed) [3.28.0-0ubuntu1.1]
[19:29] <seb128> tsimonq2, I don't blame him, but he uploaded a package in main making it use a package in universe without an approved MIR
[19:30] <seb128> tsimonq2, well they can if they want, we just didn't say we wanted to replace our solution by the new one
[19:30] <seb128> so until we do it's wrong to assume we are going to
[19:31] -queuebot:#ubuntu-release- Unapproved: accepted ssh-import-id [source] (bionic-proposed) [5.7-0ubuntu1.1]
[19:32] <tsimonq2> seb128: Ah. So if it's required for one package (and needs a MIR anyway),, why not convert other packages?
[19:32] <tsimonq2> s/,,/,/
[19:32] <seb128> tsimonq2, it's not "required" afaik
[19:32] <seb128> our solution is libappindicator atm
[19:32] <tsimonq2> seb128: Well, transmission needs it.
[19:32] <seb128> or needs to be patched to use the library Ubuntu support
[19:32] <tsimonq2> So unless you want a delta (not up to me), oi's required.
[19:32] <tsimonq2> *it's
[19:33] <seb128> we want a delta
[19:33] <seb128> our main packages need to use components in main
[19:33] <tsimonq2> OK; like I said, not up to me.
[19:33] <tsimonq2> In that case, on the other side of it, why not adopt it?
[19:34] <seb128> read t he backlog of this channel? I stated the reason earlier
[19:35] <tsimonq2> Let me rephrase: why not do the review?
[19:35] <tsimonq2> Of course, it has to go through e.g. a security review.
[19:52] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.32.9+18.04]
[19:58] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (artful-proposed) [2.32.8+17.10]
[20:00] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.32.8]
[20:00] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.32.8~14.04]
[20:03] <apw> bdmurray, oh are we clashing ?
[20:05] <bdmurray> apw: I don't know. What are you doing?
[20:05] <apw> bdmurray, i was just clearing up some pending snapd uploads i was intending to review
[20:05] <apw> bdmurray, but you had just accepted bionic i think, so was checking if i should do the rest
[20:06] <apw> bdmurray, in the sense i know the background with mvo
[20:06] <bdmurray> apw: Have at it.
[20:06] <apw> bdmurray, ack
[20:10] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (artful-proposed) [2.32.9+17.10]
[20:12] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.32.9]
[20:12] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.32.9~14.04]
[20:13] -queuebot:#ubuntu-release- Unapproved: accepted simbody [source] (artful-proposed) [3.5.4+dfsg-1ubuntu1.1]
[20:27] -queuebot:#ubuntu-release- Unapproved: accepted rasdaemon [source] (artful-proposed) [0.5.8-1ubuntu2.1]
[20:30] -queuebot:#ubuntu-release- Unapproved: accepted rasdaemon [source] (xenial-proposed) [0.5.6-2ubuntu1.1]
[20:39] -queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (xenial-proposed) [3.20.5-0ubuntu<IP_ADDRESS>]
[22:02] -queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (trusty-proposed) [0.103ubuntu4.11]
[22:22] <tsimonq2> cjwatson, slangasek: There, this looks right now, could I please get a review? https://code.launchpad.net/~tsimonq2/debian-cd/lubuntu-cosmic-changes/+merge/345792
[23:19] -queuebot:#ubuntu-release- New binary: grabix [ppc64el] (cosmic-proposed/none) [0.1.6+git20171023-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: listserialportsc [ppc64el] (cosmic-proposed/none) [1.4.0-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: ocaml-obuild [ppc64el] (cosmic-proposed/none) [0.1.10-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: libocxl [ppc64el] (cosmic-proposed/none) [1.0.0-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: ocaml-obuild [s390x] (cosmic-proposed/none) [0.1.10-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: listserialportsc [s390x] (cosmic-proposed/none) [1.4.0-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: grabix [s390x] (cosmic-proposed/none) [0.1.6+git20171023-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: dd-plist [amd64] (cosmic-proposed/none) [1.20-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: libb-debug-perl [amd64] (cosmic-proposed/none) [1.26-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: grabix [amd64] (cosmic-proposed/none) [0.1.6+git20171023-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: minetest-mod-infinite-chest [amd64] (cosmic-proposed/none) [1.0.1-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: grabix [i386] (cosmic-proposed/none) [0.1.6+git20171023-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: listserialportsc [i386] (cosmic-proposed/none) [1.4.0-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: pytest-sugar [amd64] (cosmic-proposed/none) [0.9.1-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: listserialportsc [amd64] (cosmic-proposed/none) [1.4.0-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: ocaml-obuild [i386] (cosmic-proposed/none) [0.1.10-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: ocaml-obuild [amd64] (cosmic-proposed/none) [0.1.10-1] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: grabix [arm64] (cosmic-proposed/none) [0.1.6+git20171023-1] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: listserialportsc [armhf] (cosmic-proposed/none) [1.4.0-1] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: grabix [armhf] (cosmic-proposed/none) [0.1.6+git20171023-1] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: ocaml-obuild [arm64] (cosmic-proposed/none) [0.1.10-1] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: listserialportsc [arm64] (cosmic-proposed/none) [1.4.0-1] (no packageset)
[23:29] -queuebot:#ubuntu-release- New binary: ocaml-obuild [armhf] (cosmic-proposed/none) [0.1.10-1] (no packageset)
[23:32] -queuebot:#ubuntu-release- New: accepted dd-plist [amd64] (cosmic-proposed) [1.20-1]
[23:32] -queuebot:#ubuntu-release- New: accepted grabix [arm64] (cosmic-proposed) [0.1.6+git20171023-1]
[23:32] -queuebot:#ubuntu-release- New: accepted grabix [i386] (cosmic-proposed) [0.1.6+git20171023-1]
[23:32] -queuebot:#ubuntu-release- New: accepted grabix [s390x] (cosmic-proposed) [0.1.6+git20171023-1]
[23:32] -queuebot:#ubuntu-release- New: accepted listserialportsc [amd64] (cosmic-proposed) [1.4.0-1]
[23:32] -queuebot:#ubuntu-release- New: accepted listserialportsc [armhf] (cosmic-proposed) [1.4.0-1]
[23:32] -queuebot:#ubuntu-release- New: accepted minetest-mod-infinite-chest [amd64] (cosmic-proposed) [1.0.1-1]
[23:32] -queuebot:#ubuntu-release- New: accepted ocaml-obuild [arm64] (cosmic-proposed) [0.1.10-1]
[23:32] -queuebot:#ubuntu-release- New: accepted ocaml-obuild [i386] (cosmic-proposed) [0.1.10-1]
[23:33] -queuebot:#ubuntu-release- New: accepted grabix [amd64] (cosmic-proposed) [0.1.6+git20171023-1]
[23:33] -queuebot:#ubuntu-release- New: accepted grabix [ppc64el] (cosmic-proposed) [0.1.6+git20171023-1]
[23:33] -queuebot:#ubuntu-release- New: accepted listserialportsc [arm64] (cosmic-proposed) [1.4.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted ocaml-obuild [amd64] (cosmic-proposed) [0.1.10-1]
[23:33] -queuebot:#ubuntu-release- New: accepted pytest-sugar [amd64] (cosmic-proposed) [0.9.1-1]
[23:33] -queuebot:#ubuntu-release- New: accepted grabix [armhf] (cosmic-proposed) [0.1.6+git20171023-1]
[23:33] -queuebot:#ubuntu-release- New: accepted listserialportsc [i386] (cosmic-proposed) [1.4.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted libb-debug-perl [amd64] (cosmic-proposed) [1.26-1]
[23:33] -queuebot:#ubuntu-release- New: accepted ocaml-obuild [armhf] (cosmic-proposed) [0.1.10-1]
[23:33] -queuebot:#ubuntu-release- New: accepted libocxl [ppc64el] (cosmic-proposed) [1.0.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted listserialportsc [s390x] (cosmic-proposed) [1.4.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted ocaml-obuild [s390x] (cosmic-proposed) [0.1.10-1]
[23:33] -queuebot:#ubuntu-release- New: accepted listserialportsc [ppc64el] (cosmic-proposed) [1.4.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted ocaml-obuild [ppc64el] (cosmic-proposed) [0.1.10-1]
[23:48] -queuebot:#ubuntu-release- New binary: obsidian-icon-theme [amd64] (cosmic-proposed/universe) [3.5-1] (no packageset)


[04:39] <mup> Bug #1555260 changed: (1.25.3) agent-status: failed (could not write settings ... timeout) <juju-core:Expired> <https://launchpad.net/bugs/1555260>
[14:52] <mup> Bug #1581966 opened: controller node need to be restart for comissionning new nodes or lxc .. <cpe-sa> <orange-box> <juju-core:New> <https://launchpad.net/bugs/1581966>
[20:33] <mup> Bug #1582018 opened: Tab completion for file system paths and in general for stock Ubuntu cloud image <juju-core:New> <https://launchpad.net/bugs/1582018>
[21:03] <mup> Bug #1582021 opened: Juju loses track of current controller when destroying model <juju-core:New> <https://launchpad.net/bugs/1582021>


[05:22] <pitti> Good morning
[07:14] <dupondje> pitti: i'll check papyon somewhere today, something went wrong :(
[07:57] <dholbach> good morning
[09:15] <pitti> hm, yesterday's dailies grew by 7 MB, due to adding fonts-nanum
[09:32] <pitti> fixed seeds and uploading new -meta, that should do it
[09:36] <cjwatson> pitti: thanks
[09:40] <pitti> cjwatson: FYI, nanum is actually expected to be there, it just looked a bit weird because some ttf-* got renamed to fonts-*; but it replaced ttf-unfonts-core which is still on the imags
[09:47] <cjwatson> pitti: right, I knew about the ttf-* -> fonts-* renaming
[09:47] <cjwatson> still need to process some removals for that
[09:55] <bdrung> broder: debug-symbols-directly-in-usr-lib-debug?
[10:58] <cjwatson> pitti: https://launchpad.net/ubuntu/+source/eog/3.2.1-0ubuntu2 - could you please use libjpeg-dev rather than libjpeg8-dev for such changes, per http://lists.debian.org/debian-devel-announce/2010/02/msg00006.html ?
[10:58] <pitti> cjwatson: ah, ok; I used 8-dev | -dev
[10:58] <pitti> cjwatson: I thought the first alternative should always be preferred
[10:59] <cjwatson> That will make future transitions require a source change
[10:59] <pitti> cjwatson: pushed to bzr
[10:59] <cjwatson> For this library we're just having only one provider to make it easier to transition
[10:59] <pitti> cjwatson: do you want me to upload that now to satisfy some report scripts, or is it not that urgent?
[10:59] <cjwatson> thanks
[10:59] <cjwatson> it's not urgent
[11:00] <cjwatson> I just wanted to catch it quickly in case you were making the same change to lots of packages
[11:00] <pitti> I only really caught it because I was using it for testing the new scour
[11:00] <pitti> but good to know for other cases
[11:35] <Daviey> cjwatson: Does anyone on your team have prior experience with bonding interfaces?
[11:36] <Daviey> cjwatson: trying to work out if bug 889423 would be better worked on my server or foundations.
[11:36] <cjwatson> not that I know of for certain, although I wouldn't put it past Stéphane
[11:37] <Daviey> I have /some/ experience, but don't claim to be an expert.
[11:37] <Daviey> stgraber: When you see this, can you chime in please? :)
[11:39] <cjwatson> there were some ordering changes in ifupdown 0.7~beta2 (not yet in precise) although I don't know if they're relevant here
[11:39] <cjwatson> (just saw Debian mail about that yesterday)
[11:50] <Daviey> cjwatson: thanks
[13:10] <djszapi> Hi! Where can I find the source of the kdeedu 4.7 package ?
[13:50] <Riddell> djszapi: launchpad.net/ubuntu/+source/kdeedu
[13:51] <djszapi> Riddell: I do not see 4.7 there.
[14:03] <stgraber> Daviey: this looks a lot like a potential SRU regression we currently have on lucid, sadly I can't easily reproduce the bug here (need to setup all the hardware, reinstall, ... first)
[14:04] <iceroot> cjwatson: hi, you have a minute? (imo you are a patch-pilot)
[14:04] <stgraber> Daviey: bug 823366 is the potential SRU regression on 10.04.3 (the SRU in 10.04.3 is based on what we had in natty/oneiric IIRC)
[14:05] <Daviey> stgraber: ah, i thought it might have been a regression of bug 482419
[14:05] <Daviey> FWIW, Debian experimental package without ubuntu delta also has the bug.
[14:07] <stgraber> Daviey: right, bug 823366 has been filed as a potential regression of the bugfix from bug 482419
[14:07] <cjwatson> iceroot: patch-piloting is a one-morning-a-month duty for me; I'm not patch-piloting at the moment
[14:07] <cjwatson> there should be another pilot along in a bit, announced in the channel topic ...
[14:08] <iceroot> cjwatson: ok :)
[14:08] <stgraber> the problem being that the fix got taken as-is from a more recent version of ifupdown, so it's not totally clear how we should fix it. Pulling the SRU in lucid will get us back to the previous not-always-working state, keeping the current one is a different kind of not-always-working AFAICT
[14:09] <Daviey> stgraber: We've been discussing it in #ubuntu-server, one user suggested that gets 10% success rate, and modprobing (!) gave him reliable setup
[14:10] <Riddell> sladen: where do I report uses of the old ubuntu logo?
[14:11] <stgraber> Daviey: that could be explained by the fact that all of /proc/sys/net/ipv4/*/bond* only appears once the module is loaded (same with /sys/class/net/bonding*)
[14:11] <sladen> Riddell: http://launchpad.net/ubuntu-branding/+filebug?field.title=XYZ+uses+pre-2010+Ubuntu+logo
[14:11] <stgraber> Daviey: so we may have some kind of race condition between ifupdown/ifenslave and the kernel module being loaded
[14:14] <Daviey> stgraber: I've been given access to an env where we can reproduce it, do you want me to try and get you access?
[14:14] <stgraber> Daviey: that'd be great
[14:23] <stgraber> Daviey: so if you add "bonding" to /etc/modules, does it then work reliably?
[14:23] <stgraber> (trying to figure out a quick test/workaround for the guy who reported the SRU regression so we can confirm it's the same issue and "fix" his setup for now)
[14:27] <smoser> pitti, you touched libtasn1-3, right?
[14:29] <pitti> smoser: yes, I debugged this weird NEWS.gz issue this morning a bit
[14:29] <smoser> pitti, sorry. i was going to say it didn't seem to fix it for me
[14:30] <smoser> but it was user error downloading wrong deb from launchpad (mirror doesn't have it yet for me)
[14:30] <smoser> all better now it seems.
[14:30] <pitti> smoser: you need ubuntu1, not build1
[14:30] <smoser> right.
[14:30] <pitti> build1 was more or less a check whether it still happens
[14:30] <pitti> it seems to happen consistently on ubuntu buildds
[14:30] <smoser> but then when i downloaded that, i accidently downloaded the wrong thing
[14:30] <smoser> and it didn't help
[14:30] <smoser> :)
[14:30] <pitti> but not anywhere else
[14:30] <smoser> now i'm square. yeah, a gzip bug is a bit strange.
[14:31] <cjwatson> pitti: I was working through a gdb session on that over the weekend
[14:31] <pitti> cjwatson: oh, you have a way to reproduce it locally?
[14:31] <cjwatson> will be getting back to it this week ...
[14:32] <pitti> I tried local builds, chroots, porter boxes, PPAs, all deliver the "correct" checksum
[14:32] <cjwatson> pitti: not as such but the difference is in alignment slack near the end of the file, so I'm prepared to bet that it's uninitialised data somewhere and I think I may be able to track it even without being able to reproduce it directly
[14:34] <pitti> cjwatson: ah, so perhaps the ubuntu buildds do use a different fs than ext4 for /build ?
[14:35] <cjwatson> I wouldn't have jumped to the filesystem being at fault
[14:35] <cjwatson> but I haven't ruled out anything in particular
[14:35] <pitti> not necessarily "at fault", I just can't think of any other significant difference
[14:35] <pitti> more like "triggers this bug"
[14:35] <pitti> perhaps truncate() zeroing vs. not, or something
[14:35] <cjwatson> could also be kernel differences
[14:36] <pitti> as the kernel, chroot, architecture shoudl more or less match
[14:36] <cjwatson> not in distro build chroots
[14:36] <cjwatson> the kernel is often several releases older than the chroot, and the degree of difference itself differs across architectures and also isn't necessarily the same as (virtualised) PPAs
[14:37] <cjwatson> personally I think that's the most likely cause, although I don't have a particular mechanism in mind and it probably amounts to a gzip bug anyway
[14:38] <pitti> cjwatson: ah, I had assumed that the buildds run lucid kernel
[14:38] <cjwatson> definitely not true across the board
[14:38] <pitti> ok, that's another possibility then
[14:38] <cjwatson> in fact I think lots of them are still on hardy, since they still need to build hardy-security packages
[14:38] <pitti> I tried precise on lucid kernel, but not precise on hardy or so
[14:39] <cjwatson> some are newer since hardy didn't support the relevant machine
[15:16] <ct529> hi! I am trying to compile the kernel, but 1) I am not certain about the numbering of the ubuntu kernel: does it follow the numbering of the kernel? 2) is it possible to compile the kernel by using the output of cpuid, or /proc/cpuinfo?
[15:39] <cjwatson> pitti: https://launchpad.net/ubuntu/+source/haskell-dummy/1:6/+build/2906774 looks like a pkgbinarymangler bug to me.  Shouldn't pkgstriptranslations only walk over the list of control files once, no matter how many times it's called for a given package?
[15:40] <cjwatson> pitti: I suspect this isn't doing kernel builds any favours in terms of performance either
[15:40] <cjwatson> (I'm not sure why it's exiting 1 in the haskell-dummy case; perhaps a lockfile timeout)
[16:11] <bdmurray> dobey: any idea what happend to the fix for bug 791927?
[16:13] <dobey> bdmurray: looks like it was fixed in upstream, but maybe the packaging didn't get updated to actually include it?
[16:14] <dobey> bdmurray: i can fix that after lunch probably
[16:15] <bdmurray> dobey: okay, thanks for looking at it
[16:15] <dobey> bdmurray: should we SRU it, or just put it in precise?
[16:17] <bdmurray> dobey: I'd think SRU'ing it makes sense but I'm don't know how many bugs desktopcouch gets ...
[16:20] <dobey> bdmurray: ok. will do then
[16:42] <asac> smoser: I remember that our lucid cloud images had issues to boot on high mem amazon instances. do you know if was that fixed at some point or are better off sticking to maverick still?
[16:43] <smoser> asac, i think it is fixed, but dont know for sure the exact bug.
[16:45] <asac> thanks. we might try :)
[16:45] <asac> will let you know if folks can spare some time testing this
[16:45] <smoser> do you remember the bug ?
[17:26] <dobey> bdmurray: https://code.launchpad.net/~dobey/ubuntu/oneiric/desktopcouch/include-apport/+merge/82197
[18:34] <zul> slangasek: Ping what do you think of bug #873423 is it a good idea?
[18:35] <slangasek> zul: all libraries should be converted for multiarch
[18:35] <zul> slangasek: so yes :)
[18:36] <cjwatson> not after feature freeze; but it's open season at the moment
[18:36] <slangasek> zul: certainly - that one's low priority from my POV though, since it's not part of the replace-ia32-libs critical path
[18:36] <zul> slangasek: gotcha thanks
[18:37] <roadmr> SRU-related question, are string changes SRUable? Our trunk has updated strings having to do with Unity and g-c-c changes and we'd like to have those changes in 11.10 as well
[18:46] <broder> bdrung: I'm looking at our outstanding lintian diff and trying to understand the "Drop debug-symbols-directly-in-usr-lib-debug from binaries-general." change you made
[18:56] <slangasek> roadmr: generally not, since this would result in a worse user experience for those who aren't using English rather than a better one
[18:57] <roadmr> slangasek: ok, so unless it's a major snafu on the string it's not likely to be accepted right?
[18:57] <slangasek> yes
[18:58] <roadmr> slangasek: ok, thanks! exactly what I wanted to know :)
[18:58] <slangasek> no prob
[19:01] <slangasek> debfx: bug #889475> you know you can use syncpackage to sync mozc yourself these days, it doesn't need to go through an archive admin?
[19:01] <slangasek> (and indeed, syncpackage is recommended )
[19:09] <stgraber> slangasek: hey, I just noticed http://packages.qa.debian.org/i/ifenslave-2.6/news/20111114T104742Z.html in Debian, which looks a lot like our current ifenslave bug. bug 823366, bug 482419 and bug 889423
[19:09] <stgraber> I'm tempted to just try a merge in a PPA and test on the server that Daviey and I are using for testing
[19:10] <stgraber> slangasek: I noticed you're the touched-it-last, is there anything weird with merging that one from Debian or should I just go ahead and do it myself?
[19:16] <slangasek> stgraber: feel free to take it, though I doubt Debian actually has a fix for any of this since these are mostly issues specific to event-driven boot
[19:18] <slangasek> maybe some of the code has been streamlined to reduce the need for duplicating information
[19:36] <hallyn> SpamapS, do you mind pulling the libvirt-bin from lucid-proposed?  (it failed to build, I marked bug 863629 wontfix for lucid)
[19:54] <stgraber> slangasek: yeah, looking at it, the change in Debian is basically what was pushed as an SRU in lucid (and then lost a bit later on in Ubuntu for some unknown reason)
[19:54] <stgraber> slangasek: basically just re-ordering the lines at the bottom of the pre-up script
[19:56] <stgraber> slangasek: doing a few tests now, my guess is that we should have the upstart job do nothing at all if an interface is in a bonding setup as bond0 will bring up the interfaces anyway
[19:58] <SpamapS> hallyn: hmmm?
[19:59] <SpamapS> hallyn: heading to lunch, do you mean revert it or try it out?
[19:59] <SpamapS> hallyn: or is it just in queue ?
[19:59] <hallyn> SpamapS, i mean pull it out of the -proposed queue
[19:59] <slangasek> stgraber: "lost a bit later on"?
[19:59] <slangasek> grr
[20:00] <SpamapS> hallyn: "The unapproved queue is empty"
[20:01] <SpamapS> hallyn: figure out what you need me to do, I'll be back online in about 45 min
[20:01] <stgraber> slangasek: yeah, the SRU for lucid basically looks like what has been uploaded in Debian this morning. So it looks like we thought changing the ordering was a good idea, got that as an SRU but didn't apply it to later versions of Ubuntu.
[20:02] <stgraber> I'll look at that once I have something that works and push the needed SRUs
[20:02] <slangasek> stgraber: that's not what I see in the current version of ifenslave-2.6 in precise
[20:02] <slangasek> add_master
[20:02] <slangasek> early_setup_master
[20:02] <slangasek> enslave_slaves
[20:02] <slangasek> setup_master
[20:02] <slangasek> that's what we currently have... which is intuitively correct
[20:02] <hallyn> SpamapS, it was approved for -proposed.  It should be pulled out of -proposed.
[20:03] <hallyn> "figure out what I want" depends on what 'revert it' means.  it's not in -updates yet, so I didn't think revert would have applied.  But if revert means pull it from proposed, then yes.
[20:03] <stgraber> slangasek: right, lucid has:
[20:03] <stgraber> add_master
[20:03] <stgraber> setup_master
[20:03] <stgraber> enslave_slaves
[20:03] <SpamapS> hallyn: if it has already been pushed out to mirrors, its better to upload a new package with the change reverted
[20:03] <hallyn> SpamapS, huh?  for something only in -proposed?
[20:03] <SpamapS> hallyn: no if it hit -proposed users will be affected
[20:04] <slangasek> stgraber: yes; that's different not because precise doesn't include the fix, but because precise includes a *further* fix to split setup_master into setup_master + early_setup_master
[20:04] <SpamapS> hallyn: many devs (myself included) run with -proposed enabled all the time.
[20:04] <hallyn> SpamapS, it didn't build, so users won't be affected
[20:04] <slangasek> because presumably some bits need to be done before enslavement, and some after
[20:04] <SpamapS> hallyn: ahh if it FTBFS then just upload a new one with the fix.
[20:05] <stgraber> slangasek: -19 to -20 in Debian is: http://paste.ubuntu.com/738533/
[20:05] <hallyn> i thought things got pulled from -proposed all the time when verification wasn't done by anyone, or failed.
[20:06] <slangasek> stgraber: that looks to me like the maintainer is flip-flopping; I don't believe that's going to be a correct fix
[20:06] <SpamapS> hallyn: they do, but I don't believe I can do that as I don't have direct "cocoplum" access.
[20:07] <slangasek> stgraber: I think this needs more investigation rather than just a simple merge
[20:07] <hallyn> ok, thx
[20:07] <slangasek> because it will probably reintroduce the other bugs that led to the early/setup split to begin with
[20:07] <SpamapS> hallyn: I'm no help at all I know. :-P
[20:07] <stgraber> slangasek: yeah, agreed on that point (once I actually saw what the change was in Debian). Looking at tweaking the upstart job to not run ifup when the interface is in a bond
[20:08] <stgraber> which means only bond0 will be brought up and it should then bring up the interfaces, making everything work (hopefully)
[20:08] <slangasek> stgraber: I think we need a clearer statement of what problem you're actually trying to fix.  That also sounds like a wrong change to me
[20:08] <hallyn> and i'm just a cranky jerk who hates mondays.  i think i'm less fun to be around.
[20:08] <slangasek> bond0 will not be brought up correctly
[20:08] <slangasek> don't do that :)
[20:09] <slangasek> the bonding bring-up *must* be initialized starting from the physical interfaces
[20:09] <slangasek> because those are the only things we get events for
[20:10] <slangasek> we need to properly handle hot-adding of interfaces to an already-up bonding interface, and we need the bonding interface to be brought up when the first physical interface is brought up; there's no other way to do it reliably
[20:13] <stgraber> ok, let me start a clean precise install on a machine that uses bonding and that's not in Montreal (the one I'm currently working on had way too many changes done to it to still be trusted :))
[20:14] <slangasek> ok
[20:14] <slangasek> fwiw, with a complete config here, I'm not reproducing any of these issues
[20:18] <stgraber> slangasek: that machine in Montreal is failing at every boot but I'd like to see it happen on a perfectly clean system
[20:20] <slangasek> stgraber: can I see your /e/n/i?
[20:25] <Daviey> stgraber: that is a volatile machine that can be re-installed if you need it to be?
[20:28] <stgraber> slangasek: http://paste.ubuntu.com/738559
[20:28] <cjwatson> slangasek,debfx: syncpackage doesn't support sponsorship yet, though, so the requestor wouldn't get credited; that's one situation where the old-style workflow is still recommended
[20:28] <slangasek> cjwatson: ah
[20:30] <slangasek> stgraber: right, so, the design of the current code is such that you need to reproduce the 'bond-mode' and 'bond-miimon' options in the stanzas for each of the physical interfaces, or else they don't get picked up
[20:31] <slangasek> stgraber: I expect that if you copy those down, the interface will come up reliably
[20:31] <slangasek> and it's a design defect of the script that this is required
[20:33] <Daviey> cjwatson: sync bugs don't exactly work well, when they bake in the queue and another developer comes along and does a sync whilst waiting for the bug based sync, so the reporter gets credit.
[20:34] <cjwatson> Daviey: I'm not saying they're ideal - they aren't.  But syncpackage has no way to assign credit to somebody else right now, so it's a difference between some chance and no chance.
[20:34] <slangasek> stgraber: /etc/network/if-pre-up.d/ifenslave-2.6 probably needs to use 'ifquery' to extract the details for the bonding interface; this is inelegant, but ifup is obviously not going to know to inject variables from a different interface (bond0) when bringing up the physical interface, so the script would have to do the work
[20:35] <stgraber> slangasek: rebooting now, I also think I reverted most of the changes that happened to that machine (thanks to debsums)
[20:35] <slangasek> ifquery also being Ubuntu-specific for the moment
[20:35] <cjwatson> (Of course the availability of syncpackage has meant that there's less general pressure to process the bug queue regularly ...)
[20:36] <cjwatson> I'd do it now while thinking about it but I'm being called away
[20:37] <stgraber> slangasek: machine just finished rebooting, still not working
[20:37] <slangasek> stgraber: hmm, ok
[20:39] <stgraber> back to installing a clean precise server :)
[20:48] <SpamapS> slangasek: think you will have time to upload from the mysql-5.5 svn tree again today?
[20:48] <Daviey> cjwatson: ack
[20:48] <SpamapS> slangasek: 5.5.17-3 implements Multi-Arch: foreign for libmysqlclient18
[20:49] <slangasek> SpamapS: not sure if I'm going to get to it today; if not today, then tomorrow
[20:50] <SpamapS> slangasek: ok thats great. I am also preparing an upload to make 5.1 stop building libmysqlclient-dev, libmysqld-dev, libmysqld-pic, mysql-common, mysql-server, and mysql-client
[21:10] <bdrung> broder: that's needed to work around bug #808767
[21:10] <bdrung> broder: i would be happy, if you can find a fix for it
[21:26] <broder> bdrung: ...huh. that is *bizarre*
[21:32] <stgraber> slangasek: same problem with a clean precise install
[21:32] <slangasek> stgraber: phooey
[21:32] <stgraber> slangasek: /etc/network/interfaces => http://paste.ubuntu.com/738619/
[21:33] <stgraber> slangasek: dmesg => http://paste.ubuntu.com/738620/
[21:33] <stgraber> lots of complaining going on in dmesg
[21:34] <stgraber> including some complaints (also visible when doing ifup eth0/eth1) that bond-mode can't be changed from an interface definition (as it can only be set when the bond is down)
[21:35] <slangasek> stgraber: hmm.  so results may be driver-dependent
[21:35] <slangasek> it's possible that my own testing in kvm is inadequate :P
[21:35] <stgraber> in that dmesg (50.) is roughly the time where I fix stuff manually
[21:35] <stgraber> yeah, test environment here and in Montreal is using e1000 + cisco/hp switches doing actual LACP
[21:36]  * slangasek nods
[21:37] <slangasek> well, I know it's working for me because my interface is dhcp-configured and successfully gets an IP, and I can route traffic out
[21:37] <Fusionite> Hey all
[21:37] <slangasek> but I'm not using bonding mode 802.3ad
[21:48] <stgraber> slangasek: ok, so I tried something very ugly but that seems to work pretty well. Added "ifup bond0 || true" to /etc/init/network-interface.conf (before the ifup call)
[21:48] <slangasek> strange
[21:48] <slangasek> oh, network-interface, not networking
[21:48] <slangasek> less strange, just ugly :)
[21:49] <bdrung> broder: yes, it's a weird i386 bug
[21:49] <stgraber> yeah, at least that confirms the theory that we need to make sure we always bring up the bond before the slaves
[21:49] <stgraber> now to find the right place to do it
[21:49] <slangasek> I'm not sure it does that
[21:49] <broder> bdrung: does that mean that all i386 dbgsym packages are statically linked?
[21:50] <slangasek> because /etc/network/if-pre-up.d/ifenslave-2.6 would trigger in both cases
[21:50] <slangasek> just with different environment variables set
[21:50] <bdrung> broder: IIRC not all, only that specific file
[21:52] <stgraber> slangasek: oh, also something that's wrong in most configs I've seen so far, bond-primary only applies to active-backup mode, not to 802.3ad or any of the other bonding modes
[21:55] <slangasek> ah
[21:55] <stgraber> slangasek: so that seems to be a minimal valid 802.3ad config: http://paste.ubuntu.com/738645/
[21:56] <stgraber> at least it works fine (with that hack in the upstart job) and I don't see anything weird in dmesg anymore
[21:56]  * stgraber just finished reading http://www.kernel.org/doc/Documentation/networking/bonding.txt again
[22:08] <bdrung> tumbleweed: question.py doesn't seam to be the right place for class EditFile
[22:10] <tumbleweed> bdrung: it seemed about right to me. Better suggestions?
[22:10] <bdrung> tumbleweed: where is it used?
[22:10] <tumbleweed> bdrung: submittodebian, and in the subclass EditBugReport
[22:11] <tumbleweed> (which is used by requestsync, requestbackport)
[22:11] <bdrung> tumbleweed: maybe put those two classes into a separate pyfile
[22:17] <stgraber> slangasek: I'm starting to think these scripts should be split between bond and slaves. Then have the code for the slaves check if the bond exists and if it doesn't call ifup on it so we go through the usual stack instead of bypassing half of it
[22:36] <YokoZar> I have concluded that the proper way to stop regular kernel panics is to install the kernel-crashdump package
[22:37] <stgraber> YokoZar: I noticed a similar fix for apache a while ago, if you want it to stop crashing, just turn on debugging
[22:38] <YokoZar> stgraber: maybe we should put the debug packages in the default install then
[22:38] <broder> and, of course, the best way to fix race conditions is to have a debugger attached :)
[22:41] <hallyn> SpamapS, looking at bug 625882 - we are at 0.8.4 of libdbi, does that mean that anything compiled against libdbi can go back to being build-depends on libdbi0-dev instead of libdbi-dev ?
[22:42] <SpamapS> hallyn: no, libdbi0-dev is deprecated, it needs to be libdbi-dev
[22:42] <SpamapS> hallyn: if its coming in as a merge from Debian, then there needs to be a bug opened against the debian package.
[22:43] <hallyn> SpamapS, with rationale 'libdbi0-dev is deprecated'?
[22:44] <SpamapS> hallyn: I assume the intention of the maintainer is to drop the provides after a time...  in 0.8.4-1 " Renamed libdbi0-dev to libdbi-dev"
[22:44] <hallyn> SpamapS, d'oh, nm, i was misreading anyway.  it has 'libdbi0-dev | libdbi-dev'
[22:45] <SpamapS> hallyn: then in 0.8.4-2 he did 'Adds a Provides: libdbi0-dev' presumably because the API was still compatible
[22:57] <stgraber> slangasek: I have a working hack on top of ifenslave's pre-up script that seems to work great here (except for the part where both interfaces come up at the exact same time, that I worked around with a sleep for now :))
[22:58] <slangasek> stgraber: heh, right - plenty of race conditions to be watched after here
[22:58] <slangasek> stgraber: also, what's the right behavior if one of the interfaces is unavailable (never comes up at boot)?
[23:00] <stgraber> slangasek: http://pastebin.com/irAA6erR
[23:01] <stgraber> slangasek: with that code, only the first interface will be added to the bond, which should still work fine
[23:02] <stgraber> going back home now, will look at backlog later
[23:12] <bdrung> tumbleweed: bug #890464
[23:18] <Laney> that diff does more than the changelog says
[23:19] <slangasek> bryceh: ping re: bug #889226
[23:19] <tumbleweed> bdrung: right, that was on my queue, but nobody was verifying distro-info SRUs
[23:19] <tumbleweed> err udt
[23:20] <tumbleweed> bdrung: please go ahead. Also, we should come up with a long-term solution to this before precise freezes.
[23:21] <bdrung> tumbleweed: SRUing distro-info should be easier to SRUing ubuntu-dev-tools
[23:21] <broder> stgraber: is there a ppa or something with a new version of arkose? i want to play with some of the dbus filtering stuff :)
[23:24] <tumbleweed> bdrung: I suppose that works for tzinfo...
[23:25] <bdrung> tumbleweed: there are some weeks between the announcement and the release, so we should have enough time for the SRUs
[23:26] <tumbleweed> usually, the last one was a bit tight
[23:30] <stgraber> broder: yes, ppa:arkose-devel/stable
[23:32] <bryceh> slangasek, yeah
[23:34] <slangasek> bryceh: hey; followed up on the bug, if you want to debug this I suggest we do so in realtime
[23:34] <slangasek> as this is a one-off situation that happened *during* an X session that was previously fine
[23:34] <slangasek> and I don't expect it to be reproducible if I restart the X server
[23:34] <bryceh> slangasek, I'm reading up on Cypress TetraHub
[23:34] <slangasek> why?
[23:34] <slangasek> it's just a USB hub
[23:34] <slangasek> I can see the kernel events just fine
[23:34] <slangasek> the devices are there
[23:34] <slangasek> it's only X that's confused
[23:35] <stgraber> slangasek: so, I think that the diff I pasted earlier should work and seems to do the right thing. Only thing that needs fixing is the code bringing up the bond interface if it's not there.
[23:36] <bryceh> slangasek, I won't argue that X may not be doing something stupid, however we've not yet updated the X stack in precise, so what you're running right now should be pretty similar to what you were running in oneiric.
[23:36] <stgraber> basically whatever is the first slave coming up needs to do the ifup on the bond, any other interface needs to wait for the bond to be up, then add itself to the list of slaves
[23:37] <slangasek> bryceh: sure; so it could be a latent bug in the oneiric stack, or it could be related to the kernel in some unidentified fashion
[23:37] <bryceh> slangasek, also there appear to be a lot of usb subsystem error messages in your dmesg; possibly unrelated but also make me wonder at kernel problems
[23:37] <slangasek> stgraber: my understanding was that the ifup on the bond was already being done by the previous code
[23:37] <bryceh> slangasek, also I've found a linux-usb thread discussing this particular USB hub and issues with devices not detecting properly
[23:38] <slangasek> bryceh: heh; I've been using it for a couple of years now with no such problems
[23:38] <bryceh> the hub appears to have some usb 2.0 / 3.0 switching behaviors that I gather confused the kernel in the case being described in this thread
[23:38] <bryceh> slangasek, yeah the thread is very recent (nov 12)
[23:38] <slangasek> ah
[23:39] <bryceh> http://www.spinics.net/lists/linux-usb/msg54013.html
[23:39] <bryceh> not sure if it's relevant though.
[23:39] <stgraber> slangasek: kind of, the previous code was creating the bond and doing all the sysctl configuration, but never actually doing an ifup on it (so you'd have to wait till the ifup -a at the end of the boot to get an IP and run the other post-up scripts)
[23:40] <slangasek> stgraber: no, you shouldn't have to wait for ifup -a; creating the device causes a udev event for bond0
[23:40] <slangasek> which (asynchronously) triggers /etc/init/network-interface for bond0
[23:40] <bryceh> slangasek, last paragraph on this email suggests some known issues exist with this hw - http://www.spinics.net/lists/linux-usb/msg54377.html
[23:41] <slangasek> stgraber: maybe instead of calling ifup explicitly, we can just cause the interface to be created?
[23:41] <slangasek> (which I think would probably be cleaner)
[23:42] <slangasek> bryceh: checking to see what happens if I plug the mouse in directly
[23:43] <slangasek> stgraber: I guess it depends whether there's additional setup that needs to be done on the slave interface after ifup is called on the master
[23:44] <slangasek> bryceh: same problem when I plug the mouse in directly
[23:44] <slangasek> device shows up in lsusb, lsinput, input-events shows the events are being received, nothing useful out of X
[23:44] <stgraber> slangasek: I need a way of waiting for bond0 to be done initalizing because only then the other interfaces can be added as slaves to that bond
[23:45] <slangasek> stgraber: I don't think it's very clear what "done initializing" means in all cases
[23:45] <stgraber> slangasek: currently what's creating bond0 is the pre-up script for bond0, so not sure how to trigger the udev event without running the whole pre-up script
[23:46] <stgraber> slangasek: I need to have the bonding module loaded, have the bond interface created, have it's mode set and the interface up so /sys/class/net/bond0/bonding/slaves is writable
[23:47] <bryceh> slangasek, let's pop over to #ubuntu-x
[23:57] <slangasek> stgraber: oh; I was mistaken, there apparently *aren't* any udev events for bonding interfaces
[23:57] <slangasek> stgraber: arguably a bug, but I guess we shouldn't design to rely on it
[23:58] <stgraber> I don't think calling ifup on the master interface is a big problem, as long as we can be sure never to do it twice at the same time because of some race condition
[23:59] <slangasek> no, ifup itself guards against that


[04:15] <PryMar56> ttps://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1436461
[04:19] <PryMar56> to see what fc22 did: http://paste.ubuntu.com/10679310/
[04:23] <PryMar56> this LIB ^^ has pkg-config support and headers, but not shared object. Seems like a huge oversight
[04:23] <PryMar56> to classify the bug as wishlist is foolish
[09:17] <yossarianuk> is there an ETA on when the beta2 .iso will be populating in the mirrors?
[11:00] <BluesKaj> 'Morning all
[11:00] <lotuspsychje> BluesKaj: hello mate
[11:00] <BluesKaj> Hi lotuspsychje
[14:28] <Xvigorator> Hi all. There appears to be a problem with disabling the SSH daemon on boot up (i.e. want a manual start/stop only).
[14:31] <Xvigorator> I have tried systemctl disable sshd But it is ignored. I have also disabled via sysv-init (/etc/rc2 through rc5)
[14:32] <Xvigorator> Can anyone confirm unstoppable SSH daemon at boot up?
[14:34] <Xvigorator> 'sudo service ssh stop' or 'systemctl stop sshd.service' will work once logged in. No desktop autostart is used.
[14:38] <Xvigorator> Vivid Velvet is installed.
[16:43] <yossarianuk> still no beta-2 iso.......
[16:43] <TheNumb> yossarianuk: use a daily iso
[16:46] <elfy> yossarianuk: if it does turn up today it will be tomorrow in some parts of the world
[16:47] <elfy> never completely sure why the fascination with milestone releases - it'll be out of date more or less as soon as it releases :p
[16:48] <yossarianuk> ok - cheers
[16:48] <yossarianuk> had an issue with UEFI on previous nightly (kubuntu(
[16:49] <yossarianuk> where I had to install twice in order to get the UEFI boot entry
[16:49] <elfy> I did see a bunch of updates being talked about for kubuntu - they might be on the current b2 that's available for testing
[16:49] <elfy> but couldn't be sure - don't use it here
[16:50] <yossarianuk> elfy: would not the same installer bugs be present with ubuntu
[16:50] <yossarianuk> its really on the desktop that's difference
[16:50] <yossarianuk> (at the min - when Mir is out there will be more differences)
[17:24] <Xvigorator> testing
[17:52] <gr33n7007h> is 15.04 using systemd?
[17:57] <Xvigorator> gr33n7007h  Yes!
[17:57] <BluesKaj> gr33n7007h,yes
[17:58] <CptRageToaster> Hmm... over in Xen, PryMar56 and I were talking about a missing systemd lib that's needed to compile Xen 4.5
[17:58] <CptRageToaster> over in #Xen*
[17:58] <CptRageToaster> issue in launchpad was marked as "wont fix"
[17:58] <gr33n7007h> ok thanks
[17:59] <CptRageToaster> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1436461
[18:04] <CptRageToaster> is there any recourse?
[18:17] <knittl> how can I find out, why a package will be removed by apt-get/aptitude?
[18:25] <PryMar56> I need source code sd-daemon.c from the systemd sources, how can I extract this?
[18:25] <PryMar56> for Vivid 15.04, systemd 219
[18:26] <PryMar56> I found the header, sd-daemon.h
[23:51] <PryMar56> to build libsystemd-daemon.so.0 (systemd-219): ./configure --enable-compat-libs


[14:02] <larsks> harlowja: btw, submitted that pr yesterday.  And now it has tests, too.
[15:39] <Odd_Bloke> smoser: I'm looking at fixing https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1411582 in cloud-init.
[15:40] <Odd_Bloke> smoser: My suggested fix is to shift the udev rule that creates /dev/disk/azure/... in to cloud-init, and then teach cloud-init to dereference /dev/disk/... symlinks.
[15:41] <Odd_Bloke> smoser: We could also look at making the directory created more generic (e.g. /dev/disk/cloud-init/...), so that we have a single place to look for stuff on different clouds.
[15:42] <Odd_Bloke> (This would, for example, allow us to answer 'do I have an ephemeral disk?' by just looking at /dev/disk/cloud-init/ephemeral or whatever)
[15:42] <Odd_Bloke> smoser: Thoughts?
[17:02] <smoser> Odd_Bloke, well, looking forward, there is a plan for a block device usage languange. that explicitly declares how disks should be used. this will support raid, lvm, bcache ...
[17:02] <smoser> that is happening for curtin usage.
[17:02] <smoser> i'd like for cloud-init to be able to take that language and render it into being also.
[17:07] <smoser> the added piece that cloud-init needs is kind of what you were mentioning. curtin will be fed disk config like http://paste.ubuntu.com/10939715/ .
[17:08] <smoser> but ideally cloud-init can then allow substitution of things like 'ephemeral0' where it finds out what that is.
[17:23] <harlowja> larsks awesome
[17:23] <Odd_Bloke> smoser: Right, is that something that can happen now?  We've got pressure from Azure to get this fixed.
[17:24] <Odd_Bloke> smoser: (Also, will we realistically ever take the curtin language in to 0.7.x?)
[17:26] <smoser> Odd_Bloke, probably not
[18:00] <smoser> Odd_Bloke, so i think i'm ok with the overall idea.
[18:00] <smoser> then cloud-init would allow users to specify 'ephemeral0' as they can elsewhere.
[18:00] <smoser> and on azure that would map to /dev/cloud-init/ephemeral0
[18:00] <smoser> i think thats what you're saying
[18:16] <Odd_Bloke> smoser: Yeah, it would be /dev/disk/cloud-init/ci-ephemeral or somesuch.
[18:16] <Odd_Bloke> smoser: Ben proposed this udev config: http://paste.ubuntu.com/11566987/
[18:17] <smoser> it doesnt seem unreasonble.
[18:18] <smoser> but i dont know how this determines between "running on azure" and "running on hyper-v"
[18:19] <alexpilotti> smoser: this is for cirros?
[18:19] <smoser> alexpilotti, that above was azure ubuntu
[18:20] <alexpilotti> oh, k tx
[18:20] <Odd_Bloke> smoser: I'm not sure either; udev is not my strong suit. Let me check with Ben.
[18:23] <Odd_Bloke> smoser: Ben confirmed with Microsoft that that would only match in Azure environments.
[18:27] <smoser> why would they only match in azure
[18:27] <smoser> that is odd
[18:27] <smoser> dont you think ?
[18:27] <smoser> ID_VENDOR of Msft
[18:27] <smoser> odd
[18:35] <Odd_Bloke> smoser: I _think_ it's the UUIDs that are Azure-specific.
[18:36] <smoser> ah. that does seem more reaosnable.
[21:16] <alexpilotti> smoser: I’m hearing about ext4 for config drives
[21:48] <smoser> alexpilotti, that is odd / roughly stupid
[21:49] <smoser> not really here. but a link to info woudl be good. but really cloud-init doesnt care.
[23:35] <harlowja> windows dll fun scares me lol


[00:38] <Vivid_> Might i as what peoples current hardware is that they are running ubuntu on?
[01:12] <asterismo> hi
[01:12] <asterismo> i need help to recover all my notes from ubuntu-one
[01:12] <asterismo> it will not sync with the address 'https://one.ubuntu.com/notes'
[01:12] <asterismo> how do i recover my notes please
[01:13] <asterismo> i read it is not supported anymore
[01:18] <wilee-nilee> asterismo, I doubt anyone here will know, however I started a search to see, you will be better looking I have no idea. https://www.google.com/search?hl=en&output=search&sclient=psy-ab&q=recover+ubuntu+one+notes&btnG=&gbv=1&sei=399YUfnrI-SviAL8pYBo
[01:18] <asterismo> nobody here uses ubuntu-one?
[01:19] <wilee-nilee> somebody might know, this channel is slow you might try #ubuntu asterismo
[01:20] <wilee-nilee> asterismo, http://askubuntu.com/questions/239403/is-it-possible-to-recover-tomboy-notes-from-ubuntu-one-now-that-the-sync-featur
[01:21] <asterismo> thanks wilee-nilee
[01:21] <wilee-nilee> no problem.


[00:35] <pabs3> hmm, git-remote-bzr from breezy doesn't work as well as the old git-remote-bzr, I guess I need to port that to Python 3 & breezy


[00:59] <eot3> hello
[11:12] <Bogdan22> hello
[11:12] <Bogdan22> is this ubuntu gnome efi compatible?
[12:14] <Ponch0> Hey room, alot of people most likely code here: so here's my question, I've tried changing up themes in ubuntu and programming IDE;s but there always seems to be  some place where a color is completely blinding, any recommendations?
[12:14] <Ponch0> super buggy stuff.
[13:05] <bjsnider> the high contrast themes have those types of colours i guess, otherwise no idea what the problem is
[13:40] <Ponch0> thanks
[19:22] <ddoooog> hello
[19:22] <ddoooog> are there some active members here?
[19:25] <Noskcaj> !ask | ddoooog
[19:27] <ddoooog> oh, ok. My question is: if i install the final beta of ubuntu gnome will i be able, later on when it releases, to upgrade to the stable one without installing it from scratch again?
[19:31] <Noskcaj> ddoooog, yep, it happens automatically
[19:32] <ddoooog> nice, thank you for your answer, Noskcaj.
[19:32] <Noskcaj> Just please report the results of installing the beta to iso.qa.ubuntu.com , we need more testers
[19:52] <bjsnider> a lot of people ask that question in various channels towards the end of a release cycle