[03:05] <Decorater> alright so, I want to make my own ubuntu distribution that adds an special section to the ELF file format that windows has as it could be benefitcial
[03:05] <Decorater> what are all the repos that I would have to clone to be able to make it happen?
[03:05] <Decorater> I can clone it using git for Windows btw.
[03:06] <tsimonq2> Decorater: Hey! :)
[03:06] <Decorater> hi
[03:06] <tsimonq2> Decorater: It's a lot more complex than you think
[03:06] <tsimonq2> Seriously, turn back now. :P
[03:06] <tsimonq2> BUT
[03:06] <tsimonq2> If you REALLY want to, I can tell you about some core stuff and where to find them
[03:07] <tsimonq2> But otherwise with that Windows thing, you're on your own, Decorater ;)
[03:07] <Decorater> yeah I want to add the rsrc section from the PE format headers to the ELF format as it would solve a ton of issues including embedding icons for terminal applications
[03:07] <Decorater> instead of having to ship an .desktop file
[03:07] <tsimonq2> Hold on, let's see if I can find this easily...
[03:08] <tsimonq2> Decorater: How low do you want to go here?
[03:08] <tsimonq2> Is this kernel-level?
[03:08] <tsimonq2> This ELF stuff is a little over my head ;)
[03:09] <Decorater> Well lets say I want it to be an special but optional section that would allow embedding of icons similar to how you can on Windows and display the embedded version in file browser and in terminal
[03:11] <tsimonq2> Decorater: Take a look at tasksel and the various seeds Ubuntu has. If you find a package that has what you're looking for, run "apt source PACKAGE" in your terminal to get the code. Do whatever you want to it, then rebuild it.
[03:11] <tsimonq2> Decorater: That's the tl;dr here.
[03:12] <tsimonq2> Decorater: I would highly suggest reading through this, this can really help you understand what I'm saying: https://www.debian.org/doc/manuals/maint-guide/
[03:13] <tsimonq2> Decorater: Otherwise, without more specifics, I hope this can point you in the right direction. :)
[03:13] <Decorater> ok
[03:14] <tsimonq2> Decorater: Good luck ;)
[03:17] <Decorater> Also I plan to on the distribution I am thinking of making not shipping python 3.x but 3.x only. Specifically 3.5+ because of asyncio.
[03:17] <Decorater> which would mean the python parts would need converted to 3.x
[03:18] <tsimonq2> Feel free. And don't be afraid to contribute what you modified back to us. ;)
[03:18] <Decorater> ok
[03:18] <tsimonq2> Decorater: You might want to look into this effort: https://lists.ubuntu.com/archives/ubuntu-devel/2017-January/039648.html
[03:18] <tsimonq2> "I'd like to enable Python 3.6 as a supported version early in the Zesty+1 cycle, with a goal of 3.6 as default-and-only in the 18.04 LTS."
[03:18] <tsimonq2> So it's coming either way.
[03:19] <Decorater> I see
[03:20] <Decorater> if I noticed correctly it seems that parts of sudo and apt are in python? At least on my 16.10 or so VM.
[03:21] <tsimonq2> I'm unsure.
[03:21] <Decorater> alright
[05:25] <Decorater> I wonder now when the linux kernel would start to ship an modified version of the latest v1.2.11
[08:23] <rbasak> nacc: usd queue in master> ack
[08:45] <Unit193> ginggs: Hah, saw the t-d upload, figured it'd be you that did it. :P
[08:46] <ginggs> Unit193: how so?
[08:47] <Unit193> You seem to like to poke around in universe at the cool things nobody else cares to.  Also saw your comment on the Debian bug report (Mirroring what I happened to say in -motu too. :P )
[08:48] <Unit193> https://launchpadlibrarian.net/314653678/buildlog_ubuntu-zesty-s390x.telegram-desktop_1.0.14-1ubuntu1_BUILDING.txt.gz  Heh:  #error "Only little endian is supported!"
[08:49] <ginggs> Unit193: ha, ok :)
[08:49] <Unit193> (Nice job!)
[08:50] <ginggs> I wanted to test armhf before I uploaded, but my rpi3 ate three of my sd cards while upgrading from 14.04 to 14.10
[08:50] <Unit193> Ouch.
[08:50] <ginggs> err. i mean 16.04 to 16.10
[08:51] <ginggs> tried a different rpi3 and was able to upgrade 16.04 -> 16.10 -> 17.04 without too much hassle
[08:53] <Unit193> I wonder if the version on mentors can easily be patched to not use microsoft-gsl though...
[08:54] <ginggs> rpi3 eating sd cards seems to be a thing
[08:54] <ginggs> https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=140845
[08:55] <Unit193> Wow, that's not cool..
[08:55]  * Unit193 is un *armed.
[09:02] <Decorater> I just thought of it
[09:03] <Decorater> what if there was some sort of api endpoint that would allow an EOL version of Ubuntu to be able to upgrade to latest directly without reinstalling Ubuntu itself.
[09:03] <Decorater> that is for future EOL versions
[09:09] <cjwatson> EOL versions can already upgrade without reinstalling.
[09:10] <cjwatson> Though possibly not directly to latest; they may have to go via the next non-LTS release or the next LTS release, as appropriate.
[09:25] <jbicha> any core dev care to sponsor LP: #1674773 today?
[09:27] <tjaalton> jbicha: the debdiff doesn't look right :)
[09:27] <jbicha> tjaalton: what's it supposed to look like? it's a diff of the debian/ directory?
[09:28] <jbicha> have I been doing it wrong for years?
[09:29] <tjaalton> jbicha: you should run debdiff old.dsc new.dsc
[09:29] <tjaalton> so it has the diff of the whole package
[09:31] <Laney> That's not that nice for upstream bumps IMO
[09:31] <Laney> especially if it contains binary files like an icon theme might ...
[09:32] <tjaalton> true about binary files yes
[09:32] <tjaalton> but ok
[09:34] <tjaalton> I don't know how to sponsor that diff though ;)
[09:34] <Laney> Use uscan to download the new version, unpack it, copy debian/ over, apply the patch
[09:34] <tjaalton> alright
[09:35] <tjaalton> jbicha: do you have the package built somewhere, would be easier to just dget & debsign..
[09:49] <nanodrone> where's the touch handles code for unity located?
[10:00] <sil2100> cpaelzer: hey! I'm looking at the openssh SRU for yakkety right now - I see in the Bileto silo that there are some failed autopkgtests
[10:00] <sil2100> cpaelzer: was that expected/transient?
[10:03] <cpaelzer> sil2100: I explained in the bug already in more detail, but TL;DR expected since always failed that way
[10:04] <sil2100> Thanks :)
[10:04] <cpaelzer> sil2100: commend #25 is the one with the details
[10:04] <cpaelzer> "comment" even
[10:05] <cpaelzer> sil2100: once they are in <release>-proposed we have to make sure only "the same" issues pop up, but other than that that should be ok
[10:07] <cjwatson> sil2100: Yep, fixed in zesty, but the fixes are quite involved.
[10:07] <cjwatson> It should be OK as long as they haven't got worse, indeed.
[10:36] <sil2100> cjwatson: ok, thanks!
[10:37] <sil2100> cpaelzer: hah, one little thing - https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1670745 has the [Impact] part copy-pasted from the template, could you fill it in with real impact contents?
[11:07] <sil2100> cpaelzer: ok, I dived into the bug so I know the Impact of it so I can continue with the review, but please be sure to fill that up
[11:07] <sil2100> cpaelzer: (for documentation's sake)
[11:39] <sil2100> doko: hey! Could you retry https://launchpad.net/ubuntu/+archive/test-rebuild-20170322.1/+build/12251212 from the test-rebuild?
[11:39] <cpaelzer> sil2100: will fill it
[11:43] <cpaelzer> sil2100: done
[11:44] <sil2100> cpaelzer: thanks!
[12:19] <jbicha> tjaalton: I got distracted, here you go: http://people.ubuntu.com/~jbicha/adwaita-icon-theme/
[12:55] <tjaalton> jbicha: cool, thx
[12:56] <doko> sil2100: now built
[12:56] <tjaalton> jbicha: uploading
[12:58] <sil2100> doko: thanks, so it's a flaky test as I remembered
[13:42] <rbasak> slashd: around? About bug 1176046.
[13:45] <rbasak> slashd: I'm sure I asked you this before, and you answered, but I can't find your answer anywhere, sorry. Are you proposing your debdiff in commit 40 as ready for upload to Trusty? Or is it still in progress? And do you have a debdiff for the transitional package in Xenial please? That needs to go in first.
[14:44] <nacc> rbasak: thanks -- does that mean you were able to test or will test? :)
[14:55] <rbasak> nacc: I will test :)
[14:55] <rbasak> nacc: I was going to just continue to use it to do SRU reviews, which will probably be next week now. Unless you'd like me to test sooner?
[15:00] <nacc> rbasak: not urgent, just was curious
[15:26] <stgraber> apw: just did a test and screen indeed won't attach to existing fifos when built with sockets... we're looking at a way to build screen so that it supports connecting to both to deal with the upgrade path
[15:27] <stgraber> apw: because unfortunately it's a change that's going to happen at some point, sockets have been the default since 2011 or so and the next screen release won't have fifo support anymore
[15:29] <stgraber> apw: I suspect we may need to make do-release-upgrade aware of this and not spawn screen when doing the next LTS to LTS upgrade as I expect 18.04's screen won't have a clue what a fifo is
[15:30] <cyphermox> jbicha: gdm3 still fails to start
[15:31] <cyphermox> maybe I'll reinstall with ubuntu-gnome iso though, just in case there's something else off
[15:35] <apw> stgraber, what about switching to tmux ...
[15:35] <apw> (and i don't mean that flippantly)
[15:44] <stgraber> apw: not sure what kind of backward compatibility tmux provides as far as their internal protocol, but yes, if they're doing something sane, that'd be an option
[15:45] <stgraber> having screen support upgrading from fifos to sockets would be nice in general for anyone upgrading, just not sure how much work that'll be to sort out...
[15:51] <apw> stgraber, yeah, though i guess most people upgrading will reboot after upgrade so will not have an old session after the upgrade
[15:52] <nacc> rbasak: re: LP: #1680125, did my pseudo-algorithm make sense?
[15:52] <Laney> doesn't the upgrade process start a screen though?
[15:53] <rbasak> nacc: which bit?
[15:53] <nacc> rbasak: c#2 -- wrapping pristine-tar
[15:54] <nacc> rbasak: rather than changing the algorithm (which is messy anwyays because gbp-import-orig is inflexible)
[15:54] <rbasak> Ah
[15:54] <rbasak> I'm not sure wrapping pristine-tar is useful. As you point out, that's what usd effectively does already.
[15:55] <rbasak> Depending on how hard it is to fix it in the local pristine-tar branches, it might not be worth fixing this then I guess.
[15:55] <nacc> i mean it'd be pretty trivial to just let the tool figure out which branches should be renamed
[15:55] <nacc> to extract an orig
[15:55] <nacc> i don't think we can trivially fix the local pristine-tar branches
[15:55] <rbasak> When importing, we could check to see if the orig is available in the correct pristine-tar branch, and if not, then find it and add it perhaps? With no other change to the current upstream import mechanism.
[15:56] <rbasak> Are we correctly handling the case where the Ubuntu orig tarball differs from Debian currently?
[15:56] <nacc> "if the orig is available in the correct pristine-tar branch" is not algorithmically implementable
[15:56] <rbasak> Why not?
[15:56] <nacc> rbasak: iirc, i think so -- but i'll check
[15:56] <rbasak> We know which distro we're importing at import time.
[15:57] <rbasak> And we know the orig tarball name/version.
[15:57] <nacc> rbasak: yes, but how do you look in the branch to know what was imported
[15:57] <nacc> rbasak: that doesn't help you for the pristine-tar branches
[15:57] <rbasak> pristine-tar list.
[15:57] <rbasak> (and cached if needed, presumably)
[15:57] <nacc> rbasak: ah, didn't know about that command
[15:58] <nacc> rbasak: ok, i'll look at that today
[15:58] <rbasak> nacc: thanks, but no rush!
[15:58] <rbasak> Now that there's a snap, it really is unlikely I'll hit it in practice again I think, especially now I know about it.
[15:58] <rbasak> (an updated snap I mean - thanks for that!)
[15:59] <nacc> still pending of course
[16:14] <nacc> cpaelzer: re: LP: 1677578, with 17.04 -- that's the same php-imagick (i believe) as you tested with ondrej's upstream
[16:14] <nacc> cpaelzer: are you able to confirm that for me, just to be sure?
[16:14] <cpaelzer> nacc: ? what is the question
[16:14] <cpaelzer> nacc: in the bug?
[16:15] <nacc> cpaelzer: so your last two comments are: it happens with 17.04 and then it doesn't happen with ondrej's ppa
[16:15] <nacc> afaict, 17.04 and ppa have the same php-imagick (sans delta from ubuntu, but should be irrelevant)
[16:16] <cpaelzer> nacc: yeah php-imagick is the same then other than the Delta
[16:16] <cpaelzer> nacc: but php is obviously a big step from 7.0... to 7.1.3
[16:16] <nacc> cpaelzer: ack, ok -- will look at php
[16:16] <nacc> right but if it's a bugfix, i believe they are backporting to 7.0
[16:16] <nacc> and i have a newere upstream in a ppa
[16:17] <cpaelzer> nacc: as I wrote in the bug, I don't think somebody coded that as a bugfix
[16:17] <cpaelzer> nacc: I think they changed how php-cgi works in general
[16:17] <cpaelzer> nacc: to really kill it if hit by max-exec while in plugins
[16:17] <cpaelzer> nacc: but you might sift through the release notes and commut log and might find it
[16:18] <nacc> cpaelzer: any chance you can try https://launchpad.net/~nacc/+archive/ubuntu/php7testbuilds if you ahve the testcase around? on 16.04 -- if not, i will do it, no worries
[16:18] <cpaelzer> until wife or kids coe in and punch me I can try to help
[16:19] <nacc> cpaelzer: thanks, figured you might have the env already setup or so
[16:23] <nacc> rbasak: i'm 100% on board with what you are suggesting, but note that it would require a re-import to fix existing imports
[16:23] <nacc> rbasak: which is probbly fine, just fyi
[16:28] <rbasak> nacc: I think that's OK. We can defer doing that until we need it for some other reason.
[16:28] <rbasak> nacc: but again, no rush to even start addressing it :)
[16:32] <nacc> rbasak: ack, it's pretty easy to do, i think
[16:54] <nacc> rbasak: also, this will end up requiring lpusip/upstream/debian/ and lpusip/upstream/ubuntu/, if htat's ok with you :)
[17:08] <robru> Laney: oh, uh, you rolled to production without merging I guess. https://code.launchpad.net/~robru/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/322132
[17:47] <rbasak> nacc: that seems reasonable, given that they could be different.
[17:47] <nacc> rbasak: yep
[18:19] <Laney> robru: I didn't see a merge proposal, so yes?
[18:21] <Laney> done that one, merci
[18:21] <robru> Laney: I think there's some confusion with the branches because I pulled you commits from somewhere but then in proposing the MP it's trying to merge commits that are already in production
[18:22] <Laney> hmm
[18:22] <Laney> someone's at the door, back in a bit
[19:13] <Laney> robru: I think I have to push to somewhere else now that it's a project
[19:13] <Laney> the one everything's looking at was a personal repo
[19:13]  * Laney updates 9999999 checkouts with the new url
[19:15] <robru> Laney: yeah this isn't the first time I've seen martin not have the necessary LP project in place to allow MPs
[19:16] <robru> I wonder if these git repos pre-date much of the LP git support
[19:17] <robru> Laney: so we're standardizing on lp:autopkgtest-cloud?
[19:17] <Laney> if that's the same as https://git.launchpad.net/autopkgtest-cloud
[19:18] <Laney> that's the one you can do merge proposals against, so it seems to make sense
[19:18] <robru> Laney: yes, ok
[19:26] <pitti> infinity: at your service, https://launchpad.net/ubuntu/+source/cockpit/137-3 builds everywhere now :)
[19:27] <Laney> apw: do "git remote set-url origin git+ssh://git.launchpad.net/autopkgtest-cloud" in your checkout, the branch moved
[21:18] <rbasak> nacc: accept/reject aren't needed; they'd be future enhancements.
[22:24] <nacc> rbasak: ok, so we can mark fix released upon your test
[22:24] <nacc> rbasak: fwiw, i left placeholders in for accept/reject so it should just be an uncomment and define a function to add them
[22:27] <rbasak> nacc: ack
[23:50] <Basketball> I know this is #ubuntu-dev but I have a question about elementary os
[23:51] <Basketball> there is a script chrx (chrx.org) that currently supports ubuntu and I want to add support for elementary os
[23:51] <Basketball> elementary os is built from seeds of ubuntu whatever that means
[23:52] <Basketball> the code for ubuntu and fedora builds it using the base images.... anyone have idea for elementary os which does not have a base image