[10:07] <Wimpress> xnox: Do you have a few minutes to help me understand what my expectation for blacklisting package in seeds should be?
[10:07] <Wimpress> The context is this.
[10:08] <Wimpress> I would like to seed gnome-mpv. It has a Recommends: youtube-dl
[10:08] <Wimpress> youtube-dl has deep requirements that end up in libqt5* getting pulled in.
[10:09] <Wimpress> Is blacklisting a means by which I can prevent youtube-dl from getting on the Ubuntu MATE iso image?
[10:10] <cjwatson> I can answer that: no.  Blacklisting in seeds doesn't affect what apt does
[10:10] <cjwatson> See "man germinate" where I discuss this a bit
[10:11] <cjwatson> "The purpose of a blacklist is to make it obvious when a package that is not supposed to be installed ends up in germinate's output, so that package relationships can be fixed to stop that happening.  It is not intended for the purpose of working around buggy package relationships, and attempts to do so will not work because apt has no way to know about blacklist entries in seeds."
[10:12] <cjwatson> To avoid that Recommends taking effect, you would need to put gnome-mpv in a seed that has the follow-recommends feature disabled, *and* you would need to ensure that anything that installs the corresponding task/metapackage/whatever does so in a way that tells apt not to follow recommends
[10:12] <cjwatson> The latter requirement is impractical in most cases, so this entire approach is IMO probably impractical
[10:14] <cjwatson> The only way to do this kind of thing is usually to adjust the package relationships themselves
[10:15] <Wimpress> cjwatson: That is a brilliant suggestion about using an alternate seed!
[10:15] <Wimpress> Thank you :-)
[10:16] <Wimpress> Oh, I do want to follow-recommends in the desktop seed however.
[10:16] <Wimpress> So, as you say, probably not a solution.
[10:17] <cjwatson> Right, people have tried this in the past and it has nearly always turned out to be painful or unworkable in practice.
[10:17] <Wimpress> I have talked to the Debian package maintainer. They are not interested in change the youtube-dl Recommends: to a Suggests:
[10:19] <cjwatson> I wonder if changing youtube-dl's recommendation of mpv | mplayer to also include gnome-mpv would help?
[10:20] <Wimpress> Is the the phantomjs Depends that is the issue.
[10:20] <Wimpress> It has requirements for libqt5*
[10:20] <cjwatson> Installing mpv on its own also pulls in libqt5*
[10:20] <Wimpress> Yes
[10:20] <cjwatson> So it may be both
[10:21] <Unit193> The problem lies mostly in apt, as it would be pretty simple (though overkill in most cases) to create another seed in the structure for not following recommends.  His problem mostly likes in phantomjs, I'd imagine.
[10:21] <Wimpress> Because youtube-dl is a Recommends of mpv also.
[10:21] <cjwatson> Oh right
[10:21] <cjwatson> Can youtube-dl's Recommends on phantomjs be reduced to a Suggests?  (I don't know this package at all)
[10:21] <Wimpress> cjwatson: From the research I did, no.
[10:22] <cjwatson> Unit193: Fairly simple in seed terms but in practice prohibitively complex in the rest of the system, indeed.
[10:22] <Wimpress> It will break the ability for youtube-dl to work with many of the sites it supports.
[10:22] <cjwatson> Sounds like you may be out of luck ...
[10:22] <Wimpress> Yes, sadly I think you are right.
[10:22] <Unit193> Based on how quickly youtube-dl has releases, we should not create a long-term delta.  As far as how youtube-dl is useful without that?  I use it all the time and do not have phantomjs.
[10:23] <Wimpress> youtube-dl is not a hard requirement for gnome-mpv, which is why I was hoping it could be changed to Suggests.
[10:23] <Wimpress> But the maintainers don't want to introduce inconsistent behaviour between mpv and gnome-mpv.
[10:24] <cjwatson> Maybe both mpv and gnome-mpv could be changed then?
[10:25] <Unit193> So: out of the 1K+ sites, it looks like only one or two uses phantomjs, that looks just fine to move it to suggests.
[10:25] <Wimpress> Interesting.
[10:26] <Wimpress> So, perhaps I change tack a discuss changing phantomjs to a Suggest in youtube-dl with its maintainer.
[10:26] <Unit193> Note: That's only a quick grep of `grep -Ri phantom` and checking to see if that looks right.
[10:26] <Wimpress> Upstream youtube-dl are considering using chromium-headless instead of phantomjs.
[10:28] <Unit193> In fact, I would appreciate the drop of phantom to suggests too. :P
[14:52] <ahasenack> hi, I found an old piece of delta in an ubuntu package (backuppc, https://pastebin.ubuntu.com/p/cGNsW7BqJs/), which says it's implementing this old spec: https://wiki.ubuntu.com/Teardown
[14:52] <ahasenack> does this still apply in our systemd world?
[14:54] <ahasenack> there is no systemd service file provided in this package
[15:50] <alkisg> xnox: hi, I just read https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040726.html "In all other places, our performance profile is in favor of lz4."
[15:50] <alkisg> ...and I wanted to add "netbooting" into consideration; loading a kernel/initrd via tftp might need 10 secs; so lz4 would add 1.4 secs to boot time; dunno if it would save some from the decompression time
[15:50] <alkisg> I'm not saying it's important, I just thought to mention that loading the kernel/image via tftp (instead of disk) is one of the affected use cases...
[15:51] <xnox> alkisg:  tftp, not http?
[15:51] <xnox> *sigh*
[15:52]  * xnox should start making public notes about thigns people told me.
[15:52] <alkisg> xnox: yes normally in netbooting tftp is used; some people can "afford" a web server and use both tftp for ipxe and http for kernel/initrd
[15:54] <alkisg> Sorry I wasn't on that list, to properly reply, and I thought "better do a quick ping, even if it gets lost, than be silent". /me shrugs
[15:59] <xnox> alkisg:  this is fine, and very welcomed.
[16:14] <alkisg> ty :)
[16:23] <tmhoang> how does Ubuntu detect available tty ? In terms of code.
[16:24] <xnox> tmhoang:  we run systemd generators for gettys and serial consoles.
[16:24] <tmhoang> xnox: thanks, so systemd takes care of discovery
[16:25] <tmhoang> I think this thing happens somewhere during initramfs phase. Checking ...
[16:26] <xnox> tmhoang:  initramfs is different....
[16:26] <xnox> tmhoang:  we read console= arg and magic
[16:26] <xnox> tmhoang:  d-i is different again
[16:26] <xnox> tmhoang:  core is different too... but only slightly.
[16:28] <tmhoang> xnox: well systemd is your /init. if tty discovery happens in system, it happens in initramfs, correct ?
[16:28] <xnox> tmhoang:  no......
[16:28] <xnox> tmhoang:  we don't use systemd in the initramfs, we use a different init there, and later exec systemd to replace pid1 with it......
[16:29] <tmhoang> hah interesting
[16:29] <xnox> tmhoang:  and systemd does rediscovery again and can setup more consoles. E.g. initramfs may, or may not load/use serial consoles, but systemd will generate units for them.
[16:30] <tmhoang> understood. I just assumed systemd is /init. cool
[23:44] <kyrofa> Hey, anyone around who knows more than I do about mokmanager?