[03:20] <Obscenity> after 3 failed installs on 3 different isos, i have to question the integrity of subiquity
[03:20] <Obscenity> is there a boot flag to use the old debian installer instead
[04:04] <tomreyn> Obscenity: did you both verify the iso checksums, and the data written to the installer media? which images did you use? what failed exactly?
[04:05] <Obscenity> well i tried the jammy daily first, then the jammy beta, and then the old 21.10 stable
[04:05] <Obscenity> it faled duing the entering of my username when asked
[04:10] <tomreyn> failed how? and you didn't answer the first question
[04:36] <Obscenity> no, i cantm and it has a popup that the installer failed, and i can send a report to canonical, which i did each time too
[04:39] <tomreyn> well, verify the checksums for downloaded iso and installer image writtern and see whether this helps.
[04:40] <Obscenity> i cant
[04:40] <Obscenity> i do have an idea of what to change though, so ill try that
[04:47] <tomreyn> if you'll be looking for support with this later, be sure to explain "i can't".
[04:48] <Obscenity> yeah i got it
[04:48] <Obscenity> subiquity crashes if i enter a mirror, then enter the user information screen
[04:48] <Obscenity> so no mirror
[04:49] <Obscenity> and i cant because the image is stored remotely on a VM Host
[04:49] <Obscenity> thats why, hah
[04:49] <Obscenity> it gives me a UUID that is not in valid UUID format
[04:49] <Obscenity> thats about it
[04:50] <tomreyn> what is "it" that gives you a UUID? 
[04:51] <tomreyn> you should talk to whomanaged the VM Host to have them verify integrity of the .iso
[04:51] <tomreyn> *who manages
[04:52] <Obscenity> that would probably take several days, but it works now if i just dont use a mirror
[04:52] <Obscenity> https://www.virtualizor.com/
[04:52] <Obscenity> that is "it"
[04:55] <tomreyn> this may be bug 1883401
[04:55] <ubottu> Bug 1883401 in subiquity (Ubuntu) "crash due to bad custom mirror" [Low, Triaged] https://launchpad.net/bugs/1883401
[04:56] <tomreyn> but your descriptions is so imprecise, it's hard to tell
[04:57] <Obscenity> ooof, abandoned bug from 2020
[04:57] <Obscenity> unlucky
[04:58] <Obscenity> at least i can add the mirror back to apt later
[04:58] <tomreyn> there is also bug 1874248 and bug 1860352
[04:58] <ubottu> Bug 1874248 in subiquity "stage-curthooks/001-configure-apt: SUCCESS: Status.FAIL" [Undecided, New] https://launchpad.net/bugs/1874248
[04:58] <ubottu> Bug 1860352 in subiquity "User supplied mirror server not verified, no errors reported" [Undecided, New] https://launchpad.net/bugs/1860352
[05:00] <Obscenity> 1860352 makes sense since https-transport is not installed by default, which is pretty insane if you ask me
[05:00] <tomreyn> i don't see why you're saying the first bug report was 'abandoned'. it was just considered low importance, possibly because the error is a result of a bad environmental configuration
[05:03] <Obscenity> i just dont know what Triaged means so I assumed it was kicked aside
[05:04] <tomreyn> package apt-transport-https is no longer needed for adding https support to apt since apt 1.5
[05:05] <Obscenity> huh, when i dont add it i always get [Ign] or [Err] in the apt output
[05:05] <tomreyn> "Triaged" status is the state where a bug report is under examination.
[05:08] <tomreyn> it is unclear which ubuntu release or exact output you're referring to.
[05:11] <Obscenity> since as long as i remember, at least from 10.04 to 18.04 if not newer
[05:11] <Obscenity> im going to try it when im logged in and ill let you know
[05:11] <Obscenity> the output i mean
[05:27] <Obscenity> huh, totally works in 22.04
=== brlin_ is now known as brlin
[07:34] <mirespace> good morning
[07:40] <utkarsh2102> mirespace: o/
[07:46] <mirespace> hi utkarsh2102 o/
[11:25] <ShellcatZero2> Walex: What directory would you pass to debootstrap for a side-by-side install though?
[13:14] <athos> sdeziel: on the squid vs squid-openssl, I am not sure if it is just regarding historical reasons. I will dig around though :) squid-openssl was in main in impish though
[13:20] <Odd_Bloke> Hey folks, if we have a patch that we'd like to see backported to focal's systemd, what would the appropriate process be?  I will file a bug, but I'm not sure if those are regularly reviewed.
[13:23] <ahasenack> in any case, it all starts with a bug
[13:23] <ahasenack> I think bugs with patches get a special tag even
[13:24] <lotuspsychje> Odd_Bloke: did you check the recent systemd bugs, to see if there's something similar? https://bugs.launchpad.net/ubuntu/+source/systemd/+bugs?orderby=importance&start=0
[13:24] <ahasenack> and then ping in ubuntu-devel perhaps, as systemd is not under server
[13:27] <Odd_Bloke> lotuspsychje: Yup, no mention of it!
[13:27] <Odd_Bloke> ahasenack: Thanks!  It's Foundations still, presumably?
[13:27] <ahasenack> you presume correctly
[14:26] <sergiodj> sdeziel: hey.  I don't think it's historical, TBH.  I also agree that we should probably stick to the openssl version because that seems to be the preferred crypto suite.  as athos said, squid-openssl was in main and has been demoted to universe; I'm trying to find more info on why this happened
[14:28] <sdeziel> athos: oh, I had not seen this re squid-openssl in impish
[14:29] <sdeziel> sergiodj: cool, let me know if I can help in any way
[14:30] <sergiodj> squid-openssl has been added quite recently.  upstream is still working on the openssl support TBH, so that's something we should consider before promoting the package to main again
[14:30] <sergiodj> sdeziel: thanks for bringing this up
[14:39] <sdeziel> yeah, I'd be curious to know why it was demoted that recently?
[16:45] <ahasenack> athos: sergiodj: https://launchpad.net/ubuntu/jammy/amd64/squid-openssl
[16:45] <ahasenack> the "publishing" page for binaries
[17:23] <ahasenack> https://github.com/openzfs/zfs/issues/326
[17:23] <ubottu> Issue 326 in openzfs/zfs "Support fallocate(2)" [Closed]
[18:07] <sergiodj> ahasenack: thanks.  I couldn't find an explanation on the demotion in the page, though
[18:46] <sergiodj> sdeziel: so, the reason for the demotion was that squid-openssl is not an rdep for anything & it's not in a seed
[18:47] <sdeziel> sergiodj: ah, I see, thx
[18:48] <sergiodj> with that in mind, and knowing that upstream is still working on the patches to support openssl 3, I think a good plan ahead is to wait until upstream finishes working on the PR, backport its missing bits to squid on Jammy, and then work on getting squid-openssl into main
[18:49] <sdeziel> sergiodj: and realistically, that'd be for Jammy+1 right?
[18:50] <sergiodj> sdeziel: Jammy+1 would have an MIR, but I believe we should/could also aim for Jammy given that squid is an important package
[18:50] <sdeziel> sergiodj: that'd be nice indeed :)
[18:50] <sergiodj> I will write something about squid-openssl in the release notes
[18:50] <sergiodj> as suggested by ahasenack
[18:57] <sdeziel> sergiodj: if the plan is to have the OpenSSL one in main, will there be a demotion of the GnuTLS one? (I'd be in favor of minimal maintenance IMHO)
[18:58] <sergiodj> sdeziel: the best outcome would be to have a squid-gnutls package (in universe), and have squid link against openssl IMO.  I will talk to the debian maintainer and see what he thinks
[18:59] <sdeziel> sergiodj: works for me
[21:11] <JanC> maybe also look at what is best supported upstream...
=== eitteabs is now known as sbeattie