[09:03] <philroche> xypron: I learned that this morning yes.
[09:04] <mapreri> Eickmeyer: I also received a report in debian - #1006697 - but I can't reproduce it...   since you can reproduce it, it would help if you could test with 1.1.1-3 (I'm wonder if this is caused by https://salsa.debian.org/multimedia-team/inkscape/-/commit/22960b0b09d0f476a93f98e1ff90f5114ace8dec so next step if 1.1.1-3 works would be to disable that patch)
[09:04] <ubottu> Commit 22960b0 in multimedia-team/inkscape "Add patch from upstream to fix a crash when inkscape is run with --batch and a gui is not available"
[09:48] <eoli3n> Hi
[09:49] <eoli3n> ok guys, snap packages start to piss me off
[09:49] <eoli3n> i manage 800 hosts, and deploy some snaps like chromium or blender
[09:49] <eoli3n> 11000 users, randomly gets "cannot open path of the current working directory: Permission denied"
[09:50] <eoli3n> home are mounted with NFS under /home sub directories
[09:51] <eoli3n> if canonical is pushing his own containered packages system, it should ensure that everything is working well
[09:51] <eoli3n> if snaps are shitty like it seems to be, just use flatpaks
[09:55] <eoli3n> https://forum.snapcraft.io/t/cannot-open-path-of-the-current-working-directory-permission-denied-bis/28704/6
[11:10] <eoli3n> i just listened my own advice, and moved all my packages from snapshit to flatpak
[11:15] <seb128> eoli3n, 👍
[11:44] <ahasenack> morning
[12:03] <athos> good morning!
[12:08] <ahasenack> hi athos
[12:10] <didrocks> ahasenack: hey, at least, it seems adsys passed autopkgtests without the need for a rerun. Crossing fingers this is now addressed
[12:10] <ahasenack> you did another upload?
[12:11] <ahasenack> oh, you did, cool
[12:11] <ahasenack> 0.8.2
[12:11] <ahasenack> arm64 took 10min, twice as armhf
[12:12] <didrocks> yes, I was waiting on autopkgtests passing before declaring victory :p
[12:12] <ahasenack> hehe
[12:13] <didrocks> thanks for the hw access, I can release it now :)
[12:15] <ahasenack> :)
[15:45] <Eickmeyer> !guidelines | eoli3n
[15:45] <ubottu> eoli3n: The guidelines for using the Ubuntu channels can be found at https://wiki.ubuntu.com/IRC/Guidelines
=== dbungert1 is now known as dbungert
[17:06] <Eickmeyer> mapreri: I'm building 1.1.2-3 in my PPA now, we'll see how it goes. I might just do the merge and upload if all goes well.
[17:10] <Eickmeyer> mapreri: Annnnnd confirmed, it does fix it. I'll merge it in.
[17:26] <Eickmeyer> mapreri: Actually, dropping the patch is no good, but I'll test to make sure.
[17:30] <mapreri_mobile> Eickmeyer: please don't upload so happily..  personally I'd also find it weird if dropping that patch would really fix the issue.  Besides, it has since been merged upstream, so if it really was the cause it would need to be reported and further debugged.
[17:30] <Eickmeyer> mapreri: Yeah, I'm not dropping it. I'm just bulding in my PPA to make sure that everything is kosher.
[17:32] <Eickmeyer> mapreri_mobile: The only place I'm uploading is my PPA. :)
[17:36] <mapreri_mobile> Thanks!
[18:33] <Eickmeyer> mapreri: The merge worked, the problem is fixed. I have it in my PPA if you want to review, but I can upload if you'd like, unless you *really* want to do it.
[19:01] <dbungert> I want to request sync on mariadb-10.6, but the current verison number is funky (has ~exp in it).  Debuild can't round trip it - applying the debdiff then attempting to create it again wants me to commit 20 files.  It's not a fakesync, as the tarball isn't different.  Any suggestions?
[19:16] <vorlon> dbungert: what do you mean by "wants me to commit 20 files", is this specifically using git-ubuntu or something?  And, can you show the delta in question?
[19:21] <rbasak> FWIW, AIUI that version or mariadb-10.6 will FTBFS on ppc64el (and does on Debian at least). Last I looked anyway. That's why I had hesitated to sync it. But it might be better than the current situation, so it might be preferable to sync it and hope to fix the ppc64el build later. There is activity upstream on the fix. Just AFAIK it hasn't been resolved yet.
[19:21] <rbasak> I'm not sure I understand what's failing to round trip. Why is a debdiff involved?
[19:22] <rbasak> Note that debdiffs are lossy. They can't represent binaries or changes to file permissions for example. And they fall over with symlink changes.
[19:23] <rbasak> git can cope with all of that, so this is one benefit of using git-ubuntu. But git can't represent empty directories, so there is that downside still.
[19:24] <dbungert> mariadb doesn't seem to be in git-ubuntu?  Or maybe I'm using it incorrectly.
[19:25] <dbungert> vorlon: my commit comment was in reference to output from `debuild -d -S` saying "you can integrate the local changes with dpkg-source --commit"
[19:26] <rbasak> Let me add mariadb-10.6 to git-ubuntu. It'll take a few hours though I expect.
[19:27] <dbungert> rbasak: thanks for the note about ppc64el.  I think a sync is still beneficial to show progress on the openssl 1.1 transition.  Thanks also for the git-ubuntu bit.
[19:28] <dbungert> vorlon: here is the debdiff, which is just a trivial debdiff of mariadb-10.6_10.6.7-1.dsc mariadb-10.6_10.6.7-3~exp1.dsc - https://paste.ubuntu.com/p/FsrD7RGcFG/
[19:28] <rbasak> dbungert: I'm inclined to agree, but I'd like an ack on that from the release team before syncing
[19:28] <dbungert> sure, makes sense
[19:30] <vorlon> dbungert: that message means there are changes outside of the debian/ directory but I don't see anything in that debdiff.  Did the debuild command fail and spit out a filename of a new diff?  Can we see that?
[19:31] <dbungert> vorlon: https://paste.ubuntu.com/p/cp9wQ577Zd/
[19:33] <vorlon> dbungert: that seems to indicate that debian/patches/openssl-3-enable.patch at least is not applied
[19:33] <vorlon> also debian/patches/openssl-3-compatibility.patch
[19:33] <vorlon> so I don't know how things got into this state
[19:38] <dbungert> ok, that was enough of a hint, I have a better plan now
[19:45] <dbungert> the summary of my problem is "don't apply debdiffs on a package dir that has quilt patches applied"
[19:46] <rbasak> Ah. Yes. Thanks for reporting back!
[19:47] <rbasak> If you like git, you might be interested in "gbp pq" as a means to work on quilt patches
[19:47] <dbungert> yes, I'm overdue to learn gbp properly.  I have used it just enough to forget how to use it.
[19:48] <rbasak> This corner of gbp is fairly independent from gbp itself FWIW
[19:49] <rbasak> It's not perfect either, but you might prefer its set of rough edges over the rough edges of using debdiff and quilt manually
[20:05] <mapreri> Eickmeyer: ah, wait I misunderstood you.  so you can't reproduce it based on 1.1.2-3.  now, that would be *very* weird.  I can't imagine why 1.1.2-1 is affected but 1.1.2-3 is not.
[20:05] <mapreri> I thought you had to drop the patch to make it work
[20:06] <Eickmeyer> mapreri: No, that's not the case. I don't know why it works, but it does.
[20:06] <mapreri> well, if it's just that merge, feel free to do it.  but really it makes no sense for that to be a fix.
[20:07] <Eickmeyer> Agreed.
[20:08] <mapreri> i suppose you can do it, and ask the OP to verify *shrugs*
[20:09] <Eickmeyer> Makes me wonder if it was an updated build-dep.
[20:10] <Eickmeyer> I'm just spitballing here.
[22:24] <rbasak> FWIW the git-ubuntu import of mariadb-10.6 is complete