=== gusnan is now known as Guest27953
=== popey8 is now known as popey
[05:51] <cpatrick08> I was on the Cd Image server and noticed their is a Ubuntu-Canary iso. I was wondering what the differences are between it and the regular Ubuntu Daily ISO.
[07:26] <gimpnixon> can I ask about Ubuntu 21.04 here?
=== popey8 is now known as popey
[08:20] <eoli3n> xnox Hi, wasn't there. Could you add details to issues please ?
=== juergh` is now known as juergh
[09:52] <eoli3n> 23:19 xnox: eoli3n:  either you need to mount tmpfs as /target/run _before_ invoking in-target (it checks for that), or we need to adjust chromium-browser.preinst to test that we are not inside a chroot. Cause that's not somewhere where
[09:52] <eoli3n> snapd can run.
[09:53] <eoli3n> you need to checkin preinst, because i need some other things in /run to run ansible properly
[09:54] <eoli3n> if you have any more specific workaround ?
[10:08] <xnox> eoli3n:  ack.
=== gusnan is now known as Guest28222
=== alan_g_ is now known as alan_g
[14:31] <dbungert> doko: looks like you're looking into dh-exec.  Do you want me to continue on this?
[14:33] <doko> dbungert: please do, I just tried to find the offending code, but don't know if it's safe to replace it
[14:34] <dbungert> doko: will do, thanks
=== jdstrand_ is now known as jdstrand
[16:45] <GunnarHj> Hi doko, I'm about to change the symbols files for two C++ packages (opencc and marisa) to address FTBFS after LTO was turned on. Is that the right way to deal with it, or would disabling LTO be better?
=== ijohnson is now known as ijohnson|lunch
=== ijohnson|lunch is now known as ijohnson
[18:08] <leftyfb> I'm trying to backport a package from focal to xenial. Specfically wpa_supplicant 2.9. I can download the source on focal, compile it and it installs and runs fine on xenial. I'm trying to take that same source and get it into a PPA. The issue I'm running into is the build system complaining about debhelper-compat. I've tried setting it to "Build-Depends: debhelper-compat (= 9)," in the debian-control but that doesn't seem to work. Also, I
[18:08] <leftyfb> did all this or porting wpa2.9 from focal to bionic and it all worked fine
[18:10] <leftyfb> I've also tried "Build-Depends: debhelper-compat (>= 9)," and "Build-Depends: debhelper-compat (>= 9~),". Neither of those seem to be valid for debhelper where the same syntax works fine on the other dependencies
[18:11] <dbungert> leftyfb: you may need to tweak debian/compat
[18:12] <leftyfb> I tried removing the debhelper-compat line from the control file completely and just adding a "9" to debian/compat, as the error message suggested. That seemed to make it angrier than normal. :)
[18:12] <leftyfb> dbungert: got any suggestions on how that file should look? BTW, it doesn't actually exist in the original source
[18:13] <dbungert> leftyfb: ah, 'echo 9 > debian/compat' was my assumption, sounds like something else is going on
[18:19] <leftyfb> this is with it specified as "9" in both the control and compat files https://pastebin.ubuntu.com/p/gcgdfV5vr5/
[18:25] <dbungert> well, it definitely seems unhappy about the value in both compat and control, so your original way in compat was probably fine.  Which sends you back to your original problem.
[18:35] <RikMills> leftyfb: if you have 9 in debian/compat then set 'Build-Depends: debhelper (>= 9)' in debian control?
[18:35] <leftyfb> let me try
[18:37] <RikMills> that is what most xenial packages will have
[18:37] <leftyfb> https://pastebin.ubuntu.com/p/Pg4sWsyfD9/
[18:38] <RikMills> you didn't do what I said
[18:38] <RikMills> debhelper, not debhelper-compat
[18:38] <leftyfb> oh
[18:39] <leftyfb> do I remove/replace debhelper-compat?
[18:39] <RikMills> repleace with debhelper (>= 9)
[18:39] <RikMills> as you still need debhelper as a build dep
[18:41] <leftyfb> ok, that is working so far, pushing to LP. Next issue, got any fancy ways to do something like this (trying different things to push to PPA) so that I don't need to keep incrementing the version? Deleting says happens every 6 hours, yet after about 20 I'm still not able to upload (force) the same version with some changes
[18:43] <RikMills> leftyfb: nope. once you use a version in a PPA, that version is 'burned' for future use permanently
[18:43] <leftyfb> boo
[18:43] <leftyfb> ok, thanks
[18:44] <RikMills> it is a security thing. bad actors can't silently replace packages with identical versions but different contents
[18:45] <RikMills> same applies to the main archive
[18:48] <leftyfb> build failed
[18:48] <leftyfb> https://pastebin.ubuntu.com/p/KgMH9TJxdk/
[18:48] <leftyfb> it's not clear to me what is wrong now
[18:56] <leftyfb> it looks like it might be related to the libnl-3-dev. I have specified version >= 3.2.27~ in the control file
[19:02] <RikMills> possible that xenial has too old a glibc for that to compile
[19:03] <leftyfb> I can build a local .deb fine using the same source
[19:04] <RikMills> build on xenial?
[19:05] <leftyfb> to be honest, I forget where I built it. It know I built it FOR xenial and it built and installs and works fine on it
[19:54] <doko> GunnarHj: for a package in main, yes, update the symbols file. do you have a build log with the missing symbols? if it's in universe and you don't want to fix it, add it to the lto-blocklist package
[20:12] <RikMills> doko: I did some discussion in another place. package was marisa in universe. build with missing symbols was in your rebuild ppa I believe. a proposed symbols fix was https://launchpad.net/~gunnarhj/+archive/ubuntu/marisa/+sourcepub/12264722/+listing-archive-extra
[20:14] <RikMills> but I think doing optional=lto instead of complicated !arch changes would again be better
[20:14] <RikMills> plus that personal ppa did not do riscv64
[20:17]  * RikMills goes back to his pint of beer
[20:59] <doko> RikMills: sure, I'm preferring optional=lto as well. But if it's universe and you don't want to fix things now, just add to the lto-blocklist
[22:04] <RikMills> doko: fair. I just don't want to postpone the inevitable for my ones
[22:40] <bdmurray> RikMills: Why did you tag bug 1681830 hirsute? I don't see any indication in it that it affects hirsute.
[22:40] <ubottu> bug 1681830 in ubiquity (Ubuntu) "No Label for LVM Encryption Passwords" [Medium,Triaged] https://launchpad.net/bugs/1681830
=== paride3 is now known as paride
[22:43] <RikMills> bdmurray: because it does affect hirsute still, and I want it to show up in the filtered bug list to put on the kubuntu beta notes
[22:43] <RikMills> it is only KDE front end that if affects
[22:43] <RikMills> plus it is a reminder for me to try to look at it :(
[22:44] <bdmurray> RikMills: Adding some details would have avoided this conversation. ;-)
[22:44] <RikMills> sorry. noted