User1: cyphermox: Any reason why your latest grub2 upload isn't in Git? https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu
User2: User3 hi, any update on LO? we had to work around the uninstallability in -proposed already, to avoid blocking the ffmpeg transition
User3: 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
User3: expect something build in cosmic some time this morning
User2: ta
User4: 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
User5: 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
User5: If the edit was actually abusive then we can deal with that
User4: cjwatson, well i left a comment for them in the bug report but that was 5 days ago  - no reply
User4: 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
User4: cjwatson, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1780971
User6: Launchpad bug 1780971 in ubiquity (Ubuntu) "Insufficient options for encryption" [Undecided,New]
User4: 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
User4: 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
User5: User4 That seems like a reasonable way to resolve it
User5: Doesn't need a moderator unless it turns into bug description tennis :)
User5: 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
User7: tseliot, hey! have you seen https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1655584 ? any thoughts?
User6: Launchpad bug 1655584 in systemd (Ubuntu) "systemd-udevd busyloops when nvidia kernel module fails to load" [Undecided,Confirmed]
User8: User7 I don't think one should install the nvidia driver and expect it not to be used
User7: tseliot, har har har =)
User7: 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.
User8: User7 while certainly possible, we don't have the pci id of the GPU to prove it
User9: User4 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.
User9: User4 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
User9: User4 or are you saying that if any of your suggestions in your comment 1 were implemnted, you'd consider the bug fixed?
User4: 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
User4: *is
User4: the bug report should just explain the circumstances
User4: s/but it should/but it shouldn't/
User4: :D
User9: User4 but it's really difficult for any developer to propose a solution for an open ended problem.
User4: i'd hardly call it open ended - not when there are several possible solutions talked about
User9: 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?
User4: i've already done that by saying what the target system should be capable of doing
User4: be encrypted, work with hibernation, not delete existing os's
User4: and important of all - be friendly to newbies because the above shouldn't be a tall order
User9: OK, so how about "Encryption option doesn't support installation alongside existing OSes"?
User4: 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
User4: rbasak, except I don't expect that to be fixable
User4: as it would require ubiquity to be able to resize all known os's :D
User4: which is why I haven't called it that
User4: at some point the problem has to be accepted for what it is - and stop redefinining it
User9: OK, so how about "Encryption option doesn't support installation alongside Windows"?
User4: right but you're just as equally stuffed if wanting to do this on a chromebook or macbook ? :D
User9: Got to start with something
User9: I don't feel that this re-defining it. I feel that it needs defining for the first time :)
User4: 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
User4: and yeah if its windows - it'd be nice if it could offer making that free space too
User9: 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.
User9: And that's what I think that triager was trying to achieve.
User4: bugs are 'i found this problem, this is how'  not  'i found this problem, you should fix it this way'
User9: It's up to you how you want to do that I guess.
User4: right well triage it without rephrasing the problem! :D
User9: The triager tried and you didn't like it.
User9: So I think the ball's in your court :)
User4: :D
User9: At some point someone has to pin down the bug to a specific solution
User4: sure but that comes *after* it is reported
User4: not by changing what was reported
User9: 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.
User9: It will become a zombie bug, changing form to whatever part of it you feel isn't fixed yet.
User4: bug reporters can't help come into the difficulties they find themselves in - and describing it in the exact way they found it
User9: And developers don't like touching those because there's no objective way to fix them.
User9: Sure, and we value that feedback.
User9: But the bug tracker is supposed to be used to fix specific issues.
User4: it is one of those
User9: General feedback is perhaps better given in mailing lists or forums etc.
User4: it isn't one of those
User4: many bugs have several possible ways to fix them - this is no different
User4: 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
User4: this is no different - but all that comes *after* it is reported
User9: That's all fine.
User4: not by defining the problem
User9: The key is that the bug title and description accurately describe the conditions under which the bug may be closed.
User9: (closed as fixed, that is)
User4: they do
User4: the description describes several scenarios that may be possible ways to resolve it
User4: the title is kept specific enough to speak to those scenarios
User9: "Insufficient options for encryption" doesn't cover that though.
User9: 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.
User4: it does because all the other titles you and others have proposed - narrow down on just one scenario
User9: I don't think I'm able to be helpful any more, so I'll stop.
User4: ok :P thanks anyway
User9: Thank you for the report and the feedback.
User2: stgraber: please could you have a look at the lxd/i386 autopkg test failure triggered by python3-defaults?
User3: doko, libreoffice 6.0.6~rc1 is currently building in cosmic-proposed, and I'm uploading the corresponding -l10n package
User3: hopefully that unblocks transitions
User10: Laney, doko, hi, regarding ffmpeg 4 -- gst-libav seems to be some trouble
User10: https://bugzilla.gnome.org/show_bug.cgi?id=792900
User6: Gnome bug 792900 in gst-libav "Update to ffmpeg 4.0 API" [Normal,Resolved: fixed]
User2: User10 feel free to fix it. I'm not the transition owner
User11: ricotz, L_aney is on holidays
User10: doko, ok
User10: seb128, hi, I see
User2: seb128, jbicha: any update with brotli? will block the python3-defaults transition
User12: 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"...
User11: doko, no idea about what you are talking about, and j_bicha is not really around anymore atm
User2: User11 I'm talking about a desktop owned package which currently ftbfs
User7: alkisg, one is bionic, the other one is xenial.
User7: alkisg, it does say 18.04.1 and 16.04.5 clearly next to each date =)
User12: User7 ah, thank you; https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule did it differently
User12: I.e.  13     July 21st      PointRelease  Ubuntu 16.04.1
User7: alkisg, meh
User7: the info is there =) and it's not structured data, just hand editted wiki =)
User12: It just didn't come to my mind that pointrelease was referring to 16.04 there. Thanks! :)
User11: doko, bug number?
User11: doko, https://bugs.launchpad.net/ubuntu/+source/brotli is empty
User11: 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
User7: seb128, would it be useful to generate FTBFS mailing list notifications for subcribing teams as they happen?
User7: seb128, e.g. something that monitors the ftbfs report and reports those somewhere or would that just be spam? trello cards? automatic bug reports?
User11: 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
User7: seb128, so during a team meeting you don't brookscarl@example.net. http://qa.ubuntuwire.org/ftbfs/#desktop-packages ? and http://qa.ubuntuwire.org/ftbfs/#desktop-extra ?
User2: well, what x-nox said ...
User13: User16 hey! jibel metioned to me that pre-installed snaps on bionic images don't work
User13: User16 he pointed to the bug LP: #1772844 which apparently should be fixed in the seeds (and therefore in the dailies we build)
User6: Launchpad bug 1772844 in ubuntu-meta (Ubuntu) "snapd didn't initialize all the seeded snaps" [Undecided,Confirmed] https://launchpad.net/bugs/1772844
User13: But the snaps seem to still not work
User13: User14 are you sure it's the same issue still?
User14: sil2100, I suppose it's the same from this thread https://forum.snapcraft.io/t/gnome-calculator-failed-to-create-symbolic-link/5742
User15: Fixed in the seeds doesn't mean fixed in the images, because germinate re-orders things.
User15: So when it gets to livecd-rootfs to write in the seed.yaml, gtk-common-whatever is last again.
User13: I guess infinity's proposition of working-around it by hacking livecd-rootfs to force gtk-common-themes ordering might work
User16: 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?
User15: User16 What do you mean "how much"?
User15: User16 It's needed as much as people want the snaps to work? :P
User15: User16 Or if you're asking why livecd-rootfs reorders things currently, it doesn't.
User15: User16 snaps are seeded, germinate consumes seeds, livecd-rootfs consumes germinate output.  germinate's output order isn't the same as the input order.
User15: User16 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.
User9: User17 o/
User9: User17 what would you like to do wrt. https://code.launchpad.net/~smb/ubuntu/+source/iproute2/+git/iproute2/+merge/348673?
User16: User15 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
User17: rbasak, if I were not rubbish (or distracted by so many other things) I would update the merge request
User16: User15 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
User9: User17 no rush. Just making sure you aren't expecting something from me.
User15: User16 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.
User15: User16 Oh, except it needs to be second in the list, doesn't it? :P
User17: rbasak, no, right now rather the opposite
User16: User15 I need to look, I don't look from the top of my head :/ but the order from the bug works
User15: User16 The entire list is:
User15: * snap:gnome-3-26-1604
User15: * snap:gtk-common-themes
User15: * snap:gnome-calculator
User15: * snap:gnome-characters
User15: * snap:gnome-logs
User15: * snap:gnome-system-monitor
User15: User16 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.
User15: User16 And this is how it gets spit out of germinate: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.bionic/desktop.snaps
 * mvo looks
