[00:01] <mwhudson> sigh, i guess "ubuntu dev wants to get things done" "debian dev wants to play with new shiny" is a common thing?
[00:03] <mwhudson> infinity: i said this upstream, lmk if it sounds insane: https://github.com/golang/go/issues/7094#issuecomment-123911439
[00:06] <infinity> mwhudson: That's true, ish.  Except guess who thinks "gnueabihf" is "icky" and, thus, their GNU triplet doesn't match upstream?
[00:06] <infinity> mwhudson: (hint: RedHat)
[00:06] <mwhudson> infinity: oh god
[00:06] <mwhudson> what does theirs say?
[00:08] <infinity> mwhudson: Unless they've repented (would be nice to check a recent Fedora build), they were encoding it in the machine type instead, ie: armv7hl-linux-gnueabi
[00:09] <infinity> mwhudson: Which I told them repeatedly was ridiculous, since armv7l, the kernel machine type, can run both sf and hf binaries.
[00:09] <infinity> mwhudson: But... Whee?
[00:09] <mwhudson> argl
[00:09] <mwhudson> well how about i fix it for sensible systems and we see who complains
[00:09] <infinity> Sure.
[00:45] <infinity> doko: Does https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1477350 look familiar?  It broke in a security update, so I've poked sbeattie, but if you have any ideas, yay.
[00:45] <ubottu> Launchpad bug 1477350 in binutils (Ubuntu Precise) "Rgression building sbsigntool with binutils >= 2.22-6ubuntu1.2 in precise" [Undecided,New]
[04:50] <dragos> hi i want to make an custom ubuntu but i have an problem. how can i modify the installer menu like this one : http://listthemout.com/wp-content/uploads/2011/04/install-ubuntu.png
[05:00] <dragos> help me
[05:01] <sarnold> dragos: it's an awkward time; .us is done for the day, europe isn't awake yet
[05:02] <dragos> im in europe and im awake
[05:02] <Unit193> sarnold: So which one are you?
[05:03] <sarnold> Unit193: .us, west coast.. trying to put in another hour or two to get infinity off my back :)
[05:03] <sarnold> Unit193: how about you?
[05:03] <Unit193> Hah, nice!  And East coast, Ohio.
[05:03] <dragos> im europe, romania
[05:04] <sarnold> o! hi o!
[05:04] <dragos> im in europe, romania
[05:04] <sarnold> dragos: cool :D
[05:04] <dragos> what?
[05:04] <sarnold> dragos: romania looks beautiful
[05:04] <Unit193> I got it. :P
[05:04] <dragos> i know
[05:04] <dragos> if you look on the map it looks like a fish :D
[05:05] <sarnold> Unit193: sorry. my parents went to ohio state university, some things are ingrained deep :)
[05:06] <Unit193> Aha!  Nice, and yeah, shout "OH" and someone will complete it. :P
[05:06]  * sarnold tries something else
[05:06] <sarnold> The Stars At Night, And Big And Bright!
[05:09] <dragos> the sun
[05:12] <dragos> sweet dreams every1
[05:13] <dragos> bye
[05:15] <dragos> im back
[05:16] <sarnold> welcome back :)
[05:21] <dragos> i just installed the newest security updates to ubuntu 10.10
[05:23] <sarnold> dragos: note that 10.10 hasn't been supported for three years: https://wiki.ubuntu.com/Releases
[05:23] <dragos> i know but im aking it suported
[05:23] <dragos> i know but im making it suported
[05:28] <dragos> hi
=== marcusto_ is now known as marcustomlinson
[05:48] <dragos> who remembers the ubuntu version "the perfect 10" or 10.10 ?
[05:57] <Noskcaj> Can someone please retry gimp in wily?
[05:57] <Noskcaj> The missing build-dep should be fixed by the new version of gegl
[05:58] <dragos> wily is ubuntu 15.04 or 15.10
[05:59] <Noskcaj> grimble_, 15.10
[05:59] <Noskcaj> oops, dragos ^
[05:59] <dragos> i have wily and and imp works like a charm
[06:00] <dragos> i have wily and and gimp works like a charm
[06:00] <didrocks> Noskcaj: done on amd64, let's see the result before kicking the others
[06:01] <Noskcaj> didrocks, ok. It will at least get further, since the build failure was from a missing dep in the gegl dev package
[06:02] <Noskcaj> dragos, This is for a version of gimp patched to work with the new gegl
[06:05] <dragos> who remembers ubuntu 10.10?
[06:07] <dragos> how can send an email to canonical ?
[06:11] <didrocks> dragos: http://www.canonical.com/about, look for "contact us"
[06:12] <didrocks> Noskcaj: amd64 successfully built! starting the other archs
[06:12] <dragos> thx m8
[06:26] <Noskcaj> ty didrocks
[06:27] <didrocks> yw
[06:28] <dragos> i have the biggest project EVER
[07:10] <dholbach> good morning
[07:24] <dragos> good morning
[07:48] <jhenke> hi folks. The recent 8.1 release of ownCloud server does not allow owncloud-client < 1.7 to sync files. I have filed bug 1477421 about this. Would you consider backporting owncloud-client from wily to odler releases to make it work again?
[07:48] <ubottu> bug 1477421 in owncloud-client (Ubuntu) "ownCloud-client < 1.7 can no longer sync with ownCloud Server 8.1 and above" [Undecided,New] https://launchpad.net/bugs/1477421
=== Logan is now known as y
=== y is now known as Logan
[08:15] <dbarth__> o/ hey there trainguards, i'm looking for a silo for line 66
[08:31] <sil2100> dbarth__: on it
[08:33] <cjwatson> dbarth__: (you wanted #ubuntu-ci-eng BTW)
[08:39] <flexiondotorg> ogra_, I see you are piloting today. May I kindly request you look at Ubuntu MATE packages please?
[08:44] <jhenke> anybody able to look into the issue I posted above?
[08:46] <dbarth__> oops wrong channel indeed
[08:48] <Laney> doko: you synced libvpx, which caused a transition - are you going to look at the rebuilds? :)
=== G_ is now known as G
=== masACC is now known as maswan
=== spineau is now known as spineau_afk
[09:47] <jhenke> hi, anybody able to look into bug 1477421? With the recent 8.1 release of ownCloud upstream requries owncloud-client to be at least 1.7, which currently only is true for wily. They dropped support for older version due to "technical difficulties". Is there a chance to backport the 1.8.1 client from wily to older releases to make it work out of the box with recent ownCloud server isntallations again?
[09:47] <ubottu> bug 1477421 in owncloud-client (Ubuntu) "ownCloud-client < 1.7 can no longer sync with ownCloud Server 8.1 and above" [Undecided,New] https://launchpad.net/bugs/1477421
[09:48] <rbasak> jhenke: https://wiki.ubuntu.com/UbuntuBackports is the straightforward option. If you want an SRU then you'll need to get approval from the SRU team specifically, or quite possibly the Technical Board as it's a major version bump.
[09:49] <seb128> jhenke, you already asked earlier, and I already replied on #ubuntu-desktop that it makes sense, unsure what else you are looking for there
[09:49] <rbasak> (and agreed - it makes sense, but it will need an exception granted from the appropriate team)
[09:52] <jhenke> seb128 you said #ubuntu-desktop would not be the right place, so I was hoping this is the right place to rais this issue with someone who has the chance to work on it
[09:53] <jhenke> basically I am looking for a dev who is willing nad ha the time to do the next steps
[09:53] <seb128> jhenke, yeah, I also told you that the request made sense ... you can ask here, it's more ontopic, but everybody is busy and it's not likely that you find somebody to work on that through IRC pings
[09:54] <jhenke> too bad, I was hopeing that would work :(
[09:54] <seb128> you are welcome to work on the update yourself, finding a sponsors might be easier
[09:56] <jhenke> from the webpage I do not really find with whom I can request a backport. How can I get that started?
[10:14] <jhenke> thanks guys, I think I figured it out now, I hope someone of the backports team will look into that soon.
=== spineau_afk is now known as spineau
[10:30] <doko> seb128, GCC 5 ping
[10:30] <seb128> doko, yes, what about it?
[10:31] <doko> seb128, basically I'd like to know what will break when upgrading to the silo 16 ppa (see email)
[10:32] <doko> and fix that before copying the ppa to -proposed next Friday
[10:32] <seb128> doko, it's on my list to investigate for today/tomorrow
[10:35] <doko> ok, thanks
[10:36] <doko> seb128, if you can reach robert ancell, please can he avoid updating the gnome mm stack? before GCC is the default? can't reach him, and he didn't reply on my email
[10:36] <seb128> doko, ok, he probably read your email even if he didn't reply to it (knowing him)
[10:55] <doko> mvo, I also filed an issue to build apt using gcc-snapshot to investigate the test failure using GCC trunk
[10:58] <seb128> zyga, hey, did you notice that the new plainbox is depwaiting on python3-xlsxwriter which needs a mir?
[11:00] <zyga> seb128: oh - no, thanks for noticing that
[11:00] <seb128> zyga, yw!
[11:00] <zyga> I'll work on MIR paperwork ASAP
[11:00] <seb128> can you take care of the mir report?
[11:00] <seb128> thanks
[11:00] <zyga> yep, absolutely
[11:05] <seb128> flexiondotorg, Laney, that -welcome package you discussed earlier (iirc) is in the wily NEW queue, so somebody already sponsored it
[11:05] <flexiondotorg> seb128, That's great news.
[11:07] <seb128> bdmurray, it seems your apport update in wily is creating a real regression for autopkgtest, it has been retried several times and fails consistently, that block other things in proposed, are you looking at the issue?
[11:11] <seb128> hum
[11:11] <seb128> devscripts is blocked because lava-server autopkgtests fail, but looking to https://jenkins.qa.ubuntu.com/job/wily-adt-lava-server/ that doesn't seem a new situation
[11:11] <seb128> could somebody unblock it/mark the test as buggy?
[11:12] <seb128> same for distro-info
=== JanC_ is now known as JanC
=== MacSlow is now known as MacSlow|lunch
[11:42] <doko> apw, schroot ping
[11:59] <zyga> seb128: https://bugs.launchpad.net/ubuntu/+source/xlsxwriter/+bug/1477531
[11:59] <ubottu> Launchpad bug 1477531 in xlsxwriter (Ubuntu) "[MIR] xslxwriter" [Undecided,New]
[11:59] <seb128> zyga, thanks
[12:08] <zyga> seb128: I could use a bit of advice, checkbox will require two new packages, one is applicable for Debian (QML module) but the other one is not (depends on SDK components). What should we do to make them available in Ubuntu
[12:08] <seb128> zyga, have it packaged and submitted for sponsoring
[12:08] <zyga> we have the qml module
[12:08] <zyga> how can we submit it to Debian for sponsoring?
[12:09] <zyga> seb128: I only have experience with python packags
=== _salem is now known as salem_
[12:09] <zyga> packages
[12:10] <seb128> zyga, http://mentors.debian.net/sponsors
[12:10] <zyga> seb128: thanks
[12:10] <seb128> yw!
[12:11] <mvo> doko: oh, gcc-snapshot fails in the same way? I haven't checked the upstream gcc report in some days
[12:12] <doko> mvo, no, apt even fails to build using GCC trunk
[12:21] <dragos> hi i have installed ubuntu on my tab 2 7.0 and i dont have an otg cable cause to bring the gui i have to press CTRL+ALT+F7 and i was wondering if ubuntu can autopress these keys from an edited text
=== hloeung_ is now known as hloeung
=== MacSlow|lunch is now known as MacSlow
[13:34] <hjd> Hi all. I have to admit I don't know whether this is the right place, but I've seen various bugs like bug 1472165. These are marked as affecting a dozen different packages, presumably because the kernel is available in different forms. I do wonder whether the linux-lts-backport-maverick and -natty are simply added for completeness, or whether they don't need to be added for new bugs filed.
[13:34] <ubottu> bug 1472165 in linux-manta (Ubuntu Wily) "CVE-2015-5366" [Medium,New] https://launchpad.net/bugs/1472165
[13:35] <Laney> doko: Should I rebuild things for python3.5 if necessary?
[13:35] <Laney> e.g. pyside
[13:36] <doko> Laney, sure, maybe coordinate with slangasek, he is doing these uploads currently
[13:37] <hallyn> mbiebl: hi, can you point me to a url explaining how to have a systemd service not restart on package reinstall?  (i.e. to make dh_installinit --no-restart-on-upgrade work)
[13:38] <mbiebl> hallyn: is that a package without a sysvinit script, i.e. systemd service file only?
[13:38] <hallyn> mbiebl: yeah, looks like only upstart and systemd.
[13:38] <hallyn> (pkg is lxc)
[13:38] <mbiebl> then use dh_systemd_start --no-restart-on-upgrade
[13:38] <hallyn> call that after the dh_installinit?
[13:39] <mbiebl> is the package using dh?
[13:39] <hallyn> uh.  yeah.  i think.
[13:39] <hallyn> i get the pkging type names confused
[13:39] <mbiebl> then use the usual override_dh_systemd_start: ...
[13:40] <hallyn> ok, but so - should this NOT be considered a bug in dh_installinit?
[13:40] <mbiebl> what do you mean?
[13:40] <hallyn> i.e. what used to just work with dh_installinit --no-restart-on-upgrade now requires extra steps...
[13:41] <mbiebl> dh_installinit deals with sysv init scripts primarily
[13:41] <mbiebl> and handles .service files if the names match
[13:43] <mbiebl> hallyn: one could argue, that the functionality of dh-systemd should be merged into dh_installinit, but at the time, it seemed better to do it in a separate helper
[13:43] <hallyn> i suspect dh-systemd adds power that justifies its existing, but it does seem to me like dh_installinit should be able to handle the arguemnts it says it handles
[13:44] <hallyn> or, at least the manpage should be updated to say that no-restart-on-upgrade doesn't work with systemd by itself :)
[13:44] <hallyn> mbiebl: but thanks!  i'll try this out.
[13:44] <mbiebl> well, --no-restart-on-upgrade works with systemd
[13:44] <hallyn> ?
[13:45] <hallyn> not in dh_installinit though
[13:45] <mbiebl> say you have a /etc/init.d/foo and foo.service and you use dh_installinit --no-restart-on-upgrade
[13:45] <mbiebl> invoke-rc.d will correctly handle that
[13:45] <hallyn> i only have foo.service
[13:46] <mbiebl> and not restart the service file on upgrades
[13:46] <mbiebl> hallyn: that's what I tried to explain, apparently I failed
[13:46] <hallyn> so if i had a /etc/init.d/foo, it wouldn't restart on upgrade?
[13:46] <mbiebl> yes
[13:46] <hallyn> and it would start both foo.service and /etc/init.d/foo?
[13:46] <mbiebl> no, only foo.service obviously
[13:47] <mbiebl> (under systemd)
[13:47] <mbiebl> if there is no sysv init script, dh_installinit will do nothing
[13:47] <hallyn> hm.  we *have* sysv jobs, maybe installing those is the way to go
[13:47] <mbiebl> so dh_systemd_start kicks in
[13:47] <mbiebl> and you get the default behaviour of dh_systemd_start
[13:47] <mbiebl> which is to restart on upgrades
[13:47] <mbiebl> so you need to override that
[13:48] <mbiebl> via override_dh_systemd_start:\n dh_systemd_start --no-restart-on-upgrades
[13:49] <mbiebl> has it become clearer, how it works?
[13:49] <mbiebl> (nobody said, supporting multiple init systems wouldn't be simple)
[13:49] <hallyn> mbiebl: so in the past dh_instlalinit worked for all inits.  Is the thing I'm missing that 'dh_installinit' simply isn't meant to work with systemd?
[13:50] <hallyn> mbiebl: yeah i think i get it better now.  I'll get something worked out - thanks!
[13:50] <mbiebl> hallyn: upstart units don't need to be enabled
[13:51] <mbiebl> and we need some flexibility in the enabling and starting bits
[13:51] <mbiebl> so the helpers were split into dh_systemd_enable and dh_systemd_start
[13:51] <hallyn> and i don't need to put a call to dh_systemd_start under dh_installinit or anything, just put in the override_dh_systemd_start?
[13:51] <mbiebl> something which was odd to cram into dh_installinit
[13:51] <mbiebl> right, you override as any other dh command
[13:52] <hallyn> mbiebl: yeah i can believe it would've been awkward.  I only think that i'm not the only one confused and that the manpages should spell out to look at dh_systemd_start :)  I'll make a note to look into a docs patch
[13:52] <hallyn> mbiebl: thanks again
[13:53] <mbiebl> https://anonscm.debian.org/cgit/pkg-utopia/network-manager.git/tree/debian/rules#n61
[13:54] <mbiebl> dh_installinit's behaviour really becomes awkward if you want to achieve something like that
[13:54] <rbasak> infinity: I'm interested in your opinion on bug 1194074 please. Clearly user error, but it seems to be that we're leading them into it, and apache2's approach is better. What do you think, please?
[13:54] <ubottu> bug 1194074 in nginx (Ubuntu) "Default index.html blindly overwritten" [Medium,Triaged] https://launchpad.net/bugs/1194074
[13:55] <mbiebl> that's mostly an issue though, for packages shipping multiple .service units
[13:55] <mbiebl> which is more common though under systemd, where you have multiple service unit instead of a giant init script starting multiple processes
=== zyga is now known as zyga-afk
[14:14] <Odd_Bloke> arges: There's a new release of cloud-init in wily, which should mean that all the SRUs are now fixed in wily.
[14:27] <arges> Odd_Bloke: ok
[14:30] <Laney> Odd_Bloke / smoser: will/can we get a new cloud image today?
[14:30] <Laney> There's an autopkgtest bug which triggers if there is a new cloud-init vs. what shipped in the image :/
[14:31] <Odd_Bloke> Laney: One will normally pop out of our automation whenever there are new packages on the base image.
[14:31] <Odd_Bloke> Laney: But I'll give it a kick if it hasn't started yet.
[14:32] <Laney> Odd_Bloke: ack, thanks
[14:41] <Odd_Bloke> Laney: I've kicked that off; last build failed for spurious reasons so I'll keep an eye on it to make sure it works.
[14:41] <Odd_Bloke> Laney: What's the autopkgtest bug?
[14:41] <Laney> Odd_Bloke: It creates a conffile prompt which it doesn't (tell dpkg how to) handle
[14:46] <Odd_Bloke> Laney: "it" being?
[14:46] <Laney> adt-buildvm-ubuntu-cloud
[14:47] <Laney> https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1477626
[14:47] <ubottu> Launchpad bug 1477626 in autopkgtest (Ubuntu) "adt-setup-vm modifies cloud-init's conffile but doesn't handle dpkg conffile prompts" [Undecided,New]
[14:49] <Odd_Bloke> Laney: Ah, right.  I've added a comment suggesting using /etc/cloud/cloud.cfg.d/ instead of modifying the apt installed config file.
[14:49] <Laney> Nice, didn't know that existed
[14:54] <Odd_Bloke> :)
[15:11] <infinity> rbasak: I could have sworn Debian policy actually defined the default docroot as being /var/www/something, and nginx is buggy for pointing people to /usr/share and encouraging exactly that bug.  Too busy to look right now, though.
[15:12] <tarpman> #730382?
[15:13] <infinity> rbasak: https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-web-appl
[15:13] <bdmurray> seb128: I am but I'm not making much progress.
[15:13] <infinity> rbasak: It's not strongly-worded, but it's certainly mentioned.
[15:14] <rbasak> infinity: interesting, thanks. Has that changed recently? Last time I looked it wasn't as clear (it was more for applications than servers)
[15:14] <rbasak> teward: ^^
[15:15] <infinity> rbasak: Well, it is for applications, yeah, but it still mentions that the default docroot is /var/www/html, so one can infer that it should apply to servers.
[15:15] <rbasak> Yeah
[15:15] <infinity> rbasak: It's not a policy "must" or anything there, but I'd still consider it reasonable guidance for all httpds.
[15:15] <rbasak> I certainly get the impression that this is the intent, and it's never been a point of contention before nginx.
[15:16] <Odd_Bloke> There's also https://lintian.debian.org/tags/dir-or-file-in-var-www.html
[15:16] <infinity> rbasak: Certainly, pointing the default docroot to an FHS location owned by the package manager isn't sane.
[15:17] <infinity> rbasak: I'd argue they should ship their bit in /usr/share (as they do), and iff /var/www/html is empty, add a symlink to their index.html (and if not, leave it alone).
[15:17] <rbasak> Yeah that sounds reasonable
[15:17] <infinity> rbasak: Which, I imagine, is similar to what apache does, but I haven't looked at apache packaging in years.
[15:17] <seb128> bdmurray, k
[15:17] <infinity> rbasak: s/symlink/copy/ if the default nginx config doesn't follow links.
[15:52] <dragos> hi
[15:55] <teward> infinity: i think that was brought up in the given bug that was linked - nginx maintainers said "This is the root [current] in accordance with policy."
[15:56] <teward> rbasak: infinity: I would love that policy to have better wording, the next question is given the current hostility situation on this, should this be elevated higher than package maintainers in Debian to get authoritative policy on the decision
[15:56] <teward> or is that even possible?
[15:56] <teward> I know the Ubuntu politics, moreso than Debian
[15:56] <teward> (I actually try and AVOID Debian politics altogether)
[15:56] <teward> (at least, from the political/policy determination/interpretation side()
[15:57] <infinity> teward: It could be brought to the TC in Debian, though it would be smarter to try to get concensus on adding stronger wording to policy, with the nginx maintainers' input.
[15:58] <infinity> teward: That said, Debian's nginx maintainers refusing to move on this is no excuse for us not fixing it in Debian.
[15:58] <infinity> s/in Debian/in Ubuntu/
[15:58] <teward> infinity: of that, you, myself, and rbasak agree, given that I went on a 20-minute tirade in PM about this exact issue
[15:58] <teward> i'm quite happy of the community driven nature here in Ubuntu, where community consensus is preferred over the individual maintainer
[15:59] <teward> probably why i'm a fan of Ubuntu moreso than Debian XD
[15:59] <teward> infinity: i'm about to unarchive the bug in Debian on this for nginx maintainers.
[15:59] <infinity> teward: Meh, it's not really that different anymore.  And we do have "weak ownership" of some packages/sets in Ubuntu where you'll get smacked down pretty hard if you try to override those people.
[15:59] <dragos> im making cool ubuntu image for older pc's but with new apearane
[16:00] <teward> infinity: i'm of the preference that community or team consensus is better than 'weak ownership' - in this case, nginx is 'weakly' maintained by me but ultimately I stand down in favor of Server, Release, SEcurity, etc. team governance
[16:00] <teward> infinity: for all intents and purposes, I'm tempted to unarchive the bug in Debian, and say "Wait a minute, what about this policy? https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-web-appl ..."
[16:00] <teward> and say that the package is violating policy
[16:01] <teward> but the moment i do that i get negatively received
[16:01] <infinity> teward: Sure.  Just saying it's not actually *that* much different.  You're appealing to me, not because I care and want to overrule you, but because you trust my input.  That's just being a humble maintainer.  Same happens in any distro (and doesn't happen, when egos get in the way).
[16:02] <teward> Right
[16:02] <infinity> teward: That policy wording really can't be used as a stick to smack people with, as it's neither directed at httpd maintainers, nor is it stated as a "must" anywhere.  But it's a good talking point, since it certainly IMPLIES that the "default" docroot should be consistent, and consistently /var/www/html
[16:02] <teward> mmm
[16:03] <teward> i need to reexamine the policy, the prior arguments given, and then reach out again about the bug, with a stressor on "I want more than just Michael's opinion on this, I'd like other maintainers to weigh in"
[16:03] <infinity> teward: Anyhow, I'd honestly just fix it in Ubuntu for now, submit the patch to Debian without any inflamatory comment, and let them deal with it.
[16:03] <teward> infinity: i'm more tempted to see what their response will be
[16:03] <infinity> teward: And if it's something you feel passionate about, bring up a policy ammendment to set this slightly more in stone for all web servers.
[16:04] <teward> I expect a "[CENSORED] you, and [censored] the people affected"
[16:04] <teward> which is the current state
[16:04] <teward> infinity: i have 0 say in Debian, nor am I familiar with that current state - i would be petitioning for the policy rereview anyways given my current level of passion and drive on this
[16:04] <teward> infinity: if i were to propose such policy amendment who do I petition?
[16:04] <teward> (brb lunch, i'll respond to comments after i return)
[16:04] <cjwatson> debian-policy@
[16:05] <teward> cjwatson: debian-policy @ debian ?
[16:05] <infinity> teward: File a bug on debian-policy, if you have an ammendment ready, or a mail to debian-policy@ if you want a discussion.
[16:05] <infinity> teward: @lists.d.o
[16:05] <teward> infinity: i probably will mail in on the discussion first
[16:05] <cjwatson> you should cc affected lists/maintainers/etc. though, people aren't generally expected to keep up with everything on -policy
[16:05] <infinity> s/everything/anything/
[16:06] <teward> cjwatson: i intended to CC the maintainers group for nginx
[16:06] <teward> or rather, each of them, since it's comaintainership and not team based
[16:06] <cjwatson> but also other www maintainers
[16:06] <infinity> teward: Yeah, all httpd maintainers.
[16:06] <cjwatson> a policy change would affect all of them
[16:06] <teward> there's no list for that is it?
[16:06] <infinity> teward: Since the point of this is standardisation.
[16:06] <cjwatson> teward: dunno, your job to figure that out
[16:06] <teward> i mean, that's... what, lighttpd, apache2, nginx, probably smaller ones...
[16:06] <cjwatson> (that is, the job of the person proposing a change)
[16:06] <teward> heheheh
[16:06] <teward> i'll go hunting then
[16:06] <infinity> teward: Check maintainer fields.  debian-apache@lists.d.o, for instance.
[16:07] <cjwatson> have a look on http://lists.debian.org/ too
[16:07] <teward> even if the battle ends up with me smacked
[16:07] <teward> (back in a bit I need food)
[16:07] <cjwatson> debian-webapps maybe
[16:07] <cjwatson> though that might be defunct ...
[16:07] <infinity> cjwatson: Given that current policy seems aimed at webapps already, I hope they agree. :P
[16:08] <infinity> (but it's silly to tell webapps people where the default docroot is and not tell httpd people to serve stuff there, so clearly someone needs to write gooder)
[16:08] <dragos> help i have an pc and it says to login i put my password and it logs out and asks me again to login
[16:09] <infinity> Pretty sure this all came about when apache1.3/2 were the only really viable web servers in the archive, and they decided the docroot, so no one thought an httpd policy was necessary.
[16:13] <Gallomimia> dragos: i've had that problem before. errors in X configuration. #ubuntu should be able to help
[16:13] <dragos> some dude banned me from #ubuntu for no reasion
[16:18] <cjwatson> dragos: I'm sorry, but this channel isn't for escalations from #ubuntu.  Perhaps you could try askubuntu.com for a calmer environment than IRC
[16:20] <dragos> bye
[16:20] <dragos> gtg
[16:30] <teward> infinity: perhaps it's time to revisit that then
[16:30] <teward> on the Debian side
[16:39] <teward> cjwatson: infinity: so basically i have to email the maintainers for the source packages of everything here , while emailing the discussion list?  https://packages.debian.org/unstable/httpd/
[16:40] <teward> (to propose a more set-in-stone discussion on the HTTPd enforcement of web docroots)
[16:40] <teward> as well as their webapps list?
[16:41] <cjwatson> I suspect everything there is a bit much, the apache modules don't matter for this
[16:42] <cjwatson> but I'm not that familiar with this, I was just giving general pointers
[16:42]  * teward shrugs
[16:42] <teward> might be easier to just submit a bug for the amendment then
[16:44] <teward> although this is what i think is the conflict point in the same policy doc infinity linked: "Instead they should use the /usr/share/doc/package directory for documents and register the Web Application via the doc-base package"
[16:44] <teward> i think that leads to confusion and there should be one set-in-stone one :/
[16:44]  * teward shrugs
[16:44] <teward> infinity: input would be nice, should i target everyone in the httpd subsection or just the major httpds?  Since I don't think there's a complete list of httpds out there
[16:50] <infinity> teward: I'd go with everything that 'Provides: httpd', probably, as that implies they're providing a standard interface.
[16:51] <infinity> teward: I'd argue that standard interface isn't just about serving stuff on port 80, but also which location in the filesystem they serve by default.
[16:51] <teward> infinity: any easy way to pull that whole list of packages short of page by page?
[16:51] <infinity> teward: http://paste.ubuntu.com/11926008/
[16:52] <teward> oooo nice
[16:52] <teward> that helps narrow it
[16:52] <infinity> teward: But grep-dctrl would be the other right way.
[16:54] <teward> infinity: i'll start drafting the discussion - do you want me to include you on this as well?
[16:54] <cjwatson> grep-dctrl is your friend, definitely, anyone who deals with stuff across a distribution rather than just a few packages should be familiar with it
[16:54] <teward> (on the CC list and such)
[16:54] <teward> cjwatson: indeed.  this is my first venture into cross-distro for more than just two packages so heh
[16:54] <infinity> teward: I probably won't get too involved.
[16:54] <teward> infinity: ack.  was more for a situational awareness reason than involvement
[16:55] <infinity> teward: grep-dctrl example http://paste.ubuntu.com/11926018/
[16:55] <infinity> Though some of those can probably be left off the list.  Use a bit of common sense. :)
[16:56] <cjwatson> -wFProvides is handy to avoid unwanted mid-word matches
[16:56] <infinity> The providers of httpd-cgi (ie: web servers that can do useful things!) are a smaller and saner list.
[16:56] <infinity> cjwatson: Ahh, didn't realise I was substring matching there.  Yes, -wFProvides httpd is a sane list.
[16:57] <infinity> teward: http://paste.ubuntu.com/11926020/ <-- There.
[16:57] <infinity> teward: Might want to re-run in a Debian chroot, in case they have ones we don't.
[16:57] <teward> right
[16:58] <teward> infinity: that does give a starting point though
[16:59] <infinity> teward: Realistically, you don't need 100% concensus here from every dinky thing that claims to provide an httpd, but apache, nginx, aolserver, and lighttpd at least all have a fair few users and consistency is nice.
[16:59] <teward> infinity: indeed, i was thinking about the major ones, didn't know aolserver was a thing though
[17:01] <infinity> teward: aolserver's actually not terrible.  Turns out that the people who built an empire out of providing a curated version of the internet knew a thing or two about serving stuff on port 80 by the time all was said and done.
[17:11] <teward> heh
[17:11] <teward> infinity: correct, i don't need a full consensus, in theory i need simple majority
[17:11]  * teward misused 'consensus' earlier
[17:40] <rbasak> infinity, cjwatson: just caught up. Thank you for the discussion with teward - I wasn't confident in the Debian processes involved here. I agree that it's an ambiguity in policy because nobody had reason to be better defined than "what apache does" in the past.
[17:41] <rbasak> I'm a little concerned about an Ubuntu delta because it involves a conffile change and moving data about for users (even if they do it themsleves).
[17:41] <rbasak> So I'd like to see an attempt to reach agreement to fix it in Debian first if we can do that. And it seems like that's where teward is going anyway.
[17:41] <rbasak> So maybe hold on an Ubuntu delta until Debian either decide or its clear that it isn't going anywhere in Debian please?
=== zyga-afk is now known as zyga
[20:10] <Laney> doko: is http://people.canonical.com/~ubuntu-archive/transitions/html/python3.3-5.html ok?
[20:11] <doko> Laney, yes, looks reasonable
[20:11] <Laney> thx
[20:11] <doko> Laney, boost1.58? is this run against the silo 16?
[20:12] <Laney> they all are, that's how it got set up
[20:12] <doko> argh, ok
[20:13] <Laney> at least it shows you work that needs doing in there ;)
[21:22] <Laney> doko: is this legitimate?
[21:22] <Laney> build-3.5/data/ShibokenConfig.cpython-35m-x86_64-linux-gnu.cmake:SET(SHIBOKEN_PYTHON_SUFFIX ".cpython-35m-x86_64-linux-gnu")
[21:22] <Laney> build-3.4/data/ShibokenConfig.cpython-34m.cmake:SET(SHIBOKEN_PYTHON_SUFFIX ".cpython-34m")
[21:55] <doko> Laney, yes, this is now upstream
=== salem_ is now known as _salem
[23:48] <robert_ancell> slangasek, is there anything in particular I need to setup my wily box to compile with GCC5? I installed the packages and updated the symlinks but I still don't reproduce the errors in the PPA for zeitgeist
[23:48] <robert_ancell> Wondering if there's another package that might be affecting it
[23:51] <slangasek> jamespage: it looks like most of the openstack packages' autopkgtests are failing in wily now because they're uninstallable due to the sqlalchemy transition.  Is someone working on fixing the versioned deps on older sqlalchemy?
[23:52] <slangasek> jamespage: fwiw I'm asking about this because sqlalchemy is one of the packages that needed rebuilding against python3.5... it's rebuilt, but is clearly incompatible with openstack currently in wily
[23:52] <slangasek> robert_ancell: I'd say the most reliable way to reproduce it would be to enable that ppa in your sources.list
[23:53] <robert_ancell> slangasek, yeah, there is a lot of stuff in that PPA though...
[23:53] <slangasek> robert_ancell: right, you wouldn't need to install it all, but you'd want to pull your build-dependencies from there
[23:53] <robert_ancell> Good point
[23:55] <slangasek> robert_ancell: what I do notice from eyeballing the logs, the failing test links against xapian and xapian is in the list of packages pulled from the ppa