[08:07] <RikMills> jibel: is a fix for LP: #1885414 likely to land soonish? I got new Plasma into groovy the other day, and some testers are being a bit blocked by that
[08:22] <mantas-baltix> Hi, I need your advice for choosing metapackage creation technology - I'm developing Ubuntu-based distribution for schools and previously used simply repackaged ubuntu-meta as base, see https://bazaar.launchpad.net/~baltix-members/baltix-seeds/baltix-meta-packages/files
[08:26] <mantas-baltix> but this way isn't effective - it seems Debian uses Tasksel-based Blends metapackages, see https://blends.debian.org/blends/apa.html#blends-dev and Ubuntu uses "Seeds"
[08:26] <mantas-baltix> like https://code.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/+git/ubuntustudio
[08:30] <mantas-baltix> I don't know which is better for long-term (at least 4-5 years) , it seems metapackages created with blends-dev depends on tasksel, while Ubuntu "Seeds" don't depend on tasksel and are easier to understand, see for example https://git.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/+git/ubuntustudio/tree/desktop
[08:41] <jibel> RikMills, once https://code.launchpad.net/~mwhudson/ubiquity/+git/ubiquity/+merge/386704 is merged and released
[08:42] <juliank> mantas-baltix: So you've got your own seed like thing already, I'm not sure where full blown seeds would help you? what problem are you trying to solve?
[08:44] <juliank> anyway, seeds might be the way to go
[08:44] <juliank> personally i find germinate overkill for my use cases in metapackage building
[08:45] <mantas-baltix> juliank: my thing is very hard to maintain, because I have separate files for depends and recommends and symlinks for different architectures :(
[08:45] <juliank> I see
[08:45] <juliank> I never implemented Recommends for my metapackage generator
[08:45] <mantas-baltix> juliank: I never used germinate, could you point to some documentation?
[08:46] <juliank> mantas-baltix: e.g. https://wiki.ubuntu.com/Germinate, https://manpages.ubuntu.com/manpages/cosmic/man1/germinate.1.html
[08:47] <juliank> mantas-baltix: germinate is what reads the files, checks them for consistency, and outputs the substvars for debian packages, amongst other things
[08:47] <juliank> (it can also like fully expand the seed, which in turns determines which packages end up in the live images)
[08:56] <mantas-baltix> juliank: it seems Tasksel-based Blends metapackages, see https://blends.debian.org/blends/apa.html#blends-dev does the same but in different way :)
[08:59] <mantas-baltix> cjwatson: hi, it seems you are germinate developer, could you advice me if I should use Tasksel-based Blends for custom ubuntu-based distribution metapackages (see https://blends.debian.org/blends/apa.html#blends-dev) or Germinate and "Seeds" ? ;)
[09:05] <cjwatson> mantas-baltix: False dichotomy.  Seeds are in fact used to generate tasks in Ubuntu as well
[09:06] <cjwatson> So they can be an input to tasksel
[09:06] <cjwatson> mantas-baltix: Anyway, I have no experience with blends so can't advise you
[10:03] <mantas-baltix> cjwatson: thanks, maybe you can tell if there are some plans to use blends in Ubuntu or metapackages will use only seeds in near future?
[10:12] <cjwatson> mantas-baltix: although I maintain the germinate package, I haven't otherwise been involved in that sort of thing in Ubuntu for five years
[10:12] <cjwatson> mantas-baltix: I'm pretty sure there are no plans to use blends.  Otherwise I couldn't tell you
[10:47] <rbalint> kanashiro, doko happy +1 day, what are you working on and what is free to grab on update-excuses?
[10:56] <rbalint> i'm going through the small stuck sets then will pick a big transition, so suggestions will be welcome
[11:02] <doko> rbalint, kanashiro: working mostly from the bottom up on ftbfs
[11:16] <rbalint> doko, kanashiro i'm finishing the small orcania transition
[11:32] <AsciiWolf> kenvandine, hi, I am not sure if you are the one who is working on this bug or Robert is: https://bugs.launchpad.net/snap-store-desktop/+bug/1873040 - anyway, please let me know if there is anything I could do (test, debug, provide additional info etc.) to help getting this annoying bug fixed... :)
[11:32] <AsciiWolf> some regular users that I recommended Ubuntu 20.04 to were already asking me how to install non-snap apps because they did not realize that the empty space is actually clickable :/
[12:04] <ahasenack> good morning
[12:16] <kanashiro> rbalint: doko I intend to finish my work on all ruby packages in proposed today. If I have time I'd like to start to work on some prometheus deps (golang packages)
[12:16] <kanashiro> I'll keep you posted about the status here
[12:19] <kanashiro> haskell packages need some love, hopefully I'll find some time until tomorrow to work on some of them
[12:39] <mantas-baltix> AsciiWolf: hi, could you confirm if Snap Store launcher isn't translated in any language, see gug #1882929
[12:39] <mantas-baltix> AsciiWolf: bug #1882929
[12:46] <AsciiWolf> mantas-baltix, hmm, to be honest, I am not aware of this issue... I can't speak for other translations, but in our Czech translation, the "Ubuntu Software" and "Snap Store" strings are intentionally left in the original, untranslated, form :)
[13:11] <kanashiro> mwhudson: as you should have noticed your golang-github-miekg-dns PR was accepted upstream, if you want I can prepare an upload with the patch. Please let me know
[13:14] <ahasenack> go for it? He will only be online at our EOD
[13:17] <kanashiro> I can but I also have other stuff to do, idk if he wants to handle this by himself
[13:18] <mitya57> LocutusOfBorg: I filed Debian #964141 now, let's see what the glibc maintainers think about it.
[13:18] <kanashiro> it's in my TODO list anyway
[13:22] <LocutusOfBorg> thanks!!!
[16:38] <realtime-neil> Is there a way to `apt --reinstall install` a package without re-downloading it? `--no-download` doesn't work.
[17:56] <sarnold> popey: hmm -- I'm trying to use the matterhorn 'view' thing to view attachments and getting unexpected DENIED messages -- this worked yesterday? http://paste.ubuntu.com/p/NDfcbdJT6z/plain/
[17:57] <sarnold> realtime-neil: if the package actually does exist in /var/cache/apt/archives, that sounds like a bug
[17:58] <realtime-neil> sarnold, that sounds accurate
[18:29] <xnox> realtime-neil:  are you sure it's the same? and has the same checksum/metadata etc?
[18:29] <xnox> realtime-neil:  you can do $ sudo apt install --reinstall ./packages_*.deb
[18:30] <xnox> with absolute path to the .deb, or like with './' prefix.
[18:42] <realtime-neil> xnox, the problem I'm having is that, after the initial installation there is a process beyond my control that deletes the Debian archive from the apt cache.
[18:43] <realtime-neil> Some nice folks in #debian have led me to believe that, once the archive is gone, it's impossible to reinstall without downloading again
[18:47] <cjwatson> realtime-neil: that belief is correct
[18:48] <cjwatson> It's not uncommon for things to run 'apt clean' or 'apt autoclean' or similar automatically on the basis that there's a very small amount of point in leaving large files around on the off-chance somebody might want to reinstall from them
[18:49] <cjwatson> But if the files in question are still in the cache then IIRC they shouldn't be redownloaded
[18:51] <realtime-neil> cjwatson, makes sense; my particular context is in the ubuntu installer --- after `pkgsel/include` does its thing, my package is very slightly broken. A reinstall fixes it, but by the time the `preseed/late_command` fires, the installer has already cleaned the cache.
[18:52] <realtime-neil> cjwatson, you wouldn't happen to be this author, would you? https://wiki.ubuntu.com/Installer/Development
[18:52] <cjwatson> Yes but I haven't worked on the installer for years
[18:52] <cjwatson> So not likely to be much use to you now
[18:53] <realtime-neil> If you remember anything about the patching debian-installer and/or the build process, I'd appreciate any words you can offer.
[18:53] <cjwatson> I don't recall where there might be a clean call, but it should be visible somewhere ...
[18:53] <cjwatson> This is a bit of a vague problem for me to page in memory of at 8pm I'm afraid
[18:54] <cjwatson> Maybe tomorrow if you have more details and logs
[18:55] <realtime-neil> I can accept the double download ... my overarching issue is that I don't know how to build the ubuntu installer
[18:55] <realtime-neil> Or, really, how it differs from d-i
[19:07] <xnox> realtime-neil:  there is a newish apt option to retain downloaded .debs and not delete them.
[19:07] <xnox> realtime-neil: you can use that
[19:07] <xnox> rafaeldtinoco:  when you say "ubuntu installer" => it is ambigious, as we have many.
[19:08] <xnox> rafaeldtinoco:  unping
[19:08]  * rafaeldtinoco hides
[19:08] <xnox> realtime-neil:  and most of them use combination of preinstalled squashfs + pool of debs. With base system bootstraped, and no debs for those available during the install.
[19:08] <xnox> realtime-neil:  which package are you trying to reinstall?
[19:09] <xnox> realtime-neil:  i want to put a banner "obsolete" on https://wiki.ubuntu.com/Installer/Development
[19:11] <tumbleweed> realtime-neil: you say "your package is very slightly broken" - best option is probably to fix it
[19:14] <realtime-neil> xnox, I'm asking specifically about the d-i installer ... the one I can use to make installation media
[19:14] <realtime-neil> well, I guess all of them can do that, but I'm interested in USB sticks to start
[19:15] <realtime-neil> xnox, yeah, that page seems a little dated
[19:15] <realtime-neil> tumbleweed, yes, I'm still trying to figure out how to fix a project that is broken when installed without grub
[19:16] <sarnold> popey: oh. It was snap autorefresh :(
[19:26] <kanashiro> I have been facing a ruby-http autopkgtest failure in s390x which seems that the testbed is broken, however, I re-triggered it a couple of times and it is still failing. Could someone give me any tip on how to fix this? https://autopkgtest.ubuntu.com/packages/ruby-http/groovy/s390x
[19:27] <kanashiro> it is passing in the other architectures
[19:42] <realtime-neil> kanashiro, I must know: where did you get that s390x system?
[19:45] <kanashiro> realtime-neil: it is the Ubuntu autopkgtest infrastructure. The failure does not represent a real issue in s390x, it should be something related to the testbed setup I think
[20:22] <cjwatson> realtime-neil: (I will defer to xnox who has spent a lot more time with the installer lately than I have)
[20:23] <realtime-neil> cjwatson, 10-4; xnox is there any documentation you can point me at?
[20:49] <xnox> realtime-neil:  i don't know what you are trying to do.
[20:49] <xnox> so it's hard to help =)
[20:49] <xnox> realtime-neil:  what is you project, and goal?
[20:51] <realtime-neil> xnox, I want to remaster Ubuntu installers and make custom images for netinst and hd-media
[20:52] <realtime-neil> debian has this https://wiki.debian.org/DebianInstaller/Build ... I'm wondering if Ubuntu has something similar
[20:52] <xnox> realtime-neil:  which architectures are you planning to install on to? is it VMs or bare-metal? why remaster -> what do you want to include in them, and from where?
[20:53] <xnox> is it going to be deployed with or without network access?
[20:54] <xnox> realtime-neil:  note that vast majority of installations today do not use d-i, but use ubiquity-desktop isos, subiquity live-server isos, or the cloud-images that are booted in place, and self-customize on first boot => but also all of those can be booted over the network & locally.
[20:54] <realtime-neil> arches: amd64 certainly, maybe armv7 in the distant future; UEFI firmware platforms, both virtualized and metal; remastered because I want to add packages gotten from private repositories; netinst images require network, but hd-media should avoid network
[20:55] <xnox> realtime-neil:  and our .iso by default support airgapped deployment. I.e. without internet access.
[20:55] <xnox> realtime-neil:  ack. sounds reasonable.
[20:55] <realtime-neil> excellent
[20:55] <xnox> armv7 has no boot protocol however => and we do not provide media for it, only preinstalled images for select targets
[20:56] <realtime-neil> that's fine, i figured as much -- I'm not going to hold my breath waiting for UEFI on arm-anything
[20:57] <xnox> realtime-neil:  if i were you, i'd prepare an offline pool of debs, write it as append track to existing .iso, and then boot it with extra paramemeters on the cmdline to enable that additional repository.
[20:57] <xnox> realtime-neil:  we have multiple public clouds, server grade hardware and iot devices with ARM and UEFI.
[20:58] <xnox> realtime-neil:  i.e. packet cloud, AWS Graviton instances, pi4 with uefi firmware flashed, etc.
[20:58] <xnox> all enabled for ubuntu
[20:58] <realtime-neil> xnox, I'll take that advice. Just for the sake of argument, how would I create images (including isos) from source?
[20:58] <xnox> realtime-neil:  we build images from binaries, from debs.
[20:58] <realtime-neil> xnox, granted, I'm talking about the initramfs contents that drive the installation
[20:59] <xnox> realtime-neil:  the d-i artefacts, one can rebuild, with $ pull-lp-source debian-installer focal; sbuild -A -d focal ./debian-installer*.dsc
[20:59] <xnox> is how the initrd, inside the /installer-*/ directories are built.
[20:59] <xnox> realtime-neil:  it would produce the same layout, in a tarball.
[20:59] <xnox> realtime-neil:  why do you need to modify the initrd?
[21:00] <xnox> realtime-neil:  one can enable, extra local, repositories, keys, and install .udebs or .debs, from it, _without_ changing the initrd.
[21:00] <realtime-neil> just in case I have to track down some dirty module
[21:00] <xnox> realtime-neil:  i cannot help, if you don't tell me what you want to do. and things i say, may be misused, as you are not sharing context.
[21:01] <realtime-neil> ah, okay, understood; I'll leave the initrd alone.
[21:01] <xnox> realtime-neil:  the initrd itself, has very little things. most things are installed from udebs dynamically after the initrd has found a way to fetch udebs (from internet or from local locations)
[21:01] <xnox> realtime-neil:  and inside debian-installer there is LOCAL_UDEBS, and config files, if you must replace things in the initrd. But it's unlikely that you do.
[21:02] <xnox> having custom pool, and enough apt-source/* things specified via backed-in preseed on the cmdline should be enough to force the installer to always use your extra pool, for things.
[21:02] <xnox> (both udebs during d-i, and debs for in-target)
[21:03] <xnox> realtime-neil:  note, you don't need to rebuild initrd to append preseed to it, as initrds are appendable.
[21:03] <realtime-neil> understood ... this all great stuff ... is there no documentation for this?
[21:04] <xnox> realtime-neil:  do not modify shim, grub, kernel, kernel modules => if you want to boot with secureboot on UEFI firmware. If you don't care about secureboot, anything goes.
[21:04] <xnox> realtime-neil:  we have removed documentation, as focal is the last release that ships with d-i.
[21:04] <xnox> realtime-neil:  and the server guide is updated, on how to netboot the new installer, or boot in place, and it is mostly driven by cloud-init to customize on first boot.
[21:05] <realtime-neil> xnox, ouch. so the successor is documented in the server guide?
[21:05] <xnox> with a simply yaml autoinstall preseeds, that allow to declaratively install servers.
[21:05] <xnox> and there is any cloud-init to e.g. enable local/custom, or remote repositories, install things from there.
[21:06] <xnox> realtime-neil:  the nice thing about the new installer, is that it is just a cloud-image repacked as netbootable or local .iso. And everything is build from debs, without any .udebs
[21:06] <xnox> realtime-neil:  meaning it's a live server environment with regular cloud-init / apt / ssh all working, during live-session, and post install.
[21:07] <realtime-neil> xnox, where can I learn everything about this new mechanism? Which releases does it support?
[21:07] <xnox> realtime-neil:  https://ubuntu.com/server/docs see installation in the overview, and the detailed installer sections.
[21:07] <xnox> realtime-neil:  bionic and focal, that is 18.04 and 20.04
[21:08] <realtime-neil> I picked the wrong release to start with a d-i preseed :D
[21:08] <xnox> realtime-neil:  which one did you pick?
[21:08] <realtime-neil> I've been following the debian d-i documentation and trying to adapt it to bionic
[21:09] <realtime-neil> This may have been a colossal waste of time.
[21:09] <xnox> realtime-neil:  less than 5% of ubuntu installs use d-i. The vast majority use preinstalled ubuntu server images, that are booted in place (or like initrd+kernel booted over the network, to them do remote root to again boot in place) and self customize on first boot with cloud-init.
[21:10] <xnox> why customize installer, install, and reboot. When one can use stock images to boot, straight away, and apply necessory customization on first boot.
[21:10] <xnox> and like for IoT stuff, mostly people use Ubuntu Core to use one of the hundreds existing models, to add custom snaps, and boom you have your product enabled on any armhf/IoT boards.
[21:11] <realtime-neil> A. Because I was completely ignorant of this. Better late than never, I guess.
[21:11] <xnox> including private/custom/propietary snaps.
[21:11] <xnox> like all of the ROS things are build on top of snaps with Ubuntu Core without any installers at all.
[21:12] <xnox> realtime-neil:  debian, doesn't build as many custom, target/platform specific, presintalled images as we do.
[21:12] <realtime-neil> Don't the snaps use containers or something?
[21:12] <xnox> realtime-neil:  no
[21:12] <xnox> realtime-neil:  the run on bare-metal....
[21:13] <xnox> they use a lot of kernel features to do so securely, with strict upgrade / isolation, but there are no hypervisors/docker/k8s or similar invovled.
[21:13] <xnox> i.e. they use AppArmor, seccomp filters, firewalls, signature checking, etc.
[21:13] <realtime-neil> in my limited experience, playing with dkms modules inside of that kind of isolation doesn't work very well.
[21:14] <xnox> Ubuntu Core has kernel as a snap. Why do dkms builds on target, when you can prebuild a kernel snap, with all the dkms modules you want once, and just deploy it.
[21:15] <xnox> i.e. ubuntu-image can be trivally be used to rebuild any ubuntu-core image, with a tweaked kernel snap.
[21:15] <realtime-neil> You make have just sold me on this.
[21:15] <realtime-neil> You may have just sold me on this.
[21:15] <xnox> and one can even skip rebuilding kernel snap from scratch and append a kernel module to it.
[21:15] <xnox> realtime-neil:  maybe you should join #snappy channel and like talk to ogra who build a lot of custom things.
[21:16] <xnox> realtime-neil:  for ROS, robots / kioks / smart screens, etc.
[21:16] <realtime-neil> Just when I thought I was getting good with dpkg-buildpackage, everything changes. XD
[21:18] <xnox> realtime-neil:  https://snapcraft.io/ https://snapcraft.io/docs https://forum.snapcraft.io/
[21:20] <xnox> realtime-neil: ultimately, if one is building a product, one wants to be able to have reproducible images, that are easy to build, have stock components reused (i.e. core, snaps, gadget to boot the thing, etc) have extra stuff on top (i.e. a snap, that reuses ROS snapcraft plugin, and adds one more thing), and be able to quickly build images for any model, and deploy them in a reproducible manner.
[21:20] <xnox> with quick, boot in place, self-configure / initialize.
[21:21] <xnox> and snapcraft / ubuntu-image tooling deliver all of that. such that one can focus just on customization, whilst reusing "common" platform for the rest. (pick & mix)
[21:21] <xnox> or like derive from it, by staging existing component, and patching it as needed.
[21:22] <realtime-neil> I'm coming from a hard-core Debian packaging assumption --- control files, maintscripts, etc. --- what kind of learning curve can I expect with this new methodology? How many weeks until I'm good enough to be dangerous?
[21:36] <xnox> realtime-neil:  there are shit tone of examples, which are simplier to modify or write your own.
[21:37] <xnox> realtime-neil:  unlike debian packaging, it's mostly just a single snapcraft.yaml file per component you try to modify. Possibly gadget.yaml and a model. So learn a 4 files, and build them. and at that point one is dangerous.
[21:38] <realtime-neil> xnox, this is going to change everything; thanks very much.
[21:38] <xnox> realtime-neil:  i think we have a lot of recorded snapcraft webinars pre-recorded, and tutotrials / docs. I think people manage to build a custom ROS image, as a workshop in less than 5h as a tutorial / classroom thing?
[21:38] <xnox> realtime-neil:  maybe Wimpress has some links for you. Cause we ran contests for those sort of things too.
[21:38] <xnox> as fun/hack events
[21:40] <xnox> realtime-neil:  https://snapcraft.io/blog/your-first-robot-a-beginners-guide-to-ros-and-ubuntu-core-1-5 ?
[21:40] <xnox> there is alot on https://ubuntu.com/robotics
[21:40] <realtime-neil> xnox, I'm noticing a tangible emphasis on ROS --- do you work with robots?
[21:52] <xnox> it seems popular.
[21:52] <xnox> but there are other things too, non-robotic.
[21:52] <xnox> realtime-neil:  https://ubuntu.com/appliance
[21:53] <xnox> it's more about having purpose build things, on top of a common reliable core, that is trivially deployable to a variety of architecutres/forfacotrs.
[21:53] <xnox> cause "what" "where" and "how" are all separated.
[21:54] <xnox> realtime-neil:  for example, vendors often provide kernel snaps and gadgets, for others to build images with their "appplication snap" to deploy something.
[21:54] <xnox> ROS mostly provides plugins/frameworks/parts which others embed inside their application snaps (aka middlewear/drivers/etc)
[21:55] <xnox> realtime-neil:  i mostly build base snaps, which everyone bases their rootfs on. The 50-odd MB that everything operates on.
[22:14] <ogra> realtime-neil, this is pretty old and very arm centric but should give you an idea https://ograblog.wordpress.com/2019/01/07/291/ ...
[22:15] <ogra> (there are newer tutorials for each of the bits on snapcraft.i👋docs somewhere, but i'm not sure there is one document that summarizes the single bits like this post)
[22:16] <ogra> *geez ... that emoji plugin ...*
[22:16] <ogra> the docs category on snapcraft io
[22:16] <realtime-neil> ogra, nice, thanks!
[22:17] <ogra> and regarding ROS you probably want to talk to kyrofa 🙂
[22:39] <mwhudson> kanashiro: happy for you to upload it, i'll do it in my +1 shift on monday if you don't get to it!
[22:40] <kanashiro> mwhudson: good, I can do it tomorrow :)
[22:40] <mwhudson> ugh why are libraries on arm64 built with ie tls-model?
[22:42] <mwhudson> oh they're not but the surplus tls space gets used for gd libraries
[22:42] <mwhudson> that seems bonkers