[00:37] <nacc> cjwatson: random question -- I thikn you did this change a while ago for man subpages: http://git.savannah.gnu.org/cgit/man-db.git/commit/?id=7de45db026166ea55f9b7c240928ef0de0245a3f. As we added subsubcommand with git-ubuntu, would it make sense to find the longest concatenation with a manpage? (That is, `man git ubuntu lint` currenly opens `man git-ubuntu` even though `man git-ubuntu-lint` is alsoo
[00:37] <nacc> available
[00:38] <nacc> it seems like currently it tries git-ubuntu (finds it) and also tries lint (without git-ubuntu-)
[00:40] <cjwatson> nacc: maybe; it would need a fair bit of refactoring as the code that does that is horribly special-cased right now
[00:40] <nacc> yeah, I see that :)
[00:40] <cjwatson> I would take patches for it but I think it would have to be in a few passes, with cleanup first
[00:41] <nacc> cjwatson: thanks -- I'm not sure if it's always correct either way to do what I'm suggesting (but I thinkn worst case we'd iterate a few times and not find it)
[00:41] <nacc> cjwatson: yep, i'll consider it, as it'll be a good improvement for our use case :)
[00:41] <cjwatson> I think it would be OK to do so; interactively asking for several pages is pretty rare
[00:41] <nacc> yeah
[00:41] <cjwatson> (well, OK, I have no data, but from observation)
[00:41] <nacc> I've only done it on accident :)
[02:47] <KD2JRT> I'm vaguely curious if a 32 elevation path is workable from NYC
[02:48] <KD2JRT> *pass
[02:48] <KD2JRT> er, wrong channel
[06:52] <acheronuk> mitya57: subbed you: https://bugs.launchpad.net/ubuntu/+bug/1721191
[07:32] <NIGGGGGGGGGGGGER> !ops
[11:35] <Son_Goku> it's a weird day when I see @ubuntu.com email address added as a CC to a package I'm reviewing in Fedora...
[11:36] <Son_Goku> also... hi jbicha
[12:03] <slashd> rbasak, good day I don't know if you saw my irc message yesterday (you were on pto I think), and just in case I left the comment (#53) in the bug (LP: #1657256). To summarize, would you be able to perform a 2nd review of percona-xtradb-cluster-5.6 since the last upload had some compilation issues ?
[13:28] <rbasak> slashd: I already said (weeks ago) on IRC that that debdiff is unacceptable for Artful.
[13:28] <rbasak> slashd: I'll dig out the IRC logs.
[13:33] <rbasak> 17:14 <rbasak> ddstreet: sorry, I didn't realise you had a new patch for me there. I don't think forcing use of gcc-6 is a suitable fix for the development release though. I suspect doko wouldn't be happy about that.
[13:34] <ddstreet> slashd niedbalski i believe i passed that info on to you guys...
[13:37] <ddstreet> rbasak sorry, i thought they had addressed that, i'll follow up with them
[14:06] <niedbalski> rbasak, doko what would be the preferred approach then? I wonder if disabling all the introduced warnings is suitable though,.. also a reminder that current vanilla package fails to build from source.
[14:10] <niedbalski> rbasak, saw your comment on the public bug, will follow up from there, thanks for the input.
[14:23] <slashd> rbasak, thanks for the recap, I was in conference and vacation, I might have missed it.
[14:38] <jbicha> Son_Goku: I subscribe to a lot of bugs, I forget which bug you are thinking of
[14:38] <Son_Goku> jbicha: rhbz#1481630
[14:39] <Son_Goku> aww, no bot to turn that into a url
[14:39] <Son_Goku> meh: https://bugzilla.redhat.com/show_bug.cgi?id=1481630
[14:40] <jbicha> that's a very interesting bug since that's related to upstreaming virtualbox drivers to the Linux kernel, and I use virtualbox
[14:44] <Son_Goku> well, I was a bit surprised, since it's not extraordinarily helpful to you (Ubuntu isn't RPM-based, sadly :P )
[14:45] <rbasak> s/sadly/gladly/ :-)
[14:54] <jbicha> Son_Goku: it is helpful. VirtualBox was broken for a few days just before Ubuntu Final Beta because the upstreamed drivers didn't work right (at least in Ubuntu)
[14:55] <Son_Goku> rbasak: I don't think so :)
[14:55] <jbicha> also I occasionally run latest or dev Fedora in VBox as a reference and installing the guest additions there is a pain sometimes
[14:56] <jbicha> Fedora 27 might be affected by the same problem Ubuntu had with Linux 4.13
[15:00] <Son_Goku> jbicha: which was what?
[15:01] <Son_Goku> incidentally, 4.13 has already rolled out to Fedora 26 too
[15:01] <Son_Goku> https://bodhi.fedoraproject.org/updates/FEDORA-2017-c0e81a1c7a
[15:02] <Son_Goku> https://bodhi.fedoraproject.org/updates/FEDORA-2017-6d64333469
[15:02] <Son_Goku> jbicha: are you referring to login screen being busted in VirtualBox?
[15:04] <jbicha> Son_Goku: could be, I haven't used Fedora recently, the Ubuntu bug was LP: #1718679 and we set CONFIG_DRM_VBOXVIDEO=n in the Ubuntu kernel to workaround it
[15:05] <Son_Goku> iirc, I don't think wayland *ever* worked with vbox
[15:05] <jbicha> yes, Fedora agressively pushes new kernels to stable releases
[15:05] <jbicha> it works fine for me
[15:05]  * Son_Goku shrugs
[15:05] <Son_Goku> I don't use vbox so I dunno
[15:06] <jbicha> sometimes I've had a problem with the login screen not refreshing correctly but once logged in, things are good
[15:07] <Son_Goku> jbicha: that's the only issue I've seen people report about vbox in general
[15:23] <nacc> would it be reasonable for `dpkg-source --print-format` to not complain about the format of binary package stanzas? (it's a fatal error)
[15:23] <madigens> hm! how do i get a wayland session in artful? in both virtualbox and on a laptop with some radeon 5xxx igp i can't select it on the login screen
[15:23] <nacc> madigens: #ubuntu+1
[15:25] <madigens> nacc: thanks
[16:19] <ackk> mvo, any chance you could have a look at https://code.launchpad.net/~ack/apt-btrfs-snapshot/fix-arg-parser/+merge/328776 ? should be trivial
[16:33] <mvo> ackk: sure, sorry, that totally escaped my view. looks great, thank you for this
[16:33] <ackk> mvo, np, thanks for looking
[18:38] <sarnold> Unit193: indeed, I'm not here :)
[18:38] <sarnold> Unit193: well, I guess I'm here now, but not here sunday.
[19:01] <Unit193> Heh, I was right, I have no clue what that was about anymore. :D
[19:03] <niedbalski> rbasak, could you please review the latest patch on LP: #1657256? thanks.
[19:08] <sarnold> Unit193: success! :D
[19:39] <juliank> bdmurray: I think https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1721364 is opinion. As I just wrote in the comments, the behavior was explicitly changed so dependencies of meta packages are removed when explicitly removing the meta package and marked as manually when the meta package (dependencies) breaks
[19:46] <juliank> bdmurray: So, it would be great if you could test installing a package that conflicts with ros-desktop and see what that does
[19:53] <bdmurray> juliank: Do you have a suggestion for a conflicting package?
[19:53] <juliank> bdmurray: Use equivs-build to create one conflicting with ros-desktop (for example) and installl that with apt install ./path/to/dummy.deb
[19:56] <juliank> bdmurray: Example on my system with a package conflicting with my jak-machine-master package and installing that vs. removing jak-machine-master explicitly :https://paste.ubuntu.com/25675324/
[19:58] <juliank> We also have the opposite variant of never-mark-auto which moves auto bits on installs to new dependencies (used for oldlibs), I like that.
[20:01] <bdmurray> juliank: The Move-Autobit-Sections? My concern is recommending people use autoremove or enabling that and having a whole mess of packages removed if they did something silly and removed a metapackage.
[20:02] <juliank> bdmurray: Life sucks either way. The current behavior makes most sense from a UI perspective. If we just did the mark as manual bit on all removals, we'd have tons of users complaining that "Hey, I told apt to remove gnome, but all the stuff is still there"
[20:03] <juliank> "My system continuous to grow, apt does not remove packages I tell it to!"
[20:06] <juliank> bdmurray: I don't think that people removing a meta package explicitly is a common situation. If they remove it accidentally, they are covered by the manual bit moving. Maybe we should make it harder and ask people "Removing the following packages allows other packages to be automatically removed, do you want to continue?"
[20:06] <juliank> Or move "The following packages were automatically installed and are no longer required:" to the end and rename it "The following packages were automatically installed and will be removed when running autoremove" or something
[20:08] <juliank> There was generally a question whether removals should be shown last
[20:08] <juliank> currently they are shown at the top, but moving them right before the prompt and coloring them red would probably help a lot (and autoremove stuff yellow)
[20:09] <juliank> For gnome-software and other app store-type applications, the problem with manual bit moving does not really arise, as they likely don't (and really should not) allow meta packages to be removed in the first place.
[20:09] <juliank> Well, at least not enable explicit removals
[20:11] <bdmurray> juliank: Better messaging and fixing https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776790 would be helpful too
[20:15] <jbicha> juliank: you give gnome-software too much credit. Currently it does allow metapackages to be removed with no warning :(
[20:15] <bdmurray> jbicha: is there a bug reported about that?
[20:16] <jbicha> a workaround is to mark metapackage Depends with compulsory_for_desktop in the appstream metadata but we haven't really done that thoroughly yet
[20:17] <juliank> jbicha: Probably should be hidden. They are really an "OS" thing
[20:17] <jbicha> LP: #1546636 sort of mentions the issue
[20:19] <jbicha> juliank: the Remove button is hidden for those compulsory apps. I disagree that we should hide the apps completely from Software
[20:19] <jbicha> you can install addons for some apps, leave reviews, etc.
[20:20] <jbicha> https://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/epiphany-browser/debian/patches/dont-make-compulsory.patch?view=markup
[20:20] <jbicha> ^ is an example (in reverse) of what that appstream tag looks like
[20:21] <juliank> jbicha: I guess we should give gnome-software the ability to always move manual bits then
[20:22] <jbicha> (gnome-software uses packagekit in Ubuntu as of 17.10)
[20:23] <juliank> Well, yes, PackageKit might want to do that in general then, but we need an option for that in APT
[20:57] <rbasak> niedbalski: thanks! Quick glance. 5.6.34-26.19-0ubuntu3 is already taken. Can you prepare a debdiff against the already uploaded 5.6.34-26.19-0ubuntu3 to 5.6.34-26.19-0ubuntu4? I expect that debdiff to include only the FTBFS fix, as I think the other necessary fixes are already present in 5.6.34-26.19-0ubuntu3?
[21:00] <niedbalski> rbasak, ok, doing that.
[21:09] <niedbalski> rbasak, ok, I don't think is going to be possible, I incorporated a small nitpick on the original patch (that prevents a warning), thus the ibuf* patch actually differs from ubuntu3.
[21:15] <rbasak> niedbalski: if you want to update what you did in ubuntu3, that's fine. Just include it in ubuntu4 and bullet point that additional change separately in the changelog.
[21:15] <niedbalski> rbasak, perfect.
[21:15] <rbasak> niedbalski: but ubuntu4's changelog should include things that are already covered in ubuntu3's changelog. Does that make sense?
[21:15] <rbasak> Sorry
[21:16] <rbasak> niedbalski: but ubuntu4's changelog *shouldn't* include things that are already covered in ubuntu3's changelog. Does that make sense?
[21:16] <niedbalski> rbasak, yes, it does.
[22:20] <niedbalski> rbasak, ok, the new patch in top of current proposed is attached to the bug. thank you for looking.
[22:27] <powersj> rbasak: the package to team mapping page shows source packages, correct? Is there a fast way (doing this in python) to say what team owns a binary? e.g. Look up lxd-client and know it is based on lxd  source and therefore the owner is ubuntu-server
[22:28] <nacc> powersj: apt-cache show lxd-client | grep Source
[22:28] <nacc> powersj: if it comes up with an answer that is the Srouce
[22:28] <nacc> otherwise the binary package is the same as the source package
[22:29] <powersj> nacc: thanks!
[22:29] <nacc> powersj: there are probably better ways, but that should always work (maybe | grep ^Source: )
[22:30] <powersj> yeah now I have to decide if there is a faster way to do that in python, rather than running that command O(10k) of times
[22:35] <nacc> powersj: @lru_cache
[22:39] <powersj> nacc: ah right! I've seen rbasak use that in the triage script
[22:39] <powersj> thanks again!
[22:40] <nacc> powersj: np, we use it pretty heavily in the importer code
[22:49] <powersj> nacc: that will only find packages that are in the release I'm running right? e.g. php7.0 won't be found since I'm running artful
[22:49] <nacc> powersj: rmadison can do it (with some help) or use chdist and bin2src
[22:50] <nacc> powersj: (and of course apt-cache assumes your apt cache is up to date)
[22:50] <powersj> right, was playing with python apt module to do all of that, then realized I'm missing a bunch of packages since I'm not on xenial
[22:51] <nacc> ah sure
[22:51] <nacc> so chdist could probably create the right layouts for you
[22:51] <nacc> and maybe python-apt can be told to use different root dirs
[22:54] <nacc> infinity: not urgent, but do you think it would be reasonable for `dpkg --print-format` to not error out when it finds invalid binary package stanzas in d/control?
[23:12] <nacc> infinity: specifically a patch like http://paste.ubuntu.com/25676319/ which results in (IMO) improved behavior as: http://paste.ubuntu.com/25676320/