[07:20] <ricotz> kenvandine, hi :), fyi https://launchpad.net/~gnome3-team/+snap/gnome-characters
=== cpaelzer__ is now known as cpaelzer
[07:53] <cpaelzer> Hi, anybody working on the autopkgtest fails of livecd-rootfs already (http://autopkgtest.ubuntu.com/packages/l/livecd-rootfs/disco/amd64) ?
[07:54] <cpaelzer> jbicha: I saw you retrying it for rsync, let me know if you know someone is already on that
[07:55] <cpaelzer> I'm collecting just the basic info of that issue right now as it starts to block more packages migration ...
[07:55] <cpaelzer> rbasak: in case you heard anything yesterday that I might have missed ^^ ?
[08:08] <rbasak> I didn't
[08:32] <cpaelzer> FYI: I filed bug 1813730 for the issue I asked above hoping that others looking for it find the bug and we can join forces
[08:32] <ubottu> bug 1813730 in util-linux (Ubuntu) "livecd-rootfs autopkgtest fails configuring required packages calling out util-linux" [Undecided,New] https://launchpad.net/bugs/1813730
[08:48] <cpaelzer> rbalint: I just saw in the livecd-rootfs testcase that you are listed as Author, therefore ping as FYI for the bug above ^^
[08:50] <rbalint> cpaelzer, i just noticed you are on it, and i already started triaging but did not get much further yet
[08:50] <rbalint> cpaelzer, nor i filed a tracking bug :-(
[08:51] <cpaelzer> rbalint: "I'm on it" is saying too much, I'm staring at it and blindly try random things :-)
[08:51] <cpaelzer> if anything I post in the bug rings a bell for you let me know
[08:53] <rbalint> cpaelzer, my hunch is udevadm timing uout thus I'm now reproducing with timestamped output and cleanup trap disabled
[08:54] <rbalint> cpaelzer, (no packages from proposed)
[08:56] <cpaelzer> rbalint: the most recent error seems to be around "loop0p1 is in use", you think that this is due to udev timing out?
[08:56] <cpaelzer> I'd have expected that this is more due to some background process not letting go properly
[08:57] <rbalint> cpaelzer, in theory prior umount should have cut out any process accessing the device
[08:57] <cpaelzer> also it seems to fail only with the ubuntu-cpc template, but since I don't even know what that does I need a while for my next step
[09:00] <rbalint> cpaelzer, cloud images so they have ext4 partition causing us trouble :-)
[09:01] <cpaelzer> rbalint: it seems your understanding of this area is much better than mine so I should stop wasting my time and rely on you - will you update bug 1813730 with what you continue to find?
[09:01] <ubottu> bug 1813730 in util-linux (Ubuntu) "livecd-rootfs autopkgtest fails configuring required packages calling out util-linux" [Undecided,New] https://launchpad.net/bugs/1813730
[09:01] <cpaelzer> thanks in advance
[09:02] <rbalint> cpaelzer, yes, sure, thanks for looking into it and sorry for not opening a bug earlier
[09:03] <cpaelzer> not a problem
[09:22] <rbasak> http://people.canonical.com/~ubuntu-archive/auto-sync/ could do with some sharding. It's killing my browser a little :-/
[09:31] <rbasak> That's odd. I see dep8 failures on the excuses page, which seem valid since they have corresponding logs, but the failures don't appear in eg. http://autopkgtest.ubuntu.com/packages/m/mysql-5.7/disco/ppc64el
[09:31] <rbasak> From that page it's as if these tests never took place.
[09:32] <rbasak> The passing ones appear but the failing ones seem to all be absent.
[09:34] <cpaelzer> rbasak: I recently had failing tests missing as well
[09:34] <cpaelzer> rbasak: but I thought it was because I rerun them with all kinds of extra triggers and had assumed I would have been too trigger-happy :-)
[09:35] <cpaelzer> rbasak: did the one you are missing just finish and might just take a while, or did it run quite a while ago?
[09:35] <rbasak> It is all very recent so there could be some lag I suppose.
[09:36] <cpaelzer> the one I was missing (but did not have too many triggers) ran about 1.5 hours ago and so far didn't appear
[09:37] <cpaelzer> I'd expect one more run here http://autopkgtest.ubuntu.com/packages/l/livecd-rootfs/disco/amd64 for qemu+all-proposed=1
[09:37] <cpaelzer> I thought I give it some time to appear, not sure when it would be "too long"
[09:37] <cpaelzer> I have seen it in http://autopkgtest.ubuntu.com/running and it is no more there now
[09:38] <Laney> it's just slow
[09:38] <Laney> you can browse swift manually to find results immediately
[09:38] <Laney> e.g. for livecd-rootfs
[09:38] <Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/?format=plain&prefix=disco/amd64/l/livecd-rootfs/
[09:38] <Laney> that leads you to https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/l/livecd-rootfs/20190129_083414_2c2b1@/log.gz
[09:39] <Laney> help would be welcome to implement a nicer way for the website to retrieve results than polling
[09:39] <Laney> e.g. using amqp to signal completion
[09:39] <rbasak> Thanks, that's useful to know.
[09:40] <rbasak> Knowing that it's not a bug that causes the results to be absent forever is very helpful. Now my wait is bounded :)
[09:40]  * rbasak will just look at it again later
[09:40] <Laney> (also, proposed-migration isn't subject to this delay since it fetches the results itself)
[09:40] <Laney> probably if it were someone would have fixed it sooner :P
[09:50] <rbasak> :)
[09:51] <rbasak> jbicha: are you familiar with mythtv? It currently FTBFS on a couple of arches, causing it to be stuck in proposed. It's the last stuck rdep of libmysqlclient20 that I want to transition.
[09:59]  * rbasak filed bug 1813746
[09:59] <ubottu> bug 1813746 in mythtv (Ubuntu) "FTBFS 2:30.0+fixes.20190118.c62e273394-autobuild on some arches" [High,Triaged] https://launchpad.net/bugs/1813746
[10:00] <rbasak> I intend to proceed anyway, and we'll have to sort it on the way.
[11:06] <ahasenack> sil2100: hi, good morning/afternoon, wondering if you could help me a bit. I have 3 bileto tickets (https://bileto.ubuntu.com/#/ticket/3610, 3611 and 3613) that have "queued" tests since last friday, nothing has run
[11:06] <ahasenack> sil2100: do you have access to logs about that perhaps?
[11:18] <sil2100> ahasenack: hey! hm, weird, let me take a look
[11:19] <sil2100> argh
[11:19] <sil2100> 2019-01-29 10:59:45.746494 Updating ticket 3610: 401 UNAUTHORIZED
[11:20] <sil2100> ahasenack: let me try getting that fixed, but in the meantime it seems that 3610 was passing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-3610-excuses/2019-01-29_10:20:01/3610_cosmic_excuses.html
[11:21] <ahasenack> thanks
[11:21] <sil2100> I'll quickly look at the other two and then try to find a way to make Bileto update the tickets contents again
[11:22] <sil2100> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-3611-excuses/2019-01-29_10:20:01/3611_bionic_excuses.html <- 3611 is green as well
[11:22] <sil2100> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-3613-excuses/2019-01-29_10:20:01/3613_disco_excuses.html <- and 3613 disco too
[11:22]  * ahasenack copies the links
[11:23] <sil2100> I think this might just be a case of the token not updating itself again, but yeah, I'll know more once I'm done with my current thing
[11:23] <ahasenack> ok, I won't resubmit, specially since they are green :)
[11:23] <ahasenack> thanks
[11:37] <kenvandine> ricotz: fixing, thanks!
[12:07] <jbicha> LocutusOfBorg: hi, could you follow up on bug 1813587?
[12:07] <ubottu> bug 1813587 in libunistring (Ubuntu Bionic) "libunistring ftbfs on 18.04 LTS" [High,New] https://launchpad.net/bugs/1813587
[13:09] <ahasenack> sil2100: bileto tickets updated themselves, thanks!
[13:09] <andrewsh[m]> can anyone see my messages?
[13:09] <ahasenack> I mean, with your nudging I'm sure :)
[13:09] <andrewsh> andrewsh[m]: right, it works now
[13:09] <ahasenack> andrewsh[m]: I can
[13:09] <andrewsh> ahasenack: I was posting here yesterday and nobody could see me
[13:09] <andrewsh> because I wasn't logged in :/
[13:10] <andrewsh> I thought everyone was very ignorant of me :D
[13:10] <ahasenack> right, that had to be changed because of a spam attack last year
[13:10] <andrewsh[m]> > is there any chance this patch gets tested and applied? https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1733557/comments/120
[13:10] <ubottu> Launchpad bug 1733557 in unity (Ubuntu) "Login screen showing Authentication Failure Switch to greeter..." [Undecided,Confirmed]
[13:11] <andrewsh[m]> > I know Unity doesn’t receive much attention these days, but nevertheless, if I want a bug fixed in Disco and the LTS, who should I prod for this?
[13:11] <andrewsh[m]> > there’s a patch one of the commenters have produced which other users report helped with the issue
[13:12] <xnox> rbasak, systemd stopped ignoring failures from safe remounts... which should be possible if unsharing a mount namespace is. But that didn't work, due to apparmor denials.
[13:12] <xnox> rbalint, opened lxd apparmor profile bug. But there is a manual workaround one can apply.
[13:13] <xnox> rbasak, see the bug report.
[13:13] <xnox> https://bugs.launchpad.net/lxd/+bug/1813622
[13:13] <ubottu> Launchpad bug 1813622 in lxd (Ubuntu) "systemd-resolved, systemd-networkd and others fail to start in lxc container with v240 systemd" [High,Confirmed]
[13:17] <ahasenack> andrewsh[m]: the rules for a stable release update are listed in https://wiki.ubuntu.com/StableReleaseUpdates. In particular, the bug needs this template filled out: https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
=== ricab is now known as ricab|lunch
[13:22] <andrewsh[m]> ahasenack: thanks; I suspect it's best to get it fixed in the current development release first. Since I don’t have upload rights to Ubuntu-only packages, I understand I need to find someone who does that for me
[13:22] <LocutusOfBorg> jbicha, done
[13:24] <ahasenack> andrewsh[m]: correct, and fixing it in disco (if it's still present there) is actually a requirement for the sru
[13:24] <jbicha> andrewsh[m]: if you prepare the debdiff and subscribe ubuntu-sponsors to the bug, it will show up on http://reqorts.qa.ubuntu.com/reports/sponsoring/
[13:27] <andrewsh[m]> right; before I go ahead, could please someone with some PAM knowledge sanity-check the patch just to make sure I don’t prepare an upload that doesn’t make sense? my knowledge of PAM is very infra-basic to be honest
[13:38] <andrewsh[m]> right, commit 44e60221 seems to have introduced this bug, by Andrea Azzarone <azzaronea@gmail.com>
[13:42] <sil2100> ahasenack: yay! So indeed it was the cache, I kicked it and this fixed it, as always
[13:43] <ahasenack> cool
[13:43] <sil2100> ahasenack: if we ever resume Bileto-work, solving the outdating-cache issue would be one thing I'd like to do
[13:43] <ahasenack> sil2100: I hope it can be brought up in one of these product sprints :)
[13:49] <andrewsh[m]> hmm, I’m not sure how can I submit a merge request to the project’s Git repo
[13:50] <andrewsh[m]> actually, I’m not sure I can at all
[13:50] <andrewsh[m]> (I see others have, however)
[13:52] <andrewsh[m]> right, lunch time
=== chrisccoulson_ is now known as chrisccoulson
[14:33]  * kenvandine waves as boarding plane
[14:33] <kenvandine> Whoops, wrong channel
[14:37] <ahasenack> andrewsh[m]: you can, go do http://launchpad.net/ubuntu/+source/<package>
=== ricab|lunch is now known as ricab
[14:37] <ahasenack> andrewsh[m]: then click on the "code" tab
[14:37] <ahasenack> that will show the git repo for the package, and all its branches
[14:37] <ahasenack> the "ubuntu/devel" branch always points at the latest development release, i.e., right now that will be what's in disco or disco-proposed
[14:38] <ahasenack> andrewsh[m]: you can also install the git-ubuntu snap (sudo snap install git-ubuntu) and then do "git ubuntu clone <package>"
[14:49] <andrewsh[m]> I was able to clone it but I'm not sure where to push it for the review
[14:54] <rbasak> andrewsh[m]: what was your clone URL?
[14:54] <rbasak> andrewsh[m]: and what's your Launchpad ID?
[14:55] <andrewsh[m]> git+ssh://andrew.sh@git.launchpad.net/unity for the upstream code, git+ssh://andrew.sh@git.launchpad.net/ubuntu/+source/unity for the packaging
[14:55] <andrewsh[m]> (that reveals my ID too)
[14:56] <cjwatson> other people can't clone using andrew.sh@ URLs, but I imagine rbasak knows what you mean :)
[14:57] <rbasak> So push to git+ssh://andrew.sh@git.launchpad.net/~andrew.sh/unity/my-bugfix-branch-name I think?
[14:57] <rbasak> cjwatson: will be able to confirm :)
[14:57] <cjwatson> for an upstream branch?
[14:57] <rbasak> I assumed so
[14:57] <cjwatson> push to git+ssh://andrew.sh@git.launchpad.net/~andrew.sh/unity
[14:57] <cjwatson> branch name isn't in the URL
[14:57] <rbasak> Oh, sorry.
[14:57] <rbasak> Yes of course.
[14:58] <cjwatson> then go to https://git.launchpad.net/~andrew.sh/unity
[14:58] <rbasak> FWIW, it would be useful for that URL to be displayed at https://code.launchpad.net/unity
[14:58] <rbasak> with the others
[14:59] <rbasak> If it's not. I'm not sure as apparently I can push directly so perhaps it is omitted for me.
[14:59] <rbasak> Though even in that case I would want to push a personal branch to file an MP against it for peer review.
[15:01] <cjwatson> It would.  Care to file a bug?
[15:02] <rbasak> ack
[15:07] <rbasak> Filed https://bugs.launchpad.net/launchpad/+bug/1813778
[15:07] <ubottu> Launchpad bug 1813778 in Launchpad itself ""Personal" push URLs not displayed on code pages" [Undecided,New]
[15:12] <cjwatson> thanks
[15:15] <rbasak> Thank you for somehow finding time to make these minor tweaks that I keep asking for :)
[15:22] <cjwatson> ... I didn't say I was going to implement it soon, just to be clear ;-)
[15:26] <rbasak> I understand, and no pressure. I'm just thanking you for having implemented a bunch of my previous Wishlist bugs :)
[15:37] <Woodpecker> Where should I place files that should be queued up to be handled by a daemon? I wont want /tmp/ given that it is flushed on reboot.
[15:38] <rbasak> I believe the FHS uses /var/spool for that.
[15:38] <rbasak> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARSPOOLAPPLICATIONSPOOLDATA
[15:44] <Woodpecker> rbasak: Awesome. Thanks
[16:18] <ddstreet> xnox looks like the latest systemd in disco is status 'deleted' - do you want us to patch on top of that, or one of the older versions?  i.e. 240-5ubuntu1 is the 'latest', should we patch on top of that version?
[16:19] <xnox> ddstreet, you shouldn't need to patch anything in disco
[16:19] <xnox> ddstreet, what patches did you expect to upload into disco?
[16:19] <ddstreet> xnox https://github.com/systemd/systemd/issues/11332
[16:19] <ddstreet> xnox we have several other systemd patches waiting to get into disco too, but will defer those to later
[16:20] <ddstreet> this one is high priority though
[16:20] <xnox> ddstreet, wait, you are planning to sru that?!
[16:20] <ddstreet> yes
[16:21] <xnox> ddstreet, slashd - my understanding you will be SRUing just this https://github.com/systemd/systemd/commit/93158c77bc69fde7cf5cff733617631c1e566fe8.patch
[16:21] <xnox> which is sufficient for your case, no?
[16:22] <ddstreet> that will fix things going thru glibc, yes
[16:22] <ddstreet> i don't know if that is the only use case
[16:23] <ddstreet> i.e., any local application that talks directly to the systemd stub resolver (instead of getaddrinfo) and uses tcp pipelining will fail
[16:23] <ddstreet> you want to leave sru relases like that?
[16:29] <xnox> ddstreet, i'd rather not fix more things than we have to.
[16:29] <xnox> ddstreet, but equally i'd want to sru options ends0 into there
[16:29] <xnox> ddstreet, but doing  that can also break people who parse resolv.conf
[16:29] <xnox> ddstreet, it is most likely that systemd in disco will release with v241+patches, or v242
[16:30] <xnox> ddstreet, current v239 and v240 are incompatible with disco (fail tests or fail in lxd)
[16:30] <xnox> ddstreet, thus there is nothing you can upload to disco atm.
[16:30] <ddstreet> xnox ok...so looks like you already put the edns0 patch in disco
[16:30] <xnox> ddstreet, and imho you shouldn't need to, cause those changes will make it into disco and will not regress.
[16:30] <ddstreet> but you're saying you don't want to sru the edns0 workaround patch either?
[16:30] <xnox> ddstreet, yes, edns0 is in; cause that's part of the removed v240 (which will be going back in)
[16:31] <xnox> ddstreet, i'm trying to assess risk, and all of them look risky =)
[16:31] <xnox> ddstreet, to answer your question - i don't think you need to prepare any uploads for disco.
[16:31] <ddstreet> well we need one or the other (or both) srued, to either workaround (edns0) or actually fix (tcp pipelining) the bug
[16:31] <xnox> ddstreet, and good luck with whatever SRUs you want to push.
[16:31] <ddstreet> heh ok
[17:35] <ahasenack> sil2100: still around? I'm not finding https://bileto.ubuntu.com/#/ticket/3613 in the /running page, I wonder if it's the same issue as earlier today
[17:42] <sil2100> ahasenack: hm, I don't see it as being considered by britney at all
[17:42] <sil2100> ahasenack: this one was green though, right?
[17:42] <ahasenack> yes, I uploaded another package to the ppa
[17:43] <sil2100> Ah
[17:43] <ahasenack> let me check the diff
[17:43] <sil2100> Did you regenerate the diff? DId you check the QA field on and off?
[17:43] <ahasenack> no for the latter
[17:43] <sil2100> Since there are no authorization failures from what I see, simply bileto's britney doesn't consider it for testing
[17:44] <ahasenack> I just selected "approved" in the lander, and then the tests switched to "queed"
[17:44] <ahasenack> ok
[17:44]  * ahasenack regens diff
[17:44] <andrewsh[m]> rbasak, cjwatson, thanks!
[17:45] <sil2100> ahasenack: let's re-try after generating the diffs
[17:45] <ahasenack> will do, thanks
[17:46] <sil2100> Ok, toggled it now that the diff was regenerated, let's look at the next britney run
[17:52] <andrewsh[m]> right, submitted https://code.launchpad.net/~andrew.sh/unity/+git/unity/+merge/362414
[18:18] <bdmurray> seb128: Is bug 1807900 something the desktop team would sort out?
[18:18] <ubottu> bug 1807900 in update-manager (Ubuntu Bionic) "update-manager suggests to use Livepatch, which is not available" [High,Triaged] https://launchpad.net/bugs/1807900
[19:47] <rbasak> I can't file a bug against https://code.launchpad.net/~wgrant/lp-ftbfs-report/production
[19:47] <rbasak> But http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html uses the same anchor name for the team ubuntu-server as it does the pacakgeset ubuntu-server, so one of the links at the top goes to the wrong place.
[19:47] <rbasak> Something the server team should generally know about to avoid missing things.
[19:48] <rbasak> cpaelzer, ahasenack, kstenerud, paride: FYI ^
[19:50] <ahasenack> and both have 5 packages :)
[20:06] <vorlon> kees, stgraber: TB ping
[20:26] <paride> thanks rbasak
[22:24] <wgrant> rbasak: Why can't you file a bug?
[22:28] <rbasak> wgrant: surely I should be filing it against your branch instead of the project in general? I am under the impression that doesn't fit Launchpad's model.
[22:28] <wgrant> rbasak: It's certainly slightly unusual, but not problematic.
[22:30] <rbasak> wgrant: how about a bug link in the footer to make it clear. Would you like a bug for that? And where exactly should I file it? :-P
[22:34] <wgrant> rbasak: Filing a bug on the project is fine.
[22:39] <seb128> bdmurray, hey, we can take on this update-manager/livepatch bug
[22:40] <rbasak> Filed bug 1813840 and bug 1813841. Thanks!
[22:40] <ubottu> bug 1813840 in FTBFS Report "Duplicate anchor names result in incorrect links" [Undecided,New] https://launchpad.net/bugs/1813840
[22:40] <ubottu> bug 1813841 in FTBFS Report "No bug link" [Undecided,New] https://launchpad.net/bugs/1813841