[05:38] <cpaelzer> hi, question around the context of auto-sync. If we have a package as a sync but need a rebuild - yet want to keep it being a sync we could make the current "29.0-1" a no change rebuild like "29.0-1build1"
[05:39] <cpaelzer> that would do the trick, but what happens if Debian (unlikely but possible) decides to do "29.0-1build1" themselve or soemthing in between the two versions ?
[05:39] <cpaelzer> I wonder if there is a better version avoiding this problem yet keeping it as a auto-sync package
[06:21] <wgrant> cpaelzer: That's the right way to do it. A version like that isn't compliant with Debian's archive policies (they have binNMUs which usually use a suffix of "+b1"), so I don't think a collision has ever occurred.
[06:30] <cpaelzer> thanks
[09:42] <cjwatson> And any other scheme you might invent would have exactly the same kind of possible collision problem anyway.l
[09:43] <cjwatson> So might as well stick with the known one.
[10:01] <xnox> vorlon:  hm, about mountfail hooks vs local-block. When ben hutchings and I, introduced local-block it was meant to replace all the mountfail hooks. Because we realized that a single pass of failure hooks is insufficient.
[10:01] <xnox> and if any one of the failure hooks "progresses things" (i.e. mounts something degraded) then all the hooks need to be rerun to retrigger udev events, and retry mounting stuff.
[10:02] <xnox> at the moment, at least in lvm2, I see that we have "udev triggered mounting", "broken mountfail hook", "local-block lvm2" hooks. Which seems redundant, and not working correctly.
[10:05] <xnox> I do like "local-block" as it does things similar to how e.g. systemd-shutdown works - iterrate all the things, if anything makes progress
[10:10] <xnox> vorlon:  i also don't quite understand how wait-for-root works, given that it doesn't allow for cryptsetup to kick in and ask for passphrase after raid was assembled, but before lvm2 is scanned.
[10:10] <xnox> which local-block loop does correctly.
[10:11] <xnox> thus the comment that "local-block" should never be reached in the initramfs-tools cannot be true.
[10:16] <xnox> vorlon:  i.e. I think we should stop using failure-hooks, and use local-block instead.
[10:55] <guidocalvano> hey, I've been playing around with the ui shell and want to try and make workspaces savable to better fit my workflow
[11:00] <guidocalvano> in order to do this I would like to store which files I have open with say a code editor or some graphical application
[11:14] <guidocalvano> i.e. save workspace goes through the list of applications on the workspace, then creates files, that then allow to reopen all the applications including the files/urls they had open
[11:15] <guidocalvano> and load workspace creates a new workspace, and starts the applications with the files urls they had open when saved
[11:15] <guidocalvano> I was thinking of using criu for this
[11:20] <guidocalvano> but when I have a browser open or a text editor it can remember its own open files as well
[11:20] <guidocalvano> so I was wondering how it does this
[11:20] <guidocalvano> where does it store what files it has open?
[11:24] <guidocalvano> and can I somehow create separate contexts the same application?
[14:16] <cpaelzer> paride: from your +1 duty is anyone on libfile-desktopentry-perl ?
[14:16] <cpaelzer> that shows up in component mismatches like a tree (many subdependencies)
[14:28] <paride> cpaelzer, not afaik. I am currently trying to sort out the regression preventing mysql-8.0 from migrating
[14:29] <paride> cpaelzer, as you mention a tree, is there anything better than https://people.canonical.com/~ubuntu-archive/component-mismatches.txt to look at component mismatches?
[14:49]  * paride saw the SVGs
[16:16] <sarnold> xnox: am just frustrated that my old habits of eg dpkg -S `which foo` are useless now :(
[16:17] <sarnold> xnox: doubly so since I never understood what problem is being solved by adding symlinks
[16:19] <gpiccoli> vorlon, xnox - can I ask your opinion on LP #1879980 ?
[16:20] <gpiccoli> I found various duplicate issues from the last 8 years or so about the same problem..it's a long-term issue
[16:20] <gpiccoli> I have an user that tested my proposed solution on Bionic with success
[16:21] <xnox> sarnold:  i wonder if we can fix -S to try both ways
[16:22] <sarnold> xnox: ooh ooh apt-file too please :)
[16:24] <xnox> sarnold:  what is apt-file?
[16:25] <sarnold> xnox: it's a simple wrapper around the contents files from the archives, eg you can find all packages that ship an apparmor profile via apt-file search /etc/apparmor.d  https://paste.ubuntu.com/p/D5pcTCMzjk/
[17:05] <xnox> sarnold:  ack
[18:13] <Eickmeyer> xnox: Were you ever able to find that gfxboot code for Ubuntu Studio?
[18:20] <xnox> nope, the thing i thought it was, was not it
[18:21] <xnox> vorlon:  what shall we do about gfxboot-theme-ubuntu? remove our attempts and publish back the binary that was there?
[18:30] <RikMills> Eickmeyer: the .pcx and .pngs in this? https://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/files/head:/data/groovy
[18:33] <RikMills> xnox: I assume that is what is used in production/iso builds? ^
[18:36] <Eickmeyer> RikMills: Yeah, that's the one. *cringes at the oldness*
[18:40] <Eickmeyer> 12 years old, goes back to first release of Studio (gutsy).
[18:42] <RikMills> "This branch is an import of the Bazaar branch at https://people.canonical.com/~cjwatson/bzr/debian-cd/ubuntu"
[18:43] <RikMills> o_O
[18:44] <Eickmeyer> Woooow.
[18:45] <RikMills> but looks like you can propose merges against the LP one all the same. odd
[18:46] <Eickmeyer> Yeah. I'll probably just do that.
[18:46] <RikMills> cjwatson: is that the correct route to get changes into the ISO build there?
[18:47] <RikMills> Eickmeyer: wow. your logo is retro!
[18:50] <Eickmeyer> RikMills: That's what I've been saying! lol
[18:57] <Eickmeyer> RikMills: I showed my son and he said, "Ok, that is SO bad!" LOL!
[19:13] <vorlon> xnox: so you're saying gfxboot-theme-ubuntu is still broken, even with your non-empty font?
[20:28] <xnox> vorlon:  yeap
[20:28] <vorlon> xnox: reference?
[20:29] <xnox> vorlon:  i booted pending ubuntu-live-server iso in bios mode, hit ESC, and the gfxboot menu had no readable labels on any buttons (as per screenshots from the bug report)
[20:30] <xnox> RikMills:  Eickmeyer: oooooh that could be it.
[20:30] <xnox> RikMills:  Eickmeyer: no idea how that is copied in, or when. But yeah, you can make merge proposals.
[20:30] <vorlon> xnox: which bug report?  I didn't see a bug link in scrollback
[20:30] <Eickmeyer> xnox: MP is done, awaiting merge.
[20:32] <xnox> vorlon:  https://bugs.launchpad.net/ubuntu/+source/lubuntu-artwork/+bug/1880394 https://photos.google.com/share/AF1QipOalqGwK-nonwRFp9T3VwQ2V1Yji3SpVAENeMjixTWb-CTCbo6gQ8jqeesaAOQoiA?key=eDMzTF9RTXpXY21CSkFpZmVFZEpsd1NMX3dXM2dB
[20:32] <xnox> vorlon:  i see the same, but with ubuntu logo
[21:13] <cjwatson> RikMills: err, tbh it's been five years and I've basically forgotten.  IIRC the release team follows https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup
[21:13] <cjwatson> I think it's committed on nusakan and then there's a mirror that goes via my home directory.  It should really be turned into proper LP-hosted branches
[21:14] <cjwatson> But all this stuff is super-old, it predates bzr even existing never mind LP code hosting
[21:14] <cjwatson> I would very much support a current cdimage person sorting it out
[21:19] <xnox> RikMills:  Eickmeyer: do make a launchpad merge proposal against lp:~ubuntu-cdimage/debain-cd/ubuntu on launchpad and it will be sorted
[22:09] <sarnold> hello :) how does this directory have only .deb packages and no tarballs, no dsc files, etc? http://archive.ubuntu.com/ubuntu/pool/universe/u/uucp/
[22:10] <tumbleweed> the source is in main
[22:10] <sarnold> ahhh
[22:10] <sarnold> http://archive.ubuntu.com/ubuntu/pool/main/u/uucp/
[22:10] <sarnold> I was just getting to that. funny. I never expected uucp to have main sources so I didn't look there until after asking on irc..
[22:11] <tumbleweed> it's there for "cu"
[22:12] <sarnold> tumbleweed: cool, thanks
[22:51] <mwhudson> bryce: are php-horde packages reappearing in groovy something we want or an accident?
[22:59] <bryce> mwhudson, the intention was for them to go away for good; what's causing them to reappear?
[23:07] <mwhudson> bryce: they are being synced from debian i assume
[23:08] <mwhudson> e.g. https://launchpad.net/ubuntu/+source/php-horde-argv/2.1.0-5
[23:09] <mwhudson> i guess if they are being maintained in debian again we might be happy to have them back
[23:09] <bryce> https://bugs.launchpad.net/ubuntu/+source/php-horde/+bug/1868281
[23:15] <bryce> mwhudson, hmm, last I checked the stack had been abandoned in Debian.  Even if it's been re-adopted, it comprises over a hundred packages that pop up stuck in proposed migration frequently.
[23:15] <mwhudson> bryce: seems a bunch of them got uploaded again about a week ago
[23:16] <mwhudson> bryce: so we should work them back into release or delete them again and blacklist them so they stop syncing
[23:16] <bryce> mwhudson, delete and blacklist.  Intent was to blacklist them, although looking at the bug I guess maybe this wasn't done last cycle
[23:18] <mwhudson> bryce: want to file a bug for that and subscribe ~ubuntu-archive then?
[23:22] <bryce> mwhudson, can do
[23:22] <mwhudson> bryce: thanks
[23:22] <bryce> I'm recovering from an X crash I just had a bit ago, will do so post-reboot
[23:24] <bryce> (aka with a 6-monitor layout, vtswitching is an adventure)