[01:01] <arraybolt3> OK, I know this isn't much to go on, but maybe someone has some hints for me. Using Kubuntu 22.04, I've set up sbuild as described here: https://wiki.ubuntu.com/SimpleSbuild (I didn't use the provided sbuildrc, but that shouldn't matter here). If I try to enter into one of the sbuild chroots manually for updating (schroot -c source:kinetic-amd64 -u root), I just get dropped back to my normal shell with the rather unhelpful message "E:
[01:01] <arraybolt3> Child terminated by signal ‘Segmentation fault’". How would I even start debugging this?
[01:03] <arraybolt3> I don't see much of anything alarming in /var/log/syslog, there's some "Running shell: /bin/bash", and then a lot of "Deactivated successfully" messages.
[02:07] <arraybolt3> Another question, how should I handle versioning if I want to do a sync from Debian as an SRU? I think I should add an new versioning to the packaging so as to work right with the versioning system in Ubuntu, but since it's a sync from Debian, I'm not sure if we do things differently there or not.
[03:11] <JanC> IIRC synced packages that don't have Ubuntu-specific patches get the same version as in Debian?
[05:40] <RAOF> arraybolt3: The main constraint of versioning for SRUs is that you must always be able to get a sensible "next" version that's less than the any version in any subsequent release.
[05:41] <RAOF> Also, the major benefit of not having an Ubuntu-specific version for Debian syncs (namely, that they'll get automatically resynced should a new Debian upload occur) doesn't apply to SRUs :)
[05:41] <arraybolt3> RAOF: Right. I just wasn't sure if a sync from Debian influenced that or not. For instance I know (or at least believe, I could be misremembering) that there are many packages with identical versions between releases if they're just Debian syncs. Thanks for helping me figure it out!
[05:42] <arraybolt3> And I guess this might not be a real Debian sync.
[05:42] <arraybolt3> I may be confusing terminology here.
[05:42] <RAOF> You will, at the very least, need to close a Launchpad bug in the changelog :)
[05:43] <arraybolt3> Quite easy, since the whole reason for an SRU in the first place is that there's a critical bug. (Manuskript regression, the package is utterly broken on 22.04)
[05:43] <arraybolt3> (The app won't even launch.)
[05:43] <RAOF> (Anytime you see a package with an identical version across releases that implies that there were no uploads of that package for at least a whole release cycle, and the previous package was copied forward)
[05:43] <RAOF> That sounds like a highly acceptable SRU :)
[05:43] <arraybolt3> RAOF: Oh, good to know! That makes sense to me. Thank you!
[05:44] <arraybolt3> (The idea is, if the latest version in Debian builds and works on Ubuntu, I can just take Debian's package and shove it in, done. Obviously that's just a rough overview, there's also the whole things about regression potential and whatnot, but given the fact that it's already regressed, it can't get a whole lot worse :P)
[05:45] <arraybolt3> Alright, guess I'll get to it then!
[05:48] <RAOF> Yeah, regression potential for something that's totally broken can be pleasantly easy to write :)
=== sem2peie- is now known as sem2peie
=== sem2peie- is now known as sem2peie
=== sem2peie- is now known as sem2peie
=== sem2peie- is now known as sem2peie
=== sem2peie- is now known as sem2peie
=== sem2peie- is now known as sem2peie
=== sem2peie- is now known as sem2peie
[14:21] <jdstrand> mwhudson: hi! I'm sure you're aware, but if not, go 1.18.7 and 1.19.2 are out. The stable snaps are still on 1.18.5 and 1.19. These two and the previous 1.18.6 and 1.19.1 are security updates
[14:22] <jdstrand> mwhudson: 'latest' is also pointing to 1.18.5 (I think that should be updated to 1.19.2?)
[14:24] <jdstrand> mwhudson: I'd be happy to file an issue, but don't know where. https://snapcraft.io/go points to https://code.launchpad.net/~go-snap-maintainers/+git/gosnap but it isn't clear it is setup for bugs
[14:24] <jdstrand> (that people would see)
[14:33] <mwhudson> jdstrand: oh right yes, been getting behind
[14:33] <mwhudson> jdstrand: want to be a maintainer of the snap? :-)
[14:39] <jdstrand> mwhudson: I wouldn't mind participating on a team to help maintain it
[14:41] <mwhudson> jdstrand: i added you to https://launchpad.net/~go-snap-maintainers which owns the branches
[14:42] <jdstrand> mwhudson: https://code.launchpad.net/~go-snap-maintainers/+git lists two branches. is lp:~go-snap-maintainers/+git/gosnap historic?
[14:43] <mwhudson> jdstrand: er. let's say yes
[14:44] <mwhudson> jdstrand: should i send a snap collaboration invite to jdstrand@ubuntu.com ?
[14:46] <mwhudson> jdstrand: fwiw pushes to the branches trigger builds that get published to 1.X/candidate and i usually do a very tiny smoke test before publishing to /stable
[14:51] <jdstrand> mwhudson: ok, so going forward it looks like for 1.18 and 1.19 you just updates the snapcraft.yaml for the source and source-checksum. When 1.20 comes out, would you just branch off of go1.19 to create go1.20 and adjust source and source-checksum?
[14:51] <mwhudson> jdstrand: yes
[14:51] <jdstrand> mwhudson: jdstrand@ubuntu.com is fine, sure
[14:52] <mwhudson> the update.py script does the update for the simple case
[14:52] <jdstrand> mwhudson: what smoke testing to you typically do?
[14:53] <jdstrand> do*
[14:54] <mwhudson> jdstrand: it's very in depth https://paste.ubuntu.com/p/5Nvb52tf3t/
[14:54] <jdstrand> mwhudson: ack. I have access to a lot of code, I could try to build it
[14:54] <mwhudson> i also usually make a the new release stable after the first non bug fix point release but that seems to be taking longer to come out with the more recent releases
[14:54] <jdstrand> (for my smoke testing)
[14:55] <mwhudson> so maybe we should just say the new version becomes stable after two weeks or something
[14:55] <jdstrand> mwhudson: so in this case, you stayed on 1.18.5 when 1.19 came out, and you intended to make 'latest' go to 1.19.1 when it came out?
[14:56] <mwhudson> jdstrand: y
[14:56] <jdstrand> mwhudson: I think that policy is not terrible. They've been roughly monthly lately iirc
[14:58] <mwhudson> it's been more than a month since 1.19 hasn't it? or is my sense of time slipping?
[14:58] <jdstrand> mwhudson: want to continue with that or augment it with 'point latest at the first .1 when it comes out or a month after the 1.N is out if there isn't a point release yet, whichever is sooner'?
[14:59] <jdstrand> mwhudson: it has since 1.19, yes, but you didn't point latest at 1.19.1 when it came out. 1.19.2 has been our for a couple/few weeks already
[14:59] <mwhudson> jdstrand: i don't know. what do you think would benefit users the most?
[14:59] <jdstrand> s/out/out/
[14:59] <mwhudson> jdstrand: this is why i am keen to add new maintainers :-) i am losing touch with go upstream
[15:01] <jdstrand> mwhudson: I'd like to stick with your original policy for now, and I can try to help with keeping it current. We can revisit later if needed. I like the policy and think it serves users as it gives a little wiggle room for the occasional breaking change
[15:01] <mwhudson> jdstrand: cool
[15:04] <jdstrand> mwhudson: ok, I think I've got a handle on what you've been doing. I follow upstream fairly closely for security updates. I'll try to do the updates next time. It all seems quite clear but if I run into anything weird, I'll holler (I'll also plan to fyi you that I did it and won't push to stable without talking to you for at least this next one)
[15:04] <mwhudson> jdstrand: yeah that makes sense
[15:04] <mwhudson> jdstrand: tia!!
[15:05] <mwhudson> (i really should have a swing at getting the snap built by upstream's release process)
[15:05] <jdstrand> mwhudson: you mean following their RCs?
[15:07] <mwhudson> jdstrand: i mean having the upstream release process publish the snaps
[15:07] <mwhudson> (probably pretty optimistic but it would sure be nice)
[15:21] <jdstrand> oh, yes, that would be nice :)
[20:10] <ahasenack> any idea why debian (and us) hasn't moved to gnupg 2.3 yet? Because it's not marked as LTS?
[20:11] <ahasenack> it has tpm support (`keytotpm`)
[20:12] <ahasenack> unsure if I would want to use that command, but first I need it available :)
[20:12] <ahasenack> "so the keyfile now
[20:12] <ahasenack> becomes locked to the laptop containing the TPM"
[20:14] <genii> !info gnupg2
[20:14] <ubottu> gnupg2 (2.2.35-3ubuntu1, kinetic): GNU privacy guard - a free PGP replacement (dummy transitional package). In component universe, is extra. Built by gnupg2. Size 5 kB / 51 kB
[20:14] <genii> hm
[20:15] <ahasenack> 2.3.0 is from 2021/04/07
[20:15] <ahasenack> (april)
[23:00] <arraybolt3[m]> Simon Quigley: If you're around, I could use some help, otherwise help from someone else trusted would be appreciated. My Internet connection's upload speed is too slow for me to attach some debdiffs to a Manuskript SRU I'm preparing. They're ~5MB files, and I know Launchpad will time out if I try to upload those with my current upload speed. If I upload them using Matrix so that they show up directly in the chat, can someone with
[23:00] <arraybolt3[m]> decent upload speed attach them to the bug report? The bug in question is https://bugs.launchpad.net/ubuntu/+source/manuskript/+bug/1989203
[23:00] -ubottu:#ubuntu-devel- Launchpad bug 1989203 in manuskript (Ubuntu Kinetic) "Manuskript crashes on start" [High, Confirmed]
[23:00] <tsimonq2> I can certainly do some bug report attaching for you, sure. :)
[23:01] <tsimonq2> Feel free to send them via PM.
[23:01] <arraybolt3[m]> Thanks. I have the files uploading now.
[23:01] <arraybolt3[m]> They aren't sensitive, I'm uploading them right into the chat, is that OK>
[23:01] <arraybolt3[m]> s/>/?/
[23:02]  * arraybolt3[m] posted a file: kineticDiff.patch (4499KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/AEIpcOmUTILBuKQKOsiAfpBP >
[23:03] <tsimonq2> Sure, just didn't want to spam the chat. What has been done has been done, I will attach it to the bug report for you, and likely review this soon :)
[23:03]  * arraybolt3[m] posted a file: jammyDiff.patch (4499KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/bftBnjLYJLvANoOczjtozzUW >
[23:03] <arraybolt3[m]> Ah, that makes sense. I'll keep that in mind for next time.
[23:05] <tsimonq2> No worries. Happy to help.