[00:45] Are backports going to be a thing for Bionic? [02:23] Unit193: Vs, say, snaps? [02:23] Not really a 'vs' unless you mean 'vs ignoring the backports queue' [02:31] RAOF: In the past few releases, there haven't been many people reviewing the queue, so very few things got into backports. [02:33] This has not escaped my notice as I'm reviewing the SRU queues, yes. [02:34] Heh, SRU's being more important, and strict of course. [02:36] I'm not actually sure whose job it is to accept things into backports, either. I don't believe I'm supposed to 😀 [02:37] Nah there's a team for it, but so far it's...Not really had much movement. [02:40] (https://launchpad.net/~ubuntu-backporters/+members FWIW) [05:40] seems like the administrators could've done a better job :) most of the pending members left years ago === maclin1 is now known as maclin === maclin1 is now known as maclin === mquin is now known as Guest54612 === Guest54612 is now known as mquin [09:05] updated, but i didn't just want to add the complete installer log tarred up, please select which one you want: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1769044 [09:05] Launchpad bug 1769044 in debian-installer (Ubuntu) "Ubunut 18.04 d-i preseeded installer hangs at 66 % of update-grub..." [Undecided,New] [09:14] when will the debian2ubuntu archive sync start again? [11:42] tarzeau: a few days ago [11:43] cjwatson: then it failed to pickup cloudcompare and pushover [11:43] or it's lagging [11:43] (or the web interface is lagging) [11:43] tarzeau: No it didn't - those are both in cosmic-proposed [11:44] ah then the debian qa page lags [11:44] tarzeau: I don't know which page that is, but it may very well track cosmic and not cosmic-proposed [11:44] tarzeau: pushover failed to build everywhere: https://launchpad.net/ubuntu/+source/pushover/0.0.5+git20180420-2 [11:45] also possible, thanks for the info though [11:45] interesting, also failed for me with manual building.. but i couldn't figure out why [11:46] cloudcompare is actually in cosmic already. it needed a no-change rebuild for a pdal soname change, and that's currently in cosmic-proposed [11:46] so maybe whatever page this is in fact tracks bionic and hasn't been updated yet [12:01] many thanks! === rmk` is now known as rmk === Spads_ is now known as Spads === slashd- is now known as slashd === cpaelzer_ is now known as cpaelzer === realies- is now known as realies [15:00] !dmb ping! [15:01] !dmb-ping [15:01] bdmurray, BenC, cyphermox, jbicha, micahg, rbasak, sil2100: DMB ping. === kees_ is now known as kees [17:26] regarding apache2, say i have a prod ubuntu 14.04 box running apache2 2.4.7 from the repos... and i have a 14.04 dev box, and built apache2 from source... shouldn't i have binary compatibility? [17:26] i take mod_autoindex.so from the build on my dev box, overwrite the prod box's copy, restart, segfault. [18:19] NoImNotNineVolt: Define "built from source". Which source? [18:19] NoImNotNineVolt: The part where you're building it at all sort of implies you're not using the exact source used to build the packaged version (or you'd just use the packages...) [18:36] infinity: vanilla upstream [18:37] but indeed, that's a valid point. [18:37] NoImNotNineVolt: Then no, that definitely won't provide binary compat. [18:37] so, i mean, i know i can just use a third party ppa to give me a newer apache2 in 14.04, and i'm still considering that as a fallback.. [18:38] Or you could upgrade to 16.04 or 18.04? :) [18:38] 16.04's apache2 still doesn't have the fix and 18.04 isn't approved for prod by my org yet. [18:38] but also i wouldn't mind learning something :P [18:38] e.g. how to shoehorn an updated mod_foo.so into an os-managed apache [18:39] (which is very hackish, i know) [18:39] Well, if you know the patches required to fix mod_foo, the answer is to take the 14.04 sources, apply the patches to fix mod_foo, build, and go. [18:39] oh. [18:39] that makes too much sense :P [18:39] Alternately, backport mod_foo wholesale into the 14.04 source tree, if it's still compatible. [18:39] thankfully, it's a tiny patch. [18:40] The tiny cherrypick approach is certainly going to be the best option. [18:40] i guess my problem was starting with the wrong source tree. [18:40] instead of cherrypicking. [18:40] advice much appreciated. [18:40] Also, is there a bug filed? If it's a simple cherrypick and a clear verifiable bug, we could (and should) SRU it for the benefit of everyone who isn't you. [18:41] (Welcome to being part of a community :)) [18:41] so, debian won't backport it. not sure how you guys would feel. technically, it's a "new feature". [18:41] https://github.com/apache/httpd/commit/bd2ccbb8ef9b783117573cd9452e66b8c7d813fa#diff-e76e37d6c1f852034ce1989fb72c9e72 [18:42] NoImNotNineVolt: Hrm, new feature to restore old behaviour. That's curiously borderline. [18:42] backstory: apache2 2.4.0 introduced an unexpected change in the date format of directory indexes generated by mod_autoindex. [18:42] exactly. [18:42] i could argue it either way. it's an optional bugfix exposed as a new feature :P [18:43] of course, for people depending on the traditional output (clients downstream are parsing our indexes, like idiots) [18:43] NoImNotNineVolt: It's a pretty simple and easily reviewable patch, I don't think I'd be against it in principle. [18:43] the fact that preserving the traditional behavior is a "new feature" is no consolation :P [18:44] i'm really ignorant of how much the ubuntu maintainers do with a package like apache2 vs what upstream debian does. [18:44] i already discussed this with some debian folks and the consensus is that it would be wishlist priority, extremely unlikely to get backported. [18:45] NoImNotNineVolt: It's muddy. I mean, Ubuntu maintainers (ie: me, thom, daniels) were the ones who originally packaged apache2 for Debian. Since then, participation shifts one direction or the other every once in a while. [18:45] in that case, brief aside: thank you so much for your work [18:45] NoImNotNineVolt: But yeah, if we fixed this in an Ubuntu SRU, it certainly wouldn't get fixed in Debian as a result. That may well still be worth it. [18:45] having dabbled in packaging, i salute you :P [18:46] Ahh, it's the distant and hazy past at this point. [18:46] in any case, i doubt it's an issue affecting many people. i mean, it didn't get fixed til 2.4.26. [18:46] * NoImNotNineVolt ends up arguing against himself somehow [18:47] by all means, if you guys want to backport it, don't let me talk you out of it :P [18:47] NoImNotNineVolt: Heh. Well, I have a slight bias as someone who does this for a living, but I despise maintaining local forks if I can avoid it. Cause then I have to rebase on every security update, etc. [18:47] NoImNotNineVolt: So, if a bug annoys me enough, I'll fix it for everyone. [18:47] yea, that's the other question i was going to ask. [18:47] what's apt/dpkg going to do to my .so? presumably it'll just clobber it on every security update, right? [18:48] NoImNotNineVolt: And hey, if you fix it for everyone, you get your name in a changelog, which is spiffy, right? [18:48] but presumably something as hackish as a cron job to compare hashes and overwrite with my custom one as needed (and then apache restart) would do the trick, right? [18:48] you'd probably want to dpkg-hold the package in place and manage every update manually [18:48] You can dpkg-divert the .so out of the way, so dpkg installs its copy to mod_foo.so-ermagerdno instead of clobbering yours. [18:48] ah, even cleaner. [18:49] mod_autoindex changes very rarely, and i don't mind just leaving my custom one in there. [18:49] awesome. thank you so much. [18:49] Still, highly recommend getting it fixed in the distro. You'll learn something new, be less afraid of doing the same thing in the future, and your infra won't live with hacky forks of packages. [18:49] hm. [18:49] so how would that work? [18:50] i don't know how to submit a pr for a backport :P [18:50] File a bug, provide a patch. If you want your name on it, provide a debdiff (and I'll work with you to get it uploaded), if you don't care whose name is on it, just a pointer to the commit is good enough for me to go ahead. [18:51] But the most important part is a bug with a testcase. [18:51] (This testcase is, thankfully, simple... enable autoindex, look at dates on a dir, change option, look at dates again, win) [18:52] this seems like a great easy way to dip my toes into learning a f/loss workflow [18:52] * infinity runs off to hunt the elusive pizzabeast, back in a few. [18:53] NoImNotNineVolt: Bug me this afternoon. I need lunch. :) [18:53] * infinity is always keen to turn a local hack into a community submission. [18:54] yea, i'll have to do this in the evening also. will need to spin up a clean vm for this on my own box. [18:55] employer is f/loss-friendly but better safe than sorry. [19:19] okay, i don't understand. trusty has apache2 2.4.7. i have trusty. i `apt-get source apache2`. i end up with source for 2.4.10. am i losing my mind? [19:22] Backports has 2.4.10? [19:24] IIRC apt-get source always gets the highest version available, ignoring pin priorities [19:28] yea, indeed, i'm an idiot. [19:28] so, should i target trusty-backports or trusty? [19:29] (regarding backporting a "new feature" that exposes a user option to fix a bug introduced in 2.4.0) [19:29] (which didn't get added until 2.4.26) [19:31] i'll just work against trusty's 2.4.7 for now. === ubott2 is now known as ubottu === ldts_ is now known as ldts === popey_ is now known as popey === balkamos_ is now known as balkamos === tedg_ is now known as tedg === blackboxsw_ is now known as blackboxsw === rsalveti_ is now known as rsalveti === tai271828_ is now known as tai271828 === czchen_ is now known as czchen === Wimpress_ is now known as Wimpress === odc_ is now known as odc [20:55] morning === tomreyn_ is now known as tomreyn [21:16] NoImNotNineVolt: infinity: you can do a git MP now, fwiw, and in theory a server team member can review it and sponsor [21:18] https://github.com/apache/httpd/commit/bd2ccbb8ef9b783117573cd9452e66b8c7d813fa [21:18] that's the commit i'm trying to backport. nice and easy. [21:18] but i figure this is a good opportunity for me to figure out how the whole "contribution" workflow works :P [21:19] NoImNotNineVolt: snap install git-ubuntu; git ubuntu clone apache2; cd apache2; git checkout pkg/ubuntu/trusty-devel; git remote add upstream https://github.com/apache/httpd.git; git cherry-pick bd2ccbb8ef9b783117573cd9452e66b8c7d813fa; dpkg-source --commit` [21:19] :) [21:20] err, should be a `git fetch upstream` before the cherry-pik [21:20] oh that's easier than this whole http://packaging.ubuntu.com/html/fixing-a-bug.html thing [21:20] yes [21:22] I can explain the bits there, if you want [21:22] but the above is the one-liner (almost) [21:22] .. snap? [21:23] SNAP - Semi-HMM-based Nucleic Acid Parser (version 2006-07-28) [21:23] NoImNotNineVolt: https://snapcraft.io/ [21:23] NoImNotNineVolt: no, the packaging format (enabled by default in Ubuntu these days) [21:24] NoImNotNineVolt: git-ubuntu is shipped as a snap. You can also use git directly, but git-ubuntu does some niceness for you (e.g. clone a srcpkg as above, handle building in a LXD, etc.) [21:24] oh god. i think i'm installing systemd :| [21:24] NoImNotNineVolt: are you not on Ubuntu already? [21:24] trusty. [21:24] this is for 14.04, remember? :P [21:24] * NoImNotNineVolt sighs and blows up that vm [21:24] NoImNotNineVolt: you don't need to be on 14.04 to develop for 14.04 [21:26] NoImNotNineVolt: https://code.launchpad.net/ubuntu/+source/apache2/+git [21:26] NoImNotNineVolt: if you want to use git directly [21:26] NoImNotNineVolt: but YMMV [21:26] i was having enough trouble getting binary-compatibility building on the same os as the target. [21:26] NoImNotNineVolt: then you're bulding it wrong :) [21:26] NoImNotNineVolt: as you said, you were building it in the source, not as a package [21:26] indeed. no need to throw extra hurdles in my path :P [21:27] NoImNotNineVolt: use a PPA [21:27] i actually built a deb and pulled the so out [21:27] greatly prefer to avoid a ppa, though that is my absolute fallback [21:27] that seems ... weird [21:27] NoImNotNineVolt: why? [21:27] requires a long conversation with cto [21:27] NoImNotNineVolt: if you actually want to contribute to Ubuntu, you have to eventually test a package [21:28] that's fine. [21:28] that's not the same thing as using a ppa in production [21:28] I never said that [21:28] I don't really care about your company :) [21:28] I'm speaking from the Ubuntu developer side [21:28] you, as a single user, can set up a PPA, build your package there, and can test from there [21:29] I would never suggest doing that for production [21:29] ah, understood. [21:29] :) [21:29] i thought you meant use a third party ppa. i found a good one with 2.4.33 for trusty. [21:29] no, that would be a bad idea in production, imo [21:30] Ondřej Surý has a ppa. [21:30] seems trustworthy, but still, that's my absolute last ditch option. [21:31] best solution would be to get the backport into 14.04 eventually, but in the meantime i've gotta get a .so i can shoehorn into my existing server. [21:31] clients are yelling :P [21:33] but thanks for the git tip. that's much easier for me. === blahdeblah_ is now known as blahdeblah