[06:07] <Unit193> tsimonq2: Reminder about LP 1822672
[07:31] <LocutusOfBorg> juliank, hello, what is your opinion wrt aptitude merge?
[07:32] <juliank> LocutusOfBorg: useless atm
[07:33] <juliank> it's just minor packaging clean up right now
[07:33] <LocutusOfBorg> oh ok :)
[07:34] <LocutusOfBorg> and what about libapt-pkg-perl?
[07:34] <LocutusOfBorg> syncpackage -f?
[07:35] <juliank> yeah
[08:01] <tkamppeter> doko, hi
[08:38] <LocutusOfBorg> juergh, will you sync or can I?
[08:39] <juergh> LocutusOfBorg, wrong nick^?
[08:39] <LocutusOfBorg> oops I meant juliank ^^
[08:39] <LocutusOfBorg> sorry!
[08:39] <juliank> Yes
[08:39] <juliank> I'll sync
[08:40] <juliank> I synced
[08:41] <LocutusOfBorg> thanks
[08:49] <juliank> Can I specifiy seccomp policies for lxd containers and use that to disallow fsync and friends?
[08:51] <juliank> That could be useful for my ephemeral containers
[09:55] <LocutusOfBorg> doko, I think the new dwz is breaking stuff, like verilator
[09:55] <LocutusOfBorg> dh_dwz: dwz -q -mdebian/verilator/usr/lib/debug/.dwz/x86_64-linux-gnu/verilator.debug -M/usr/lib/debug/.dwz/x86_64-linux-gnu/verilator.debug -- debian/verilator/usr/bin/verilator_bin debian/verilator/usr/bin/verilator_bin_dbg debian/verilator/usr/bin/verilator_coverage_bin_dbg returned exit code 1
[09:57] <ricotz> marcustomlinson, hi :), is libreoffice 6.2.5 on your list yet?
[10:06] <Unit193> LocutusOfBorg: Unrelated to the new one, I've had issues with dwz before so I've skipped updating to 12. :/
[10:12] <juliank> Maybe someone here knows this: I'm wondering if it's possible to have on dbus method, but different PolicyKit permissions
[10:12] <LocutusOfBorg> Unit193, related to the new one
[10:12] <LocutusOfBorg> I just downgraded dwz and it worked correctly a rebuild
[10:13] <LocutusOfBorg> if you have issues with dh_dwz, please tell me, I fixed a bunch of them already
[10:13] <juliank> Like a ManagePackages() method, and then ask a special permission if packages need to be removed
[10:13] <LocutusOfBorg> e.g. usually they show when the package plays bladly with *FLAGS*
[10:13] <doko> LocutusOfBorg: do you have the files in a bug report?
[10:13] <LocutusOfBorg> doko, I just opened a bug report
[10:13] <LocutusOfBorg> which files do you need?
[10:13]  * juliank has not used policykit as a developer
[10:14] <LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/dwz/+bug/1835398
[10:14] <LocutusOfBorg> I'm doing a new build with the new dwz (sorry, but I deleted it when I downgraded dwz to test if the build was good or not)
[10:17] <Unit193> LocutusOfBorg: 'DWARF version 0 unhandled' with release pocket, 'Found compressed .debug_aranges section, not attempting dwz compression' with -proposed.
[10:21] <Laney> juliank: you (the service) can decide when to invoke PK to check authorisation for an action
[10:21] <juliank> Laney: thanks
[10:23] <Laney> juliank: e.g. something like https://gitlab.freedesktop.org/bolt/bolt/blob/master/boltd/bolt-bouncer.c#L136 which I just happened to have open
[10:34] <LocutusOfBorg> Unit193, I don't get what you are referring to
[10:35] <Unit193> The aformentioned dwz issue I've run into?
[10:40] <LocutusOfBorg> ok Unit193 but which package?
[10:41] <Unit193> ruby-bcrypt-pbkdf
[10:46] <LocutusOfBorg> Unit193, the first hack might be to add an empty dh_dwz override
[10:50] <LocutusOfBorg> Unit193, I see one dwz bug... "-Wl,--compress-debug-sections=zlib" is the culprit
[10:50] <LocutusOfBorg> this probably makes dh_dwz fails to read the info because its compressed
[10:50] <LocutusOfBorg> I would try to make dwz smarter
[10:51] <LocutusOfBorg> this with dwz from release
[10:51] <Unit193> That's what it looked like to me as well.
[10:51] <LocutusOfBorg> I tried to run dwz after doing manually the link without that flag and it worked
[10:52] <LocutusOfBorg> can you please open a bug report?
[10:57] <Unit193> I modified /usr/lib/x86_64-linux-gnu/ruby/2.5.0/rbconfig.rb and was able to run the build as expected.
[11:09] <GunnarHj> Hi LocutusOfBorg, do you have time to sponsor bug #1728012? See that you did the latest merge, and this is a straightforward fix.
[11:19] <doko> LocutusOfBorg: verilator_bin_dbg is missing :-/
[11:20] <LocutusOfBorg> doko, it takes a couple of minutes to build...
[11:20] <LocutusOfBorg> I can't upoload 70Mb of binaries
[11:21] <LocutusOfBorg> GunnarHj, .
[11:22] <GunnarHj> LocutusOfBorg: Still here. :)
[11:22] <doko> LocutusOfBorg: then just upload the files needed for dwz
[11:51] <LocutusOfBorg> doko, verilator_bin_dbg isn't needed?
[11:54] <doko> LocutusOfBorg: why not?
[11:55] <doko> I don't see anthing there about compressed debug sections
[11:58] <LocutusOfBorg> doko, the problem about compressed debug sections was for ruby-bcrypt-pbkdf
[12:01] <LocutusOfBorg> I'm doing a tarball right now
[12:01] <LocutusOfBorg> I'll email to *yournick*@ubuntu.com
[12:04] <doko> LocutusOfBorg: nm, I have it
[12:04] <LocutusOfBorg> both verilator and ruby-bcrypt?
[12:04] <LocutusOfBorg> GunnarHj, my "." meant "uploaded"
[12:04] <doko> no ruby. put it on p.d.o
[12:05] <LocutusOfBorg> doko, if you want to test yourself, just change debhelper-compat from 11 to 12
[12:05] <LocutusOfBorg> I mean ruby, it takes some seconds to build
[12:06] <doko> no, I want the files from the command line
[12:06] <LocutusOfBorg> I don't get then
[12:06] <doko> ?
[12:06] <LocutusOfBorg> which files?
[12:07] <LocutusOfBorg> verilator?
[12:07] <LocutusOfBorg> verilator has nothing to do with compressed debug sections
[12:08] <LocutusOfBorg> verilator shows some kind of regression in dwz
[12:08] <LocutusOfBorg> while ruby-bcrypt-pbkdf seems to imply that dwz can't read compressed .debug_aranges sections
[12:09] <LocutusOfBorg> but only verilator (what I reported as bug) is actually a regression to me
[12:12] <marcustomlinson> ricotz: it is
[12:12] <marcustomlinson> ricotz: now that you pointed it out ;)
[13:10] <GunnarHj> LocutusOfBorg: Great, thanks! Is that "." some convention I have missed? ;)
[13:35] <LocutusOfBorg> GunnarHj, It is used on #debian-ftp irc channel when somebody does what requested, not sure but I use it on lots of places, but probably only debian developers understand it
[13:37] <rbasak> I've never heard of that. The only related thing I can think of is SMTP's end of message indicator.
[13:37] <LocutusOfBorg> doko,
[13:37] <LocutusOfBorg> -  if (debug_sections[DEBUG_INFO].data == NULL)
[13:37] <LocutusOfBorg> +  if (debug_sections[DEBUG_INFO].data == NULL
[13:37] <LocutusOfBorg> +      && !rd_multifile)
[13:37] <LocutusOfBorg> http://launchpadlibrarian.net/431463266/dwz_0.12-3_0.12.20190702-1ubuntu1.diff.gz
[13:38] <LocutusOfBorg> the diff shows clearly that they added a new statement about multifile...
[13:39] <GunnarHj> LocutusOfBorg: I see. Useful when people know about it. Thanks for explaining!
[13:40] <LocutusOfBorg> https://sourceware.org/git/?p=dwz.git;a=commitdiff;h=08becc8b33453b6d013a65e7eeae57fc1881e801
[13:41] <LocutusOfBorg> doko, ^^^
[13:41] <doko> LocutusOfBorg: please add your comments to the upstream issue
[13:43] <LocutusOfBorg> .
[13:45] <jamespage> doko: hey - so...
[13:46] <jamespage> doko: do we have a general objective to drop all python-* packages this cycle?
[13:46] <jamespage> we've had a few syncs from experimental where some early work has been done in Debian; its only very partial and has wedged a load of proposed migrations
[13:47] <jamespage> and I'm having trouble working up an appetite to work through all of the reverse-depends(-depends)* to unblock things if this will be a general objective once Debian development re-opens
[13:48] <doko> jamespage: no, it's up to you, however you'll probably have to maintain a delta with Debian for a while
[13:49] <jamespage> doko: we looks at the first level reverse-depends and hit 84 packages...
[13:49] <jamespage> I'm very tempted to *not* do this first in Ubuntu
[13:50] <doko> then you'll have to wait for the Debian plan ...  we'll have a BoF at DebConf. So if you want to provide some information, please do
[13:51] <jamespage> doko: we've already switch the openstack 'projects' to drop python-* but they are leaf packages; the module set is more intertwined with other things
[13:51] <jamespage> infact we mostly did that last cycle.
[13:51] <doko> jamespage: do you have a list of stage2 and stage3 modules as well?
[13:51] <jamespage> doko: not yet - only just started looking
[13:51] <jamespage> sahid is working the scope atm
[13:52] <doko> jamespage: could you do that analysis on unstable, and then post to the debian-python ML?
[13:55] <doko> jamespage: within the next two weeks
[13:55] <jamespage> er
[13:55] <jamespage> will try
[14:18] <sahid> jamespage: any chance you look at https://code.launchpad.net/~sahid-ferdjaoui/ubuntu/+source/cinder/+git/cinder
[14:18] <sahid> cinder was stuck in proposed and corey is out today i think
[14:19] <sahid> https://launchpad.net/~sahid-ferdjaoui/+archive/ubuntu/bionic-queens/+build/17220986
[14:19] <sahid> buildroot ^
[14:22] <jamespage> sahid: is that change needed? i.e. I think its not something we would normally SRU
[14:24] <Laney> bdmurray: did you just change something on your phased update emails? I just got a few of them which are listing *lots* of crashes that are not actually new in the upload you're pointing out.
[14:25] <sahid> jamespage: SRU 1830341
[14:25] <sahid> https://launchpad.net/ubuntu/+source/cinder/2:12.0.7-0ubuntu1/+build/17217605
[14:25] <jamespage> caused by
[14:25] <jamespage> dh_missing: usr/etc/cinder/resource_filters.json exists in debian/tmp but is not installed to anywhere
[14:26] <jamespage> maybe we need to install that file  in a package instead?
[14:27] <sahid> jamespage: let me double check
[16:17] <tomreyn> Can you already tell when exactly (which day) 18.10 reaches EOL?
[16:18] <ricotz> marcustomlinson, alright ;)
[16:47] <Eickmeyer> tomreyn: It's exactly 9 months to the day. So, since 18.10 was released October 18th, its EOL is July 18th.
[16:48] <tomreyn> Eickmeyer: oh, is this documented somewhere? because i always felt the "supported for nine months" statement to be imprecise. maybe just adding the word "exactly" there would help a lot.
[16:49] <tomreyn> Eickmeyer: but indeed the distro-info command seems to support what you're saying:
[16:49] <tomreyn> $ distro-info --days=eol --series cosmic
[16:49] <tomreyn> 14
[17:16] <rbasak> tomreyn: usually it's officially EOL only when the release team decides it is. AIUI, there are some actions associated with EOLing (certainly the announcement) so it tends to vary depending on who is busy with what at the time.
[17:24] <tomreyn> rbasak: i see. but i guess the release team would not ever decide to set the factual EOL to a point that is earlier than the exact data calculated from the release announcement and what is reported by (ubuntu-)distro-info, right?
[17:24] <tomreyn> s/data/date/
[17:34] <aiena> Does anyone know if I can use distribution source pacakges to develop custom device drivers for the linux kernel
[17:34] <aiena> I have a device I want to try my hands at driver programming for. I will take full responsibility for anything that goes wrong.
[17:45] <CarlFK> aiena: there are no rules against it if that is what you are asking
[17:45] <aiena> yes I want to eventually contribute it back.
[17:46] <aiena> I looked up the basics and got some code up but I do not know how to use the distro's linux/init.h
[17:46] <aiena> for example to build it
[17:46] <aiena> currently it just has a few printk() statements which display stuff on loading and unloading the module.
[17:47] <aiena> But I do not know how to use ubuntu's source packages to compile it
[17:47] <aiena> I got wireshark to capture packets from the hardware with the usbmon driver
[17:48] <aiena> can you guide me on how to pick up linux sources from the distro
[17:52] <CarlFK> aiena: that is a huge subject that will take hours.  I have this in my history, it is 10 years old, but still relevant: https://slideplayer.com/slide/6865803/
[17:53] <CarlFK> aiena: I have a page somwhere that has more details about that, having trouble finding it
[17:53] <rbasak> tomreyn: I assume so
[17:55] <CarlFK> aiena: https://github.com/timvideos/litex-buildenv/wiki/FPGA_Linux_module  - if you want to talk to me about this,  /join #TimVideos
[17:55] <rbasak> aiena: there's usually a linux-headers-* package that corresponds to the linux-image-* that you have in use.
[17:59] <aiena>  /join #TimVideos
[23:19] <tsimonq2> Unit193: popularity-contest> ack