[01:24] <StevenK> RAOF: O Hai
[01:24] <RAOF> StevenK: Yo!
[01:24] <StevenK> RAOF: So, I bought a GeForce GTX970 yesterday ... and Trusty does not love it at all
[01:25] <StevenK> RAOF: I thought LTS releases were supposed to get updates to support new hardware?
[01:25] <StevenK> From what I can see, only Vivid has a new enough version of the binary driver to support the card.
[01:26] <RAOF> It should get ported back, yes.
[01:28] <StevenK> RAOF: Do you keep tabs on where stuff is up to, or that more someone else?
[01:28] <RAOF> You'd be looking for tseliot
[01:28] <StevenK> I thought so
[01:29] <StevenK> RAOF: In the mean time, I need fresh crack?
[01:29] <StevenK> The description for that PPA is not very encourging :-P
[01:30] <RAOF> StevenK: rmadison nvidia-current tells me that trusty-updates has the same version as vivid.
[01:30] <StevenK> RAOF: nvidia-346 exists in Vivid
[01:30] <RAOF> Ah. nvidia-current is a lie.
[01:30] <RAOF> Good, good.
[01:31] <StevenK> Yes -current is not current at all
[01:31] <RAOF> Hm.
[01:32]  * RAOF heads out to lunch.
[02:22] <StevenK> RAOF: Huh. So installing nvidia-346 from the edgers PPA ends up gnome-terminal only showing as a black box
[02:22] <StevenK> If I click in the right area, it does close, at least
[04:18] <tjaalton> nvidia-current-updatest
[04:18] <tjaalton> -t
[04:19] <tjaalton> latest in -proposed i guess
[04:19] <StevenK> tjaalton: rmadison doesn't show -proposed, but current-updates in trusty-updates is still only 304.125
[04:29] <tjaalton> oh right, not -current* anyway :)
[04:32] <tjaalton> 346.47 was uploaded to vivid last week
[04:33] <tjaalton> so looks like it's not uploaded to trusty yet then
[04:35] <StevenK> It looks like my three choices are, 1) Have no X at all, 2) Have a broken X, due to -edgers or 3) Install 346 myself and hopefully everything works
[04:35] <StevenK> Frankly, all of those options suck.
[04:36] <tjaalton> don't pull all of edgers
[04:36] <tjaalton> just the driver and then disable it, or use apt pinning
[04:36] <tjaalton> it=the ppa
[04:36] <StevenK> tjaalton: Which the descriptions for -edgers said do not do
[04:37] <tjaalton> wonder why
[04:39] <tjaalton> since the blobs aren't tied to any specific driver abi
[04:45] <infinity> StevenK: Just install the blob from vivid, they're blobs+dkms, the release they're uploaded to is irrelevant.
[04:57] <StevenK> infinity: Just rebooted, to make sure X libraries didn't contaminate RAM or loaded libraries, and I have lightdm up, so that's promising
[04:58] <StevenK> Haha. But gnome-terminal is still just a black box
[05:03] <infinity> StevenK: I'd say you get to take up that bug with the people whose binary driver you're using. :P
[05:04] <StevenK> Blah
[06:00] <happyaron> cyphermox: hey, wonders what's the status of the SRU for bug 1325801?
[06:31] <tjaalton> what's the story with gpg-agent/ssh-agent, I still don't have them on a vivid session
[06:43] <tjaalton> there was a bugreport at some point
[07:20] <tjaalton> huh, works on my laptop though
[07:21] <tjaalton> gnome-keyring-gpg that is
[07:27] <tjaalton> ah, it's just run so late that my terminator shells didn't get that..
[07:29] <donniezazen> The design tab of Qt-Creator is grayed out on my Kubuntu 14.04 box. Anyone would know why?
[07:30] <didrocks> smoser: assigned you bug #1434020, don't know yet if your -4ubuntu7 fixes it but worth a look still
[07:32] <tjaalton> hmm no. why does a single terminator shell have all the GPG stuff exported, but not one with my own layout
[07:34] <tjaalton> if a terminal is started from alt-f2 it doesn't have them
[08:07] <zyga> hey, vivid boot today was bad, nothing came up normally, systemd seems to have dbus issues
[08:07] <zyga> I brought eth0 up maually and I'm trying to update
[08:08] <tjaalton> 1434020?
[08:09] <zyga> not sure, I'm in text mode
[08:09] <tjaalton> "With systemd 219-4ubuntu6, ifup fails on startup" [Undecided,New]
[08:10] <tjaalton> 7 available
[08:10] <zyga> how do I copy / paste in screen
[08:11] <zyga> ^A [ but then what?
[08:12] <tjaalton> set the first mark with space
[08:12] <zyga> anyway, pastebin.ubuntu.com/10632989
[08:12] <zyga> that's 10K of journald logs
[08:12] <tjaalton> do you have -4u7?
[08:13] <zyga> looking
[08:13] <tjaalton> apt-cache policy systemd
[08:13] <zyga> 4u7
[08:13] <tjaalton> k
[08:13] <zyga> yes
[08:13] <zyga> update now borked on something, looking at that :/
[08:14] <zyga> policykit + dbus seem borked, this prevents configuration of udev
[08:14] <zyga> tjaalton: is there a workaround for that bug?
[08:15] <tjaalton> not that I know of
[08:15] <zyga> tjaalton: thanks, I'll lurk around in my 90's linux console and see what happens
[08:15] <zyga> ;)
[08:21] <dholbach> good morning
[08:21] <zyga> o/
[08:21] <dholbach> hi zyga
[08:43] <tjaalton> meh, something is actively cleaning up /run/shm?
[08:56] <alf_> Hi all! This morning, after booting, I found my .bash_history to be 0 bytes, any ideas what could have happened? I am on (almost) latest vivid, have lots of disk space free, no signs of disk problems.
[08:59] <zyga> alf_: hey, at least you got to boot :)
[09:01] <alf_> zyga: :)
[09:15] <mpt> Ah, bdmurray, thanks for fixing bug 1084979!
[09:55] <Chipaca> we're past translatable texts freeze for v, yes?
[10:14] <adam_magic_pack> slangasek: hi, could you please take a look at https://bugs.launchpad.net/hwe-next/+bug/1396429 ? there is a v2 patch. cert qa found this issue on more and more new machines. cc ypwong
[10:16] <adam_magic_pack> slangasek: root cause is in patch commit message, you could give another fix if mine is ugly =,=
[10:17] <adam_magic_pack> is described in commit message, I mean
[10:48]  * zyga wonders if pitti is working today
[10:51] <tjaalton> zyga: nope, on vacation still
[11:08] <zyga> tjaalton: oh, that's not good :/
[11:08]  * zyga has no working machine with ubuntu now
[11:48] <rbasak> In uvtool, the uvtool package owns /var/lib/uvtool/, and the uvtool-libvirt package owns /var/lib/uvtool/libvirt/
[11:48] <rbasak> I want to remove all of /var/lib/uvtool/ when the user purges both packages.
[11:48] <rbasak> But the uvtool postrm runs before the uvtool-libvirt postrm.
[11:48] <rbasak> So the rmdir of /var/lib/uvtool fails.
[11:49] <rbasak> I'm doing rmdir /var/lib/uvtool || true, but that means that it remains after the inside is cleaned up.
[11:49] <rbasak> And I have a bug report because someone thought the rmdir failing was an error (since it still printed the error even if the exit status was ignored).
[11:49] <rbasak> What am I doing wrong. How should I arrange things instead?
[12:40] <smoser> didrocks, :-(
[12:40] <smoser> i dont think my uploda would have fixd that.
[12:40] <didrocks> smoser: so, regression from ubuntu6? mind having a look?
[12:40] <smoser> i'd suspect its still racey.
[12:40] <smoser> regressoin from 5
[12:40] <smoser> still present in 7 i suspect.
[12:41] <didrocks> smoser: maybe ask the user to try 5 and reboot multiple times?
[12:41] <didrocks> maybe just got unlucky and first time the races showed up for him was after latest upgrade
[12:41] <smoser> well, his explanation is good.
[12:42] <smoser> he diagnosed the problem well.
[12:42] <smoser> and i did change the creation of that directory.
[12:43] <smoser> its easy enough to fix, by just creating the dir, but do you know how /run gets mounted ? other than in the initramfs .
[12:44] <didrocks> smoser: let me look quickly, I think it's at early stage of systemd, one sec
[12:44] <smoser> so the short of it is , that if /run is guaranteed to be mounted when ifup@.service is run, then 'mkdir -p /run/network' there is fine.
[12:44] <smoser> but we dont want those to create and use /run/network before /run is mounted
[12:45] <didrocks> smoser: oh, if it's the question, it's guaranteed to be mounted even before any unit start
[12:45] <didrocks> smoser: the generators are running as the first systemd setps, and they are using /run
[12:45] <didrocks> steps*
[12:45] <didrocks> (even before the transactional service path computation)
[12:46] <smoser> didrocks, so i think then its fine to just have ifup@ do a mkdir /run/network
[12:46] <didrocks> smoser: why not setting it After=systemd-tmpfiles-setup.service?
[12:47] <didrocks> as you have the mkdir there
[12:47] <smoser> i dont have a strong feeling on it.
[12:48] <smoser> your solution forces ifup@ to run afer that, meaning guaranteed to start later (or at best same time). i dont know.
[12:48] <didrocks> smoser: let's preferably do that. I think we'll have some boot speed task before LTS when we will revisit
[12:48] <smoser> i suspect this all happens REALLY FAST and REALLY EARLY
[12:48] <smoser> :)
[12:48] <didrocks> heh :)
[12:48] <didrocks> we just need to ensure to document the patch to not just drop this After=
[12:49] <smoser> but after is fine with me.
[12:49] <didrocks> without further thoughts
[12:49] <didrocks> smoser: want to do it or should I?
[12:49] <smoser> i'm happy to let you do it, but i'm also happy to do it myself as its my regression.
[12:49] <smoser> but i will ask you for a review... this is my first real experience with systemd.
[12:50] <didrocks> smoser: sure, please do then and poke me :)
[12:50] <didrocks> smoser: if you base on the git branch, we are using gbp-pq
[12:50] <smoser> juts as a bit of info, the upstart jobs did 'mkdir -p /run/network' (or equivalent)
[12:50] <didrocks> (see debian/README.source)
[12:50] <didrocks> yeah, but there was not this "create dir" facilities
[12:50] <didrocks> let's centralize it there
[12:51] <smoser> right. thats fine.
[12:51] <smoser> is there a git-import-dsc ?
[12:52] <didrocks> smoser: I'm mostly old-school and apply debdiff manually…
[12:52] <smoser> k
[13:14] <smoser> didrocks, http://paste.ubuntu.com/10634625/
[13:15] <didrocks> smoser: you need the .service suffix
[13:15] <smoser> i was just checking that.
[13:15] <smoser> :)
[13:15] <didrocks> :)
[13:15] <smoser> http://paste.ubuntu.com/10634632/
[13:15] <smoser> didrocks, do you want me to create a git branch for you and push it somewhere ?
[13:16] <didrocks> smoser: yeah, looks good to me. I trust more your testing with manual network setup that I would on mine
[13:16] <didrocks> smoser: on git branch -> just give some patch-format files, and I'll get them applied
[13:20] <smoser> didrocks, well, my testing is suspect for sure. although yesterday i did painfully walk through 6 reboots of my laptop.
[13:22] <didrocks> smoser: well, we get some racing issues blocking the whole boot appearing every ~30 boots, pitti had fun bisecting!
[13:23] <smoser> didrocks, aren't those just:
[13:24] <smoser>  https://launchpad.net/ubuntu/+archive/primary/+files/systemd_219-4ubuntu5_219-4ubuntu6.diff.gz
[13:24] <smoser>  https://launchpad.net/ubuntu/+archive/primary/+files/systemd_219-4ubuntu6_219-4ubuntu7.diff.gz
[13:25] <didrocks> smoser: yeah, but would be nice to get some git-format patch for them (so that the commit is credited with a nice commit message). No hurry, we can deal with that next week
[13:25] <smoser> k
[13:28] <Riddell> is anyone able to say what's up with https://jenkins.qa.ubuntu.com/job/vivid-adt-konsole/ARCH=i386,label=adt/75/console ? "test dependencies are unsatisfiable" but it's fine on amd64
[13:31] <cjwatson> Riddell: is it possible it's just skew in when builds for different architectures were available?  I can mash retry
[13:33] <Riddell> cjwatson: mash retry? sounds fun
[13:38] <ogra_> infinity, seems oyu made fakechroot rather unhappy with the new libc ... https://launchpadlibrarian.net/200713317/buildlog_ubuntu-vivid-amd64.initramfs-tools-ubuntu-touch_0.88_BUILDING.txt.gz
[13:38] <ogra_> /usr/sbin/chroot: °§^6ß: SH‰ûHÇÁþÿÿÿHƒìH‹²(: Error 18446744073178213872
[13:39] <ogra_> (but at least there is a smiley in the error)
[13:40] <davmor2> ogra_: there might be several you don't know what the uncoded elements are ;)
[13:53] <cjwatson> Riddell: done
[13:53] <Riddell> thanks
[13:53] <xnox> hallyn: https://github.com/shadow-maint/shadow/pull/4
[13:53] <xnox> hallyn: also emailed the alioth mailing list
[13:53] <xnox> hallyn: who are the shadow maintainers? do i need to ping anyone else?
[14:07] <flexiondotorg> Is some piloting today?
[14:07] <flexiondotorg> I have a few package updates I'd really like actioning so I can get some QA done this weekend.
[14:07] <flexiondotorg> Nice debdiffs, super simple 😉
[14:10] <Laibsch> Is the mirror: protocol for apt still actively developed?
[14:11] <Laibsch> or is it more likely that http.debian.net will be adopted?
[14:11] <Laibsch> I'm sure many mobile users would love to have a better solution for getting their downloads
[14:12] <Laibsch> I'm frequently transiting between three different countries that are 6-12 hours away by plane and have vastly different networks.
[14:12] <ogra_> Laibsch, what mobile users do you mean ?
[14:13] <Laibsch> people who are not always connected to the same network
[14:13] <ogra_> ah, not mobile phone users then.. i see
[14:13] <Laibsch> unless you are (always connected to the same network) having a fixed mirror in sources.list isn't going to be ideal
[14:13] <ogra_> yeah, i thougth you referred to ubuntu on phones :)
[14:14] <Laibsch> well, could be mobile phone users, too (in one of the countries, I'm frequently connected over mobile phone, sometimes as slow as 2G without edge, ouch!)
[14:14] <ogra_> (we dont use apt/dpkg there(
[14:14] <ogra_> )
[14:14] <Laibsch> no, this is not about Ubuntu on phones, my apologies if that was confusing
[14:14] <Laibsch> opkg?
[14:14] <Laibsch> that's the one being used last time I was involved in embedded
[14:14] <ogra_> no, its my conditional brain beeping if i read "mobile" anywhere, not your fault :)
[14:15] <ogra_> no, we use click packages on the phones
[14:15] <ogra_> (and "soon" will use snap packages)
[14:18] <flexiondotorg> Anyone available for a little sponsoring?
[15:01] <roaksoax> doko_: thanks for working on dj1.6
[15:01] <roaksoax> doko_: we will do a little testg, and upload to vivid, that ok with you?
[15:01] <doko_> roaksoax, sure
[15:01] <roaksoax> doko_: do we need to file a FFe/MIR or anything along those lines?
[15:02] <doko_> I don't think so. no new code, was already there
[15:02] <roaksoax> doko_: ok, great!
[15:07] <doko_> infinity, looking at the glibc cross builds, multilib-stage1.diff still not applied :-/
[15:21] <doko_> roaksoax, please see mdeslaur's python-django upload and apply these to the python-django16 packages too
[15:22] <mdeslaur> python-django16?
[15:31] <LocutusOfBorg1> hi, can anybody please sync poedit from debian/experimental (I'm the maintainer)
[15:42] <Laibsch> doko: May I ask if the code behind http://mirrors.ubuntu.com/mirrors.txt is still being actively developed?
[15:46] <doko> Laibsch, sorry, I'm the wrong person to ask
[15:47] <Laibsch> doko: I see. Sorry for the noise. I thought you were the one who developped the code in 2011.
[15:49] <hallyn> stgraber: https://jenkins.qa.ubuntu.com/job/vivid-nova-adt-cgmanager/1/   is this a temporary failure in the infrastructure?  (I don't see any actual cgmanager tests being run there)
[15:54] <stgraber> hallyn: I think the -nova ones are some test new infrastructure
[15:54] <stgraber> hallyn: the one you want to look at is https://jenkins.qa.ubuntu.com/job/vivid-adt-cgmanager/
[16:01] <hallyn> stgraber: ok - i got an email about the othe rone
[16:01] <hallyn> thanks
[16:01] <hallyn> will ignore then :)
[16:25] <infinity> ogra_: Fun.
[16:25] <ogra_> infinity, i guess we'll have to wait til it migrated
[16:26] <infinity> ogra_: Hrm?
[16:26] <ogra_> to test again ... seems to be rather unhappy if there are diferent libc versions inside and outsiode the fakechroot
[16:27] <infinity> Oh, really?  That's... Poor design.
[16:27] <ogra_> i tried adding -s (--use-system-libs) to the fakechroot call to force usage of the new libc ... but i get a segfault instead of the cryptic error then
[16:28] <ogra_> well, fakechroot is all LD_PRELOAD stuff afaik ... so not unreasonable that it gets confused between the two libc's
[16:28] <stgraber> hallyn: fginther just sent an e-mail saying to disregard any e-mail regarding -nova-
[16:29] <infinity> mvo: You around?
[16:29] <mvo> infinity: about to leave for dinner, sup?
[16:29] <infinity> mvo: The apt autopkgtest regression doesn't look like it would be glibc's fault, but can you have a poke at it?
[16:30] <infinity> mvo: When you're not busy eating. :)
[16:30] <hallyn> stgraber: yeah saw it - thx
[16:30] <mvo> infinity: I meant to look at it, I suspect its a race in some way, but I'm not seeing it on the debian autopkgtest and on travis and not locally, this is a bit annoying,
[16:31] <infinity> mvo: Oh, you don't locally see it with glibc_2.21?
[16:31] <infinity> mvo: In that case, I'll retry it a few times, and you can worry about fixing it later.
[16:32] <infinity> Although, I doubt a retry will help, it seems pretty consistent in our infra.
[16:32] <mvo> infinity: let me double check
[16:32] <infinity> But, not related to glibc, it failed before too.  So, yay.
[16:32] <mvo> aha, ok
[16:38] <dholbach> LocutusOfBorg1, the casablanca update is probably not a bug fix release, right?
[16:39] <dholbach> might be worth subscribing the release team there
[16:44] <mvo> infinity: I might found the issue, lets see if this upload helps
[16:50] <infinity> mvo: \o/
[16:50] <infinity> mvo: I thought you were eating.
[16:53] <Laney> mvo subsists on a diet of bugs
[16:57] <dholbach> yummy
[19:25] <Noskcaj> Can someone please sync gnumeric? The latest debian release has a crashfix and drops a unneeded recommend
[19:27] <jamespage> coreycb, doko: as part of the python update for 14.04 we must co-ordinate with openstack upstream to get fixes landed into stable branches first
[19:27] <jamespage> otherwise when we push the SRU, we'll break alot of the upstream gating process and make ourselves very unpopular
[19:28] <doko> jamespage, if we update, then not before June/July
[19:28] <jamespage> doko, that gives us plently of time to get fixes proposed and landed - I'll work with coreycb before then to communicate plans etc...
[19:29] <coreycb> jamespage, alright.  cinder and neutron are submitted for icehouse and juno.  I didn't submit the keystone patch since it hasn't landed in kilo yet.
[19:29] <jamespage> coreycb, urgh
[19:29] <jamespage> coreycb, ok lemme nudge that along
[19:29] <coreycb> jamespage, thx
[19:39] <doko> infinity, fyi, the guile-2.0 ftbfs seems to be triggered by the new glibc, just verified
[19:39] <doko> on powerpc
[19:50] <infinity> doko: Where did you verify?
[19:56] <micahg> Noskcaj: that release of gnumeric looks like it comes with some new features, i'd suggest filing an FFe
[20:14] <smoser> i need an archive admin help
[20:14] <smoser> i need to NACK 2 uploads for sru.
[20:15] <smoser> curtin upload to -proposed in utopic and trusty
[20:18] <smoser> actually, please ignore that statement.
[20:20] <infinity> smoser: So, you don't want me to reject them?  Cause I was really looking forward to it.
[20:21] <smoser> go ahead and reject if you want.
[20:21] <infinity> smoser: Well, make up your mind. :)
[20:21] <smoser> i have one small change
[20:21] <infinity> Right.  If you need to change, I'll reject.
[20:23] <smoser> please do. thank you
[20:58] <smoser> infinity, thank you. now, since you're feeling nice, you could ack the entry of my replacement uploads into -proposed .
[21:00] <infinity> smoser: Not just now.
[21:09] <infinity> doko: Okay, guile-2.0 failure reproduced, chasing it up.
[21:16] <infinity> doko: And I think I found the bug, testing a fix.
[23:29] <ericsnow> how can I tell which vivid daily build I have installed?
[23:34] <elfy> have you updated today?
[23:35] <infinity> ericsnow: Context?  Talking read-only builds like ubuntu-core/snappy, or just regular old Ubuntu?
[23:36] <infinity> ericsnow: For the latter, you can tell which media you installed *from*, with /var/log/installer/media-info, mine says "Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20121209)"
[23:36] <infinity> ericsnow: But as elfy implies, what you're running depends on the day you last updated/upgraded.
[23:36] <infinity> For me, that was yesterday.
[23:37] <elfy> oh sorry - thought I was elsewhere tbh ...
[23:54] <ericsnow> infinity: just trying to identify which vivid daily build we are running on some test infrastructure
[23:54] <ericsnow> infinity: the folks who run it all are EOW
[23:55] <ericsnow> (and I'm too impatient to wait until Monday to ask them)
[23:59] <infinity> ericsnow: Right, well, like I said, you can see what it was installed from.  But as soon as someone runs apt-get update/upgrade, that value is meaningless.
[23:59] <ericsnow> infinity: right, I expect we run update/upgrade every night