[00:04] <xnox> doko: DEB_AUTO_UPDATE_AUTOCONF=2.69
[00:05] <xnox> .... and similar for automake (if needed) and etc.
[00:05] <xnox> doko: working example http://sources.debian.net/src/libshout/2.3.1-3/debian/rules?hl=23#L21
[00:16] <slangasek> xnox: ITYM DEB_AUTO_UPGRADE_TO_DH
[00:17] <xnox> slangasek: yeah, i'm gonna write cdbs snippet to execute dh_autoreconf with a single include =)
[00:18] <slangasek> no, I mean a command to replace debian/rules with /usr/share/doc/debhelper/examples/rules.tiny
[00:19] <xnox> heh
[00:29] <infinity> slangasek: I think that command is "cp", but ymmv.
[00:36] <sarnold> xnox: hello :) what's happening re: samba and samba4 packages in trusty? samba4 appears to be based on 4.0.3, samba appears to be based on 4.0.10, but launchpad thinks trusty samba is based on "samba 3.4 series".
[00:37] <xnox> sarnold: "based on series" is bogus metadata, can be fixed.
[00:37] <sarnold> xnox: okay, I figured as much there.. :)
[00:37] <xnox> sarnold: samba4 src package and binaries should be removed from the archive, once ready.
[00:37] <xnox> sarnold: fully superseeded by samba src package, which has now switched to 4.x series in debian and ubuntu
[00:38] <sarnold> xnox: cool! thanks. :)
[00:38] <xnox> sarnold: but, do note that upgrade story is aweful. If one had samba4 package installed on upgrade, it is removed =(
[00:38] <xnox> sarnold: if one had samba installed -> it's upgraded to samba (3.x -> 4.x)
[00:38] <xnox> sarnold: if one had both samba & samba4 installed, there are held packages and both are removed \o/
[00:38] <xnox> slangasek: ^ =)))))
[00:39] <sarnold> xnox: oh. that's .. less than ideal, hehe. is that something do-release-upgrade can paper over? or is just going to be slightly ugly? or an ugly transitional pacakge in trusty?
[00:39] <sarnold> xnox: hahah, that's even more special :)
[00:39] <xnox> i filed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730650
[00:40] <xnox> i think with http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730090 it will be better
[00:40] <xnox> but still....
[00:41] <sarnold> xnox: thanks for finding this so early :) it'd be a lot less pleasant to find this in february or march. :)
[00:43] <infinity> sarnold: This isn't the sort of thing do-release-upgrade should be papering over, we should make apt-based upgrades DTRT.
[00:44] <infinity> xnox: Are you keeping an eye on this one to make sure it ends up being sane?
[00:44] <infinity> xnox: Also, wouldn't a samba4 transitional package help here a bit?
[00:45] <sarnold> infinity: I've been lucky enough to not need the details of what apt can and can't fix itself :)
[00:45] <infinity> sarnold: apt can fix pretty much anything if the packages are sane. :P
[00:45] <xnox> infinity: well, look at the current samba4 package ;-) it is already transitional in ubuntu.
[00:45] <infinity> About the only thing we should be doing in do-release-upgrade are the post-upgrade "make sure the packages we care about are installed" bits.  Most other quirks SHOULD be in packages.
[00:46] <sarnold> infinity: oh, nice :D
[00:46] <xnox> infinity: but it needs to happen in debian as well. Also not sure what's suppose to be done no all the LDAP databases and such. As if someone had both samba & samba4 I presume the'd want both to still be functioning........
[00:46] <infinity> xnox: It... is?  Not according to rmadison.
[00:46] <xnox> infinity: but I don't know if there are samba4 -> samba config migrations or not.
[00:47] <xnox> infinity: samba4:any transitional package is built from samba4:src
[00:47] <xnox> infinity: i did it to bypass NEW and get the migration rolling, when everyone was away =)
[00:47] <infinity> xnox: It wouldn't have been NEW.
[00:47] <xnox> (it was blocking eds/libav9 transitions)
[00:48] <xnox> my bet then.
[00:48] <xnox> i should upload proper one then.
[00:48] <infinity> xnox: New is literally new.  As in, binaries not yet in the archive.  Moving a binary from one source to another isn't new, unless you delete the first before you upload the second.
[00:49] <xnox> infinity: ... same in debian?
[00:49] <infinity> I'm not sure how deeply we should care about the samba4 migration path.  But if we can do it without TOO much effort, we might as well.
[00:49] <infinity> We really should never have shipped it in the first place. :(
[00:49] <infinity> xnox: Same in Debian, yes.  A binary takeover from one source to another doesn't bug DAK.
[00:49] <xnox> we have never shipped it ;-) (*) in an LTS
[00:51] <xnox> wait, we did.... nevermind me.
[01:07] <stgraber> xnox: FWIW I'm running samba4 on 12.04 and will want to upgrade those servers to 14.04 at some point :)
[01:08] <xnox> stgraber: heh =) last time i touched samba, was when we were doing medical ORM on top of LDAP.....
[01:09] <xnox> stgraber: once transition packages are fine, maybe you can test how bad/well the samba4 -> samba upgrade goes? (can you snapshot boot those samba servers?)
[01:09] <stgraber> xnox: my domain has 4 domain controlers, so just upgrading one should be easy enough
[01:27] <infinity> stgraber: 4 DCs?  Overengineered house much?
[01:34] <stgraber> infinity: that's 4 different locations on 2 continents ;)
[01:38] <roadmr> talk about a house...
[01:44] <xnox> stgraber's neighborhood http://xkcd.com/1298/large/
[01:48] <arun> help
[02:46] <xnox> pitti: jibel: squid3 autopackagetest is failing because "/var/log/syslog" is not there. It's very odd, given one would expect all computers to have that available. Is there something wrong with the test-bed?
[04:27] <slangasek> infinity: 'cp' - that's not very cdbsish!
[04:27] <slangasek> xnox: samba upgrade> yes, have seen the bug report :/
[05:28] <pianogmx> hey im an extra hand.  does anyone need any help with anything?  I don't mind volunteering my time.  and I want to expand my programming skills as well by helping someone.
[05:29] <sarnold> hey pianogmx :) it's a bit late for north america and a bit early for europe..
[05:30] <sarnold> pianogmx: is there anything in particular that's most interesting to you?
[05:30] <pianogmx> sarnold, idk... im just bored and want to help someone... lol... i get lost on the forums and howtos for ubuntu because there is so much info.
[05:31] <pianogmx> sarnold, my last projects were with a professor at my university but now I finished them all so thus im bored
[05:31] <pianogmx> C# windows forms apps
[05:31] <sarnold> pianogmx: bored is good, that's what drives you to find something fun to do! :)
[05:32] <sarnold> pianogmx: the first thing that comes to mind is you could download the new ubuntu sdk and try it out, build a few qml-based applications
[05:33] <tarpman> pianogmx: http://harvest.ubuntu.com/ is a neat site listing some not-too-difficult bugs that people could use help working on
[05:33] <sarnold> pianogmx: I'm sure those teams would love some feedback from users and you could probably find things to work on that would be small enough and yet meaningful enough to be fun to work on them
[05:34] <sarnold> ooh, I've never seen harvest before. neat. :)
[05:35] <tarpman> sarnold: :)
[05:36] <pianogmx> yeah i saw harvest but it started to hurt my head... because i was just searching and searching for something I could do...  i understand form applications but i saw some pretty freaky code for some ubuntu apps
[05:36] <pianogmx> lol
[05:38] <pianogmx> sarnold, so lets say after i build a few qml based apps, what would be useful to ubuntu that I could try making?
[05:41] <sarnold> pianogmx: well, it's a -huge- undertaking, but I think a nagios frontend that doesn't use garish horrible colors would be nice :) but ... man, that'd be a huge pile of work.
[05:53] <pianogmx> :( information overload...
[05:53] <pianogmx> i loved it when people would break things into smaller tasks for me to accomplished
[05:54] <pianogmx> now I just use the computer to stare at it ... because if no one manages me, i love my television
[05:57] <sarnold> pianogmx: ah, yes, the television, I call that my "stupid time" :) time to turn off the brain and just giggle at the same old jokes..
[05:58] <sarnold> pianogmx: perhaps a simpler problem -- our phone is going to need some RPN-based calculators, most platforms have five or six to choose from, it'd be nice to have some of our own :)
[06:00] <pianogmx> huh?   you mean the ubuntu phone project?
[06:00] <pianogmx> sounds cool...
[06:01] <sarnold> pianogmx: yeah, I saw your message in there after seeing this channel. go figure. :) hehe
[06:01] <pianogmx> do TI 84 use RPN?
[06:02] <sarnold> no, they use algebraic input
[06:02] <pianogmx> lol... id have to understand RPN first then it would be simple... yeah thats doable :)
[06:03] <pianogmx> all i would need help with is how the community would like the UI to be... then I would be set
[06:03] <sarnold> RPN is simpler than algebraic; there's a stack that supports "push" and "pop" types of operations; you put two pieces of data on the stack, then a command. the command takes arguments off the stack and puts results onto the stack.
[06:04] <sarnold> the end result is you get to type things like 14 21 + 7 *  rather than (14+21)*7
[06:04] <pianogmx> interesting, reminds me when I stared at a sample assembly code... yeah I get it
[06:07] <pianogmx> so the ubuntu phone uses the QML development stuff?
[06:07] <sarnold> yes
[06:07] <sarnold> qml is going to be the "preferred" method of programmer advertised to most developers, though other options such as python and java and phonegap and C and C++ are all available...
[06:08] <pianogmx> lol... i remember back in high school when making an algebraic calculator in java was an assignment
[06:09] <sarnold> same here, I cringe when I think of how poorly mine worked. yes, it worked, but no, it wasn't pretty. :)
[06:09] <pianogmx> i just never really stepped up my game since 07 to devbelop my skills...
[06:09] <pianogmx> stopped programming for like 3 years
[06:10] <pianogmx> made me depressed because i forgot shit
[06:10] <pianogmx> oh mine used a java jpanel and i had it scroll 7 lines until it disappeared
[06:11] <pianogmx> + i take mind altering medications... also upset because it screws with my thinking a bit...
[06:11] <pianogmx> but... at least my body aint shaking
[06:12] <sarnold> oh man, I'm sorry :/ programming well takes an unreal level of concentration. It wouldn't be fun to be fighting medication to make that happen. :(
[06:13] <pianogmx> as for an RPN calculator on a ubuntu phone... is there an emulator for the ubuntu phone?
[06:13] <pianogmx> and if someone gave me an interface mockup, that would be better than me trying to spend a few days hitting my head until i hullcinate something that looks nice (lol)
[06:14] <sarnold> pianogmx: I think the emulator is called "goldfish", and I'm not sure, but I think last I heard graphics didn't work at all. most folks currently working on it have a nexus 4 or similar to play with.
[06:15] <pianogmx> im on boost mobile (cant afford contract phones) thus i cant get a nexus 4 (cries)
[06:15] <pianogmx> if nexus 4 did CDMA then it would be cool.
[06:16] <pianogmx> i was happy when I got my HTC phone to run a partially working CM10
[06:16] <pianogmx> but then went back to a modified stock instead...
[06:19] <sarnold> heh yeah, for your _phone_ that makes sense. :) some folks do rely upon their ubuntu phone as their only phone though, so they'll have plenty of incentive to file bug reports and fix things :)
[06:20] <infinity> https://wiki.ubuntu.com/Touch/Emulator <-- The emulator.
[06:20] <pianogmx> exactly... is ubuntu phone OS going to have CDMA, EvDo compatbility in it?
[06:21] <sarnold> break=bottom?? o_O
[06:22] <infinity> sarnold: Instructions for how to recover a system that got hosed due to earlier emulator versions...
[06:22] <infinity> (Well, due to a libc6 bug tickled by earlier emulator deps)
[06:22] <sarnold> infinity: yeah, looks very unfun. I've never seen break= before, hehe.
[06:22] <infinity> sarnold: break= refers to breakpoints in the initramfs's init.
[06:23] <infinity> sarnold: bottom being the last thing before it pivots.
[06:23] <sarnold> infinity: very cool, where's this thing documented? I don't see 'bottom' in upstart-events(7)..
[06:23] <infinity> sarnold: initramfs init isn't upstart.
[06:24] <infinity> Also, I lie, the last breakpoint pre-pivot is "init", bottom's a bit higher.  Anyhow, you get the point.
[06:24] <geofft> man initramfs-tools
[06:24] <pianogmx> OH.... android emulator requires the rolling release of trusty...
[06:24] <infinity> Wow, it is kinda documented.
[06:25] <infinity> I just read /usr/share/initramfs-tools/init when I want to refresh my memory.
[06:25] <sarnold> thanks infinity, geofft :) I love learning new things. I'm not an entirely old dog yet! :)
[06:26] <pianogmx> i wish gparted / ubuntu could shrink a partition when its in use (kindof like windows)... but the live usb always works :)
[06:27] <pianogmx> is trusty tahr stable enough to handle QML app development for the ubuntu phone?
[06:27] <pianogmx> (idk yet because im downloading it)
[06:46] <pianogmx> sarnold, for the ubuntu sdk and the ubuntu phone, are all of the updates being pushed into the 13.10 for download?
[06:46] <pianogmx> reason i ask, is i found an error that is supposedly already fixedx...
[06:46] <geofft> While I'm here, anyone know if there's a data dump or API for www.ubuntu.com/certification?
[06:46] <geofft> (or where I should ask?)
[06:46] <pianogmx> and i noticed the ubuntu phone emulator asks for a trusty tahr environment...
[06:47]  * pianogmx waves at geofft
[06:47] <sarnold> pianogmx: it's possible to get updates to 13.10 but it requires more process; see https://wiki.ubuntu.com/StableReleaseUpdates  for more information
[06:48] <pianogmx> sarnold, yeah, thats why im thinking to just shrink the ubuntu partition i have right now to keep it on stable packages
[06:48] <pianogmx> and install another installation of trusty tahr for pre-release
[06:50] <pianogmx> would be cool if rolling releases used p2p
[06:50] <pianogmx> put less strain on the server...
[06:52] <pianogmx> sarnold, so basically right now most people are using trusty tahr to develop QML apps for the Ubuntu Phone?
[06:52] <sarnold> pianogmx: I've seen some efforts to get apt to do bittorrent or steal packages from peers in some fashion; most people with more than one machine (or lots of VMs or chroots or whatever) use either squid-deb-proxy or apt-cacher-ng -- a pretty ugly bug in apt-cacher-ng made me switch away from it a few days back, but squid-deb-proxy seems faster anyway. that helps immensely. :)
[06:53] <sarnold> pianogmx: trusty tahr will be our next LTS release; it'll be the new flagship release for ubuntu for all uses -- phones, tables, desktops, servers, cloud hosts, cloud guests, supercomputer clusters, you name it, and trusty will be the Go-To solution.
[06:55] <pianogmx> sarnold, i saw that... pretty familiar with the LTS, but I love sticking with the 6 month releases...  each one gives my intel HD 3000 an extra boost...
[06:55] <sarnold> pianogmx: so the server team is polishing it for cloud hosting, cloud guest, traditional server tasks, etc. the desktop team is working on making it the best desktop operating system. The phone and tablet stuff has far enoug ht ogo that 14.10 will probably be the "go-to" release in a year's time, but trusty will be a very important step.
[06:55] <pianogmx> awesome.
[06:55] <pianogmx> will the ubuntu phone OS be CDMA compatible?
[06:58] <pianogmx> im going to setup that quid package... sounds awesome... but I was addressing http downloads being slow from particular websites...
[06:59] <pianogmx> oh... but i only have one machine with ubuntu.
[07:00] <sarnold> pianogmx: you might wis hto pick a different mirror for ubuntu; mirror.anl.gov is roughly ten times faster than archive.ubuntu.com
[07:05] <pianogmx> one thing that got me hooked on ubuntu a while back in high school was thinking that is mostly done by volunteers that don't work for a salary...
[07:05] <pianogmx> i found that impressive
[07:06] <ScottK> lfaraone: Please update the quassel packaging branch too.
[07:08] <pianogmx> reading about axel... wouldn't axel theoretically overload an http server if too many people used axel on the same server?
[07:08] <pianogmx> however, i am not complaining... it does download faster
[07:10] <sarnold> pianogmx: normally a single TCP session will saturate the available bandwidth between a specific client and server; multiple connections really only helps if a server rate-limits on connection rather than rate limiting by IP or something similar.
[07:11] <sarnold> pianogmx: multiple connections help a bit more when there are multiple smaller downloads to retrieve, it's more likely that one or the other will always be sending data rather than waiting in a latency-bound state (which is why most web browsers open two connections to web servers..)
[07:11] <pianogmx> yeah, but i remember seeing when I setup a webserver on a max connections it can handle.
[07:11] <pianogmx> so like, lets say axel opens 20.... and multiple people do that... it can theoretically hit that max connections open limit
[07:11] <pitti> Godo morning
[07:12] <sarnold> morning pitti :)
[07:12] <sarnold> pianogmx: yeah; some server admins go to the effort of rate-limiting by IP or by network instead.
[07:13] <pianogmx> yep... i setup a server or two a while back... one windows server , one ubuntu based... more to see how it works.
[07:14] <pianogmx> i cant wait to see if there is any gpu performances in trusty tahr :)
[07:14] <pitti> doko, infinity: python-imaging job removed from public jenkins, someone already did that for the public jenkins
[07:18] <pitti> jibel, xnox: I have /var/log/syslog in my desktop's run-adt-test VM, but indeed not on wazn's; not sure why
[07:18] <pitti> xnox, jibel: there are other log files like /var/log/udev or cloud-init.log, but apparently none from rsyslog
[07:18] <pitti> rsyslog start/running, process 843
[07:20] <jibel> pitti, it is not only wazn but all the test VMs
[07:20] <pitti> *.*;auth,authpriv.none          -/var/log/syslog
[07:20] <pitti> that's in /etc/rsyslog.d/50-default.conf in the test VM
[07:21] <pitti> jibel: I wonder what makes the ones in the DC special; they ought to look exactly like a "prepare-testbed amd64" one created locally
[07:22] <jibel> pitti, yes, they should be exactly the same
[07:35] <dholbach> good morning
[07:36] <jibel> pitti, I don't have /var/log/syslog on a local VM created with prepare-testbed either, and syslog is running
[07:36] <pitti> jibel: ok, so perhaps mine is special then..
[07:37] <pitti> jibel: ah, mine is some two days old, hang on; building a fresh one
[07:53] <jibel> pitti, from rsyslogd in debug mode
[07:53] <jibel> 3558.255026043:7f23687e2700: file '/var/log/syslog' opened as #-1 with mode 416
[07:53] <jibel> 3558.255029594:7f23687e2700: strm 0x7f2360000b70: open error 13, file '/var/log/syslog': Permission denied
[08:06] <jibel> pitti, I'll workaround the problem with a touch/chown/restart until I understand what is going on. It started yesterday so it is something that changed 2 days ago
[08:09]  * Mirv is excited at his first upload to archives
[08:09] <jibel> pitti, xnox same problem on a fresh server install with latest trusty images
[08:10] <pianogmx> someone said that in order to find a way to contribute to contact a project on launchpad.net.... well there are so many options I don't know which to click :(
[08:12] <pianogmx> i just want to know that if I start out with basic knowledge of programming, if there is anyone online that needs a volunteer to do something to help them....
[08:13] <pianogmx> Mirv, what you uploading?
[08:14] <jibel> pitti, http://paste.ubuntu.com/6518563/ it should be enough until logs are rotated which shouldn't happen during a test.
[08:15] <Mirv> pianogmx: I uploaded qtdeclarative-opensource-src
[08:15] <pitti> jibel: ouch; that seems to be new behaviour from rsyslog?
[08:16] <pianogmx> cool Mirv
[08:17] <pianogmx> wish i knew more stuff... then I could do the things on harvest (bug fixes)... most of the easy ones tend to get done to quick...
[08:18] <jibel> pitti, yes, it seems to have started with 7.4.4
[08:18] <pitti> jibel: that sounds like a regression
[08:30] <jibel> pitti, xnox bug 1257633
[08:31] <pitti> jibel: merci
[08:31] <jibel> I pushed the workaround to unblock tests
[08:49] <jibel> squid3 is green, and I restarted apport which failed for the same reason
[08:49] <pitti> jibel: thanks; did these tests explicitly check for /var/log/syslog? I don't remember doing that in apport
[08:49] <pitti> and it woudl be bad, as people can configure that to their liking
[08:51] <jibel> pitti, test_recent_logfile fails on a tail /var/log/syslog apparently, but I haven't checked the code to know what it does exactly.
[08:52] <pitti> jibel: ah indeed, thanks
[08:52] <pitti> I'll fix that
[08:53] <pitti> jibel: or rather, it's not the test, it's the hookutils' "recent_syslog()" which assumes that /var/log/syslog exists
[08:53] <pitti> jibel: so again an actual regression which slipped in ;/
[09:14] <brendand> is anyone else here accutely aware of the vast performance gulf between SSD and HDD in terms of the dash (opening/searching etc)?
[09:14] <brendand> i've just made the transition and it feels like we couldn't be doing any user testing on HDD systems or else we would have noticed that performance isn't adequate there
[09:36] <MacSlow> pitti, seb128: where do I need to push a notify-osd-icons branch to in order to make it a MR for lp:ubuntu/notify-osd-icons ? Just trying to push it to e.g. lp:~macslow/ubuntu/notify-osd-icons-0-8 doesn't work.
[09:37] <pitti> MacSlow: try lp:~macslow/ubuntu/trusty/notify-osd-icons/foobarize
[09:37] <pitti> (pick a more adequate branch name, of course)
[09:38] <MacSlow> pitti, ah... ok thanks
[09:38] <seb128> pitti, is https://code.launchpad.net/~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu the packaging branch?
[09:39] <pitti> seb128: ah, yes accordign to Vcs-Bzr
[09:39] <pitti> MacSlow: so, you don't actually want the UDD branch
[09:39] <seb128> MacSlow, ^ you might want to target that, not lp:ubuntu/notify-osd-icons
[09:39] <pitti> MacSlow: s/might want to /must/
[09:40] <pitti> unless we want to give up on the ~ubuntu-art-pkg team and that branch
[09:41] <MacSlow> seb128, pitti: it's to add new icons from https://bugs.launchpad.net/ubuntu/+source/notify-osd-icons/+bug/1253591 for precise
[09:42] <seb128> MacSlow, you need them added to trusty first, before SRUing, in any case that package didn't change since precise, so they should be the same content, just different changelog version/target
[09:42] <MacSlow> pitti, seb128: so right now I've pushed them to lp:~macslow/ubuntu/precise/notify-osd-icons/fix-1253591
[09:42] <MacSlow> seb128, ah... will do that
[09:42] <seb128> thanks
[09:49] <cjwatson> xnox_: cc doko: don't use DEB_AUTO_UPDATE_*, use autoreconf.mk from dh-autoreconf instead - it's better-designed for clean handling and such
[10:02] <MacSlow> pitti, seb128: When you got a moment... https://code.launchpad.net/~macslow/ubuntu/trusty/notify-osd-icons/fix-1253591/+merge/197670
[10:02] <MacSlow> pitti, seb128: Can I delete my lp:~macslow/ubuntu/precise/notify-osd-icons/fix-1253591 branch now? I assume SRUing the trusty branch works differently,right?
[10:03] <pitti> MacSlow: yes, we can't use UDD for (the first) SRU, and we don't use UDD in general for that package
[10:04] <pitti> MacSlow: also, that MP is against UDD; it can still be applied (with manually downloading and applying the patch), but not formally merged
[10:05] <MacSlow> pitti, so what's the next step to get it in precise once it was merge to trusty?
[10:05] <pitti> MacSlow: you prepare the bug for SRU justification, and the sponsor just reuploads the very same package with a ~precise version suffix (and an adjusted changelog)
[10:07] <pitti> MacSlow: you aren't in ~ubuntu-art-pkg? If you are, you can just commit to the actual branch
[10:08] <MacSlow> pitti, no I'm not in that team
[10:09] <MacSlow> pitti, didrocks is afaik
[10:10] <MacSlow> didrocks, could you look at https://code.launchpad.net/~macslow/ubuntu/trusty/notify-osd-icons/fix-1253591/+merge/197670 when you have a moment? thanks in advance!
[10:11] <pitti> MacSlow: if you want to avoid the manual pain for the reviewer, perhaps you can reapply your changes on the real branch, and re-do the MP
[10:12] <didrocks> MacSlow: yeah, better to do it in the real branch
[10:14] <didrocks> then, we can add it to daily-release because we don't AFAIK. I'll ask robru to do it
[10:14] <MacSlow> didrocks, d'accord
[10:14] <didrocks> MacSlow: merci! :)
[10:15] <pitti> didrocks: I guess we can't run autopkgtests in CI yet, can we?
[10:15] <pitti> didrocks: I mean s/CI/daily autolanding/
[10:16] <MacSlow> pitti, didrocks: the "real" branch is ~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu then I assume
[10:16] <didrocks> pitti: unfortunately, not
[10:16] <didrocks> MacSlow: we should create a project for it
[10:16] <pitti> didrocks: ack, thanks (once we can, I'd like to add apport and the sponsoring queue at large into it)
[10:16] <didrocks> MacSlow: please, merge it there, I'll ask robru to fix all this :)
[10:16] <didrocks> pitti: yeah, I think it's one of the priority for the CI AFAIK
[10:16] <didrocks> team*
[10:16] <MacSlow> didrocks, push my changes based on this directly there?!
[10:17] <MacSlow> didrocks, no MR?
[10:17] <pitti> didrocks: FWIW, notify-osd-icons hasn't changed in years, probably not worth spending much time on
[10:17] <pitti> MacSlow: nah, you'll need an MR if you aren't in ~ubuntu-art-pkg; but I'm happy to review/merge
[10:17] <didrocks> MacSlow: I think nobody can review it, so please do (seems safe icon changes)
[10:18] <didrocks> pitti: well, better to have the same process for all our components
[10:18] <didrocks> with proper projects settings and so on
[10:18] <didrocks> this is only a 10 minutes process
[10:18] <pitti> didrocks: right, but it sounds like this shoudl be an "icons" branch under lp.net/notify-osd, not a separate project
[10:19] <didrocks> pitti: well, the thing is that the bzr repo are mixed then, it's not really git, and so, we force for consistency having source package name <-> lp:branch name
[10:19] <pitti> didrocks: ah, ok
[10:27] <seb128> didrocks, pitti: we need that uploaded to trusty and SRUed to precise, I think oem want those changes in the coming lts point release
[10:27] <seb128> didrocks, pitti: e.g would be nice to get upload now and not delay too much on infra changes
[10:27] <MacSlow> didrocks, pitti: ok... pushed changes to lp:~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu now... next step is SRU-ing this?
[10:27] <pitti> MacSlow: ah, so you can push after all, nice
[10:27] <seb128> MacSlow, yes, SRU just needs a bug report with the SRU info (https://wiki.ubuntu.com/StableReleaseUpdates)
[10:28] <didrocks> seb128: I think MacSlow can prepare the SRUing while we do the daily release part, it's a 10 minutes thing. If it's that just that we need it know, I think sil2100 is free for it
[10:28] <didrocks> seb128: even if I would have prefer robru to train on that one :)
[10:28]  * MacSlow reads...
[10:28] <seb128> didrocks, well, they want the stuff to land this week in trusty/precise SRU
[10:28] <seb128> didrocks, so whatever, as long as you are sure he's going to follow up and not screw it
[10:29] <didrocks> seb128: yeah, it will land that week, I'll backup tomorrow if it's not done tonight
[10:29] <pitti> MacSlow: thanks; (note that I changed the changelog from trusty to UNRELEASED as it's not uploaded yet; the uploader will do it)
[10:29] <seb128> didrocks, thanks
[10:29] <seb128> didrocks, are you going to do the SRU landing as well?
[10:29] <MacSlow> pitti, ah... didn't know that... thanks
[10:29] <didrocks> seb128: not that one, I vary changing things for older release, so if you want to handle it
[10:29] <pitti> MacSlow: yes, no big deal, just for the records in case you wonder
[10:30] <pitti> MacSlow: thanks for keeping up with the bureaucracy and the UDD complications
[10:30] <seb128> didrocks, ok
[10:30] <pitti> MacSlow: deleted your trusty UDD MP
[10:30] <MacSlow> pitti, I have not dealt with this for 18 months... so I'm expecting to be a bit rusted on the process details :)
[10:30] <MacSlow> pitti, ah good... was about to do that too
[10:35] <seb128> pitti, do you want to sponsor the SRU or should I?
[10:35] <pitti> seb128: can do, but I understand we need to wait for landing this in trusty first?
[10:35] <pitti> seb128: after that, it's a simple apt-get source, meddle changelog, upload
[10:36] <seb128> pitti, well, that's usual SRU rules, but didrocks said he's going to make autolanding happen in the next day, so we can already put it in the SRU queue
[10:36] <seb128> pitti, well, my guess is that they are going to do packaging changes to have it aligned with the other components (dh9, install fail-missing, etc)
[10:36] <didrocks> yeah, I doubt the queue is going to be reviewed in a day from past experience :)
[10:37] <seb128> so it's not going to be the same upload for the SRU
[10:37] <pitti> seb128: ah, ok; I'll upload it now, then.
[10:37] <seb128> we can as well dput what MacSlow just got up
[10:37] <seb128> pitti, danke
[10:37] <MacSlow> pitti, seb128, didrocks: The SRU-info is actually part of LP: #404658 and LP: #1253591 (icons) is just "part" of the fix.
[10:37] <pitti> seb128, MacSlow: precise SRU uploaded (but SRU team will not consider it before it lands in trusty)
[10:38] <seb128> pitti, there is a bug reference in the changelog right?
[10:38] <MacSlow> pitti: ok
[10:38] <MacSlow> seb128, yes... and I used --fixes in bzr commit
[10:38] <seb128> great
[10:38] <seb128> MacSlow, danke
[10:55] <pitti> xnox_, slangasek: I adjusted bug 1257633; apparently rsyslog is now completely unable to create  any of its logs?
[10:57] <cjwatson> pitti: I'm investigating that at the moment, bug 1256695
[10:57] <cjwatson> pitti: it seems to be to do with a rearrangement of how privilege-dropping works
[10:58] <pitti> cjwatson: ah, thank you
[10:58] <cjwatson> +- bugfix: do not open files with full privileges, if privs will be dropped
[10:59] <cjwatson> +  This make the privilege drop code more bulletproof, but breaks Ubuntu's
[10:59] <cjwatson> +  work-around for log files created by external programs with the wrong
[10:59] <cjwatson> +  user and/or group. Note that it was long said that this "functionality"
[10:59] <cjwatson> +  would break once we go for serious privilege drop code, so hopefully
[10:59] <cjwatson> +  nobody still depends on it (and, if so, they lost...).
[10:59] <cjwatson> e.g.
[10:59] <cjwatson> so, uh, oh dear
[11:00] <pitti> cjwatson: ah, that's because /var/log is root:root 755?
[11:00] <cjwatson> Yeah, it might be as simple as changing that
[11:00] <cjwatson> I see that rsyslog-controlled files there were already syslog:adm
[11:00] <pitti> rsyslog runs as syslog:syslog, so we could just make it root:syslog 775?
[11:03] <cjwatson> that's certainly sufficient to make it work
[11:04] <cjwatson> I can't immediately think of a reason not to do that
[11:06] <cjwatson> what do other distros do?
[11:07] <cjwatson> it's not clear to me that Fedora drops privileges, looking only at its rsyslog packaging
[11:07] <pitti> cjwatson: do they even use rsyslog still? it's not all journald now?
[11:07] <pitti> I understand you can still install it, but it's not by default
[11:08] <cjwatson> Nor Gentoo
[11:08] <cjwatson> pitti: could be
[11:10] <cjwatson> pitti: however, there's a further difficulty
[11:10] <cjwatson> pitti: if I just change the /var/log perms, then it appears to work, but /var/log/syslog is created syslog:syslog not syslog:adm, so the ability for users in group adm to read logs has been broken
[11:11] <cjwatson> (and mode 640)
[11:11] <cjwatson> pitti: this is related to bug 484336
[11:12] <pitti> cjwatson: ah, so we'd need to put user "syslog" into "adm", or perhaps even make that its primary group?
[11:12] <pitti> (that's ugly to do on upgrades, though)
[11:13] <cjwatson> or run rsyslogd as group adm
[11:13] <cjwatson> I don't know which is worse
[11:13] <cjwatson> we have to do one of those if rsyslogd is no longer willing to use raised privileges to open files, though ...
[11:14] <cjwatson> it wouldn't need to be syslog's primary group
[11:14] <cjwatson> syslog is a dynamic user owned by the rsyslog package, so it's not necessarily horrible to change its supplementary groups
[11:15] <cjwatson> hmm, that doesn't fix the ownership though
[11:15] <pitti> right, with a non-primary groupd it'd need a source patch
[11:16] <cjwatson> oh, because rsyslogd doesn't setgroups when it drops privileges?
[11:17] <cjwatson> or rather it does but only to deliberately drop supplementary groups
[11:18] <pitti> cjwatson: no, I meant if it creates a new file, it would need to explicitly set their group to "adm", unless that's its primary group?
[11:18] <cjwatson> it's already configured with FileGroup to do that
[11:18] <pitti> ah, of course; sorry
[11:19] <cjwatson> but the problem is that it can only do the chown() if it did the appropriate setgroups at privdrop
[11:19] <cjwatson> http://kb.monitorware.com/feature-request-privdroptogroup-setgroups-initgroups-t11491.html
[11:19] <pitti> $PrivDropToGroup syslog
[11:19] <pitti> so that's what's not keeping the aux groups
[11:19] <xnox_> doko: cjwatson: yeah, noticed for 1 of the 2 packages that autoreconf.mk snippet is available. Ended up using dh-autoreconf in both. DEB_AUTO_UPDATE_* seems to fail updating libtool, whilst autoreconf works.
[11:20] <pitti> xnox_: <jedi wave> DEB_AUTO_* is not the tool you are looking for, it comes from the dark side
[11:20] <cjwatson> right.  now the questions would be (a) would changing that to adm expose rsyslog to any malice by users in group adm? (b) might there be systems right now that are relying on rsyslog being able to open files in group syslog?
[11:21] <pitti> I don't see an immediate case for (a) as "adm" is pretty much only a "get read privs" group, but (b) certainly might happen
[11:21] <xnox_> pitti: =))))))
[11:21] <cjwatson> the link above has an example of situations where you want rsyslogd to be able to set different log files to be owned by different groups
[11:21] <pitti> cjwatson: TBH it seems safer to me to change the code to not drop the aux groups
[11:22] <cjwatson> dropping the aux groups is required to drop the root group, but it could call initgroups afterwards
[11:39] <cjwatson> pitti: Considering something like http://paste.ubuntu.com/6519272/
[11:40] <pitti> cjwatson: I'm a bit rusty on the order of the various set* calls; does initgroups() come before or after setgid()?
[11:41] <pitti> cjwatson: AFAIR, you have to setgid(), then initgroups(), then setuid(), right?
[11:41] <cjwatson> pitti: rsyslog calls doDropPrivGid then doDropPrivUid
[11:41] <pitti> the patch looks like initgroups() would come after set[ug]id?
[11:41] <pitti> ah, so these two hunks are not from one functino
[11:41] <cjwatson> pitti: doDropPrivGid already calls setgroups before setgid to discard the previously-held supplementary groups
[11:41] <cjwatson> pitti: they are
[11:42] <pitti> cjwatson: ack; LGTM then, thank you!
[11:42] <cjwatson> pitti: the important bit is that you have to drop the old groups before you lose the ability to do so
[11:42] <pitti> cjwatson: but this is still missing a chgrp syslog /var/log, isn't it?
[11:42] <cjwatson> pitti: I think initgroups is fine after setuid
[11:42] <cjwatson> pitti: oh yes good point
[11:42] <pitti> cjwatson: after setuid> that's surprising; that sounds like increasing privileges after you dropped them and shouldn't be able to get them any more?
[11:43] <cjwatson> I think you can gain your own supplementary groups ... but wait, something just occurred to me
[11:43] <pitti> cjwatson: (and chmod 775)
[11:43] <cjwatson> /var/log must not be owned by group adm
[11:43] <cjwatson> because if we do that then users in group adm will be able to add files to it
[11:43] <cjwatson> which is not expected
[11:43] <pitti> no, adm group members must nto be able to write there
[11:43] <pitti> that's why I thought root:syslog would be better
[11:44] <cjwatson> oh, right, yeah, too many pieces
[11:44] <pitti> so that rsyslog can write into it, but no real users
[11:44]  * pitti adds to this TODO list to create an autopkgtest for rsyslog to cover new logs, log rotation, etc.
[11:46] <cjwatson> http://paste.ubuntu.com/6519302/ then
[11:46] <pitti> cjwatson: chmod g+w /var/log ?
[11:47] <cjwatson> added
[11:50] <cjwatson> pitti: hm, you were right earlier, setgroups (called by initgroups) requires the CAP_SETGID capability
[11:50] <cjwatson> so I'll move that before the setuid
[11:51] <pitti> ok, that's relieving (would be weird otherwise)
[12:17] <pitti> tseliot: do you know a way to install the broadcom wl driver on current precise (12.04.3)? when installing it (kernel 3.8) the module fails to build
[12:17] <tseliot> pitti: does it? I thought I had fixed that. Let me check
[12:17]  * pitti tries the current trusty package
[12:18] <tseliot> pitti: 6.20.155.1+bdcom-0ubuntu0.0.2 should fix that (precise-updates)
[12:23] <pitti> tseliot: ah, that's not yet on the 12.04.3 image
[12:23] <pitti> tseliot: I installed the trusty pacakge, that works
[12:23] <tseliot> pitti: ok, let me know if there's anything I can do to help
[12:23] <pitti> tseliot: if you already fixed it, that's fine; it'll be in 12.04.4
[12:24] <tseliot> pitti: good :)
[12:42] <cjwatson> pitti: OK, so after some fixups this basically works, but there's an amusing complication
[12:42] <cjwatson> pitti: On upgrade, we restart rsyslog in postinst rather than stop in prerm / start in postinst, for generally obvious reasons
[12:43] <cjwatson> pitti: But this means that when it restarts it tries to log one final message to say it's shutting down (and others might racily be logged, of course)
[12:43] <cjwatson> pitti: And on a system without /var/log/syslog, that last message now gets successfully written (since we just adjusted permissions) but /var/log/syslog ends up as syslog:syslog (since we hadn't yet completed the restart with supplementary groups)
[12:53] <brainwash> can anyone confirm that the software-center crashes after launch (trusty)?
[12:53] <brainwash> bug 1256929
[12:54] <mdeslaur> @pilot in
[13:00] <cjwatson> pitti: So, I don't know; I suppose we could choose to not care because it's only been a problem for five days or so and it would go away at the next logrotate
[13:00] <cjwatson> pitti: wdyt?
[13:01] <pitti> cjwatson: re (sorry, lunch)
[13:01] <pitti> cjwatson: TBH I'd go with the "don't care" approach, as it didn't affect any stables
[13:01] <pitti> cjwatson: and in trusty, logs are already broken anyway
[13:02] <pitti> cjwatson: i. e. the fully "correct" solution would be to create the file in preinst with the correct permissions on upgrade?
[13:03] <cjwatson> pitti: well, except that the race case could involve log messages going to any log file
[13:03] <cjwatson> I'm cool with "don't care" if you are :-)
[13:05] <pitti> I am
[13:06] <pitti> the main conclusion I draw from this is "this needs an autopkgtest" :)
[13:07] <MacSlow> seb128, taking a look at #1257717
[13:08] <cjwatson> pitti: yes, quite - are you working on that?
[13:08] <cjwatson> pitti: https://code.launchpad.net/~cjwatson/ubuntu/trusty/rsyslog/repair-groups/+merge/197705
[13:08] <pitti> cjwatson: I added it to my TODO list
[13:08] <cjwatson> thanks
[13:08] <seb128> MacSlow, thanks
[13:09] <MacSlow> seb128, odd still... as I didn't run into this when I tested a branch larsu did for nosd
[13:10] <seb128> MacSlow, do you use trusty? as written on the bug, only the new glib is warning about those
[13:10] <MacSlow> seb128, yes... I'm on trusty.
[13:10] <pitti> cjwatson: do you want to wait for slangasek for another review, or just upload?
[13:10] <MacSlow> seb128, did you do anything special to trigger that glib-warning?
[13:10] <pitti> (approved the branch)
[13:11] <cjwatson> pitti: slangasek's on holiday until tomorrow
[13:11] <MacSlow> seb128, or just ran into it right away?
[13:11] <cjwatson> pitti: so I think I'll just upload, thanks
[13:11] <pitti> cjwatson: agreed, thanks
[13:11] <seb128> MacSlow, just wait for a bubble to vanish
[13:12] <seb128> MacSlow, sync or async (e.g sound ones, or just simple "notify-send hey")
[13:12] <MacSlow> seb128, ok... I'll see where I get with this.
[13:13] <seb128> MacSlow, danke
[14:01] <MacSlow> pitti, seb128: With https://code.launchpad.net/~larsu/notify-osd/update-sync/+merge/194364 being merged... what's the expected time to hit trusty-archives?
[14:01] <MacSlow> pitti, seb128: It's purely an automatic process from now on right?
[14:02] <seb128> MacSlow, you need to ask for a landing to didrocks&co
[14:02] <MacSlow> seb128, ah ok...
[14:03] <seb128> notify-osd is not used on touch
[14:03] <seb128> should be easy enough then
[14:03] <didrocks> yep, just get it in the landing spreadsheet and we'll do it right away
[14:03] <MacSlow> didrocks, ehm... "landing spreadsheet" that's something new to me... on google-docs?
[14:04] <didrocks> MacSlow: yeah, maybe ask your manager or tech lead? He should know about it I'm sure :)
[14:04] <MacSlow> didrocks, ok
[14:07] <MacSlow> Saviq, https://code.launchpad.net/~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu
[14:19] <MacSlow> pitti: robru does not seem to be online so if you have a free slot some review-eyes would be nice on https://code.launchpad.net/~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu/+merge/197720 thanks in advance!
[14:24] <dholbach> didrocks, seb128: saw http://packaging.ubuntu.com/fr/html/ already? :)
[14:24] <seb128> dholbach, fr \o/
[14:24] <dholbach> :)
[14:25] <dholbach> seb128, and it's a complete translation :)
[14:25] <seb128> dholbach, tu vois, les traducteurs français travaillent !
[14:25] <didrocks> excellent!
[14:25] <didrocks> (the french word ^)
[14:25] <dholbach> :-)
[14:40] <zul> mterry: ping im looking at the python-librabbitmq MIR and it needs a running rabbitmq-server to test against
[14:54] <MacSlow> seb128, Put a fix for LP: #1257717 up as MR -> https://code.launchpad.net/~macslow/notify-osd/fix-1257717/+merge/197728
[14:54] <seb128> MacSlow, thanks!
[15:18] <mterry> zul, hi
[15:18] <mterry> zul, bummer.  :-/  I don't suppose it's easy to setup and do in a dep8?
[15:18] <zul> mterry: not exactly
[15:19] <zul> mterry:  i spent some time on it this morning and was unsusccessful
[15:19] <mterry> zul, alright no worries
[15:19]  * mterry finds that MIR
[15:19] <zul> mterry: cool thanks
[15:27] <jamespage> infinity, hey - remember that fix you did for openvswitch on powerpc? (adding -latomic to one of the test cases)
[15:28] <jamespage> can you explain why that was required on just a single architecture? I need to backport that package to 12.04 and I'm struggling with that patch on all archs
[16:12] <MacSlow> Saviq, the nosd-icon branch lives here lp:~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu
[16:16] <utlemming> anyone know where the code branch for building the live-cd lives?
[16:19] <cjwatson> utlemming: the squashfs part or the iso9660 wrapper part?
[16:20] <utlemming> cjwaston: I'm actually looking for the code that generates the boot loader portion
[16:21] <cjwatson> utlemming: that'd be in lp:~ubuntu-cdimage/debian-cd/ubuntu
[16:21] <cjwatson> tools/boot/$series/boot-$arch
[16:21] <utlemming> cjwaston: awesome, thank you kindly
[16:21] <cjwatson> nature of the beast is that some of the *real* code lives in the boot loader packages themselves and/or in debian-installer though
[16:22] <cjwatson> so "it depends"
[16:22] <MacSlow> Saviq, notify-osd-icons needs a release from lp:~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu (fixing 1253591), notify-osd needs a release from lp:notify-osd (fixing 404658)
[16:23] <utlemming> cjwatson: understood...I was looking to it for hints on UEFI
[16:24] <cjwatson> yeah, you'll find that's partly in debian-installer/build/util/efi-image and partly (esp. due to secure boot) in grub2 itself
[16:25] <cjwatson> debian/build-efi-images
[16:28] <utlemming> ack, and thank you for the hints :)
[16:34] <kentb> mdeslaur: on that ledmon package, how were you able to tell that it was synced already?  I'd like to know so I don't file an unneccessary bug in the future
[16:35] <mdeslaur> kentb: i got synced about 30 seconds before I wrote that comment :)
[16:35] <mdeslaur> kentb: I saw it on the trusty-changes list
[16:35] <kentb> mdeslaur: ah ok cool
[16:43] <brainwash> bug 1163886 happens in trusty without adding the gnome3 ppa, should the importance level be raised?
[16:45] <brainwash> oh my bad, already set to "critical" (webkit)
[16:53] <seanz> Good day, humans. Is there anyone here maintaining a Debian package that contains a Java .war file?
[16:54] <seanz> I'm looking to obtain information on building a package that will automatically create the .war file, so I wanted to ask questions about how those sorts of packages are officially maintained.
[16:57] <robru> MacSlow, I'm here now, still need that review?
[16:58] <MacSlow> robru, oh ... no... the upload-machinery is already working... I actually did a bit too much initially... you can savely ignore me initial request
[16:58] <robru> MacSlow, ok
[17:12] <infinity> jamespage: Some arches offload some atomic bits to -latomic, and some don't, we only happen to (currently) ship one such arch.  But with --as-needed, it shouldn't matter to link it on all arches anyway.
[17:13] <infinity> jamespage: What problem are you seeing?  Do you have a PPA with source and build logs?
[17:32] <jamespage> infinity, for 12.04 I see a built failure when linking the test-atomic binary - fails to find -latomic
[17:33] <jamespage> lemme dig out a build log
[17:33] <jamespage> infinity, source package is a straight no-change backport
[17:34] <rbasak> mdeslaur: sorry, I checked and synced bug 1257790 earlier, but was waiting to see if it all worked before letting syncpackage close the bug as instructed by it.
[17:35] <mdeslaur> rbasak: ah, cool...didn't know if you had seen the bug or not
[17:35] <mdeslaur> @pilot out
[17:36] <hallyn> stgraber: cgroup-lite in saucy does 'mount (cgroup) || true'.  in precise it doesn't.  Now this was changed so that cases where /sys/fs/cgroup/* was already mounted (i.e. by cgroup-bin), but it happens to also quietly allow cgroup-lite in non-nested profile to be installed
[17:36] <rbasak> mdeslaur: I didn't think there'd be a conflict in that short time. Next time I'll mark it In Progress.
[17:36] <hallyn> stgraber: my question is, which is the right behavior?
[17:36] <jamespage> infinity, log extract - http://paste.ubuntu.com/6520885/
[17:36] <hallyn> my feeling right now is that if cgrousp can't be mounted, cgroup-lite should fail to install.  else things dependin gon it will just fail later
[17:36] <hallyn> i don't intend to change it for saucy, but am wondering whether to change it for precise or not
[17:38] <infinity> jamespage: Oh.  -latomic might be entirely unnecessary on older GCC versions.
[17:39] <infinity> jamespage: I can do a test build on precise/ppc to see if we're good with just dropping that patch on backport.
[17:39] <stgraber> hallyn: I'm not sure. I hate for things to blow up at install time but I also don't think letting cgroup-lite start is a good move, so if it can be installed fine but not started (pre-start check and call to stop) then that should be reasonable
[17:39] <jamespage> infinity, I guess I could write a macro to figure out whether its actually needed
[17:40] <jamespage> trying to avoid deltas due to the number of packages we have to backport for openstack
[17:40] <infinity> jamespage: Or if it can be linked at all. :P
[17:40] <hallyn> stgraber: but things we have now just depend on the cgroup-lite package.  they don't refuse to start if cgroup-lite job is not started
[17:40] <infinity> jamespage: A simple AC_* (try_compile or link?) would get the job done.
[17:40] <infinity> Assuming it's an autoconf project.
[17:40] <jamespage> infinity, yeah - I'll go that route
[17:40] <jamespage> it is yes
[17:40] <infinity> jamespage: Well, let me verify quickly that it works fine on precise without (but it should).
[17:41] <jamespage> thanks
[17:41] <infinity> If I need a *different* fix for precise, I'd like to know.
[17:41] <stgraber> hallyn: sure but none of those actually depend on cgroup-lite either. If cgroup-lite fails to start and you have something else mounting the cgroups, LXC should still work. Actually didn't LXC used to work (maybe still does?) without cgroups?
[17:42] <infinity> jamespage: But yeah, you probably want a proper autoconf check for -latomic, add it to ATOMIC_LIBS if found, and s/-latomic/$(ATOMIC_LIBS)/ in my tests/automake.mk patch.
[17:43] <jamespage> ack - I'll look at that tomorrow
[17:43] <jamespage> (bit late in the day for my brain to work right with autoconf checks now)
[17:47] <hallyn> stgraber: ok.  so i guess we can open a bug against cgroup-lite tofix that in precise.  But I'm nto sure the best way to handle it.
[17:47] <hallyn> shoudl i just make it '/bin/mount-cgroups || {stop; exit 0}' in pre-start?
[17:47] <hallyn> (cgroup-lite does everything in pre-start, no start)
[17:48] <hallyn> i guess i can try and do it more the way saucy does it.
[17:48] <stgraber> hallyn: yeah, I think that'd be appropriate, that way anything that uses on "start on cgroup-lite" won't get started if cgroup-lite fails
[17:49] <hallyn> ok, thanks.
[17:49] <hallyn> heh, currentliy no bugs in cgoup-lite.  hate to change that :)
[17:56] <xnox> pitti: since the syslogd bug was upon new-installation, all what's needed is an extra installation validation python test added to utah, this way it would be verified on fresh installs against all install types it's executed upon.
[17:56] <xnox> pitti: i can add it.
[18:12] <infinity> jamespage: Confirmed that it builds fine on precise with my patch backed out, FWIW, so yeah, a try_link or whatever should do the trick.
[18:12] <infinity> jamespage: And that would certainly be more upstreamable too.
[18:25] <seanz> Is this the appropriate channel to ask for info about .deb packages?
[18:33] <olli> seanz, what's your question
[18:33] <seanz> olli: My question is about how to properly package a .war file as a Debian package.
[18:34] <seanz> I wanted to find a maintainer of such a package and get info from said individual. Or multiple individuals, if there are many.
[18:34] <olli> seanz, this is a good start here, I am not familiar with that though
[18:35] <seanz> olli: Ah, well thank you for confirming that I'm in the right place.
[18:36] <tarpman> seanz, might be worth checking with #debian-java
[18:36] <tarpman> erm. sorry, wrongchan, ignore me
[18:36] <seanz> tarpman: Oh man, I got pretty excited there for a moment. :) That would have been perfect.
[18:37] <tarpman> seanz: oh. well, do try it then. it's on irc.debian.org (OFTC)
[18:37] <tarpman> seanz: I was reading your messages thinking we were in #debian-devel
[18:37] <seanz> tarpman: haha - I couldn't get into debian-devel because it is invite only.
[18:37] <tarpman> seanz: on freenode it is, because all the debian channels are on oftc
[18:37] <seanz> I don't know anyone in the Debian circles.
[18:38] <tarpman> seanz: the real #debian-devel, the OFTC one, is public
[18:38] <seanz> tarpman: Which one is the "real" one?
[18:38] <seanz> OFTC or freenode?
[18:38] <tarpman> OFTC
[18:38] <tarpman> see https://wiki.debian.org/IRC
[18:39] <seanz> tarpman: Ah, most excellent.
[18:39] <tarpman> seanz: have to run. good luck
[18:39] <seanz> tarpman: Thanks. Have a good day.
[18:44] <seb128> bdmurray, thanks for SRUing mvo's aptdaemon fix, do you plan to upload to trusty as well?
[18:45] <seb128> bdmurray, infinity: could you review the wpa SRU in the saucy queue this week? That's one of the most reported e.u.c errors for saucy, would be nice to get in
[18:46] <seb128> cyphermox, thanks for uploading that ;-)
[18:51] <bdmurray> seb128: I hadn't thought about trusty yet
[18:51] <bdmurray> seb128: I'll look at wpa
[18:52] <seb128> bdmurray, ok, not sure how picky the SRU reviewers are about having stuff fixed in $unstable before accepting SRUs nowadays
[18:52] <seb128> bdmurray, thanks
[19:30] <lifeless> barry: hey, do you know the situation vis-a-vis paramiko and Python3 ?
[19:31] <lifeless> barry: upstream, that is.
[19:31] <barry> lifeless: i get emails about the open ticket all the time.  let me see if i can dig up something recent
[19:32] <barry> lifeless: https://github.com/paramiko/paramiko/issues/16
[19:32] <barry> issue is still not closed (currently they are debating python 3.2 support)
[19:33] <lifeless> thanks
[19:33] <lifeless> do you think more hands would help?
[19:34] <barry> lifeless: sounds like they could use additional validation so they'll feel more confident releasing something
[21:36] <zyga> barry: does this ring any python bug bells:  https://plus.google.com/116315264177593873442/posts/aMYRMCW9rgc
[21:36] <zyga> barry: 3.2 seems to mangle memory when certain metaclass operations are used, 3.3 does not
[21:36] <zyga> (mangle as in overwrite somewhere)
[21:45] <barry> zyga: it doesn't but let me poke around
[21:45] <zyga> barry: thanks!
[21:47] <zyga> barry: I tried several alternatives (constructing another dict from namespace, etc) but only actually iterating over the namespace dict triggers that bug), manifestations are also different, I just realised I saw this bug in some of my older code, where it borked __mro__ instead of repr
[21:50] <zyga> barry: also, works on i386 but does not work on amd64 (sadly arches are also coupled with different OSes and python releases/builds in my environment). I'm setting up tests on i386 debian py3.2 builds
[21:53] <barry> zyga: looks like it's still broken in py32 hg head
[21:54] <zyga> barry: yeah, it's broken on all builds of 3.2 that I can find
[21:58] <barry> zyga: that's a truly strange one.  if you replace the for-loop with just list(namespace.items()) it works.  that means iterating by itself isn't the problem.
[21:58] <zyga> yeah
[21:58] <zyga> I know
[21:59] <zyga> I'm going to build 3.2 and check if I can make heads/tails of what that operation may trigger in __new__
[21:59] <zyga> barry: also, might be bisectable between 3.3
[21:59] <zyga> barry: but that would take a while to run
[21:59] <zyga> barry: shall I report it upstream?
[22:00] <barry> zyga: i was just scanning bugs.python.org to see if it was already reported.   i'm happy to report it if i don't find something (unless you want to do it)
[22:00] <zyga> barry: I could do it, seems like a genuine bug and I can learn something in the process
[22:01] <barry> zyga: go for it.  i can't find anything in my tracker searches.  it's definitely a weird corner case. :)  paste me the bug number so i can subscribe to it
[22:02] <zyga> sure
[22:02] <barry> zyga: fun!
[22:06] <zyga> barry: http://bugs.python.org/issue19888
[22:07]  * zyga checks 2.7
[22:08] <zyga> barry: also affects 2.7
[22:08] <barry> zyga: with different syntax of course
[22:10] <zyga> right
[22:10]  * barry checks 2.7 hg head
[22:12] <zyga> barry: can I link that to python in ubuntu somehow?
[22:16] <barry> zyga: link it to the source packages for python3.2 and python2.7.  of course, we'll probably ignore it for 3.2 unless it's worth sru'ing into older ubuntoids
[22:16] <zyga> barry: ok, I'll try
[22:16] <zyga> barry: curious, it seems to pick up first, not too short, symbol defind in the object
[22:17] <zyga> barry: I tried with methods, variables, etc
[22:17] <zyga> barry: but short, one-letter variables didn't work
[22:17] <zyga> barry: 'problem = 1' works (reproduces the problem) though
[22:17] <barry> zyga: fun
[22:17] <barry> zyga: is this a critical problem to fix?  iow, does it break something critical for you?
[22:18] <zyga> barry: no, just breaks some tests that I've disabled
[22:18] <zyga> barry: it's not happeninng if you construct the new class before iterating over namespace
[22:18] <barry> zyga: ack
[22:21] <zyga> oohhh
[22:21] <zyga> barry: it's so silly
[22:21] <zyga> barry: it is not a bug :)
[22:21] <zyga> barry: name spills out of the for loop
[22:21]  * zyga is such a woos
[22:22] <zyga> barry: did 3.3 change anything in that behavior?
[22:23] <barry> d'oh
[22:24]  * zyga is so stupid now :)
[22:24] <zyga> barry: why did it work on 3.3 though? sheer accident?
[22:24] <zyga> barry: or does 3.3 change scoping rules?
[22:24] <barry> zyga: yes it did.  for-loop variable scopes
[22:24] <zyga> aaah
[22:24] <zyga> right
[22:24] <zyga> didn't know that
[22:24] <zyga> :D
[22:24] <zyga> that was silly, thanks, I'll fix my code
[22:25] <zyga> sorry for taking your time with my mistakes
[22:39] <zyga> barry: I cannot find any trace of that new for loop behavior, I've read http://docs.python.org/dev/whatsnew/3.3.html and looked for PEPs, is there document/discussion that describes that feature?
[22:40] <barry> zyga: hmm, i don't see one either
[22:41] <zyga> barry: are you sure it's that though, this is not a bug, just hard-to-find feature?
[22:44] <barry> zyga: you could just be getting (un)lucky.   it might be related to iteration order
[22:44] <lifeless> zyga: got a small reproduction of the problem?
[22:44] <zyga> lifeless: yeah
[22:45] <zyga> http://bugs.python.org/issue19888 see two attached files
[22:45] <zyga> barry: but namespace doesn't include __name__, it cannot be luck
[22:46] <zyga> barry: so we cannot get lucky ordering that would result in the the binding to name being right
[22:46] <lifeless> zyga: scary
[22:46]  * zyga writes another test case for 3.3 magic feature
[22:46] <barry> zyga: it's as if type.__new__() is ignoring 'name' for repr purposes
[22:46] <lifeless> zyga: but your code is clearly broken
[22:46] <lifeless> zyga: since you're rebinding name
[22:47] <barry> lifeless: right
[22:47] <barry> lifeless: but it doesn't matter :)
[22:47] <lifeless> barry: right, corrupt is corrupt
[22:48] <zyga> lifeless: yeah, my code was broken but something else seems to be broken as well
[22:48] <zyga> barry: I cannot reproduce 3.3 for-loop scoping
[22:49] <barry> zyga, lifeless forget loops.  http://paste.ubuntu.com/6522270/
[22:49] <barry> run that under 3.2 and 3.3
[22:50] <zyga> barry: o_O
[22:50] <zyga> something is indeed broken
[22:52] <zyga> barry: would you like to reopen it with the extra bits of information?
[22:52] <barry> zyga, lifeless at best it's an undocumented change in behavior afaict
[22:53] <lifeless> barry: <class '__main__.foo'>
[22:53] <barry> zyga: what makes you think it's a memory corruption?
[22:53] <barry> lifeless: right
[22:53] <zyga> barry: well, it's clearly not memory corruption, the bug can be renamed
[22:53] <zyga> barry: but it's a bug (your case shows that clearly)
[22:53] <zyga> barry: or we can have a new one
[22:53] <lifeless> oh
[22:53] <lifeless> the class name is being honoured
[22:54] <lifeless> in 3.2 and ignored in 3.3
[22:54] <lifeless> 3.3 regression?
[22:54] <barry> lifeless: could be
[22:56] <zyga> no 3.4 builds anywhere?
[22:56] <barry> zyga: i'm building it from hg now
[22:57] <barry> not in ubuntu yet.  i think doko has a 3.4 build in experimental
[22:57]  * zyga looks
[23:00] <zyga> barry: also present in 3.4 from experimental
[23:00] <barry> zyga: yes, and hg head
[23:00]  * zyga dives into cpython
[23:12] <zyga> barry: I think I found it
[23:12] <zyga> barry: just let me build to check
[23:13] <zyga> barry: how do I checkout master ahain /o\
[23:13] <doko> barry, you should run trusty
[23:14] <barry> doko: i do!
[23:14] <barry> zyga: http://docs.python.org/devguide/
[23:14] <doko> https://launchpad.net/ubuntu/+source/python3.4/3.4~b1-0ubuntu2
[23:14] <barry> doko: ah, right :)
[23:15] <zyga> barry: I mean after I've swithched to 2.7 to compare?
[23:15] <zyga> barry: hg checkout default?
[23:15] <barry> zyga: yeah
[23:15] <zyga> thx
[23:16] <barry> doko: ah, it's only in proposed
[23:18] <zyga> barry: nope, wrong idea, still searching (for the bug, not for hg manual)
[23:19] <barry> zyga: ack.  it's nearly dinner time here, so i'll be afk in a bit.  i'll check scrollback later
[23:19]  * zyga wonders what to say, it's 1:16 AM 
[23:19] <zyga> ah, 0:19 AM, my vms got borkish timezones and unsynced clocks
[23:19] <barry> zyga: i guess i can't say it's time for a midnight snack :)
[23:19] <zyga> haha
[23:22]  * zyga added import math; math.sin(0) to break on the sin symbol in C and learn how python object construction works
[23:25] <zyga> any gdb macros to poke python objects?
[23:29] <barry> zyga: checkout Misc/gdbinit
[23:30]  * zyga learned how to look at tuples with some ugly casting
[23:30] <zyga> ah, thanks
[23:31] <zyga> barry: that's super useful, thanks
[23:33] <zyga> ok, I see the wrong value being passed, let me just figure out where it came from
[23:35] <zyga> smells like broken builtin___build_class__
[23:48] <zyga> barry: any reason I get 'No symbol "_PyUnicode_AsString" in current context' when using most of the macros?
[23:49] <jtaylor> barry: Misc/gdbinit seems less feature full that the stuff that comes with python-dbg
[23:50] <jtaylor> or is it just extra stuff?
[23:51] <jtaylor> zyga: you should get gdb python object resolving automatically if you install pythonX.Y-dbg, (but its broken in saucy)
[23:54] <zyga> jtaylor: my mirror doesn't include -dbg packages, hold on
[23:54] <zyga> jtaylor: will it break if I rebuild python locally with debugging (different layout?)
[23:55] <jtaylor> probably not
[23:55] <jtaylor> so far I know its pure python implementation
[23:56] <jtaylor> and its awesome :)
[23:56] <jtaylor> http://docs.python.org/devguide/gdb.html
[23:57] <zyga> jtaylor: i'm a bit tired, I need to figure out how to break on a given condition that involves a python unicode object
[23:57] <zyga> I guess I need to just stop debugging stuff at 1AM
[23:58]  * zyga mirrors -dbg packages related to python