User15: User16 Looks pretty suspiciously like ASCII sort order.
User16: yeah
User15: 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.
User15: I *won't* fix it in cosmic, cause I think we need the glaring reminder to fix it properly.
User15: User16 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.
User15: User16 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
User16: User15 yeah, we will fix it probably soon, i.e. reoder in "base" order
User15: User16 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.
User15: Ahh, no, that looks hard.
User15: Since it just pulls the whole seed into an ordered dict and then filters the snaps back out.
User15: So the order is broken before we know it's a snap.
User5: It'd be quite a bit of surgery to get germinate to preserve order.
User15: User5 Yeah, just came to the same conclusion.
User15: livecd-rootfs hack it is, for now.  Fun, fun.
User5: Since as you say it was never previously needed so it has quite pervasive assumptions that it doesn't need to.
User16: infinity, cjwatson ok, so its more than just throwing a s/dict/collections.OrderedDict/ ? thats unfortunate :/
User16: User15 sorry for the extra trouble :/
User15: User16 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.
User16: User15 yes,that should be fine, it is not using a base itself AFAICT
User16: User15 checking some more
User16: User15 yeah, should be fine
User15: User16 Okay, that gives a simple hack like so: https://paste.ubuntu.com/p/kGVN5r34nk/
User16: User15 thank you
User15: I guess that wants to be ${ALL_SNAPS:+ ${ALL_SNAPS}} just in case.
User15: User16 http://paste.ubuntu.com/p/Y6vMzhRZQc/
User16: User15 yeah
User16: User15 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?
User15: User16 Tell me with some level of confidence that the snapcraft autopkgtest regressions aren't snapd's fault.
User16: User15 let me double check them all first to ensure nothing has changed since I looked last.
User16: User15 80-90% confident this is not related to brookscarl@example.net. 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)
User15: User16 Well, unless snapd is involved in the rust snap not installing correctly.
User15: User16 Cause that's, like, its job.
User15: User16 (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)
User14: 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?
User16: User15 let me double check but to me this looks like its not the rust snap its rustup.sh
User16: User14 uh, ok
User15: User16 Seems a bit suspect that "rustc" is ENOENT...
User16: User14 anything in snap changes and the relevant change? any warning or anything?
User16: User15 I check their testsuite now
User14: mvo, no nothing, it just hangs on "Doing  today at 18:22 CEST  -                    Automatically connect eligible plugs and slots of snap "gedit"
User14: "
User14: mvo, if it is not known, I'll open a thread in the forum
User16: User15 the rust plugin uses _RUSTUP = "https://static.rust-lang.org/rustup.sh"
User16: User15 no snap involved
User16: User14 how can I reproduce this? is this also an issue with 2.33.1 (the current one in -updates)?
User15: User16 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
User16: User15 yeah, let me quickly investigate the issue that jibel  reported, not sure if its a regression or not
User15: User16 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?
User16: User15 absolutely! thank you and enjoy breakfast
User16: 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
User16: User14 ok, 2.33.1 eventually finished with a warning, looking further
User16: User14 same for 2.34.1, took a long time but then finished, trying again fresh
User16: User14 same result, took a long time but eventually worked with 2.34.2
User14: mvo, it never finishes for me and cannot be aborted either. It's with bionic daily
User16: User14 bionic daily with -proposed?
User14: yes
User16: User14 I just created the VM with autopkgtest-buildvm-, let me try to enable proposed and try again
User14: I didn't try with 2.33, downgrading hangs too
User16: User14 `snap change <nr>` should give you more details
User14: not much https://paste.ubuntu.com/p/6DJdzKgKKy/ (in french sorry but the message it's hanging on is in english)
User16: User14 :( I just tried it again with -proposed in the vm still not reproducible, let me download the bionic daily
User16: User14 do yu have the link which image you used? just to make sure I get exactly the same
User14: mvo, http://cdimage.ubuntu.com/bionic/daily-live/current/
User14: mvo, I've to go, I'll continue tomorrow
User16: User14 ta
User16: User14 I test this out now
ubuntu-devel
Ubuntu IRC