[03:22] <robert_ancell> RAOF, if exiv2 is now in proposed (https://launchpad.net/ubuntu/utopic/+source/exiv2/0.24-2ubuntu1) and I upload new packages they'll build against that version right? I don't have to wait until it hits the release pocket
[03:29] <TheMuso> I think you do need to wait till they hit release.
[03:36] <robert_ancell> TheMuso, I tried building gexiv2 and the .deb it produces links against the new version so it seems to work
[03:41] <TheMuso> Ok.
[03:47] <ScottK> robert_ancell: That's correct. If you had to wait for it to get to -release then we'd never get a library transition done.
[03:47] <robert_ancell> ScottK, cool, thanks :)
[04:18] <michagogo> ScottK: hey, you're on SRU team, right?
[04:19] <ScottK> I am.  I'm also about to go to bed.
[04:19] <michagogo> ScottK: Ah. At some point, would you mind taking a loot at my message on the -devel list?
[04:19] <michagogo> look*
[04:19] <ScottK> Which one is that?
[04:19] <michagogo> https://lists.ubuntu.com/archives/ubuntu-devel/2014-July/038389.html
[04:21] <ScottK> At some point.
[04:21] <michagogo> Fair enough.
[04:21] <michagogo> TIA.
[04:21] <michagogo> good night!
[05:34] <pitti> Good mornin
[05:35] <pitti> shadeslayer: what is that hook supposed to do? autopkgtest didn't even run yet in that log, and it cleans up its temp dirs afterwards?
[06:39] <dholbach> good morning
[06:40] <pitti> xnox: so I know why startpar never finishes the "start" part, it's waiting on pulseaudio; it's upstart job never starts (deliberately), but the init.d script wants to
[06:40] <pitti> xnox: when I remove those (update-rc.d pulseaudio disable), startpar start correctly finishes, but still hangs on boot
[06:41] <pitti> xnox: but remind me, why do we need to make startpar work at all? we are already using insserv now, so that ought to be enough?
[06:41] <pitti> xnox: I'm also getting a race condition on start that lots of stuff tries to start before the root partition is mounted r/w
[06:41] <pitti> xnox: i. e. we could certainly spend lots of time fixing all this, but that's not our ultimate goal anyway
[06:41] <pitti> hey dholbach, wie gehts?
[06:45] <pitti> xnox: i. e. we could probably merge to a recent sysvinit and still keep startpar disabled?
[06:52] <wgrant> dpm, pitti: What are the plans for translations for RTM? Wondering how much I need to make Translations (and langpacks etc.) work for the derived distro.
[06:53] <pitti> wgrant: I don't think we actually talked about that at all
[06:54] <pitti> wgrant: but good point, we probably won't be able to build proper langpacks for the derived distro if it doesn't have its own set of templates/exports
[06:54] <pitti> we could possibly just use the latest devel series ones, but that will get inaccurate if strings get dropped/changed
[06:55] <wgrant> Exactly my concerns.
[06:56] <pitti> so if we'll have significant delta in that distro (with string diversions), we probably need to treat it as a full release wrt. translations, too?
[06:56] <dpm> that's what I'm starting to realise too
[06:57] <wgrant> I think so. And I haven't yet checked how much the Ubuntu hardcodings in Rosetta will hurt.
[06:57] <dpm> wgrant, would message sharing work between the derived distro and Ubuntu?
[06:57] <wgrant> dpm: I don't think that would require too much work, but that would be the intent.
[06:58] <dpm> yeah, that'd make sense
[08:12] <LocutusOfBorg1> sil2100, for this time I think just remove the patch and add subversion as b-d is fine :(
[08:12] <LocutusOfBorg1> I cannot build either
[08:12] <LocutusOfBorg1> I have a problem injecting the LDFLAG for tweaking the build
[08:17] <sil2100> LocutusOfBorg1: you think it won't cause any problems anywhere?
[08:19] <LocutusOfBorg1> I think it won't cause any problem, but I'm not sure
[08:19] <LocutusOfBorg1> anyway I'm discussing with upstream https://github.com/luceneplusplus/LucenePlusPlus/pull/65#issuecomment-48018656
[08:25] <LocutusOfBorg1> I'm rebuilding
[08:25] <LocutusOfBorg1> since upstream says tests are just useless and not even implemented (just one test) we can skip them!
[08:26] <LocutusOfBorg1> I'll rebuild with tests disabled and push on mentors if you agree
[09:20] <LocutusOfBorg1> sil2100, please review my changes
[09:25] <Saviq> greyback, ricmm has a beer for you
[09:26] <greyback> Saviq: beer for breakfast, if you say so
[09:26] <Saviq> greyback, I'm just the messenger
[09:44] <sil2100> LocutusOfBorg1: looking! Did you just add the subversion dependency or also some other changes?
[09:48] <sil2100> LocutusOfBorg1: ah! I see the tests being disabled ;)
[09:51] <sil2100> LocutusOfBorg1: ok, so it looks ok I guess, although won't this cause problems? I know that we basically don't have much other choices, but won't it get rejected because of disabled tests?
[09:51] <sil2100> LocutusOfBorg1: I noticed that disabling tests is generally very aggressively frowned upon ;)
[09:54] <sil2100> LocutusOfBorg1: anyway, if you as a DM accept this temporary state, then I'm +1 on it as well
[09:54] <LocutusOfBorg1> sil2100, https://github.com/luceneplusplus/LucenePlusPlus/pull/65#issuecomment-48018656
[09:54] <LocutusOfBorg1> is upstream telling that tests are almost useless at this moment ;)
[09:55] <LocutusOfBorg1> so when and if they will make a good testsuite, and fix their cmake files we can enable them
[09:55] <LocutusOfBorg1> I don't see particular issues with this
[09:56] <sil2100> hah!
[09:56] <sil2100> ;)
[09:56] <LocutusOfBorg1> I see issues with lintian instead ;)
[09:56] <LocutusOfBorg1> seems that doc package is using embedded jquery
[09:57] <LocutusOfBorg1> I'm rebuilding from a clean directory, maybe I just run dpkg-buildpackage prior to clean up the build-dir
[10:03] <LocutusOfBorg1> I tweaked dh_link to link jquery
[10:04] <LocutusOfBorg1> and make doc depend on jquery package
[10:04] <cjwatson> Use dh_linktree instead
[10:04] <cjwatson> It's much better for this, sorts out the dependencies for you
[10:06] <LocutusOfBorg1> syntax is the same?
[10:06] <LocutusOfBorg1> I read it on debian-devel but slipped of my mind
[10:08] <cjwatson> Similar but not identical - see its man page
[10:08] <LocutusOfBorg1> yes
[10:08] <LocutusOfBorg1> done
[10:08] <LocutusOfBorg1> but I still need to override dh_install right?
[10:09] <LocutusOfBorg1> dh_install --fail-missing -Xjquery.js
[10:09] <cjwatson> No, you can run dh_linktree after dh_install and have it replace stuff with symlinks
[10:09] <cjwatson> Well, you'll need to override it for --fail-missing
[10:10] <LocutusOfBorg1> mmm ok
[10:11] <LocutusOfBorg1> does it automatically run after dh_install? I create a file package-doc.linktree
[10:12] <cjwatson> If you're using dh $@ --with linktree, then dh_linktree is sequenced to run after dh_link, which runs well after dh_install
[10:13] <LocutusOfBorg1> wow a new helper ;)
[10:17] <LocutusOfBorg1> mmm strange, I need to build-depend from dh-linktree?
[10:17] <cjwatson> Yes
[10:20] <michagogo> cjwatson: I don't know if you saw it, but I posted to the mailing list as you suggested
[10:20] <michagogo> Thanks for your help!
[10:22] <cjwatson> Yup, thanks
[10:22] <xnox> slangasek: pitti: that has been in the back of my mind as well. Why can't we keep startpar disabled, given that we (a) have enabled update-rc.d (b) we have lsb initfunctions.d hook to keep everything sane
[10:26] <xnox> sarnold: so thunderbird decided to allow me encrypting emails to target email after (a) setting up security smime signing & encryption certificates on the "account" (b) repeating same on the "Manage identities" the default and the one person is going to use.
[10:26] <xnox> sarnold: none of which should be required to encrypt message to someone else....
[10:27] <xnox> (just)
[10:27] <xnox> sarnold: also it couldn't care less that FROM: identity email address did not match Subject / Alt Names on the certificate.....
[10:30] <bluesabre> Good day Sponsors!  Please let me know if anybody is available to upload this package to trusty-proposed
[10:30] <bluesabre> https://bugs.launchpad.net/ubuntu/trusty/+source/menulibre/+bug/1323405
[10:31] <bluesabre> It's been in the sponsors queue for a while now, and we would like to deliver the fixed package in time for 14.04.1
[10:31] <bluesabre> It fixes some nasty bugs that completely break the program, and can corrupt user menus
[10:37] <cjwatson> xnox: It's arguably correct not to care, since anyone can put whatever they like in From: :-)
[10:38] <cjwatson> Well, maybe, not sure
[10:39] <xnox> cjwatson: it's also entertaining how the target person uses Exchange, which appends & mangles the messages, hence the smime signature does not validate =)
[10:40] <LocutusOfBorg1> cjwatson, is it correct? seems to work, but I would like to have a feedback if possible
[10:40] <LocutusOfBorg1> http://anonscm.debian.org/gitweb/?p=pkg-sdl/packages/sdlgfx.git;a=commitdiff;h=568ac5acffec69eadb0c91bb745e01beddf7dee4
[10:40]  * xnox wonders if my Latvian National Identity smartcard certificates can be used for SMIME signing & encryption
[10:50] <cjwatson> LocutusOfBorg1: Looks OK, though I'd normally prefer "--with autoreconf,linktree"
[10:51] <pitti> xnox: right, and I believe latest sysvinit still works well with just plain insserv and without startpar
[10:52] <pitti> cjwatson: FYI, https://jenkins.qa.ubuntu.com/job/utopic-adt-click/9 failed (you didn't get the mail because it was bot-uploaded)
[10:53] <pitti> mvo: unattended upgrades failed as well, argh PEP-8 :/
[10:53] <LocutusOfBorg1> thanks cjwatson there is always to learn ;) fixed!
[10:53] <mvo> pitti: *gih*
[10:53] <mvo> pitti: what the link again? do you have it at hand?
[10:54] <mvo> pitti: I broke it (click)
[10:54] <mvo> sorry
[10:54] <xnox> pitti: hm, wasn't that upload suppose to have "Sponsored for cjwatson" though?! ( i thought we had that enabled by didrocks before he handed ci-uploads over)
[10:54] <pitti> mvo: you mean https://jenkins.qa.ubuntu.com/job/utopic-adt-unattended-upgrades/18 ?
[10:54] <mvo> pitti: yes, thanks
[10:55] <pitti> xnox: https://launchpad.net/ubuntu/utopic/+source/click/0.4.29 -> (sponsored by Ubuntu Archive Robot)
[10:55] <mvo> cjwatson: I broke the click test, I will work on a fix while stearing the the citrain
[10:56] <xnox> pitti: aha. I looked at the release pocket source publish record. Right. so that bit is in place.
[10:57] <xnox> pitti: i guess with enough trickery jenkins could be sending the email to the right sponsored for people as well....
[10:57] <xnox> priority: for later
[10:58] <cjwatson> mvo: Thanks, I hadn't looked at the autopkgtest output yet
[10:58] <mvo> cjwatson: I use os.environ["USER"] which is not available in adt it seems
[10:58] <cjwatson> xnox: My name's there, it's just obscure.  See https://launchpad.net/ubuntu/+source/click/+publishinghistory
[10:58] <pitti> mvo: actually, I thought I just fixed that a few days ago
[10:59] <mvo> pitti: oh?
[10:59] <mvo> pitti:     user = os.environ["USER"]
[10:59] <mvo> KeyError: 'USER'
[10:59] <cjwatson> OTOH, I didn't get the mail either
[10:59] <mvo> pitti: is what I see in the test
[10:59] <pitti> mvo: so if it's just that, let me roll out the latest autopkgtest to the machines and retry
[10:59] <diwic> it's probably a USER error
[10:59] <mvo> pitti: yeah, it is just that
[10:59] <diwic> (sorry, couldn't help myself)
[11:00] <mvo> diwic: lol
[11:01] <pitti> mvo: does it depend on $USER just for the tests, or for actual operation?
[11:03] <mvo> pitti: just for the tests iirc
[11:04] <pitti> mvo: hm, still failed
[11:04] <mvo> :/
[11:04] <pitti> mvo: are these tests running as root or user?
[11:05] <mvo> pitti: as root
[11:05] <mvo> pitti: I could hardcode "root" there I guess :)
[11:05] <pitti> oh, so $USER would be "root"?
[11:05] <pitti> mvo: right, I just recently fixed it for tests that run as user
[11:06] <mvo> pitti: aha, ok. so what should I do, just hardcode root here?
[11:06] <pitti> mvo: I'm knee-deep in debugging a Mir/libudev issue, would you mind filing an autopkgtest bug about that? I can look at that on Monday
[11:07] <mvo> pitti: no worries, I can also just fix it on my side, but I'm equally happy to file a bug. whatever is easier for you
[11:07] <pitti> mvo: or environ.get('USER', 'root') perhaps
[11:07] <mvo> (can do both of course)
[11:07] <mvo> pitti: yeah, good idea
[11:07] <pitti> mvo: yeah, but still appreciated, in case other tests need that as well
[11:07] <pitti> I never ran into this, and TBH $USER is a rather bad idea IMHO
[11:08] <mvo> pitti: fair enough
[11:08] <mvo> https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1337802
[11:08] <pitti> ohe of these things people should have avoided 30 years ago :)
[11:08] <pitti> mvo: thanks
[11:20] <mvo> pitti: your welcome
[12:53] <cjwatson> xnox: Could you merge dune-geometry, please?  Needed for a pending transition.
[13:05] <pitti> dobey: ubuntuone-dev-tools failure> more PEP-8 fun!
[13:10] <xnox> cjwatson: done.
[13:14] <cjwatson> xnox: thanks :)
[13:22] <bluesabre> xnox: would you mind uploading this package to trusty-proposed to begin SRU verification?
[13:22] <bluesabre> https://bugs.launchpad.net/ubuntu/trusty/+source/menulibre/+bug/1323405
[13:55] <LocutusOfBorg1> sil2100, https://mentors.debian.net/package/lucene++
[13:55] <LocutusOfBorg1> please check and I'll ask for upload
[14:10] <psivaa> infinity: chrisccoulson_: sorry missed your ping last night about /run/shm & /dev/shm state
[14:10] <psivaa> lrwxrwxrwx 1 root root 8 Jul  2 15:15 /dev/shm -> /run/shm
[14:11] <chrisccoulson> that looks normal
[14:16] <sil2100> LocutusOfBorg1: ok, browsing throught in a moment
[14:22] <Bluefoxicy> so guys
[14:22] <Bluefoxicy> what's going on with 14.10?
[14:22] <Bluefoxicy> I sent to the dev list a while back that I'd like to see pam-tmpdir integrated by default this time, and no response
[14:22] <Bluefoxicy> is anyone testing?
[14:24] <Bluefoxicy> Everything's working on my end, has been for several releases.
[14:40] <shadeslayer> pitti: http://paste.ubuntu.com/7747340/ is the hook
[14:42] <pitti> shadeslayer: is cowbuilder somehow creating /tmp/adt-* ? (sorry, I don't know at all how that works, but it seems strange that it'd create an adt* dir)
[14:42] <shadeslayer> hm, not that I know of, it's all very weird
[14:42] <shadeslayer> this hook worked a few weeks ago
[14:42] <shadeslayer> and now it doesn't
[14:42] <pitti> shadeslayer: well, you might have had one from a previous run
[14:43] <pitti> shadeslayer: but this looks like it expects the output before actually running adt-run..
[14:43] <shadeslayer> pitti: do you have a autopkgtest hook for pbuilder?
[14:43] <pitti> shadeslayer: no, I don't
[14:43] <shadeslayer> https://gitorious.org/tanglu/jenkins-tanglu-buildkit/source/6694557e21cc163573338a3b21fd4757435af8e0:slave/pbuilder-hookdir/B20autopkgtest#L21 < does the same thing
[14:43] <pitti> I usually just run adt-run on a .dsc or source tree, or on a .changes if I have a build already
[14:46] <shadeslayer> hm ok, thx :)
[14:48] <mvo> pitti: fixing the pep8 failure right now, kind of ironic to have a pep8 failure in test_pep8.py :P
[14:49] <pitti> mvo: hehe; thanks
[15:40] <shadeslayer> dpm: ping
[15:40] <shadeslayer> dpm: are you in Barcelona next week?
[17:24] <dpm> hi shadeslayer, yes
[19:42] <Bluefoxicy> anyone?
[19:43] <Bluefoxicy> pitti?
[19:59] <infinity> Bluefoxicy: By "a while ago", do you mean October 2012?
[20:00] <Bluefoxicy> wow that comes out of google
[20:01] <Bluefoxicy> what the hell?
[20:01] <Bluefoxicy> I swear I sent an e-mail to ubuntu-devel-discuss last week asking about doing this in 14.10
[20:01] <Bluefoxicy> no evidence of any such e-mail exists anywhere
[20:01] <infinity> Ahh, yes.  You did.
[20:01] <infinity> https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2014-April/014941.html
[20:01] <Bluefoxicy> it's not in my gmail or anything
[20:02] <Bluefoxicy> oh, there it is.  Wait, why don't I have it here?  o_O
[20:02] <infinity> But I'm not sure the arguments really would have changed since mdeslaur responded two years ago to the same thing.
[20:03] <Bluefoxicy> is that the "this should not be a problem, make apps behave properly" argument?
[20:04] <Bluefoxicy> infinity:  my original concern (back in 2004) actually involved information leaks in the form of file names
[20:05] <infinity> Bluefoxicy: Indeed.  Firefox and Thunderbird certainly should learn to use XDG_ locations.
[20:05] <infinity> Bluefoxicy: I get the slight information leak concern.
[20:05] <Bluefoxicy> infinity:  the FHS now specifies temporary files go in /run instead of /tmp?
[20:05] <infinity> Adding things to the defauly PAM stack is always something that needs an audit and careful consideration, though.  "It works for me" isn't quite enough for something that runs as root on every new session.
[20:06] <Bluefoxicy> i know
[20:06] <Bluefoxicy> I've been doing this since 2004 and trying to get people to use it during development cycles as at least a bulk sanity check measure
[20:07] <infinity> Bluefoxicy: If you're running it and happy with it, yay? :)
[20:07] <infinity> I run a lot of things I don't think need to be the default for everyone else.
[20:07] <Bluefoxicy> http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html wow
[20:07] <Bluefoxicy> didn't know about this
[20:07] <infinity> And this doesn't cover the other tmpdir (/var/tmp), which is where large files go.
[20:08] <infinity> (In a traditional layout)
[20:10] <Bluefoxicy> infinity:  curious, completely different topic
[20:12] <Bluefoxicy> somewhere in 2003-2005 I started arguing that Linux needs a good replacement or interface for Active Directory, to attain feature parity with Microsoft networks in the ability to push security policies, configurations, installed applications, and have central authority for users and computers on the network
[20:13] <Bluefoxicy> There are a few directory servers--FDS, RHDS, Mandriva has one, SuSE has one--but nobody seems to have actually tried to shape up client/server management for networks.  I haven't seen Ubuntu's cloud offering, which might do that.
[20:14] <Bluefoxicy> Does anyone actually consider this a deficiency?  I've had several discussions which basically ended in, "That's stupid, businesses don't want or need that"
[20:15] <Bluefoxicy> but I've never been able to look at corporate networks nad say, "You can do all that with Linux"
[20:15] <infinity> People want different things.  Nothing's sane to ship "by default", but lots of different solutions could use work.
[20:15] <Bluefoxicy> I did get as far as managing users in a central repository
[20:15] <Bluefoxicy> infinity:  You've managed Windows networks?
[20:16] <infinity> Pure UNIX/Linux networks tend to not want anything that looks at all like AD, but instead want puppet-like things, and users/groups distributed out-of-band (like ud-ldap), or other fun stuff.
[20:16] <infinity> People trying to live in AD networks want tight integration with an AD controller.
[20:16] <Bluefoxicy> yeah
[20:16] <infinity> People trying to take over AD networks want to *be* an AD controller.
[20:16] <Bluefoxicy> When I worked at Social Security, they said they've looked at switching to Linux desktops, but it's impossible to manage properly.
[20:17] <Bluefoxicy> I've used Puppet.  One day, maybe I'll write something strikingly like it that actually works.
[20:17] <infinity> There's software to do all of these things, some needs more love than others, none of it is suitable for a "default" install.
[20:17] <Bluefoxicy> puppet's getting a lot of attention from dell and vmware and such, but, honestly... it's horrible.
[20:17] <Bluefoxicy> we have a package manager
[20:17] <Bluefoxicy> it's called apt.
[20:17] <infinity> (Not because it's crap, but because everyone has differing views on what the defaults should be)
[20:18] <Bluefoxicy> you can write modules in puppet to deploy roles... but if any of the needed packages overlap, it fails.
[20:18] <Bluefoxicy> so then you break it down into smaller modules
[20:18] <Bluefoxicy> until you eventually have a module for every individual package
[20:18] <Bluefoxicy> and the only point of this is, essentially, to change the default settings in the packages
[20:18] <infinity> Bluefoxicy: In a dpkg/rpm world, config management like puppet/chef should be used to enhance the package manager, not replace it.  ie: to roll out config changes on top of the packages defaults, not to mangle the packages and anger dpkg.
[20:19] <Bluefoxicy> infinity: in puppet, if you define a package resource more than once, anywhere, it cries out because you're defining an already-defined resource
[20:19] <infinity> Bluefoxicy: I dunno, we use it quite successfully with a lot of different roles.
[20:20] <Bluefoxicy> infinity:  what if you have two different roles that both provide a web service via nginx
[20:20] <Bluefoxicy> so you depend on nginx, and have it installed in both roles?
[20:20] <Bluefoxicy> puppet fails when you put both roles on one server.  So you have to make a separate nginx role.
[20:21] <Bluefoxicy> which is okay, until you realize there's 50 different nginx modules, written different ways, and, eventually, you have a custom module for nginx in this role or that role...
[20:21] <infinity> We don't tend to do multiple roles per server.  Which, to be fair, is also how the rest of the world is going with cloudy things, juju, lxc, docker, coreos, etc.
[20:22] <Bluefoxicy> I've gone both ways
[20:22] <Bluefoxicy> hi ari
[20:22] <infinity> I do multiple roles on home servers where I don't have a datacenter to play with, and don't want the overhead of even light virtualisation.
[20:22] <infinity> But on the home or small business server scenario, you probably also don't give a crap about config management, I know I don't. :P
[20:23] <Bluefoxicy> my only multi-role server is a web app server
[20:23] <infinity> Cause it's usually one or two machines, not 100.
[20:23] <Bluefoxicy> infinity:  i'm studying project management
[20:23] <Bluefoxicy> let's not get into the merits of proper procedure in various situations ;p
[20:24] <Bluefoxicy> there are some environments where an abridged process is the absolute best way to do it, others where you need full processes, and everything in between; there are no real general rules for this :)
[20:28] <ari-tczew> hi Bluefoxicy
[20:29] <ari-tczew> cjwatson: I'm sorry but I need to ask you what's gonna on with M-o-M :)
[21:00] <Bluefoxicy> ari-tczew:  russian?
[21:00] <ari-tczew> Bluefoxicy: nope, polish
[21:12] <Bluefoxicy> ah
[21:12] <Bluefoxicy> hmm.
[21:12] <Bluefoxicy> I know an ari in moscow
[21:12] <Bluefoxicy> russian is a pretty crazy language, but polish is insane
[21:12] <Bluefoxicy> my grandfather speaks polish 'cause he came over from there on a boat
[21:27] <ari-tczew> cool