[00:04] doko: DEB_AUTO_UPDATE_AUTOCONF=2.69 [00:05] .... and similar for automake (if needed) and etc. [00:05] doko: working example http://sources.debian.net/src/libshout/2.3.1-3/debian/rules?hl=23#L21 === GridCube_ is now known as GridCube === salem_ is now known as _salem === freeflying_away is now known as freeflying [00:16] xnox: ITYM DEB_AUTO_UPGRADE_TO_DH [00:17] slangasek: yeah, i'm gonna write cdbs snippet to execute dh_autoreconf with a single include =) [00:18] no, I mean a command to replace debian/rules with /usr/share/doc/debhelper/examples/rules.tiny [00:19] heh [00:29] slangasek: I think that command is "cp", but ymmv. [00:36] 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] sarnold: "based on series" is bogus metadata, can be fixed. [00:37] xnox: okay, I figured as much there.. :) [00:37] sarnold: samba4 src package and binaries should be removed from the archive, once ready. [00:37] sarnold: fully superseeded by samba src package, which has now switched to 4.x series in debian and ubuntu [00:38] xnox: cool! thanks. :) [00:38] sarnold: but, do note that upgrade story is aweful. If one had samba4 package installed on upgrade, it is removed =( [00:38] sarnold: if one had samba installed -> it's upgraded to samba (3.x -> 4.x) [00:38] sarnold: if one had both samba & samba4 installed, there are held packages and both are removed \o/ [00:38] slangasek: ^ =))))) [00:39] 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] xnox: hahah, that's even more special :) [00:39] i filed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730650 [00:39] Debian bug 730650 in samba "samba: wheezy -> jessie upgrades may fail" [Important,Open] [00:40] i think with http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730090 it will be better [00:40] Debian bug 730090 in samba,samba-common-bin "samba,samba-common-bin: leaves alternatives after upgrade from wheezy" [Important,Open] [00:40] but still.... [00:41] xnox: thanks for finding this so early :) it'd be a lot less pleasant to find this in february or march. :) [00:43] sarnold: This isn't the sort of thing do-release-upgrade should be papering over, we should make apt-based upgrades DTRT. [00:44] xnox: Are you keeping an eye on this one to make sure it ends up being sane? [00:44] xnox: Also, wouldn't a samba4 transitional package help here a bit? [00:45] infinity: I've been lucky enough to not need the details of what apt can and can't fix itself :) [00:45] sarnold: apt can fix pretty much anything if the packages are sane. :P [00:45] infinity: well, look at the current samba4 package ;-) it is already transitional in ubuntu. [00:45] 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] infinity: oh, nice :D [00:46] 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] xnox: It... is? Not according to rmadison. [00:46] infinity: but I don't know if there are samba4 -> samba config migrations or not. [00:47] infinity: samba4:any transitional package is built from samba4:src [00:47] infinity: i did it to bypass NEW and get the migration rolling, when everyone was away =) [00:47] xnox: It wouldn't have been NEW. [00:47] (it was blocking eds/libav9 transitions) [00:48] my bet then. [00:48] i should upload proper one then. [00:48] 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] infinity: ... same in debian? [00:49] 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] We really should never have shipped it in the first place. :( [00:49] xnox: Same in Debian, yes. A binary takeover from one source to another doesn't bug DAK. [00:49] we have never shipped it ;-) (*) in an LTS [00:51] wait, we did.... nevermind me. [01:07] xnox: FWIW I'm running samba4 on 12.04 and will want to upgrade those servers to 14.04 at some point :) [01:08] stgraber: heh =) last time i touched samba, was when we were doing medical ORM on top of LDAP..... [01:09] 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] xnox: my domain has 4 domain controlers, so just upgrading one should be easy enough [01:27] stgraber: 4 DCs? Overengineered house much? [01:34] infinity: that's 4 different locations on 2 continents ;) [01:38] talk about a house... === mhall119|afk is now known as mhall119 [01:44] stgraber's neighborhood http://xkcd.com/1298/large/ [01:48] help === shuduo_afk is now known as shuduo [02:46] 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? === szicari is now known as seanz [04:27] infinity: 'cp' - that's not very cdbsish! [04:27] xnox: samba upgrade> yes, have seen the bug report :/ === thegodfather is now known as fabbione === debfx_ is now known as debfx === seiflotfy_ is now known as seiflotfy === mnepton is now known as mneptok [05:28] 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] hey pianogmx :) it's a bit late for north america and a bit early for europe.. [05:30] pianogmx: is there anything in particular that's most interesting to you? [05:30] 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] sarnold, my last projects were with a professor at my university but now I finished them all so thus im bored [05:31] C# windows forms apps [05:31] pianogmx: bored is good, that's what drives you to find something fun to do! :) [05:32] 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] pianogmx: http://harvest.ubuntu.com/ is a neat site listing some not-too-difficult bugs that people could use help working on [05:33] 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] ooh, I've never seen harvest before. neat. :) [05:35] sarnold: :) [05:36] 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] lol [05:38] 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] 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] :( information overload... [05:53] i loved it when people would break things into smaller tasks for me to accomplished [05:54] now I just use the computer to stare at it ... because if no one manages me, i love my television [05:57] 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] 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] huh? you mean the ubuntu phone project? [06:00] sounds cool... [06:01] pianogmx: yeah, I saw your message in there after seeing this channel. go figure. :) hehe [06:01] do TI 84 use RPN? [06:02] no, they use algebraic input [06:02] lol... id have to understand RPN first then it would be simple... yeah thats doable :) [06:03] all i would need help with is how the community would like the UI to be... then I would be set [06:03] 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] the end result is you get to type things like 14 21 + 7 * rather than (14+21)*7 [06:04] interesting, reminds me when I stared at a sample assembly code... yeah I get it [06:07] so the ubuntu phone uses the QML development stuff? [06:07] yes [06:07] 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] lol... i remember back in high school when making an algebraic calculator in java was an assignment [06:09] same here, I cringe when I think of how poorly mine worked. yes, it worked, but no, it wasn't pretty. :) [06:09] i just never really stepped up my game since 07 to devbelop my skills... [06:09] stopped programming for like 3 years [06:10] made me depressed because i forgot shit [06:10] oh mine used a java jpanel and i had it scroll 7 lines until it disappeared [06:11] + i take mind altering medications... also upset because it screws with my thinking a bit... [06:11] but... at least my body aint shaking [06:12] 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] as for an RPN calculator on a ubuntu phone... is there an emulator for the ubuntu phone? [06:13] 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] 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] im on boost mobile (cant afford contract phones) thus i cant get a nexus 4 (cries) [06:15] if nexus 4 did CDMA then it would be cool. [06:16] i was happy when I got my HTC phone to run a partially working CM10 [06:16] but then went back to a modified stock instead... [06:19] 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] https://wiki.ubuntu.com/Touch/Emulator <-- The emulator. [06:20] exactly... is ubuntu phone OS going to have CDMA, EvDo compatbility in it? [06:21] break=bottom?? o_O [06:22] sarnold: Instructions for how to recover a system that got hosed due to earlier emulator versions... [06:22] (Well, due to a libc6 bug tickled by earlier emulator deps) [06:22] infinity: yeah, looks very unfun. I've never seen break= before, hehe. [06:22] sarnold: break= refers to breakpoints in the initramfs's init. [06:23] sarnold: bottom being the last thing before it pivots. [06:23] infinity: very cool, where's this thing documented? I don't see 'bottom' in upstart-events(7).. [06:23] sarnold: initramfs init isn't upstart. [06:24] Also, I lie, the last breakpoint pre-pivot is "init", bottom's a bit higher. Anyhow, you get the point. [06:24] man initramfs-tools [06:24] OH.... android emulator requires the rolling release of trusty... [06:24] Wow, it is kinda documented. [06:25] I just read /usr/share/initramfs-tools/init when I want to refresh my memory. [06:25] thanks infinity, geofft :) I love learning new things. I'm not an entirely old dog yet! :) [06:26] i wish gparted / ubuntu could shrink a partition when its in use (kindof like windows)... but the live usb always works :) [06:27] is trusty tahr stable enough to handle QML app development for the ubuntu phone? [06:27] (idk yet because im downloading it) [06:46] sarnold, for the ubuntu sdk and the ubuntu phone, are all of the updates being pushed into the 13.10 for download? [06:46] reason i ask, is i found an error that is supposedly already fixedx... [06:46] While I'm here, anyone know if there's a data dump or API for www.ubuntu.com/certification? [06:46] (or where I should ask?) [06:46] and i noticed the ubuntu phone emulator asks for a trusty tahr environment... [06:47] * pianogmx waves at geofft [06:47] 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] sarnold, yeah, thats why im thinking to just shrink the ubuntu partition i have right now to keep it on stable packages [06:48] and install another installation of trusty tahr for pre-release [06:50] would be cool if rolling releases used p2p [06:50] put less strain on the server... [06:52] sarnold, so basically right now most people are using trusty tahr to develop QML apps for the Ubuntu Phone? [06:52] 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] 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] 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] 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] awesome. [06:55] will the ubuntu phone OS be CDMA compatible? [06:58] im going to setup that quid package... sounds awesome... but I was addressing http downloads being slow from particular websites... [06:59] oh... but i only have one machine with ubuntu. [07:00] 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] 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] i found that impressive [07:06] lfaraone: Please update the quassel packaging branch too. [07:08] reading about axel... wouldn't axel theoretically overload an http server if too many people used axel on the same server? [07:08] however, i am not complaining... it does download faster [07:10] 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] 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] yeah, but i remember seeing when I setup a webserver on a max connections it can handle. [07:11] so like, lets say axel opens 20.... and multiple people do that... it can theoretically hit that max connections open limit [07:11] Godo morning [07:12] morning pitti :) [07:12] pianogmx: yeah; some server admins go to the effort of rate-limiting by IP or by network instead. [07:13] yep... i setup a server or two a while back... one windows server , one ubuntu based... more to see how it works. [07:14] i cant wait to see if there is any gpu performances in trusty tahr :) [07:14] doko, infinity: python-imaging job removed from public jenkins, someone already did that for the public jenkins [07:18] 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] xnox, jibel: there are other log files like /var/log/udev or cloud-init.log, but apparently none from rsyslog [07:18] rsyslog start/running, process 843 [07:20] pitti, it is not only wazn but all the test VMs [07:20] *.*;auth,authpriv.none -/var/log/syslog [07:20] that's in /etc/rsyslog.d/50-default.conf in the test VM [07:21] 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] pitti, yes, they should be exactly the same === shuduo is now known as shuduo_afk === shuduo_afk is now known as shuduo [07:35] good morning [07:36] pitti, I don't have /var/log/syslog on a local VM created with prepare-testbed either, and syslog is running [07:36] jibel: ok, so perhaps mine is special then.. [07:37] jibel: ah, mine is some two days old, hang on; building a fresh one === shuduo is now known as shuduo_afk === shuduo_afk is now known as shuduo [07:53] pitti, from rsyslogd in debug mode [07:53] 3558.255026043:7f23687e2700: file '/var/log/syslog' opened as #-1 with mode 416 [07:53] 3558.255029594:7f23687e2700: strm 0x7f2360000b70: open error 13, file '/var/log/syslog': Permission denied [08:06] 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] pitti, xnox same problem on a fresh server install with latest trusty images [08:10] 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] 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] Mirv, what you uploading? [08:14] pitti, http://paste.ubuntu.com/6518563/ it should be enough until logs are rotated which shouldn't happen during a test. [08:15] pianogmx: I uploaded qtdeclarative-opensource-src [08:15] jibel: ouch; that seems to be new behaviour from rsyslog? [08:16] cool Mirv [08:17] 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] pitti, yes, it seems to have started with 7.4.4 [08:18] jibel: that sounds like a regression === iahmad_ is now known as iahmad|afk === masACC is now known as maswan [08:30] pitti, xnox bug 1257633 [08:30] bug 1257633 in rsyslog (Ubuntu) "/var/log/syslog doesn't exist on fresh installation of Trusty." [Undecided,New] https://launchpad.net/bugs/1257633 [08:31] jibel: merci [08:31] I pushed the workaround to unblock tests [08:49] squid3 is green, and I restarted apport which failed for the same reason [08:49] jibel: thanks; did these tests explicitly check for /var/log/syslog? I don't remember doing that in apport [08:49] and it woudl be bad, as people can configure that to their liking [08:51] 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] jibel: ah indeed, thanks [08:52] I'll fix that [08:53] jibel: or rather, it's not the test, it's the hookutils' "recent_syslog()" which assumes that /var/log/syslog exists [08:53] jibel: so again an actual regression which slipped in ;/ === mardy_ is now known as mardy === Ursinha_ is now known as Ursinha === Guest49309 is now known as LoganCloud === LoganCloud is now known as Guest2029 [09:14] 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] 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] 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] MacSlow: try lp:~macslow/ubuntu/trusty/notify-osd-icons/foobarize [09:37] (pick a more adequate branch name, of course) [09:38] pitti, ah... ok thanks [09:38] pitti, is https://code.launchpad.net/~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu the packaging branch? [09:39] seb128: ah, yes accordign to Vcs-Bzr [09:39] MacSlow: so, you don't actually want the UDD branch [09:39] MacSlow, ^ you might want to target that, not lp:ubuntu/notify-osd-icons [09:39] MacSlow: s/might want to /must/ [09:40] unless we want to give up on the ~ubuntu-art-pkg team and that branch [09:41] seb128, pitti: it's to add new icons from https://bugs.launchpad.net/ubuntu/+source/notify-osd-icons/+bug/1253591 for precise [09:41] Ubuntu bug 1253591 in notify-osd-icons (Ubuntu Precise) "Display switch and Radio enable/disable hotkey icons" [Undecided,New] [09:42] 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] pitti, seb128: so right now I've pushed them to lp:~macslow/ubuntu/precise/notify-osd-icons/fix-1253591 [09:42] seb128, ah... will do that [09:42] thanks [09:49] 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] pitti, seb128: When you got a moment... https://code.launchpad.net/~macslow/ubuntu/trusty/notify-osd-icons/fix-1253591/+merge/197670 [10:02] 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] MacSlow: yes, we can't use UDD for (the first) SRU, and we don't use UDD in general for that package [10:04] 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] pitti, so what's the next step to get it in precise once it was merge to trusty? [10:05] 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] MacSlow: you aren't in ~ubuntu-art-pkg? If you are, you can just commit to the actual branch [10:08] pitti, no I'm not in that team [10:09] pitti, didrocks is afaik [10:10] 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] 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] MacSlow: yeah, better to do it in the real branch [10:14] then, we can add it to daily-release because we don't AFAIK. I'll ask robru to do it [10:14] didrocks, d'accord [10:14] MacSlow: merci! :) [10:15] didrocks: I guess we can't run autopkgtests in CI yet, can we? [10:15] didrocks: I mean s/CI/daily autolanding/ [10:16] pitti, didrocks: the "real" branch is ~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu then I assume [10:16] pitti: unfortunately, not [10:16] MacSlow: we should create a project for it [10:16] didrocks: ack, thanks (once we can, I'd like to add apport and the sponsoring queue at large into it) [10:16] MacSlow: please, merge it there, I'll ask robru to fix all this :) [10:16] pitti: yeah, I think it's one of the priority for the CI AFAIK [10:16] team* [10:16] didrocks, push my changes based on this directly there?! [10:17] didrocks, no MR? [10:17] didrocks: FWIW, notify-osd-icons hasn't changed in years, probably not worth spending much time on [10:17] MacSlow: nah, you'll need an MR if you aren't in ~ubuntu-art-pkg; but I'm happy to review/merge === apw` is now known as apw [10:17] MacSlow: I think nobody can review it, so please do (seems safe icon changes) [10:18] pitti: well, better to have the same process for all our components [10:18] with proper projects settings and so on [10:18] this is only a 10 minutes process [10:18] didrocks: right, but it sounds like this shoudl be an "icons" branch under lp.net/notify-osd, not a separate project [10:19] 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] didrocks: ah, ok [10:27] 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] didrocks, pitti: e.g would be nice to get upload now and not delay too much on infra changes [10:27] 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] MacSlow: ah, so you can push after all, nice [10:27] MacSlow, yes, SRU just needs a bug report with the SRU info (https://wiki.ubuntu.com/StableReleaseUpdates) [10:28] 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] seb128: even if I would have prefer robru to train on that one :) [10:28] * MacSlow reads... [10:28] didrocks, well, they want the stuff to land this week in trusty/precise SRU [10:28] didrocks, so whatever, as long as you are sure he's going to follow up and not screw it [10:29] seb128: yeah, it will land that week, I'll backup tomorrow if it's not done tonight [10:29] 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] didrocks, thanks [10:29] didrocks, are you going to do the SRU landing as well? [10:29] pitti, ah... didn't know that... thanks [10:29] seb128: not that one, I vary changing things for older release, so if you want to handle it [10:29] MacSlow: yes, no big deal, just for the records in case you wonder [10:30] MacSlow: thanks for keeping up with the bureaucracy and the UDD complications [10:30] didrocks, ok [10:30] MacSlow: deleted your trusty UDD MP [10:30] 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] pitti, ah good... was about to do that too === shuduo is now known as shuduo_afk [10:35] pitti, do you want to sponsor the SRU or should I? [10:35] seb128: can do, but I understand we need to wait for landing this in trusty first? [10:35] seb128: after that, it's a simple apt-get source, meddle changelog, upload [10:36] 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 === Chipaca` is now known as Chipaca [10:36] 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] yeah, I doubt the queue is going to be reviewed in a day from past experience :) [10:37] so it's not going to be the same upload for the SRU [10:37] seb128: ah, ok; I'll upload it now, then. [10:37] we can as well dput what MacSlow just got up [10:37] pitti, danke [10:37] pitti, seb128, didrocks: The SRU-info is actually part of LP: #404658 and LP: #1253591 (icons) is just "part" of the fix. [10:37] Launchpad bug 404658 in OEM Priority Project precise "notification summary doesn't change for synchronous messages" [Critical,In progress] https://launchpad.net/bugs/404658 [10:37] Launchpad bug 1253591 in notify-osd-icons (Ubuntu Precise) "Display switch and Radio enable/disable hotkey icons" [Undecided,New] https://launchpad.net/bugs/1253591 [10:37] seb128, MacSlow: precise SRU uploaded (but SRU team will not consider it before it lands in trusty) [10:38] pitti, there is a bug reference in the changelog right? [10:38] pitti: ok [10:38] seb128, yes... and I used --fixes in bzr commit === wgrant_ is now known as wgrant [10:38] great [10:38] MacSlow, danke === Wellark_ is now known as Wellark === _salem is now known as salem_ [10:55] xnox_, slangasek: I adjusted bug 1257633; apparently rsyslog is now completely unable to create any of its logs? [10:55] bug 1257633 in rsyslog (Ubuntu Trusty) "/var/log/syslog and others don't exist on fresh installation of Trusty." [Critical,Confirmed] https://launchpad.net/bugs/1257633 [10:57] pitti: I'm investigating that at the moment, bug 1256695 [10:57] bug 1256695 in rsyslog (Ubuntu) "Trusty desktop Installation logs are not copied to /var/log/installer/" [Undecided,Confirmed] https://launchpad.net/bugs/1256695 [10:57] pitti: it seems to be to do with a rearrangement of how privilege-dropping works [10:58] cjwatson: ah, thank you [10:58] +- bugfix: do not open files with full privileges, if privs will be dropped [10:59] + This make the privilege drop code more bulletproof, but breaks Ubuntu's [10:59] + work-around for log files created by external programs with the wrong [10:59] + user and/or group. Note that it was long said that this "functionality" [10:59] + would break once we go for serious privilege drop code, so hopefully [10:59] + nobody still depends on it (and, if so, they lost...). [10:59] e.g. [10:59] so, uh, oh dear [11:00] cjwatson: ah, that's because /var/log is root:root 755? [11:00] Yeah, it might be as simple as changing that [11:00] I see that rsyslog-controlled files there were already syslog:adm [11:00] rsyslog runs as syslog:syslog, so we could just make it root:syslog 775? [11:03] that's certainly sufficient to make it work [11:04] I can't immediately think of a reason not to do that [11:06] what do other distros do? [11:07] it's not clear to me that Fedora drops privileges, looking only at its rsyslog packaging [11:07] cjwatson: do they even use rsyslog still? it's not all journald now? [11:07] I understand you can still install it, but it's not by default [11:08] Nor Gentoo [11:08] pitti: could be === sraue_ is now known as sraue [11:10] pitti: however, there's a further difficulty [11:10] 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] (and mode 640) [11:11] pitti: this is related to bug 484336 [11:11] bug 484336 in rsyslog (Ubuntu) "/etc/rsyslog.conf permissions incorrect/missing for creation of dynamic files" [Undecided,Confirmed] https://launchpad.net/bugs/484336 === psivaa is now known as psivaa-afk [11:12] cjwatson: ah, so we'd need to put user "syslog" into "adm", or perhaps even make that its primary group? [11:12] (that's ugly to do on upgrades, though) [11:13] or run rsyslogd as group adm [11:13] I don't know which is worse [11:13] we have to do one of those if rsyslogd is no longer willing to use raised privileges to open files, though ... [11:14] it wouldn't need to be syslog's primary group [11:14] syslog is a dynamic user owned by the rsyslog package, so it's not necessarily horrible to change its supplementary groups [11:15] hmm, that doesn't fix the ownership though [11:15] right, with a non-primary groupd it'd need a source patch [11:16] oh, because rsyslogd doesn't setgroups when it drops privileges? [11:17] or rather it does but only to deliberately drop supplementary groups [11:18] 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] it's already configured with FileGroup to do that [11:18] ah, of course; sorry [11:19] but the problem is that it can only do the chown() if it did the appropriate setgroups at privdrop [11:19] http://kb.monitorware.com/feature-request-privdroptogroup-setgroups-initgroups-t11491.html [11:19] $PrivDropToGroup syslog [11:19] so that's what's not keeping the aux groups [11:19] 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. === shadeslayer_ is now known as shadeslayer [11:20] xnox_: DEB_AUTO_* is not the tool you are looking for, it comes from the dark side [11:20] 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] 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] pitti: =)))))) [11:21] 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] cjwatson: TBH it seems safer to me to change the code to not drop the aux groups [11:22] dropping the aux groups is required to drop the root group, but it could call initgroups afterwards [11:39] pitti: Considering something like http://paste.ubuntu.com/6519272/ [11:40] cjwatson: I'm a bit rusty on the order of the various set* calls; does initgroups() come before or after setgid()? [11:41] cjwatson: AFAIR, you have to setgid(), then initgroups(), then setuid(), right? [11:41] pitti: rsyslog calls doDropPrivGid then doDropPrivUid [11:41] the patch looks like initgroups() would come after set[ug]id? [11:41] ah, so these two hunks are not from one functino [11:41] pitti: doDropPrivGid already calls setgroups before setgid to discard the previously-held supplementary groups [11:41] pitti: they are [11:42] cjwatson: ack; LGTM then, thank you! [11:42] pitti: the important bit is that you have to drop the old groups before you lose the ability to do so [11:42] cjwatson: but this is still missing a chgrp syslog /var/log, isn't it? [11:42] pitti: I think initgroups is fine after setuid [11:42] pitti: oh yes good point [11:42] 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] I think you can gain your own supplementary groups ... but wait, something just occurred to me [11:43] cjwatson: (and chmod 775) [11:43] /var/log must not be owned by group adm [11:43] because if we do that then users in group adm will be able to add files to it [11:43] which is not expected [11:43] no, adm group members must nto be able to write there [11:43] that's why I thought root:syslog would be better [11:44] oh, right, yeah, too many pieces [11:44] 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] http://paste.ubuntu.com/6519302/ then [11:46] cjwatson: chmod g+w /var/log ? [11:47] added === psivaa-afk is now known as psivaa [11:50] pitti: hm, you were right earlier, setgroups (called by initgroups) requires the CAP_SETGID capability [11:50] so I'll move that before the setuid [11:51] ok, that's relieving (would be weird otherwise) [12:17] 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] pitti: does it? I thought I had fixed that. Let me check [12:17] * pitti tries the current trusty package [12:18] pitti: 6.20.155.1+bdcom-0ubuntu0.0.2 should fix that (precise-updates) [12:23] tseliot: ah, that's not yet on the 12.04.3 image [12:23] tseliot: I installed the trusty pacakge, that works [12:23] pitti: ok, let me know if there's anything I can do to help [12:23] tseliot: if you already fixed it, that's fine; it'll be in 12.04.4 [12:24] pitti: good :) === iahmad is now known as iahmad|afk [12:42] pitti: OK, so after some fixups this basically works, but there's an amusing complication [12:42] pitti: On upgrade, we restart rsyslog in postinst rather than stop in prerm / start in postinst, for generally obvious reasons [12:43] 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] 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] can anyone confirm that the software-center crashes after launch (trusty)? [12:53]