[00:16]  * slangasek wonders if there's a reason not to use COMPRESS=xz by default in initramfs-tools these days
[00:17] <Unit193> Last time I asked micahg, he said rsync/zsync'ability.
[00:17] <Unit193> Takes longer, but better sizes.  I've messed around with it.
[00:17] <slangasek> Unit193: that doesn't make sense.  Nobody cares about rsyncing of an initramfs by itself
[00:18] <Unit193> slangasek: I read squashfs when you said initramfs, I'm now wondering why I did that. >_>
[00:18] <slangasek> Unit193: to be clear, I'm talking about the initramfs generated on one's system in /boot
[00:18] <slangasek> hah ok
[00:18] <Unit193> So yes, sorry.  Nevermind.  That's supposed to be a "size vs speed" argument in the initramfs.
[00:19]  * Unit193 shrugs.
[00:20] <slangasek> the tradeoff of xz is that it takes longer to compress and uses more memory
[00:20] <slangasek> which is more of an issue on end-user systems than it would be on the buildds
[00:21] <sarnold> slangasek: fwiw zstandard is getting a lot of traction; if this image is to be trusted (ha) zstd should be significantly faster to decompress than xz (which is lzma-derived) https://raw.githubusercontent.com/facebook/zstd/master/doc/images/DCspeed5.png
[00:21] <sarnold> of course some systems build initrds far more often than they use the initrds
[00:21] <cjwatson> Oh joy another compression format
[00:21] <sarnold> cjwatson: yay! just what the world needed!
[00:21] <slangasek> sarnold: I'm not looking to adopt a fringe format, just musing over gzip vs. xz which we already support :)
[00:21] <cjwatson> My cup overfloweth
[00:22] <slangasek> sarnold: and faster decompress speed is not the interesting metric
[00:22] <Unit193> https://xkcd.com/927/
[00:22] <sarnold> it might be on those iot devices our parents keep buying
[00:22] <cjwatson> Compression speed for initramfs used to be a pretty significant issue not that long ago, especially because the triggers for update-initramfs are often only partially effective
[00:23] <cjwatson> I haven't measured it at all recently
[00:23] <slangasek> sarnold: in this context, xz is already plenty fast, and generally pays for its own decompress speed with the disk read savings
[00:23] <sarnold> it's still annoying :/
[00:23] <slangasek> but the compressing is costly
[00:24] <sarnold> if you just wanted fast you'd pick lz4
[00:24] <slangasek> see also: "oh joy another compression format"
[00:25] <sarnold> :)
[00:27] <cjwatson> unscientific test with my ~2yo laptop's latest initramfs, 13.9s for gzip, 2m21s for xz, default compression levels in both cases
[00:27] <cjwatson> this isn't my call any more thankfully, but I'd call that unacceptably slow for a default
[00:27] <sarnold> holy cow
[00:27] <sarnold> I already hate how long it takes to delete three kernels
[00:27] <sarnold> it it turned into "come back in ten minutes"
[00:28] <Unit193> sarnold: Enable lzop first, then purge 3 kernels, then flip back. >_>
[00:29] <sarnold> oh joy another compression format
[00:30] <slangasek> :D
[00:30] <slangasek> yeah, here I'd like the smaller size because plymouth+cryptsetup, but that's not a sensible default
[00:39] <sarnold> speed: lz4, lzop, zstd, gzip, xz   size: xz, gzip, zstd, lzop, lz4   http://pastebin.ubuntu.com/23951331/
[00:40] <sarnold> I'm kind of feeling like lzop won this one. :) good call Unit193 :)
[00:45] <Unit193> sarnold: Amusingly, I don't notice much of a difference when changing the initramfs-tools config.
[00:55] <tsimonq2> So is MOTU a subset of Core Dev?
[00:55] <tsimonq2> Little confused after reading this: https://wiki.ubuntu.com/UbuntuDevelopers#Ubuntu_Core_Developers
[00:55] <tsimonq2> Or is Core Dev *just* Main and Restricted?
[00:56] <Unit193> Oh speaking of which, I need to seek someone out about a free sync. >_>
[00:58] <sarnold> tsimonq2: I don't think there's a formal relationship between motu and core-dev; motu can upload to universe and multiverse, core-dev can upload everywhere
[00:58] <Unit193> sarnold: -backports?
[00:59] <sarnold> Unit193: is that still alive?
[00:59] <sarnold> I have no idea there..
[00:59] <Unit193> Not really.
[00:59] <Unit193> I think I have a few stale bugs there.
[01:00] <Unit193> sarnold: If you're feeling very sync happy, synergy can be force sync'd from experimental.  If not, I'll poke Mirv. :3
[01:00] <sarnold> Unit193: sorry, I can't do syncs, just -security pocket things; better poke Mirv (sorry Mirv)
[01:01] <Unit193> Ah, I thought you had super powers.  Alrighty.
[01:01] <tsimonq2> sarnold: Oh, so if one gets Core Dev, they inherit MOTU?
[01:02] <Unit193> MOTU is basically a subset of Core.
[01:03] <sarnold> hey, indeed, core-dev is a member of motu https://launchpad.net/~ubuntu-core-dev/+participation
[01:04] <tsimonq2> Unit193: That was my question: tsimonq2> So is MOTU a subset of Core Dev?
[01:04] <tsimonq2> Unit193, sarnold: Thanks :)
=== G_ is now known as G
[04:00] <psusi> so investigating a bug report has lead me to a regression in udev behavior that may be responsible for a few other bug reports I've seen: open a disk RW ( dd if=/dev/zero of=/dev/sda count=0 ), and udev deletes and recreates all partitions on that device
[04:00] <psusi> this causes the read only flag to be reset on the partitions, as well as causing unity to re-add previously removed partitions to the launcher.. anyone have any idea why the heck udev would be doing this?
[04:01] <psusi> i.e. is it something silly they built into udev or is it one of our event handling scripts?
[04:01] <psusi> ( stopping udev prevents this from happening, and running it with --debug shows that it is deleting and recreating the partition dev nodes )
[04:03] <sarnold> probably because detecting -actual- writes would be quite difficult
[04:03] <psusi> write, no write.. open r/w... modified partitions, or not... udev has no buisiness deleting and recreating partitions
[04:03] <sarnold> so detecting that it was opened for writing is the best that could be done, and they might assume that they'd then need to re-scan partition tables because _anything_ might have been done to it..
[04:03] <psusi> *especially* if the partitions already match the partition table ( this is what parted has always done to avoid this: if it already agrees with the new partition table, leave it alone )
[04:06] <psusi> the funny thing is that udev does not do this for loop devices, but does for scsi_debug
[04:14] <psusi> guess I can try removing all of the scripts...
[04:20] <psusi> looks like it's a rules script
[04:22] <psusi> hrm.. apparently it is persistent-storage.rules
[06:31] <Mirv> Unit193: done, please follow up that everything seems fine with it
[06:35] <Unit193> Mirv: Danke.
[06:42] <cpaelzer> rbasak: a lot depends on how kind or unkind the resolving of remaining qemu/dpdk issues goes
[06:43] <cpaelzer> rbasak: but I'll at nis to my maybe this week note and we can re-check next tuesday (2 days before FF then oO)
[06:43] <cpaelzer> we might even check on the Team hangout if I had a chance to start at least
[07:43] <Mirv> Unit193: there are two failing tests on s390x and powerpc that don't happen on Debian. I've started a rebuild of both but if they persist they will block the package.
[07:45] <Unit193> Mirv: I noticed, was going to ask about that because they were just fine: https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/7468050/+listing-archive-extra
[07:46] <Mirv> Unit193: heh, your build exactly lacks the powerpc (32-bit) and s390x ones :) so not sure.
[07:46] <Mirv> or your PPA
[07:47] <Unit193> Ah right, couldn't enable those.
[07:47] <Mirv> because s390x and powerpc are not allowed in normal PPAs currently. so just bad luck of not being able to catch it.
[07:47] <Mirv> yes
[07:48] <Mirv> it's nice though that most archs are nowadays available
[07:48] <Unit193> Yep, though I just use it for test builds, don't actually need 'em. :3
[07:48] <Mirv> Unit193: ah, and my mistake, I checked the wrong logs, they also do fail on debian experimental so actually a rebuild won't help
[07:49] <Mirv> Unit193: https://buildd.debian.org/status/package.php?p=synergy&suite=experimental
[07:49] <Unit193> Nobody even really cares about ppc nor s390x anyway. :3
[07:50] <Mirv> Unit193: don't say that when xnox listens ;)
[07:50] <Unit193> Too late, you pinged him. :D
[07:51] <Mirv> Unit193: anyway, the 32-bit powerpc and s390x desktop users are few enough so I think you could patch out the two clipboard tests for those archs temporarily..
[07:51] <Mirv> s390x is a very important architecture, but not really on desktop, 32-bit powerpc starts to be not very important
[07:53] <Mirv> Unit193: I filed bug #1662797 so that it can be tracked outside IRC
[07:53] <ubottu> bug 1662797 in synergy (Ubuntu) "1.8.7-stable+dfsg.1-1 FTBFS on s390x and powerpc" [Critical,New] https://launchpad.net/bugs/1662797
=== CRogers____ is now known as CRogers
[08:44] <CRogers> Hey folks. When an application opens a file, the file browsing dialog > is that handled by nautilus in ubuntu based systems generally?
[08:49] <sladen> CRogers: the "Open dialogue" comes from the Framework (Gtk, or Qt)
[08:49] <sladen> CRogers: but the application is responsible for opening the named file itself
[08:50] <sladen> CRogers: an alternative is to use eg. Nautilus (the file manager in Ubuntu) to pass a filename to an application
[08:50] <CRogers> sladen: Okay, so if I wanted to be able to get the file-path from the bar with ctrl+l like in nautilus, I'd have to talk to the gtk3 folks?
[08:51] <sladen> CRogers: https://developer.gnome.org/gtk3/stable/GtkFileChooserDialog.html
[08:51] <CRogers> sladen: Awesome, thanks.
[08:53] <sladen> CRogers: but Ctrl-l should work automatically...
[08:53] <CRogers> ctrl+l opens an empty location box.
[08:53] <CRogers> good for pasting, not for copying the current url in the open dialog.
[08:54] <CRogers> Nautilus replaces the file folder buttons with the actual current file path, which is much more useful.
[08:54] <sladen> CRogers: so you want the Nautilus file-open dialogue in your own application?
[08:54] <CRogers> I want to be able to copy the current working directory to nautilus.
[08:54] <CRogers> from the open dialog
[08:55] <sladen> copy to where
[08:55] <CRogers> Here's my use case:
[08:56] <sladen> do you want to spawn a new copy of nautilus at some particular starting directory?
[08:56] <CRogers> I'm opening or saving a file. I discover I need to edit something in that folder before uploading attachments, or saving something to that directory.
[08:56] <CRogers> So I open nautilus, and I want to be in that same directory.
[08:57] <CRogers> but the only way to get there is to navigate manually.
[08:57] <CRogers> Which is bogus. :)
[08:57] <CRogers> It's a complete waste of time.
[08:58] <CRogers> So it would be cool if I could copy and paste the file path from the open dialog, as one can with almost any other modern file browser available today.
[08:58] <sladen> or the opposite example: The image viewer 'eog' has "File->Open containing folder"  when all I really wanted was to copy-and-paste the path to a terminal
[08:58] <CRogers> exactly.
[08:58] <CRogers> It should be consistent.
[08:59] <CRogers> There's no reason to hamper that ability, just fill the blank location box with the current location.
[08:59] <CRogers> done deal.
[08:59] <CRogers> So who do I bug? :)
[09:01] <sladen> CRogers: file a bug on Launchpad!
[09:01] <sladen> CRogers: so that it doesn't get lost
[09:03] <CRogers> sladen: Will do. I want to get an idea of if the devs will consider it first, before I take the time.
[09:04] <CRogers> Because my bug reports are awesome, and contain graphics, and other useful imput, and they take hours to prepare.
[09:04] <CRogers> *input too. ;P
[09:08] <sladen> CRogers: remember to link  https://irclogs.ubuntu.com/2017/02/08/%23ubuntu-devel.html#t08:44  in the bug report for context
[09:09] <CRogers> sladen: Oh, okay, if you think that will help. I provide full context and graphics to illustrate with my bug reports in order to avoid making devs read through logs.
[09:11] <sladen> CRogers: yes, diagrams help
[09:12] <CRogers> sladen: thanks for your help.
[09:15] <cult-> hello
[09:16] <cult-> the maintainer of the package is not responding, but we have this issue, what else can be done? https://bugs.launchpad.net/ubuntu/+source/libodb/+bug/1588330
[09:16] <ubottu> Launchpad bug 1588330 in libodb (Ubuntu) "Incompatible builds of libodb and libodb-mysql" [Undecided,Confirmed]
[09:21] <CRogers> sladen: So it seems no one is maintaining the filechooser dialog.
[09:21] <CRogers> So I may have to submit a patch myself, or get someone outside to do it.
[09:21] <CRogers> In this case, a bug report will do very little good it seems.
[09:34] <rbasak> cpaelzer: that sounds fine, thanks.
[09:43] <rbasak> tjaalton: so sssd-ad has grown a universe dependency on adcli. Any opinions on how to resolve this? Should we just move sssd-ad to universe?
[09:44] <cpaelzer> infinity: doko: I beg a pardon (trying to not be annoying but getting attention can be hard) but if you could look at https://lists.ubuntu.com/archives/ubuntu-devel/2017-February/039664.html that would be great.
=== ackkk is now known as ackk`
=== Elimin8r is now known as Elimin8er
=== flixr_ is now known as flixr
=== underyx_ is now known as underyx
[09:46] <tjaalton> rbasak: it was requested on a lp bug
=== iahmad_ is now known as iahmad
[09:47] <doko> cpaelzer: well, the ultimate test would be to cross build the package ... I didn't check if setting the CC is still necessary
=== ackk` is now known as ackk
[09:48] <tjaalton> rbasak: sssd meta-pkg depends on sssd-ad
[09:49] <rbasak> bug 1590471, thanks
[09:49] <ubottu> bug 1590471 in sssd (Ubuntu) "add adcli as sssd dependency" [Medium,Fix released] https://launchpad.net/bugs/1590471
[09:49] <rbasak> Looks like I didn't realise adcli was in universe at the time.
[09:49] <cpaelzer> doko: if that is all, would any cross build do in your opinion?
[09:49]  * cpaelzer is heading to try his first cross package build
[09:50] <tjaalton> rbasak: :) it's hardly a huge burden to maintain if it's moved to main
[09:50] <rbasak> tjaalton: it sounds like the dependency isn't needed to fix the reported problem, and it was a bug in sssd that having adcli installed happened to mitigate?
=== Riddelll is now known as Riddell
[09:53] <doko> cpaelzer: any target arch? sure
[09:53] <cpaelzer> ok, thank you doko
[09:53] <tjaalton> rbasak: I need to think about it, after lunch
[10:00] <rbasak> tjaalton: sure, thanks
[10:10] <cpaelzer> doko: it builds fine following https://wiki.ubuntu.com/CrossBuilding
[10:10] <cpaelzer> doko: but, the old one we've had since Trusty also builds fine when taken from Debian without the Ubuntu Delta
[10:10] <cpaelzer> need to check the binaries
[10:11] <cpaelzer> doko: ha got it
[10:12] <cpaelzer> doko: without the fix the old cross build did not error out, but instead created x86_64 binaries in arm deb packages
[10:12] <cpaelzer> doko: that is now correct in the new packaging
[10:12] <cpaelzer> doko: thanks for your guidance
[10:23] <jbicha> CRogers: it would be better if you would file that bug with gtk+ directly (not Launchpad)
[10:24] <CRogers> jbicha: Yep, been talking with the #gtk+ devs
[10:24] <CRogers> thanks. :)
[10:24] <CRogers> It seems no one is maintaining that package at the minute.
[10:24] <CRogers> (gtk open dialog package)
[10:25] <CRogers> So I'll likely need to patch it myself.
[10:25] <CRogers> Or get someone tremendously cool to do it.
=== SotK_ is now known as SotK
[10:35] <cult-> if there's no package for a standard architecture such as amd64, can I do anything else than filing a bugreport or contact the maintainer?
[10:35] <cult-> can somebody here trigger the build for it?
[10:45] <ginggs> cult: you could attach 'no-change rebuild' debdiffs for each package you want rebuilt to the bug, and then subscribe ubuntu-sponsors (see LP: #1515031 for an example)
[10:45] <ubottu> Launchpad bug 1515031 in llvm-toolchain-3.6 (Ubuntu) "Release no-change rebuild for ocaml transition" [Medium,Fix released] https://launchpad.net/bugs/1515031
[10:46] <ginggs> cult- ^^
[10:47] <cult-> i sent a letter to mailing list, will see if someone do it
=== marcusto_ is now known as marcustomlinson
=== ikonia_ is now known as ikonia
=== _salem is now known as salem_
[11:32] <Laney> wow, some old stuff
[11:32] <Laney> thanks to whoever did a moderation run on -devel@
[11:37] <cjwatson> yw
[11:38] <Laney> I used to do it when I got moderation email from DMB lists
[11:38] <cjwatson> cult-: not seeing your mail on any mailing list I've checked.  where did you send it?
[12:07] <mapreri> jbicha: It seems to me you discarded all the past liferea merges entries in the changelog in your last upload.  Please don't do that.
[12:11] <cpaelzer> pitti: you might still remember bug 1630909 - that now haunts me in similar fashion on ppc64el as well
[12:11] <ubottu> bug 1630909 in autopkgtest (Ubuntu) "failing console access on s390x" [Undecided,New] https://launchpad.net/bugs/1630909
[12:11] <cpaelzer> pitti: I was able to reconfig the system to spawn actual consoles on the ttyS provided (no root console, nomal ones)
[12:12] <cpaelzer> pitti: but when using user/password it gets over the first steps but then fails http://paste.ubuntu.com/23953966/
[12:12] <cpaelzer> pitti: I go for lunch now and will try to make the S1 a root console to avoid needing the user/pass logic
[12:12] <xnox> cpaelzer, you can't create extra consoles like that
[12:12] <xnox> cpaelzer, you should use -no-defaults such that slcp console is not configured by default
[12:12] <cpaelzer> xnox: ppc
[12:12] <xnox> and such that you can define slcp console by hand, and redirect it to where you want.
[12:12] <cpaelzer> xnox: ppc
[12:12] <xnox> right, but report is about s390x =)
[12:13] <xnox> fair enough
[12:13] <cpaelzer> sure, there we went the way you describe
=== hikiko is now known as hikiko|ln
[12:13] <jbicha> mapreri: Ubuntu-specific changelog entries get discarded when packages are synced, if you want to see the full changelog I think you really ought to visit https://launchpad.net/ubuntu/+source/liferea/+changelog
[12:13] <cpaelzer> xnox: but we didn't get a login either back then - I just referred to the bux as it is simewhat related - clearly not the same one
[12:14] <cpaelzer> xnox: and I agree, with defaults you always will have the special sclp one
[12:14] <cpaelzer> xnox: have you ever tried to get a totally sclp free guest - I'm not even sure that is supposed to work
[12:14] <mapreri> jbicha: from what I see on https://launchpad.net/ubuntu/+source/liferea/+publishinghistory it hasn't been synced in a looooong time; like last time has been gutsy
[12:14] <cpaelzer> pitti: if you have any extra info what it is really waiting on in the pastebin let me know
[12:15] <cult-> cjwatson: ubuntu-app-devel@lists.ubuntu.com
[12:16] <cult-> Your mail to 'Ubuntu-app-devel' with the subject ...  Is being held until the list moderator can review it for approval.
[12:16] <mapreri> jbicha: (+ I find that web page collecting changelog entries awful to read, I really prefer to see a plain text thing)
[12:18] <jbicha> mapreri: keeping old (duplicate or obsolete) Ubuntu-specific changelog entries makes the diff more cluttered when looking at new Debian versions
[12:19] <mapreri> how so?
[12:19] <mapreri> the changelog is the one thing that merge-o-matic manages to merges correctly...
[12:19] <mapreri> And it's nice to be able who introduced a particular change in debian
[12:20] <mapreri> err
[12:20] <mapreri> s/debian/ubuntu/
[12:21] <cjwatson> cult-: might be better to just say here what the package is
[12:21] <cult-> Bug report: https://bugs.launchpad.net/ubuntu/+source/libodb/+bug/1588330 Launchpad: https://launchpad.net/ubuntu/+source/libodb/2.4.0-1
[12:21] <ubottu> Launchpad bug 1588330 in libodb (Ubuntu) "Incompatible builds of libodb and libodb-mysql" [Undecided,Confirmed]
[12:22] <cult-> Apparently the library doesn't support other architectures than s390x or the GCC dual ABI fiasco is the issue?
[12:23] <cult-> issue under xenial, but i see s390x only for all above.
[12:26] <xnox> cult-, libodb was build in wily (old abi) everywhere, and in xenial (new abi; on s390x only)
[12:26] <xnox> because that's when s390x was added.
[12:26] <xnox> cult-, rebuilding libodb may be required.
[12:26] <cult-> but how about amd64 and the others for the new abi? either way libodb and libodb-* connectors are not compatible
[12:27] <cult-> need rebuild for sure, but when it'll happen?
[12:30] <jbicha> mapreri: I don't use merge-o-matic for diffs, I usually do it manually but sometimes I'll use the patches.ubuntu.com link on tracker.debian.org
[12:32] <jbicha> so the Ubuntu-specific changelog entries are not reliable if a package is ever synced, and if the package is not syncable it can be a very large amount of duplication
[12:32] <jbicha> I think the important part is that d/changelog lists the remaining Ubuntu diff
[12:33] <jbicha> if there's an issue or interest in old Ubuntu versions, you'll probably need to pull from Launchpad anyway
[12:39] <seb128> some people like to keep all the old changelog entries in the changelog when merging
[12:45] <rbasak> seb128: AIUI, that's the normal case. As a sponsor that's what I expect.
[12:45] <seb128> rbasak, dunno about "normal", I never understood why people were bothering and personally never did it
[12:45] <rbasak> I did it because my sponsors told me to :)
[12:46] <seb128> right, as said I can't explain why I never understood but some people seem attached to it
[12:46] <rbasak> The problem is that debian/changelog is linear. With Ubuntu being effectively a branch of Debian, merges aren't linear.
[12:46] <seb128> though if a package get in sync and go back to have a diff those people don't go to dig and merge back the old changelogs
[12:46] <rbasak> Our git workflow tooling assumes you will do it. I wrote a git-merge-changelogs tool that does the same thing as dpkg-merge-changelogs but using tree-ishs.
[12:47] <seb128> how do you handle packages that managed to be in sync for some time and diverge again?
[12:47] <rbasak> Yeah. That's just part of the broken-ness of an enforced-linear changelog.
[12:47] <seb128> I just consider my merges as a sync with a new delta :p
[12:47] <seb128> the changelog summarize the delta
[12:47] <seb128> so all good ;-)
[12:48] <rbasak> That's fine. But for sponsoring, I will require the merged changelog I think.
[12:48] <rbasak> It's very difficult for sponsorees otherwise. They never know what to do.
[12:48] <cjwatson> I find it a bit surprising when people drop the old changelog entries on a merge, but it doesn't really bother me either way.
[12:48] <rbasak> And it seems to be consensus to do it this way, even if you disagree and I don't object to that particularly.
[12:48] <seb128> yeah, fair enough
[12:48] <cjwatson> I agree consistency for sponsored uploaders is good though.
[12:49] <seb128> it makes the merge a bit more difficult and the diff a bit bigger
[12:49] <seb128> but as said I don't care much either way either
[12:49] <rbasak> Tooling FTW. Not an issue with our git workflow  :-)
[12:49] <seb128> what git workflow?
[12:50] <seb128> I though the current recommended way to submit changes was debdiffs
[12:50] <rbasak> Dates back to https://lists.ubuntu.com/archives/ubuntu-devel/2014-August/038418.html
[12:50] <seb128> did we go back to some UDD based on git without me noticing?
[12:50] <rbasak> https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow
[12:50] <rbasak> nacc and I are working on reintroducing UDD-like stuff with git.
[12:50] <rbasak> It's working pretty well ATM.
[12:51] <rbasak> Makes merges much easier.
[12:51] <seb128> +1 from me
[12:51] <seb128> I just though we were not there yet
[12:51] <rbasak> https://code.launchpad.net/~usd-import-team/+git are our imported branches.
[12:51] <seb128> do we have auto import from all uploads to git now?
[12:51] <rbasak> For a server-focused subset ATM, while we flush out issues.
[12:51] <rbasak> But nacc or I are happy to import anything else manually on request.
[12:51] <seb128> nice
[12:52] <rbasak> I also have Launchpad queue processing for new and unapproved working in a branch.
[12:52] <rbasak> For SRU reviews.
[12:52] <seb128> rbasak, somebody should probably update http://packaging.ubuntu.com/html/udd-intro.html
[12:52] <rbasak> Yeah, there's plenty of outstanding stuff to sort out still.
[12:53] <rbasak> It is usable for anyone who's prepared to deal with the shortcomings/lack of documentation. I don't think we're ready for everyone yet.
[12:56] <seb128> k
[12:56] <seb128> rbasak, thanks for the info, it's good to read that there is some ongoing work on that, I didn't see any recent activity on ubuntu-devel@ or IRC that hinted that was the case so it's a nice surprise ;-)
[12:58] <xnox> cpaelzer, i wonder if the kvm virtual machines should have network interfaces mac address named or not by default.
[12:59] <cpaelzer> xnox: s390 network devices you mean?
[13:00] <cpaelzer> xnox: I prefer to have virtual naming the same as HW does - so based on the subchannel id
[13:00] <xnox> cpaelzer, no, any virtio net devices. e.g. currently they end up as eth0, but imho emx5254003c4ea3 is better (mac address 52:54:00:3c:4e:a3)
[13:00] <cpaelzer> xnox: I havent checked in a while what the naming atm actually is
[13:00] <cpaelzer> I'd expect enps# things
[13:00] <xnox> not in qemu-kvm vms it seems
[13:01] <cpaelzer> xnox: ens3, enp0s0, ... those are the ones I found
[13:01] <xnox> huh
[13:02] <cpaelzer> the first on my local x86 and the second on ppc
[13:02] <cpaelzer> just checking on the guests I have open atm
[13:03] <cpaelzer> xnox: I agree that on s390 we have the old style naming of ethX
[13:03] <cpaelzer> xnox: I'd personally prefer encXXXX to match the host there
[13:03] <cpaelzer> just as we do on other architectures
[13:03] <xnox> cpaelzer, can we do encXXXX for virtio though?
[13:04] <cpaelzer> yes
[13:04] <cpaelzer> virtio effectively is a special subchannel
[13:04] <cpaelzer> type
[13:04] <xnox> why is not happening though?
[13:04] <cpaelzer> they all have IDs and new definitions of contril units for (virtio)
[13:04] <cpaelzer> xnox: I must admit I don't know why it isn't done yet
[13:05] <cpaelzer> xnox: maybe the enXXXX rule only applies to OSA?
[13:05] <cpaelzer> but should in a virt env to virtio-net as well on s390
[13:05] <xnox> indeed it is ens3 on x86_64
[13:06] <xnox> let me check what's going on in qemu case, and why it's not enc =(
[13:06] <cpaelzer> xnox: http://paste.ubuntu.com/23954180/
[13:06] <cpaelzer> xnox: one of them is the net devices, I can't remember which of the numbers withotu checking
=== hikiko|ln is now known as hikiko
[13:10] <xnox> cpaelzer, yeah i digged into /sys/devices/css0/0.0.0002/0.0.0001 ends up being the virtio device.
[13:28] <cult-> xnox: cjwatson: fedora had the same issue with libodb, they rebuilt it and all is fine.
[13:29] <xnox> cult-, i will rebuild it all, and SRU as well.
[13:29] <xnox> in a moment.
[13:29]  * cult- is excited
=== stokachu_ is now known as stokachu
=== tsdgeos_ is now known as tsdgeos
=== herb_ is now known as herb
[14:24] <caribou> dosaboy_: niedbalski: doko: barry: Here are the results of th python/gcc perf comparaison : https://goo.gl/0BIsBu
[14:26] <cult-> xnox: how often launchpad content is updated?
[14:26] <cult-> is it instant
[14:29] <xnox> cult-, yes... however SRU takes about 1-3 weeks to complete.
[14:30] <xnox> there is paperwork, and multiple eyeballs to review everything =)
[14:30] <cult-> uh
[14:30] <xnox> cult-, what are you after?
[14:30] <cult-> i m just bored to always build it bymself
=== rumble is now known as grumble
[14:38] <andyrock> fossfreedom_: ping
=== dosaboy_ is now known as dosaboy
[15:01] <caribou> seb128: who's looking after gtk+3.0 aside from Laney who's apparently not here ?
[15:02] <caribou> seb128: I'm about to sponsor LP: #1550983 for Y & X
[15:02] <ubottu> Launchpad bug 1550983 in One Hundred Papercuts "Fails to start with "Couldn't open libGL.so.1" (missing dependency?)" [High,Confirmed] https://launchpad.net/bugs/1550983
[15:03] <seb128> caribou, Laney is here, what do you mean? (he might be at lunch though)
[15:03] <caribou> seb128: his status was /away
[15:04] <seb128> caribou, jbicha is sponsoring uploads sometime and a few other desktopers, including me do as well
[15:04] <seb128> caribou, but sure, please go ahead and sponsor those changes
[15:04] <caribou> seb128: no big deal, just want to check before sponsoring the SRU
[15:04] <seb128> thanks
[15:04] <caribou> np
[15:17] <Laney> caribou: I was at lunch - you can't expect to find somebody at their screen all the time :-)
[15:18] <caribou> Laney: orly ? :-p
[15:18] <Laney> The normal procedure would be for you to ask your question, and then for me to reply when I get back
[15:19] <caribou> Laney: I try to avoid asking directly to people when I suspect that other might know (seb in that caseà
[15:19] <seb128> caribou, you should just ask on the channel ;-)
[15:20] <seb128> so whoever you ping has the msg and others can also reply
[15:21] <Laney> anyway
[15:22] <Laney> thanks for uploading
[15:27] <cult-> xnox: is the process visible somewhere?
[16:12] <nacc> seb128: thank you for reminding me, I need to send a follow-up e-mail to ubuntu-devel
[16:13] <seb128> nacc, hey, yw! ;-)
[16:13] <seb128> nacc, thanks for the work you put into that
[16:16] <nacc> seb128: of course! it's all rbasak's idea(s) :) the big thing that is preventing (which is too strong of a word, really) from broad adoption is primarily the LP side of things. It needs some work on the server side; and additionally, we're still fleshing/testing out how to be fully dgit compatible, etc.
[16:19] <seb128> it probably makes sense to polish a bit more and get feedback from early adopter before recommending it to contributors, but good to know that it's getting there
=== bluesabre_ is now known as bluesabre
[16:23] <nacc> seb128: agreed :)
[16:23] <xnox> cult-, subscribe to the bug report in question on launchpad, and you will get email notifications when it is progressing as people update the bug report as it goes through the SRU process. you can read about SRU process at http://wiki.ubuntu.com/StableReleaseUpdate
[16:38] <phunyguy> hey guys... can anyone in here tell me how Ubuntu's kernel modules are so small?  compiling a kernel manually in $another_distro, even with module compression turned on results in modules 3x the filesize of Ubuntu's....  Just curious really.
[16:39] <phunyguy> I am compiling with the Ubuntu config btw.
=== acheronuk_ is now known as acheronuk
[17:15] <camako> tjaalton, ping
[17:18] <camako> tjaalton, I am setting up my dev env to make changes for the new platform-mir in Mesa. I was told by RAOF to do 'debcheckout mesa' and use the ubuntu branch. I was expecting the platform-mir to be there but it's not. I have a copy of it, but is there a more authoritative way to get and apply it?
[17:56] <tjaalton> camako: what does debcheckout do?
[18:02] <tjaalton> camako: it's a quilt patch
[18:02] <tjaalton> in debian/patches
=== Skuggen_ is now known as Skuggen
[18:34] <fossfreedom_> andyrock: hi!
[18:34] <camako> tjaalton, I 'd like to know how we modify the mesa patch, send an MP against it, have it reviewed and merged?
[18:37] <tjaalton> camako: just send me the new version ;)
[18:37] <tjaalton> or put it somewhere
[18:37] <camako> tjaalton, ok where do I get the mesa from?
[18:38] <camako> I guess 'debcheckout mesa'?
[18:38] <camako> it checks out a mesa tree
[18:38] <tjaalton> maybe, does it clone the git repo
[18:38] <camako> tjaalton, yes
[18:38] <camako> I see your commits at the tip
[18:38] <tjaalton> ok, so ubuntu branch
[18:38] <camako> yep
[18:39] <camako> tjaalton, so the patch is in the debian/patches directory of the mesa source tree in Zesty?
=== fossfreedom_ is now known as fossfreedom
[18:40] <tjaalton> yes
[18:41] <tjaalton> that branch has 13.0.4, i have 17.0.0~rc2 locally
[18:41] <tjaalton> rc3
[18:41] <tjaalton> how quickly do you need it in zesty?
[18:43] <tjaalton> wondering if you should prepare it for 17 instead
[18:43] <tjaalton> final should arrive this friday
[18:43] <camako> tjaalton, doesn't have to be that quickly... First Mir 0.26.1 needs to land (expected in the next day or two)... Then I drop my changes on it and test and have it reviewed by you and RAOf, etc
[18:43] <camako> tjaalton, I don't mind moving it to 17
[18:44] <tjaalton> ok, let me update the branch
[18:45] <camako> tjaalton, it'd be good if my Zesty environement can support the dependencies... would like to avoid building newer versions of its dependencies
[18:45] <tjaalton> done, pull the branch
[18:45] <camako> tjaalton, last time I use tip of Mesa tree, it depended on a newer version of DRM
[18:45] <camako> used*
[18:45] <tjaalton> zesty should have latest libdrm
[18:45] <camako> ok let me see
[18:46] <tjaalton> proposed at least
[18:46] <tjaalton> .75
=== JanC_ is now known as JanC
[18:47] <camako> tjaalton, ok I have the updated tree
[18:48] <camako> conveniently platform-mir patch is in there :-)
[18:48] <tjaalton> of course :)
[18:49] <camako> tjaalton, I have my own way of building the mesa treee, but perhaps there is an easier way to apply the (set of) patch(es) and build it in one go?
[18:50] <tjaalton> haven't used quilt before?
[18:50] <camako> no I haven't
[18:50] <camako> and I see that this tree is different
[18:51] <tjaalton> just apply it directly, do your changes and send me the git diff
[18:52] <camako> tjaalton, ok
[18:52] <tjaalton> or better yet, git commit and format-patch -1
[18:52] <camako> sure
[18:52] <tjaalton> i need to run
[18:53] <camako> tjaalton, thanks for the clarifications... goon night
[18:55] <camako> good*
[20:05] <robert_ancell> slangasek, I noticed you are assigned to follow up on the snapd-glib SRU exception request. Is there anything I need to do for this?
[21:15] <acheronuk> juliank: hi. is that apt fix for hashsum mismatches on those icon tars likely to backported to xenial in any future update?
[21:16] <juliank> acheronuk: yes.
[21:17] <acheronuk> juliank: thnx. are you able to say if that may be soonish?
[21:17] <juliank> acheronuk: Why do you ask?
[21:17] <juliank> Are there any files in xenial with the same hashes?
[21:19] <acheronuk> two reasons. (1) kubuntu may at some want to backport the plasma-discover taht triggers that with it's apt config file. (2) KDE Neon who build on xenial have just hit that bug
[21:19] <juliank> I see.
[21:19] <juliank> It will probably take a month or so, though.
[21:20] <acheronuk> (1) is a maybe, possibly never (2) is not really ubuntu's problem, but I have some interest there
[21:20] <juliank> First I gotta pick them into yakkety
[21:20] <acheronuk> ok. was just asking for info. not requesting that it's done asap or anything
[21:20] <acheronuk> thank you :)
[21:20] <juliank> And there are multiple patches I want to pick, not just that one. A lot has been going on since 1.3.1
[21:39] <juliank>  date -d "0-12-25" "+%Y-%m-%d" fails on armhf and i386, but works elsewhere?
[21:42] <juliank> ah, ti's 36 bits large...
=== foli_ is now known as foli
=== plars is now known as plars-away