[00:00] <sarnold> mark06: that contains the database used by locate, for e.g. "locate apache"
[00:03] <mark06> is this the module that fills in the repositories menu? http://bazaar.launchpad.net/~ubuntuone-control-tower/software-center/stable-13-10/view/head:/softwarecenter/backend/channel_impl/aptchannels.py
[00:04] <mark06> HMM WHAT? PROBLEM DISAPPEARED
[00:05] <mark06> I was just running apt-file update, is that interfering somehow?
[00:06] <sarnold> oh I wonder if this is that crazy xapian thing I've tried to ignore
[00:17] <Noskcaj_> pitti: Could you please merge gnome-packagekit soon? It drops upower usage. If you don't have time, i could take it
[00:17] <mark06> I had deleted the xapian dir then SC started to exit after opening...
[00:23] <mark06> folks, I'm leaving then, thank you for the attention anyways... if it's ever related to apt-file and I find reproducible steps, I think I'll just file a bug.... bye
[00:48] <sladen> mtwebster:
=== timrc is now known as timrc-afk
[01:10] <mtwebster> sladen: ?
=== timrc-afk is now known as timrc
=== _salem is now known as salem_
[01:38] <sladen> mtwebster: accidentally trying to tab-complete mark06 to provide encouragement, but tab-completion + enter failed
[01:40] <luist> can i build a i386 package in my amd64 VM?
=== timrc is now known as timrc-afk
=== timrc-afk is now known as timrc
=== salem_ is now known as _salem
=== timrc is now known as timrc-afk
=== timrc-afk is now known as timrc
=== fginther is now known as fginther|away
[04:14] <pitti> Good morning
[04:14] <Unit193> Howja.
[04:16] <pitti> Noskcaj: oh, did I touch that last? indeed; if it's compatible with our packagekit, sure (feel free to steal, of course)
[04:16] <pitti> Noskcaj: ah, the merge is trivial
[04:23] <pitti> OdyX, tkamppeter: FYI, latest cups' autopkgtest now fails, thus it's stuck in -proposed
=== dpm-afk is now known as dpm
=== timrc is now known as timrc-afk
[06:03] <dholbach> good morning
=== timrc-afk is now known as timrc
[06:07] <pitti> hey dholbach, wie gehts?
[06:07] <pitti> mvo_: guten Morgen
[06:07] <dholbach> hey pitti, hey mvo_
[06:07] <mvo_> hey pitti, good morning!
[06:07] <dholbach> sehr gut - wie geht's Euch?
[06:08] <mvo_> hey dholbach
[06:08] <pitti> mvo_: recently we seem to have gotten a stricter pep8, which now makes a lot of tests fail; ubuntu-release-upgrader, update-manager, aptdaemon are your realm, there's some more
[06:08] <pitti> dholbach: supi, danke!
[06:09] <pitti> mvo_: want a hand with some of them? most of them are the new (IMHO relatively stupid) '# needs to be followed with a space' check, argh
[06:09] <mvo_> pitti: aha, thanks. I saw the failures but haven't investigated further
[06:09] <pitti> all my nice "#--------" separators cause complaints now :)
[06:09] <mvo_> pitti: haha, I have a look now, perfect work to wake up fully ,)
[06:09] <pitti> lol
[06:09] <pitti> mvo_: alternatively that particular comment one could of course just be ignored :)
=== RAOF_ is now known as RAOF
[06:43] <pitti> mvo_: as I said, feel free to toss me one or two of these for fixing
[06:45] <mvo_> pitti: thanks, if you could take a look at aptdaemon that would be great
[06:45] <pitti> mvo_: sure
=== oSoMoN_ is now known as oSoMoN
[06:45] <mvo_> pitti: I take care of the other two (and did a bit of drive-by fixing along the way :)
[06:45] <mvo_> pitti: thanks!
[07:21] <pitti> mvo_: do you happen to have the changes from https://launchpad.net/ubuntu/+source/aptdaemon/1.1.1+bzr970-1ubuntu2 in local bzr and just forgot to push, or shoudl I just grab the diff from LP?
[07:22] <pitti> mvo_: I'll also adjust vcs-* from trusty to utopic for the upload
=== timrc is now known as timrc-afk
[07:23] <mvo_> pitti: ups, I accidently pushed it to bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/aptdaemon/ubuntu-utopic/
[07:23] <mvo_> pitti: its on the right branch now. and fix for fixing the vcs header
[07:25] <pitti> mvo_: thanks
[07:25] <pitti> mvo_: I assume s/fix for/thanks for/ :)
[07:25] <mvo_> :)
[07:25]  * mvo_ can't type and needs more tea
[07:27]  * pitti hugs mvo
[07:28]  * mvo_ hugs pitti
=== timrc-afk is now known as timrc
[07:37] <pitti> mvo_: erk, I botched the version number, should have set it back to -1ubuntu1 (it's -1ubuntu3 now even though it's a new upstream snapshot); but no biggie
[07:37] <pitti> mvo_: cf. "tea"
[07:39] <mvo_> pitti: heh, no worries
[07:44] <LocutusOfBorg1> cjwatson, the new vtk is on mentors :)
[08:14] <LocutusOfBorg1> cjwatson, nevermind, vincent cheng is actually uploading, thanks :D
[08:15]  * xnox lost my irc connection again =(
[08:15] <xnox> doko: boost pretty printers that looks cool. Can one package it, in a way that it gets auto-enabled when installed / available.
[08:16] <doko> xnox, if you do so, please check that it works with Python3
[08:22] <xnox> ack.
=== sletta_ is now known as sletta
[09:55] <roadmr> why use awk when you can get just as confused with sed O_0
[10:04] <brendand> roadmr, why use either when you can just kill yourself ?
[10:05] <brendand> roadmr, haven't used either in a while and my life is better for it :)
[10:05] <brendand> less stress
[10:07] <brendand> mvo_, dumb question - how do i run the integration tests for click?
[10:09] <cjwatson> LocutusOfBorg1: ok, cool
[10:10] <LocutusOfBorg1> :)
[10:10] <cjwatson> brendand: use an autopkgtest runner on click
[10:11] <cjwatson> brendand: or debian/tests/run-tests.sh in an environment with all of click's binary packages plus the ones listed in debian/tests/control installed
[10:11] <roadmr> brendand: oh you mean: https://www.youtube.com/watch?v=0B0sFtRTlx4
[10:12] <LocutusOfBorg1> xnox, what is missing for http://people.canonical.com/~ubuntu-archive/transitions/html/libav10.html?
[10:12] <LocutusOfBorg1> just performous?
[10:12] <LocutusOfBorg1> seems that vtk6 and wxsvg are good
[10:12] <brendand> roadmr, okay then...
[10:13] <roadmr> brendand: so what do you use when you need a regex? or have you completely freed yourself from regexes?
[10:14] <brendand> roadmr, grep
[10:14] <roadmr> brendand: but.. but.. what about substitution?
[10:15] <brendand> roadmr, bah, who needs substitution
[10:15] <rbasak> infinity: with juju-core still stuck in utopic-proposed on the powerpc FTBFS, what do you think of ignoring the powerpc arch for the purposes of migration?
[10:16] <roadmr> where we're going, we don't need substitution
[10:17] <infinity> rbasak: We could pull the binaries for now.  I'd really like to get to the bottom of why it breaks, but not how I want to spend my vacation.
[10:18] <infinity> rbasak: I'll yank the binaries in utopic/powerpc for now.
[10:19] <infinity> GAH.
[10:20] <infinity> I may have just removed juju-core entirely.  La la la.
[10:20] <infinity> Well, that will have the same effect. :P
[10:22] <cjwatson> LocutusOfBorg1: vtk6, wxsvg, nepomuk-core are all false positives.  I expect to demote performous to -proposed.  I think we just need to figure out what to do with mplayer's various reverse-dependencies (since mplayer's been removed from Debian, so we should probably eventually remove it).
[10:23] <rbasak> infinity:
[10:23] <rbasak> infinity: I'm not sure what you mean by "yank the binaries".
[10:23] <infinity> rbasak: Remove the powerpc juju-core binaries from utopic.
[10:24] <rbasak> But...they never got built?
[10:24] <infinity> rbasak: Of course they did, or you wouldn't have this problem.
[10:24] <LocutusOfBorg1> exactly cjohnston
[10:24] <rbasak> Oh.
[10:24] <rbasak> I see
[10:24] <rbasak> So migration succeeds, because utopic "never had" a powerpc build. I follow now, thanks.
[10:25] <LocutusOfBorg1> sorry cjwatson I hope with the accept of new ffmpeg will be back agan
[10:25] <infinity> rbasak: Although, with my typo, migration will now succeed because utopic has no juju-core at all. :P
[10:25] <rbasak> :)
[10:25] <infinity> rbasak: But, whee.  End result the same.  Too lazy to waste the effort copying it back in just to supersede it half an hour later.
[10:25] <rbasak> OK, thanks!
[10:26] <bluesabre> hey guys, quick question... what's the process for shipping packages with *only* translation updates? I would imagine that they do not need to follow the whole SRU process, right?
[10:26] <bluesabre> (gearing up for .1)
[10:27] <infinity> rbasak: Anyhow.  We need to get to the bottom of this.  The regression is obviously a bug somewhere (toolchain bug, bug in juju tickling a toolchain change, who knows), and we do actually have people (Servergy) trying to do juju things with ppc32.
[10:27] <infinity> rbasak: But, since it seems to be okay on trusty, as long as we make sure to figure it out on utopic "soon", I'm fine with a temporary hack around it.
[10:28] <rbasak> infinity: I would have looked at it, except I don't think I have a chance of having access to somewhere where it reproduces.
[10:28] <infinity> rbasak: Also, mildly concerned that, even though ppc32 isn't an officially supported arch, any regression in powerpc usually also affects ppc64, so we could have a sleeper bug that will bite us in two weeks on ppc64el.
[10:29] <rbasak> I should probably focus on landing 1.18.4 in Trusty now that I have the MRE acked.
[10:29] <infinity> rbasak: Right, the part where it doesn't reproduce on the porter confuses the crap out of me, since I installed all the same packages locally and *could* reproduce.
[10:29] <rbasak> infinity: maybe copy the exact buildd chroot over?
[10:29] <infinity> rbasak: I'll have to move on to trying to identically reproduce the porter, including hardware, and see if that at least reproduces the lack of reproduction, cause I'm puzzled.
=== roadmr is now known as roadmr_afk
[10:30] <rbasak> infinity: I'm just saying that I seem to have no choice but to leave the whole thing to you right now.
[10:30] <infinity> rbasak: Yeah.  I can give you access to a machine where it *does* reproduce, if you're interested in trying to trace the explosion.
[10:31] <infinity> rbasak: Personally, I want to know why it *doesn't* fail on the porter, cause that's confusing as heck.
[10:31] <cjwatson> LocutusOfBorg1: well, maybe, but I'd rather not wait for that
[10:31] <rbasak> infinity: I might need to take you up on that, but I think I need to prioritise a few other things first before I can do a deep dive on that.
[10:32] <LocutusOfBorg1> cjwatson, of course not, I was thinking about a debian reintrodution and an ubuntu sync
[10:32] <infinity> rbasak: Right.  Focus on the SRU first, but keep this in the back of your mind.
[10:32] <rbasak> Ack, thanks.
[10:34] <rbasak> For an MRE SRU with 1.18.4-0ubuntu1 in utopic, is 1.18.4.0ubuntu1~14.04.1 a sensible version number for Trusty?
[10:34] <cjwatson> LocutusOfBorg1: well the wnpp bug looks like a hideous swamp to me so I see no reason to predict any particular timeframe in which ftpmaster will want to deal with it ...
[10:35] <bluesabre> Are any sponsors available to upload the following packages to trusty-proposed?
[10:35] <bluesabre> https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1331871
[10:35] <ubottu> Ubuntu bug 1331871 in lightdm-gtk-greeter (Ubuntu) "[SRU] Please backport lightdm-gtk-greeter 1.8.5 to trusty" [Undecided,New]
[10:36] <bluesabre> https://bugs.launchpad.net/ubuntu/trusty/+source/menulibre/+bug/1323405
[10:36] <ubottu> Ubuntu bug 1323405 in menulibre (Ubuntu Trusty) "[SRU] Please backport menulibre-2.0.4 to trusty" [Undecided,New]
[10:40] <xnox> doko: i've seen gobjc ftbfs, as gobjc points to gobjc-4.9, whilst gcc has been reverted to 4.8.
[10:41] <xnox> doko: will you be re-instating 4.9 as default soon (and/or already did so)
[10:41] <xnox> doko: or will you revert gobjc to 4.8 as well now?
[10:45] <doko> xnox, planned for Monday to default to 4.9 again
[10:45] <xnox> doko: cool!
[10:45] <doko> then just give back the ftbfs
[10:45] <xnox> sehr gut! =)
[10:46] <sil2100> slangasek, seb128: so, regarding libqofono tests... not sure if we'll be able to get those easily working
[10:49] <sil2100> slangasek, seb128: those tests seem to require ofono working to pass, and it's a strange configuration
[10:51] <cjwatson> siretart: I think somebody needs to go through the dependencies on mencoder in Ubuntu (of which there are rather more than in Debian due probably to debian-multimedia.org imports in the dawn of time) and see what can be done with them
[10:54] <shadeslayer> pitti: whom do I talk to about retiring some upgrade jobs on jenkins?
[10:54] <pitti> shadeslayer: jibel or me
[10:55] <shadeslayer> pitti: https://jenkins.qa.ubuntu.com/view/Upgrade/job/upgrade-kubuntu-precise-trusty-desktop-backports-amd64/ & https://jenkins.qa.ubuntu.com/view/Upgrade/job/upgrade-kubuntu-precise-trusty-desktop-backports-i386/ can be retired
[10:55] <shadeslayer> pitti: I'm assuming saucy jobs will be auto terminated on saucy EOL
=== vrruiz_ is now known as rvr
[10:56] <pitti> jibel: ^ can I just delete them, or will they come back automatically from some config file?
[10:56] <shadeslayer> IIRC he had a branch with the config in them
[10:57] <brendand> cjwatson, what have i got myself into here: http://paste.ubuntu.com/7705276/?
[11:00] <cjwatson> brendand: Can I see "find /opt/click.ubuntu.com -ls"?
[11:01] <brendand> cjwatson, right - there's some user directories in there for users i later deleted
[11:01] <brendand> cjwatson, enough to just rm those?
[11:03] <cjwatson> brendand: I'd like to see the evidence before you delete it, if possible
[11:04] <cjwatson> It definitely shouldn't crash and block upgrades
[11:04] <cjwatson> (OK, that may be hard to fix in this case and you'll have to work around it anyway, but for the future)
[11:04] <cjwatson> brendand: Also, you should be doing this kind of test in a clean chroot anyway
[11:05] <brendand> cjwatson, http://paste.ubuntu.com/7705310/
[11:05] <brendand> cjwatson, yeah. this was a little while ago
[11:05] <seb128> sil2100, slangasek, well, we probably shouldn't block landing on that then, but still have a bug for tracking the work needed
[11:07] <cjwatson> brendand: Right, so removing the stale directories from under /opt/click.ubuntu.com/.click/users/ will fix this, but I'd like a bug report
[11:07] <brendand> cjwatson, will do
[11:07] <cjwatson> We need to do something more intelligent there, not 100% sure what :)
[11:09] <brendand> cjwatson, does "Can't update click if we have previously installed packages for users that were later deleted" summarise it?
[11:12] <cjwatson> brendand: Yes
[11:14] <brendand> cjwatson, https://bugs.launchpad.net/bugs/1334611
[11:15] <ubottu> Ubuntu bug 1334611 in click "Can't update click if we have previously installed packages for users that were later deleted" [Undecided,New]
[11:15] <brendand> cjwatson, now can i zap them :)
[11:15] <cjwatson> brendand: Yep
[11:16] <cjwatson> (for future reference, bugs on click go on the click package in Ubuntu, not the upstream project)
[11:16] <cjwatson> Not even sure how that was possible, since click upstream doesn't have bug tracking in Launchpad configured
=== roadmr_afk is now known as roadmr
=== bschaefer_ is now known as bschaefer
[11:21] <sil2100> seb128: yeah, I've been trying to make them better, since I fixed up the rules to already start the tests properly but making the tests run as they should would require a lot of quilt patching probably
[11:22] <seb128> sil2100, right, well please open a bug and write your finding in there
[11:22] <sil2100> ACK
[11:22] <mvo_> cjwatson: just catching up with the backlog, do you want me to look at this issue ? (bug #1334611)
[11:22] <ubottu> bug 1334611 in click (Ubuntu) "Can't update click if we have previously installed packages for users that were later deleted" [High,Triaged] https://launchpad.net/bugs/1334611
[11:25] <cjwatson> mvo_: If you like - we should probably just ignore registrations for users that don't exist when we're trying to iterate over all users
[11:25]  * mvo_ nods
[11:25] <cjwatson> mvo_: It would be nice to figure out why we're getting getpwnam returning NULL with errno == 0 ...
[11:25] <cjwatson> Oh, maybe that's just what getpwnam does when the user doesn't exist but there's otherwise no error
[11:26] <cjwatson> Yeah, getpwnam(3) ERRORS "0 or ENOENT or ESRCH or EBADF or EPERM or ...: The given name or uid was not found."
[11:26] <cjwatson> Great, uh, I wonder if there's a reliable way of telling the difference!
[11:27] <mvo_> cjwatson: yeah, just looked at the manpage too, great to get so many "or" options :/
[11:29] <sil2100> seb128: what would be the best place to fill the bug at? As libqofono package doesn't exist yet
[11:32] <siretart> cjwatson: I fear that most of them need to be removed. alternatively, we could have an mplayer/mencoder that links statically against its internal copy, but do we really want that?
[11:32] <seb128> sil2100, just open against ubuntu and reassign once the package is uploaded
[11:33] <cjwatson> siretart: I asked because I don't want to learn enough to make the decision ... :)
[11:33] <sil2100> ACK
[11:33] <sil2100> seb128: thanks :)
[11:42] <siretart> cjwatson: I see :-)
=== roadmr is now known as roadmr_afk
=== roadmr_afk is now known as roadmr
=== MacSlow is now known as MacSlow|lunch
[12:15] <Matml_> Hi all.
[12:16] <infinity> rbasak: 1.18.4-0ubuntu1~14.04.1 implies it's a straight backport of the utopic packaging.  If it's the trusty packaging, but the new upstream source, you want 1.18.4-0ubuntu0.14.04 or similar.
[12:16] <infinity> rbasak: The distinction might not matter today, but I imagine it will in time, if {build-,}deps get versioned or the packaging diverges in other "can't be identical between releases" ways.
[12:17] <rbasak> infinity: OK, thanks. That's a good point though - for an MRE, must I use trusty packaging? In this case utopic also carries the same major series version, so the packaging changes are generally good (eg. additional dep8 tests)
[12:20] <infinity> rbasak: As a general rule, making unnecessary packaging changes in an SRU (even an MRE) just muddies the review and verification.
[12:20] <rbasak> OK, I'll avoid that then - thansk.
[12:20] <infinity> rbasak: But things that obviously don't affect the binary at all (dep-8 is a fine example), I can see why people might want to keep them in sync.
[12:21] <infinity> rbasak: The general theory though, is that the packaging in trusty was tested on trusty, the packaging on utopic was tested on utopic, and there's no guarantee the latter works on the former.  Obviously, if changes need to be made to accomodate the new upstream, that's different.
=== fginther|away is now known as fginther
[12:31] <halfie> hi, I am very new to Ubuntu (and Debian) packaging. so I was wondering if I got get some early feedback on one of packages I am packaging currently?
[12:31] <halfie> s/got/could
[12:31] <halfie> https://github.com/kholia/rexgen
=== MacSlow|lunch is now known as MacSlow
[12:48] <pitti> shadeslayer: removed from internal jenkins, RT sent to remove from public one
=== _salem is now known as salem_
[12:53] <jibel> shadeslayer, and moved to old/ in the branch so they won't be recreated if I ever need to republish trusty upgrade jobs.
[14:57] <Mlar_> Hi all.
[15:35] <Dave77> how do I get somebody to make a patch for a program?
[16:01] <chiluk> Can someone point me to the 12.04.5 development milestone dates?
[16:03] <bekks> chiluk: I dont think there will be a 12.04.5
[16:03] <chiluk> bekks there most certainly will be a 12.04.5
[16:04] <bekks> Really? https://lists.ubuntu.com/archives/ubuntu-devel/2014-February/038042.html
[16:05] <chiluk> bekks yes really https://launchpad.net/ubuntu/+milestone/ubuntu-12.04.5
[16:05] <chiluk> except I'm looking for dates.
[16:06] <bekks> Look for the expected date on the link you just posted.
[16:07] <chiluk> bekks ok man , love the effort, but expected date does not a milestone date make..
[16:08] <chiluk> basically I'm trying to find development milestones.. feature freeze dates... alpha beta milestones, etc.
[16:13] <cjwatson> chiluk: Don't think they're set, project from the earlier entries on https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
[16:13] <chiluk> thanks cjwatson that is what I was looking for.
=== roadmr is now known as roadmr_afk
[17:04] <alexbligh1> I'm having some fun with conffiles and upgrades. I am trying to upgrade between Precise (with apache 2.2) and Trusty (with apache 2.4). Precise apache has mod_ident, but Trusty does not (LP#1333388). No problem, I will create my own mod_ident module (https://github.com/abligh/libapache-mod-ident - also in the LP bug). This installs fine on a clean install of 14.04 but I am told that post an upgrade from 12.04 t
[17:04] <alexbligh1> o 14.04 the conffile (/etc/apache2/mods-available/ident.load) does not install, presumably because the residual apache package deleted the conffile on upgrade. Assuming 14.04 isn't going to be fixed in the near future and I still need my module, what's the correct way to address this? Install the conffile somewhere else then copy it in postinst and remove it in prerm (yuck)?
[17:05] <alexbligh1> I'm having some fun with conffiles and upgrades. I am trying to upgrade between Precise (with apache 2.2) and Trusty (with apache 2.4). Precise apache has mod_ident, but Trusty does not (LP#1333388). No problem, I will create my own mod_ident module (https://github.com/abligh/libapache-mod-ident - also in the LP bug). This installs fine on a clean install of 14.04 but I am told that post an upgr
[17:05] <alexbligh1> ade from 12.04 to 14.04 the conffile (/etc/apache2/mods-available/ident.load) does not install, presumably because the residual apache package deleted the conffile on upgrade. Assuming 14.04 isn't going to be fixed in the near future and I still need my module, what's the correct way to address this? Install the conffile somewhere else then copy it in postinst and remove it in prerm (yuck)?
[17:05] <alexbligh1> I'm having some fun with conffiles and upgrades. I am trying to upgrade between Precise (with apache 2.2) and Trusty (with apache 2.4). Precise apache has mod_ident, but Trusty does not (LP#1333388).
[17:05] <alexbligh1> x
[17:06] <alexbligh1> x
[17:07] <sarnold> alexbligh1: you didn't miss any responses while you were away
[17:07] <alexbligh1> (apologies if spamming the channel here, client is showing channel hung)
[17:08] <rbasak> alexbligh1: so the Precise apache2 package had a conffile defined in it, but in Trusty that's gone?
[17:10] <rbasak> alexbligh1: so the Precise apache2 package had a conffile defined in it, but in Trusty that's gone?
[17:10] <rbasak> alexbligh1: if so, can you see if dpkg lists the conffile as obsolete after the upgrade?
[17:11] <rbasak> If this is the case, then we have two bugs - the mod_ident regression, and the obsolete conffile.
[17:11] <rbasak> https://wiki.debian.org/DpkgConffileHandling has some information on this.
[17:12] <alexbligh1> rbasak, a pile of apache modules (including mod_ident) have gone between Precise and Trusty, as far as I can tell because the autoconf is 'dumb' (by which I mean doesn't send anything special on the ./configure line), and upstream apache changed the default from compile everything to 'most'. You need 'reallyall' or something for everything (it's in the LP bug)
[17:13] <alexbligh1> rbasak, I'm not sure whether omitting these modules from the standard apache module is a bug or a feature, but it would at least be nice if they were around in apache2-mod-extra or something (which they aren't at the moment)
[17:13] <rbasak> alexbligh1: sounds like that's a bug that needs forwarding to Debian.
[17:14] <rbasak> If Debian go to 'reallyall', then maybe we should consider an SRU to Trusty, although that does scare me a little.
[17:14] <alexbligh1> rbasak, well, I filed it in LP, with a patch to fix it for mod_ident :-)
[17:14] <alexbligh1> rbasak, should I file it at debian as well as Ubuntu?
[17:14] <rbasak> alexbligh1: thank you for investigation - it saves me from figuring out what's going on.
[17:15] <rbasak> alexbligh1: if you could check if it affects Debian, and file if they don't have a bug already, etc, then that would be great, yes.
[17:15] <rbasak> alexbligh1: I would prefer not to diverge from Debian on this, so would prefer to take a fix from them rather than add to the Ubuntu delta on apache.
[17:15] <alexbligh1> rbasak, then the problem is made worse with the conffile thing. QA looked at it here and then (unhelpfully) did piles of purge stuff in order to try and fix it. It looks like the conffile is obsolete or something.
[17:16] <rbasak> alexbligh1: right. If a newer package version intentionally drops the conffile, it needs to specifically take steps to remove the obsolete conffile.
[17:16] <alexbligh1> rbasak, that essentially means I can't install my replacement mod_ident (repo provided) and will presumably bite us if we do a apache2-mod-extra too.
[17:16] <rbasak> alexbligh1: that's right, yes. https://wiki.debian.org/DpkgConffileHandling explains what's going on there.
[17:16] <sarnold> heh, I'd have tried the "piles of purge stuff" myself :)
[17:17] <rbasak> alexbligh1: it sounds like this was inadvertent, so that would explain the obsolete conffile
[17:17] <alexbligh1> rbasak, yeah I think so. I will file a bug with debian but I am not holding my breath for an Ubuntu SRU in the timescale I need it - which is entirely understandable given the modules are slightly obscure.
[17:18] <alexbligh1> rbasak, what's the best way for me to work around this in the mean time?
[17:18] <alexbligh1> rbasak, (and yes I'm reading that page)
[17:18] <sladen> ...conffile shouldn't be disappearing even if it's missing from the newer package
[17:18] <sladen> unless something is explicitly causing it to be nuked
[17:18] <rbasak> alexbligh1: I'm not sure. Maybe don't ship the conffile in your extra package, and force the right thing in place with config management?
[17:19] <rbasak> alexbligh1: the trouble is that the obsolete conffile is a bug in the apache packaging in Trusty, and you can't easily fix that without rebuilding it or us landing an SRU.
[17:19] <alexbligh1> rbasak, config management == copy the file on postinst?
[17:19] <rbasak> (and for production use rebuilding it causes issues with any future security updates)
[17:20] <alexbligh1> rbasak, that is precisely my concern
[17:20] <sladen> alexbligh1: if you need a short-term ugly kludge,  chattr +i theconfile  before upgrade
[17:20] <rbasak> alexbligh1: I meant puppet/chef etc. Copying the file on postinst is evil and shouldn't be in the archive, but as a workaround for your own custom package sounds fine.
[17:23] <alexbligh1> rbasak, no puppet chef in play here. These are in essence appliance boxes out in the field
[17:24] <alexbligh1> rbasak, my concern is the next 'apt-get update && apt-get upgrade' then has the SRU in and confuses people.
[17:24] <rbasak> alexbligh1: then the postinst method sounds OK, but I can see at least one catch - if/when we SRU a removal of the obsolete conffile, you'll lose the file.
[17:25] <alexbligh1> rbasak, indeed :-/
[17:25] <alexbligh1> rbasak, chance of released SRU shipping before Jul 15?
[17:25] <alexbligh1> rbasak, (quite prepared for the answer 'zero')
[17:26] <rbasak> Two and a half weeks? Feasible but maybe unlikely.
[17:27] <rbasak> You'll want an Ubuntu developer who can help you land it as a priority.
[17:27] <alexbligh1> rbasak, do you know off the top of your head whether the name of the .load file in apache2 has to match the name of the module? Because the other option is simply to rename the .load file to something else if it's just relying on a wildcard load.
[17:27] <rbasak> IIRC it does have to match something.
[17:28] <rbasak> (I've tried using a different name in the past and something broke)
[17:28] <alexbligh1> actually perhaps I just rename the whole module, and beg someone at Ubuntu to add provides+conflicts+replaces to the SRU (when it comes) with my module.
[17:28] <alexbligh1> (as the config directives will still conflict)
[17:29] <alexbligh1> or I suppose I could change the config directives too (sigh)
[17:29] <rbasak> I don't think that adding metadata for packages that never entered the archive (Debian or Ubuntu) is acceptable, sorry. But maybe somebody can tell me otherwise.
[17:30] <rbasak> Can you fix the problem with a new apache2 in your own PPA maybe, and watch for security updates and maintain the PPA until an SRU lands?
[17:32] <alexbligh1> rbasak, well we have our own repo so I can do better than a PPA :-) I suppose I can do that, yes. Actually I'm not sure I even need to watch for security updates as if the 'right' apache is upraded to it should remove all trace of needing the conffiles, so a security upgrade would then fix it, yes?
[17:32] <alexbligh1> rbasak, and that would also mean that I could supply the bug fix for the main package :-)
[17:33] <rbasak> alexbligh1: a security update will not fix the conffile bug. They bypass the normal SRU process, including the week-long public testing period, so can't do anything but fix security issues.
[17:34] <rbasak> alexbligh1: a bug fix for the main package would be appreciated though! This probably needs some coordination with Debian's fix though, assuming this affects Debian - I don't want to diverge from them.
[17:35] <alexbligh1> rbasak, no I meant that if "my" apache2.4 is installed first, it would (presumably) remove all trace of mod_ident.load from the relevant debian package file. So then if a security update comes through it would reinstall over my package (sure) but the mod_ident thing wouldn't be there in the first place. But I'd need to know "my" apache2 was installed before mod_ident (depends: would do I suppose)
[17:36] <rbasak> alexbligh1: ah - good point. Your custom mod_ident package could have a versioned Pre-Depends on your custom apache 2.4 package to ensure that the postinst runs before it's unpacked.
[17:37] <alexbligh1> rbasak, or perhaps I could do it in a transition package
[17:38] <alexbligh1> actually doing it in my apache2.4 package is better
[17:38] <rbasak> Just look out in case mod_ident is reintroduced in an SRU. I don't know if we'll do that or not though.
[17:39] <alexbligh1> rbasak, I presume I need to do the bit marked "# Remove a no-longer used conffile" in that page you sent me?
[17:39] <alexbligh1> rbasak, hopefully if you do reintroduce it it will be in an apache2-mod-extra
[17:40] <alexbligh1> rbasak, or that will be what I will be suggesting in the debian bug :-)
[17:40] <rbasak> alexbligh1: I think so, yes.
[17:40] <rbasak> (haven't looked in detail)
[17:41] <alexbligh1> rbasak, thanks
[17:41] <alexbligh1> rbasak, very useful!
[17:53] <roaksoax> 4/win 9
[18:35] <FlowRiser> hey guys, I have a quick question; Is the /etc/os-release file also available on Ubuntu?
[18:35] <bekks>  No.
[18:35] <rbasak> I appear to have one (on Trusty)
[18:35] <slangasek> yes, it is.
[18:35] <bekks> FlowRiser: Use lsb_release -a instead
[18:36] <slangasek> it's a relatively recent thing, so it's only present in releases after 12.04
[18:36] <rbasak> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659853 was the bug in Debian. Fixed in base-files 6.8.
[18:36] <ubottu> Debian bug 659853 in base-files "base-files: Please provide /etc/os-release" [Wishlist,Fixed]
[18:36] <slangasek> but it's part of base-files, so every Ubuntu system from quantal on will have it.
[18:37] <FlowRiser> thank you, slangasek!
[18:37] <bekks> TIL :)
[18:37] <FlowRiser> what does TIL mean?
[18:38]  * FlowRiser is a noob
[18:38] <mdeslaur> bdmurray: can I steal your gnupg merge?
[18:39] <FlowRiser> also, bekks, i would normally use lsb_release on Ubuntu; But I am working on doing some Debian-Ubuntu stuff that need to work on both
[18:39] <FlowRiser> lsb_release does not come by default with Debian
[18:39] <bekks> FlowRiser: and debian doesnt support lsb_release? :P
[18:39] <bdmurray> mdeslaur: yes, please
[18:40] <FlowRiser> it just does not come by default, at least on jessie
=== dpm is now known as dpm-afk
=== barry` is now known as barry
[19:35] <stgraber> slangasek, cjwatson: can one of you let my e-mail to u-d-a through?
[19:36] <slangasek> stgraber: doing
=== rww is now known as rwd
=== gusnan_ is now known as gusnan
=== enrico_ is now known as enrico
[21:48] <achiang> having trouble building a utopic schroot hosted in trusty. any clues? http://pastebin.ubuntu.com/7708123/
[21:48] <achiang> or rather, it builds fine, but entering it is problematic
=== maxb_ is now known as maxb
[22:26] <achiang> hm, experiencing this symptom - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675189
[22:26] <ubottu> Debian bug 675189 in schroot "schroot: Doesn't mount /dev, /proc, /sys, /home, etc. anymore" [Important,Fixed]
=== salem_ is now known as _salem
[22:29] <infinity> achiang: Seems unlikely that it's that bug, based on when it was fixed.
[22:29] <achiang> infinity: agreed that it's probably not the same bug, but at least it's giving me clues on places to look
=== alexisb is now known as alexisb_afk
[22:30] <infinity> achiang: The output of "schroot -v -c utopic-amd64" might be enlightening.
[22:31] <achiang> here is a different diff, first - http://pastebin.ubuntu.com/7708266/
[22:32] <infinity> achiang: That's pretty much how it looks on my system.
[22:32] <achiang> infinity: here's the -v output -  http://pastebin.ubuntu.com/7708268/
[22:33] <achiang> infinity: interestingly, i have another schroot that i created a while ago (trusty-armhf) and it is using the default profile. and that one does mount my /home properly
[22:33] <infinity> achiang: So, I see a PROFILE=sbuild there, mine has PROFILE=default.  Do you set profile in your config for the chroot? (I don't)
[22:33] <achiang> yeah... i wonder why i am using the sbuild profile
[22:33] <achiang> need to figure out what env vars influence that (or dotfiles)
[22:33] <infinity> achiang: /etc/schroot/chroot.d/foo
[22:34] <infinity> achiang: ideally, that shouldn't contain profile= at all, then you'll get default when you run schroot, and sbuild when you access it via sbuild.
[22:34] <achiang> infinity: right... mine does contain a profile= line...
[22:34] <infinity> achiang: Which is generally the desired behaviour.
[22:34] <infinity> achiang: Err, oh.  Really?
[22:34] <achiang> infinity: i'm trying to figure out now why/how that got in there
[22:34] <achiang> it says profile=sbuild
[22:35] <infinity> achiang: Oh, you said "does" and I read "does not".
[22:35] <infinity> achiang: It could well be a bug in mk-sbuild or something.  I haven't used it in ages, since I just copied raring->saucy->trusty->utopic. :P
[22:35] <achiang> hm, i don't seem to have anything in ~/.schroot or ~/.sbuild ...
[22:36] <achiang> nothing suspicious in env either - http://pastebin.ubuntu.com/7708285/
[22:36] <infinity> achiang: It's a mk-sbuild bug.
[22:37] <achiang> indeed
[22:37] <achiang> SCHROOT_PROFILE="sbuild"
[22:37] <infinity> SCHROOT_PROFILE="sbuild" (overridable at runtime).
[22:37] <infinity> achiang: Anyhow, just whack the line entirely from the config and you'll be happy.
[22:37] <achiang> profile=$SCHROOT_PROFILE
[22:37] <achiang> infinity: ack, i can do that... just wondering why am i getting bit now?
[22:38] <infinity> achiang: Maybe you haven't used it in a while?
[22:38] <infinity> Or on trusty?
[22:39] <geofft> infinity: Oh, does leaving it out do that? Then why does mk-sbuild even bother to set it?
[22:39] <infinity> geofft: Leaving it out does the right thing, which should be the mk-sbuild default, IMO.  No idea why it's not.
[22:39] <geofft> I ran into this last night -- it changed in raring's ubuntu-dev-tools
[22:40] <geofft> (and it's not even properly overridable via the environment, like it vaguely claims)
[22:40] <infinity> geofft: It should be overridable as of 13.10, I think.
[22:40] <infinity> geofft: But it really shouldn't have a default at all.
[22:40] <geofft> You can override it in ~/.mk-sbuild.rc but not at runtime in the environment, unless I'm misreading
[22:41] <achiang> ubuntu-dev-tools (0.149) unstable; urgency=low
[22:41] <achiang>   [ Marc Deslauriers ]
[22:41] <achiang>   * mk-sbuild: allow specifying the schroot profile.
[22:41] <achiang>   * ubuntutools/config.py: properly handle name being None.
[22:41] <achiang>  -- Benjamin Drung <bdrung@debian.org>  Tue, 13 Aug 2013 23:12:42 +0200
[22:43] <infinity> geofft: Yeah, it only works with the dotfile.  Precisely because a default is set, which overrides the environment.
[22:43]  * achiang fires up ubuntu-bug
[22:43] <infinity> To be fair, the tool *is* called mk-sbuild, not mk-schroot, but given how many of us use it for the latter case, I'd call this a bug. :P
[22:51] <achiang> https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/1334886
[22:51] <ubottu> Ubuntu bug 1334886 in ubuntu-dev-tools (Ubuntu) "/home not mounted, causes schroot errors" [Undecided,New]
[22:52]  * achiang decides this yak looks nice and trim now, tries to remember what he was doing earlier
=== rwd is now known as rwwcoin