=== maclin1 is now known as maclin
[04:45] <tsimonq2> cyphermox: Any reason why your latest grub2 upload isn't in Git? https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu
=== abeato_ is now known as abeato
[08:31] <doko> oSoMoN: hi, any update on LO? we had to work around the uninstallability in -proposed already, to avoid blocking the ffmpeg transition
[08:33] <oSoMoN> doko, I've prepared a 6.0.6~rc1 build that resolves the build problems, I'm now running the autopkgtests locally and if it's all good I'll push it to cosmic
[08:33] <oSoMoN> expect something build in cosmic some time this morning
[08:33] <doko> ta
[09:02] <stevenm> are there any kind of moderators for launchpad or bugs related to ubuntu itself?  i'm kinda annoyed that someone has completely rephrased my bug report - effectively putting words in my mouth
[09:03] <cjwatson> It's intended that the bug description (but not subsequent comments) can be edited to serve as a better summary of the bug, and your original text is preserved in the "View original description" link or whatever it's called.  But if you feel the description edit was inaccurate then you can either edit it again yourself or talk to the person who made the change
[09:04] <cjwatson> If the edit was actually abusive then we can deal with that
[09:12] <stevenm> cjwatson, well i left a comment for them in the bug report but that was 5 days ago  - no reply
[09:12] <stevenm> so i've changed it back, but including their version too - with a note to say i'd rather have the bug invalidated than be completely re-edited like that
[09:15] <stevenm> cjwatson, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1780971
[09:15] <ubottu> Launchpad bug 1780971 in ubiquity (Ubuntu) "Insufficient options for encryption" [Undecided,New]
[09:15] <stevenm> i admit my original description is wordy - but at the same time it can't be helped as i'm trying to describe a user experience problem
[09:16] <stevenm> certainly can't be boiled down to what it was changed to, not only is that only 1 possible remedy (of about 5) but also it only caters for one scenario
[09:41] <cjwatson> stevenm: That seems like a reasonable way to resolve it
[09:41] <cjwatson> Doesn't need a moderator unless it turns into bug description tennis :)
[09:42] <cjwatson> Do remember that developers need to distil bugs down into actionable items in order to do anything about them, and sometimes we make mistakes in doing so because we're human
[10:12] <xnox> tseliot, hey! have you seen https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1655584 ? any thoughts?
[10:12] <ubottu> Launchpad bug 1655584 in systemd (Ubuntu) "systemd-udevd busyloops when nvidia kernel module fails to load" [Undecided,Confirmed]
[10:23] <tseliot> xnox: I don't think one should install the nvidia driver and expect it not to be used
[10:24] <xnox> tseliot, har har har =)
[10:28] <xnox> tseliot, the only thing i can think of, is that the module is declared as compatible, even though it is not. E.g. missmatch of modalises / pci lines.... but that is highly unlikely.
[10:34] <tseliot> xnox: while certainly possible, we don't have the pci id of the GPU to prove it
[10:58] <rbasak> stevenm: the challenge with your bug report is that we don't have an objective way of knowing when it has been resolved, or what we can do to actually resolve it.
[11:00] <rbasak> stevenm: for the bug to make progress, I think it needs pinning down more. Otherwise though it's useful and valuable feedback, I'm not sure its status in the bug tracker can be anything but Incomplete
[11:00] <rbasak> stevenm: or are you saying that if any of your suggestions in your comment 1 were implemnted, you'd consider the bug fixed?
[11:07] <stevenm> rbasak, yeah basically - all bugs get conversation regarding how to fix it... but it should change the description pre-emptively on what the proposed fix it
[11:07] <stevenm> *is
[11:07] <stevenm> the bug report should just explain the circumstances
[11:07] <stevenm> s/but it should/but it shouldn't/
[11:07] <stevenm>  :D
[11:10] <rbasak> stevenm: but it's really difficult for any developer to propose a solution for an open ended problem.
[11:10] <stevenm> i'd hardly call it open ended - not when there are several possible solutions talked about
[11:11] <rbasak> That's true, but the bug title is still open ended. Could you perhaps summarise the common thing that you're fixing in all of those possible solutions and update the bug title?
[11:12] <stevenm> i've already done that by saying what the target system should be capable of doing
[11:12] <stevenm> be encrypted, work with hibernation, not delete existing os's
[11:12] <stevenm> and important of all - be friendly to newbies because the above shouldn't be a tall order
[11:13] <rbasak> OK, so how about "Encryption option doesn't support installation alongside existing OSes"?
[11:13] <stevenm> at some point you'll always get feedback regarding the level of frustration that is caused - that's just as valid, it gets boiled down to a workable solution *after* the bug is filed
[11:13] <stevenm> rbasak, except I don't expect that to be fixable
[11:13] <stevenm> as it would require ubiquity to be able to resize all known os's :D
[11:14] <stevenm> which is why I haven't called it that
[11:14] <stevenm> at some point the problem has to be accepted for what it is - and stop redefinining it
[11:14] <rbasak> OK, so how about "Encryption option doesn't support installation alongside Windows"?
[11:14] <stevenm> right but you're just as equally stuffed if wanting to do this on a chromebook or macbook ? :D
[11:15] <rbasak> Got to start with something
[11:15] <rbasak> I don't feel that this re-defining it. I feel that it needs defining for the first time :)
[11:15] <stevenm> sure but likely the solution to the problem (e.g. pick which bit of contiguous free spare to setup a crypt/lvm/ubuntu system) will fix them all
[11:16] <stevenm> and yeah if its windows - it'd be nice if it could offer making that free space too
[11:16] <rbasak> I'm just trying to be helpful by saying that if the bug title isn't specific, it's unlikely to get attention from developers.
[11:16] <rbasak> And that's what I think that triager was trying to achieve.
[11:16] <stevenm> bugs are 'i found this problem, this is how'  not  'i found this problem, you should fix it this way'
[11:17] <rbasak> It's up to you how you want to do that I guess.
[11:17] <stevenm> right well triage it without rephrasing the problem! :D
[11:17] <rbasak> The triager tried and you didn't like it.
[11:17] <rbasak> So I think the ball's in your court :)
[11:18] <stevenm> :D
[11:18] <rbasak> At some point someone has to pin down the bug to a specific solution
[11:18] <stevenm> sure but that comes *after* it is reported
[11:18] <stevenm> not by changing what was reported
[11:18] <rbasak> Right now I think developers will be reluctant to do that because they'll fear that you'll reply asking for it to be made general again.
[11:19] <rbasak> It will become a zombie bug, changing form to whatever part of it you feel isn't fixed yet.
[11:19] <stevenm> bug reporters can't help come into the difficulties they find themselves in - and describing it in the exact way they found it
[11:19] <rbasak> And developers don't like touching those because there's no objective way to fix them.
[11:20] <rbasak> Sure, and we value that feedback.
[11:20] <rbasak> But the bug tracker is supposed to be used to fix specific issues.
[11:20] <stevenm> it is one of those
[11:20] <rbasak> General feedback is perhaps better given in mailing lists or forums etc.
[11:20] <stevenm> it isn't one of those
[11:20] <stevenm> many bugs have several possible ways to fix them - this is no different
[11:21] <stevenm> proposals for a fix will come and go, some will be considered janky and workarounds, some get to the root of the problem, some are just plain crazy and missing the point
[11:21] <stevenm> this is no different - but all that comes *after* it is reported
=== chrisccoulson_ is now known as chrisccoulson
[11:21] <rbasak> That's all fine.
[11:21] <stevenm> not by defining the problem
[11:21] <rbasak> The key is that the bug title and description accurately describe the conditions under which the bug may be closed.
[11:22] <rbasak> (closed as fixed, that is)
[11:22] <stevenm> they do
[11:22] <stevenm> the description describes several scenarios that may be possible ways to resolve it
[11:22] <stevenm> the title is kept specific enough to speak to those scenarios
[11:22] <rbasak> "Insufficient options for encryption" doesn't cover that though.
[11:23] <rbasak> Anyway, I'm just trying to be helpful in getting the bug addressed such that I think developers will be able to work on it.
[11:23] <stevenm> it does because all the other titles you and others have proposed - narrow down on just one scenario
[11:23] <rbasak> I don't think I'm able to be helpful any more, so I'll stop.
[11:23] <stevenm> ok :P thanks anyway
[11:24] <rbasak> Thank you for the report and the feedback.
[12:34] <doko> stgraber: please could you have a look at the lxd/i386 autopkg test failure triggered by python3-defaults?
[13:04] <oSoMoN> doko, libreoffice 6.0.6~rc1 is currently building in cosmic-proposed, and I'm uploading the corresponding -l10n package
[13:04] <oSoMoN> hopefully that unblocks transitions
[13:07] <ricotz> Laney, doko, hi, regarding ffmpeg 4 -- gst-libav seems to be some trouble
[13:08] <ricotz> https://bugzilla.gnome.org/show_bug.cgi?id=792900
[13:08] <ubottu> Gnome bug 792900 in gst-libav "Update to ffmpeg 4.0 API" [Normal,Resolved: fixed]
[13:11] <doko> ricotz: feel free to fix it. I'm not the transition owner
[13:13] <seb128> ricotz, L_aney is on holidays
[13:14] <ricotz> doko, ok
[13:14] <ricotz> seb128, hi, I see
[13:15] <doko> seb128, jbicha: any update with brotli? will block the python3-defaults transition
[13:25] <alkisg> Hi, when is 18.04.1 coming out, July 26th or August 2nd? https://wiki.ubuntu.com/BionicBeaver/ReleaseSchedule lists a different date for 18.04.1 vs the "PointRelease"...
[13:32] <seb128> doko, no idea about what you are talking about, and j_bicha is not really around anymore atm
[13:33] <doko> seb128: I'm talking about a desktop owned package which currently ftbfs
[13:33] <xnox> alkisg, one is bionic, the other one is xenial.
[13:33] <xnox> alkisg, it does say 18.04.1 and 16.04.5 clearly next to each date =)
[13:34] <alkisg> xnox: ah, thank you; https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule did it differently
[13:34] <alkisg> I.e.  13     July 21st      PointRelease  Ubuntu 16.04.1
[13:34] <xnox> alkisg, meh
[13:35] <xnox> the info is there =) and it's not structured data, just hand editted wiki =)
[13:35] <alkisg> It just didn't come to my mind that pointrelease was referring to 16.04 there. Thanks! :)
[13:36] <seb128> doko, bug number?
[13:36] <seb128> doko, https://bugs.launchpad.net/ubuntu/+source/brotli is empty
[13:40] <seb128> doko, there is no good process atm that let team know about build issues in their packages so if you see one that needs to be resolved the proper way to deal with it is the report the problem and assign or rls-cc-incoming tag it so it's on our official reports
[13:52] <xnox> seb128, would it be useful to generate FTBFS mailing list notifications for subcribing teams as they happen?
[13:53] <xnox> seb128, e.g. something that monitors the ftbfs report and reports those somewhere or would that just be spam? trello cards? automatic bug reports?
[14:00] <seb128> xnox, having some sort of reporting would be useful for sure, having individuals manually checking the status of all their packages isn't the best
[14:02] <xnox> seb128, so during a team meeting you don't look at e.g. http://qa.ubuntuwire.org/ftbfs/#desktop-packages ? and http://qa.ubuntuwire.org/ftbfs/#desktop-extra ?
[14:13] <doko> well, what x-nox said ...
[14:48] <sil2100> mvo: hey! jibel metioned to me that pre-installed snaps on bionic images don't work
[14:48] <sil2100> mvo: he pointed to the bug LP: #1772844 which apparently should be fixed in the seeds (and therefore in the dailies we build)
[14:48] <ubottu> Launchpad bug 1772844 in ubuntu-meta (Ubuntu) "snapd didn't initialize all the seeded snaps" [Undecided,Confirmed] https://launchpad.net/bugs/1772844
[14:49] <sil2100> But the snaps seem to still not work
[14:49] <sil2100> jibel: are you sure it's the same issue still?
[14:50] <jibel> sil2100, I suppose it's the same from this thread https://forum.snapcraft.io/t/gnome-calculator-failed-to-create-symbolic-link/5742
[14:56] <infinity> Fixed in the seeds doesn't mean fixed in the images, because germinate re-orders things.
[14:56] <infinity> So when it gets to livecd-rootfs to write in the seed.yaml, gtk-common-whatever is last again.
[15:02] <sil2100> I guess infinity's proposition of working-around it by hacking livecd-rootfs to force gtk-common-themes ordering might work
[15:03] <mvo> infinity, sil2100 we have this on our todo list to analyze and reoder seed.yaml as needed. however right now we rely on explicit ordering. how much is the rewriting in livecd-rootfs needed? could we keep the original order here maybe for the time being?
[15:09] <infinity> mvo: What do you mean "how much"?
[15:09] <infinity> mvo: It's needed as much as people want the snaps to work? :P
[15:10] <infinity> mvo: Or if you're asking why livecd-rootfs reorders things currently, it doesn't.
[15:10] <infinity> mvo: snaps are seeded, germinate consumes seeds, livecd-rootfs consumes germinate output.  germinate's output order isn't the same as the input order.
[15:12] <infinity> mvo: One coule maybe argue that's a bug, but historically, germinate had no reason to keep things in a specific order, as dpkg deps don't have ordering constraints.
[15:23] <rbasak> smb: o/
[15:23] <rbasak> smb: what would you like to do wrt. https://code.launchpad.net/~smb/ubuntu/+source/iproute2/+git/iproute2/+merge/348673?
[15:24] <mvo> infinity: sorry for not being precise in my question. I was wondering how hard it would be to make the germinate output order the same as the input order
[15:25] <smb> rbasak, if I were not rubbish (or distracted by so many other things) I would update the merge request
[15:25] <mvo> infinity: I know fixing this on our side is quite a bit of work unfortunately so I wonder if there is a quicker fix until we can fix the real issue
[15:26] <rbasak> smb: no rush. Just making sure you aren't expecting something from me.
[15:26] <infinity> mvo: I don't know how much work it would be to ask germinate to do that.  But just forcing gtk-thing-whatever to be first in the list if present would be doable in livecd-rootfs.
[15:27] <infinity> mvo: Oh, except it needs to be second in the list, doesn't it? :P
[15:27] <smb> rbasak, no, right now rather the opposite
[15:28] <mvo> infinity: I need to look, I don't look from the top of my head :/ but the order from the bug works
[15:30] <infinity> mvo: The entire list is:
[15:30] <infinity>  * snap:gnome-3-26-1604
[15:30] <infinity>  * snap:gtk-common-themes
[15:30] <infinity>  * snap:gnome-calculator
[15:30] <infinity>  * snap:gnome-characters
[15:30] <infinity>  * snap:gnome-logs
[15:30] <infinity>  * snap:gnome-system-monitor
[15:31] <infinity> mvo: I'm going to assume gtk-common-themese needs to come after gnome-3, but I could be wrong and maybe they can come in any order.
[15:33] <infinity> mvo: And this is how it gets spit out of germinate: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.bionic/desktop.snaps
[15:33]  * mvo looks
[15:33] <infinity> mvo: Looks pretty suspiciously like ASCII sort order.
[15:33] <mvo> yeah
[15:34] <infinity> But ASCII sort happens to be almost the order we want, except for gtk-common-themes, so I can just manually shuffle that in livecd-rootfs for the point release.
[15:34] <infinity> I *won't* fix it in cosmic, cause I think we need the glaring reminder to fix it properly.
[15:35] <infinity> mvo: I don't think asking germinate to maintain seed order is entirely sane, since that's really not how germinate has ever been historically used or documented.
[15:35] <infinity> mvo: But if there's some way to introspect the snaps and determine dependency order, then maybe that might be a valid thing to ask it to do.  But if that can be done, snapd could *&^!^& do that itself on consuming seed.yaml as well. :P
[15:36] <mvo> infinity: yeah, we will fix it probably soon, i.e. reoder in "base" order
[15:41] <infinity> mvo: I guess the snap germinate stuff is a bolt-on anyway, maybe it could be asked to not fiddle with the order, but that's not an SRU I want to do in the next two hours.
[15:43] <infinity> Ahh, no, that looks hard.
[15:43] <infinity> Since it just pulls the whole seed into an ordered dict and then filters the snaps back out.
[15:43] <infinity> So the order is broken before we know it's a snap.
[15:43] <cjwatson> It'd be quite a bit of surgery to get germinate to preserve order.
[15:44] <infinity> cjwatson: Yeah, just came to the same conclusion.
[15:44] <infinity> livecd-rootfs hack it is, for now.  Fun, fun.
[15:44] <cjwatson> Since as you say it was never previously needed so it has quite pervasive assumptions that it doesn't need to.
[15:46] <mvo> infinity, cjwatson ok, so its more than just throwing a s/dict/collections.OrderedDict/ ? thats unfortunate :/
[15:46] <mvo> infinity: sorry for the extra trouble :/
[15:51] <infinity> mvo: Can you confirm that it's okay for gtk-common-themes to come first (ie: before gnome-3-26-1604), cause that makes the hack easier.
[15:53] <mvo> infinity: yes,that should be fine, it is not using a base itself AFAICT
[15:53] <mvo> infinity: checking some more
[15:55] <mvo> infinity: yeah, should be fine
[15:56] <infinity> mvo: Okay, that gives a simple hack like so: https://paste.ubuntu.com/p/kGVN5r34nk/
[15:58] <mvo> infinity: thank you
[15:58] <infinity> I guess that wants to be ${ALL_SNAPS:+ ${ALL_SNAPS}} just in case.
[16:01] <infinity> mvo: http://paste.ubuntu.com/p/Y6vMzhRZQc/
[16:04] <mvo> infinity: yeah
[16:05] <mvo> infinity: once that fire is under control, what are our chances to get snapd 2.34.2 into -updates so that it can be part of 18.04.2? our QA team did the validation, anything I can do to help with 2.34.2 moving to -updates?
[16:06] <infinity> mvo: Tell me with some level of confidence that the snapcraft autopkgtest regressions aren't snapd's fault.
[16:07] <mvo> infinity: let me double check them all first to ensure nothing has changed since I looked last.
[16:12] <mvo> infinity: 80-90% confident this is not related to snapd at all. AFAICT the tests run rustup.sh and for some reason this is not fully working, i.e. after it ran "error: could not execute process `rustc -vV` (never executed)` fails with ENOENT. I don't see snapd involved in this failing test(s)
[16:14] <infinity> mvo: Well, unless snapd is involved in the rust snap not installing correctly.
[16:14] <infinity> mvo: Cause that's, like, its job.
[16:15] <infinity> mvo: (So, it seems to come down to "the rust snap is broken" or "snapd broke the rust snap", and I'd like a definitive answer as to which)
[16:18] <jibel> mvo, talking about 2.34.2, on a fresh installation of 18.04.1 (snapd 2.34.2+18.04) gedit snap hangs during installation on "automatically connect eligible plugs and slots ...". I cannot find any useful data about what's going on. Is it something reported already?
[16:20] <mvo> infinity: let me double check but to me this looks like its not the rust snap its rustup.sh
[16:20] <mvo> jibel: uh, ok
[16:21] <infinity> mvo: Seems a bit suspect that "rustc" is ENOENT...
[16:21] <mvo> jibel: anything in snap changes and the relevant change? any warning or anything?
[16:22] <mvo> infinity: I check their testsuite now
[16:24] <jibel> mvo, no nothing, it just hangs on "Doing  today at 18:22 CEST  -                    Automatically connect eligible plugs and slots of snap "gedit"
[16:24] <jibel> "
[16:26] <jibel> mvo, if it is not known, I'll open a thread in the forum
[16:26] <mvo> infinity: the rust plugin uses _RUSTUP = "https://static.rust-lang.org/rustup.sh"
[16:26] <mvo> infinity: no snap involved
[16:27] <mvo> jibel: how can I reproduce this? is this also an issue with 2.33.1 (the current one in -updates)?
[16:28] <infinity> mvo: Ahh, okay.  That gives me even less confindence in the snapcraft testsuite than I already had, but it guess it gets snapd off the hook. :P
[16:28] <mvo> infinity: yeah, let me quickly investigate the issue that jibel  reported, not sure if its a regression or not
[16:28] <infinity> mvo: I'm going to run and grab a coffee and some sort of breakfast sandwich, gimme a summary of what you learn from jibel's bug when I get back?
[16:29] <mvo> infinity: absolutely! thank you and enjoy breakfast
[16:39] <mvo> infinity, jibel I can reproduce the issue with gedit and 2.33.1 (the current version in -updates). so not a regression but still a bug
[16:41] <mvo> jibel: ok, 2.33.1 eventually finished with a warning, looking further
[16:45] <mvo> jibel: same for 2.34.1, took a long time but then finished, trying again fresh
[16:50] <mvo> jibel: same result, took a long time but eventually worked with 2.34.2
[16:51] <jibel> mvo, it never finishes for me and cannot be aborted either. It's with bionic daily
[16:51] <mvo> jibel: bionic daily with -proposed?
[16:51] <jibel> yes
[16:52] <mvo> jibel: I just created the VM with autopkgtest-buildvm-, let me try to enable proposed and try again
[16:52] <jibel> I didn't try with 2.33, downgrading hangs too
[16:52] <mvo> jibel: `snap change <nr>` should give you more details
[16:54] <jibel> not much https://paste.ubuntu.com/p/6DJdzKgKKy/ (in french sorry but the message it's hanging on is in english)
[16:58] <mvo> jibel: :( I just tried it again with -proposed in the vm still not reproducible, let me download the bionic daily
[16:59] <mvo> jibel: do yu have the link which image you used? just to make sure I get exactly the same
[17:02] <jibel> mvo, http://cdimage.ubuntu.com/bionic/daily-live/current/
[17:03] <jibel> mvo, I've to go, I'll continue tomorrow
[17:03] <mvo> jibel: ta
[17:03] <mvo> jibel: I test this out now
=== M_hc[m] is now known as _hc