=== jamesh_ is now known as jamesh
[08:10] <seb128> RAOF, bdmurray, SRUteam, could someone review the gnome-shell stack SRUs in the focal queue? it has several fixes for rough edges in the LTS desktop, the updates are not trivial but GNOME bugfixes ones, would be nice to see those accepted :-)
[10:48] <juliank> didrocks: i recently had this crazy idea - given that zsys snapshots the system before you upgrade stuff, why don't we just turn off some consistency features in apt and dpkg on such systems, as you can just reboot and revert if stuff fails
[10:48] <juliank> like all the fsync stuff
[11:59] <paride> rbasak, all good with the git-ubuntu build, right?
[12:02] <rbasak> paride: yes, thanks. I have a built snap, just sorting out the release announcement etc
[12:17] <didrocks> juliank: that would be excellent! The idea is also to offer offline upgrade in the long term, but meanwhile, this is a good improvements for our users
[12:20] <juliank> didrocks: Also makes me wonder if you want to setup boot so that if you have a crash during apt run, it automatically restores to the working state from before you ran apt
[12:21] <juliank> so that you get online upgrades but with an offline upgrade like feel if the machine resets during an upgrade
[12:21] <juliank> #safety
[12:22] <juliank> "Your system rebooted in the middle of package operations, do you want to continue with the possibly broken system or revert to the last known-good state?"
[12:27] <didrocks> juliank: good idea, something to file a bug against and see how we can instruct grub doing that. Just file it against the zsys github project so that we don’t forget about it
[12:27] <juliank> ack
[12:48] <Teduardo> Hello, does anyone have any idea why autoinstaller's default storage schema is to create a 100% VG on the first disk but then only use 1% of that VG for the filesystem?
[12:49] <Teduardo> I tried asking ubuntu-installer folks but I can't seem to get ahold of any of them.
[12:57] <ubusr> Is there any ETA on fixing ubuntu 18.04 and 16.04 "file/libmagic" packages to fix the ELF parsing bug ?
[12:59] <rbasak> Do you have a bug reference?
[13:00] <ubusr> nop
[13:00] <rbasak> Then presumably there is no ETA.
[13:00] <ubusr> :/  I can rereport it here if anyone is intrested
[13:00] <rbasak> If you want to track progress, I suggest that you find the existing bug there is one, or file one if there isn't.
[13:01] <ubusr> how can I track when the bug was introduced ?
[13:01] <ubusr> something likt git bisect, where I can rollback the file package till the bug stops ?
[13:01] <seb128> ubusr, is there a bug open about that issue? you mention it as it was a known problem
[13:02] <rbasak> ubusr: https://launchpad.net/ubuntu/+source/file/+publishinghistory might be helpful, assuming the root cause was actually in that package.
[13:02] <ubusr> seb128: ahh, I typed it yesterday here :/ , not sure if there is an open bug, but in the last few month, the file program started truncating the interpreter path of ELF binaries in the output
[13:02] <ubusr> (atleast in docker environments)
[13:03] <rbasak> Please don't assume that mentioning a problem in this channel is sufficient. If there isn't a bug filed, you can't assume there will be any progress.
[13:03] <ubusr> would be glad if someone can do it, I hate keeping track of yet one more password leak :/
[13:03] <seb128> ubusr, I don't think you described enough what the issue is for anyone to be able to open a report for you
[13:03] <seb128> do you have a testcase?
[13:04] <rbasak> I'm against doing it. A bug report isn't the end of the story. If developers can't communicate with the people actually affected bugs can often stall.
[13:04] <ubusr> basically if you run docker (maybe regular one as well) ubuntu 18.04 and 16.04 and install the "file" package, and run file /bin/bash this si the output
[13:04] <rbasak> If you want it fixed, please at least file a complete bug report yourself.
[13:04] <ubusr>  /bin/bash: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=12f73d7a8e226c663034529c8dd20efec22dde54, stripped
[13:05] <ubusr> you can see the interpreter is truncated there (/lib64/l) on ubuntu 20.04 docker it's not truncated, and I'm sure that about 6 month ago, it wasn't on 16.04 as well
[13:05] <ubusr> so somewhere along the line something changed in previous ubutnu versions
[13:09] <seb128> ubusr, there is already a report on https://bugs.launchpad.net/ubuntu/+source/file/+bug/1835596
[13:09] <ubottu> Launchpad bug 1835596 in file (Ubuntu) "incorrect argument to file_printable in [PATCH] PR/62" [Undecided,New]
[13:11] <ubusr> hmm... 16 month ago it worked ok
[13:12] <cjwatson> Introduced as part of a security fix
[13:12] <cjwatson> E.g. https://launchpadlibrarian.net/414997700/file_1%3A5.25-2ubuntu1.1_1%3A5.25-2ubuntu1.2.diff.gz
[13:12] <seb128> https://launchpad.net/ubuntu/+source/file/1:5.25-2ubuntu1.2
[13:12] <seb128> ah, cjwatson beat me to it
[13:13] <seb128> mdeslaur, ^ fyi
[13:13] <ubusr> nice, thanks for the info, will it ever be fixed :/  I had a script that dependend on the correct output
[13:14] <mdeslaur> thanks cjwatson seb128
[13:14] <seb128> ubusr, now that you raised it probably
[13:14] <mdeslaur> ubusr: yes, I'll handle it, I wasn't aware of it
[13:15] <ubusr> cool, thanks
[13:16] <ubusr> btw, how come in 20.04 it's ok ?
[13:16] <mdeslaur> thanks ubusr
[13:17] <cjwatson> I presume the regression was fixed upstream a bit later but that fix didn't make it back into security updates for older series
[13:19] <cjwatson> Hm
[13:19] <cjwatson> Or maybe a bad backport
[13:22] <cjwatson> Yep, bad backport
[13:22] <cjwatson> https://github.com/file/file/commit/9109a696f3289ba00eaa222fd432755ec4287e28 changed interp in that function from being a const char * to a char[]
[13:22] <cjwatson> Which changes what sizeof(interp) means
[13:23] <mdeslaur> yes, it's a bad backport
[13:23] <cjwatson> So the code was correct when committed to upstream file, but when backported it needed to be changed to um strlen(interp) + 1 or something
[13:34] <mdeslaur> ubusr: I'll publish the regression fix tomorrow or thursday
[13:35] <seb128> ubusr, thanks for raising the issue
[13:35] <seb128> mdeslaur, and thanks for taking on fixing it :)
[13:37] <mdeslaur> I broke it, I get to glue the pieces back together :)
[14:48] <rbasak> cpaelzer, waveform, ahasenack: FYI, I'm going to reimport and force push branches for u-boot, qemu, chrony, gpsd and squid soon. Previous bugs are fixed, so hopefully this will be the final time - take 2.
[14:48] <ahasenack> rbasak: ok
[14:48] <waveform> rbasak, no prob
[14:48] <ahasenack> sergiodj: ^ about squid
[14:50] <sergiodj> ahasenack: thanks
[15:34] <ubusr> seb128: if you want to see how I "found" the issue https://github.com/tzickel/docker-trim/issues/1
[15:35] <ubusr> took me time to understand that report was because ubuntu 16.04's file truncated it
[15:36] <ubusr> https://github.com/tzickel/docker-trim/blob/master/Dockerfile.get_instrumentation <-- is there a better way to get a static version of file to work ?
[15:53] <rbalint> ddstreet, i need to rewrite the ubuntu-groovy because the reverts are still needed, please rebase your branches if you have anything in flight
[15:54] <rbalint> ddstreet, i'm about to upload the queued fixes to groovy + the lxd tests to let them being srud and will try dropping the reverts again
=== M_hc[m] is now known as _hc
[16:10] <ddstreet> rbalint ack thanks, i dont think i have anything outstanding for g but i'll rebase if so
[16:39] <rbasak> cpaelzer, ahasenack, sergiodj: reimports of squid, chrony and gpsd are cmoplete.
[16:39] <rbasak> u-boot and qemu are still going
[16:39] <ahasenack> ok
[16:40] <sergiodj> rbasak: thanks
=== diddledan8 is now known as diddledan
=== gabriel1109|away is now known as gabriel1109
[20:10] <rbasak> waveform: u-boot reimport is done
=== jdstrand_ is now known as jdstrand