[00:01] <jderose> slangasek: ubuntu was carrying many cherry picked patches, plus a few things that were specific to the U1 couchdb sync, AFAIK. so there was a big delta both from debian and from upstream couchdb
[00:01] <slangasek> and the U1 couchdb sync is now obsolete, or implemented upstream in a different way?
[00:02] <slangasek> (I know the U1 packages in Ubuntu no longer use couchdb, but I'm not sure if that makes this code entirely obsolete)
[00:02] <jderose> obsolete, they turned it off
=== dendrobates is now known as dendro-afk
=== highvoltage is now known as jocarter
[00:30] <slangasek> jderose: you've dropped debian/couchdb-bin.dirs, which creates the directory /etc/couchdb/local.d - why is this no longer needed?
[00:30] <jderose> hmm
[00:31] <slangasek> oh, moved to the couchdb package instead, ok
[00:31] <jderose> ah, yeah
[00:38] <jderose> slangasek: dpkg -L couchdb-bin - http://paste.ubuntu.com/1120544/
[00:39] <slangasek> jderose: what's the reason for making /etc/couchdb owned by root instead of by couchdb?  That's certainly the usual way of doing things, but /someone/ thought it was a good idea to have it owned by couchdb in the first place, so I'd like to be sure we understand the original reasoning
[00:39] <jderose> and dpgk -L couchdb - http://paste.ubuntu.com/1120546/
[00:40] <slangasek> indeed, the Debian package is *still* calling 'chown -R couchdb /etc/couchdb'
[00:40] <jderose> slangasek: hm, you sure about that? in one of the postinst?
[00:40] <slangasek> in Debian, couchdb/postinst calls 'chown -R couchdb:couchdb /etc/couchdb'
[00:41] <slangasek> couchdb 1.2.0-2
[00:41] <jderose> so the /etc/couchdb/default.ini file is needed for per-user couchdb, and shouldn't be changed by the couchdb daemon
[00:41] <jderose> and i didn't want to require the couchdb user to be created for the couchdb-bin package... a wanted to package it as a very clean library, so to speak
[00:41] <slangasek> ok
[00:42] <slangasek> I think that's a reasonable goal, but I'd rather see the Debian package fixed first to not be chowning /etc/couchdb
[00:43] <slangasek> hmm, no, on second thought, let's go with it
[00:43] <jderose> slangasek: so in my package, i just change the ownership on /etc/couchdb/local.ini, local.d - http://bazaar.launchpad.net/~jderose/ubuntu/quantal/couchdb/1.2.0-low-delta/view/head:/debian/couchdb.postinst
[00:43]  * slangasek nods
[00:44] <jderose> slangasek: much thanks... sorry... i know this was a bear to review :)
[00:48] <slangasek> jderose: what tells the couchdb package to use /etc/couchdb/local.ini?
[00:49] <jderose> slangasek: this is hardcoded into the /usr/bin/couchdb script, it's one of the default config files to look at
[00:49] <slangasek> ok
[00:49] <jderose> per user couchdb overrides this (destkopcouch does this, we do it too)
[00:51] <slangasek> jderose: the previous Ubuntu package used a /var/lib/couchdb/$version directory, the new one doesn't?
[00:51] <slangasek> ah no, that's also shipped in the package - ok
[00:51] <jderose> root@jgd-ws:~# ls /var/lib/couchdb/
[00:51] <jderose> 1.2.0
[00:52] <jderose> :)
[00:55] <slangasek> jderose: couchdb.postrm: /etc/couchdb/local.ini is a conffile, so you don't need to rm it
[00:56] <jderose> slangasek: no even when you purge? that was in the debian package, btw, so that's why i left it in there
[00:56] <jderose> *not* even when...
[00:57] <slangasek> the Debian package has 'rm -rf /etc/couchdb'
[00:57] <slangasek> which is different :)
[00:57] <jderose> ah, gocha
[00:57] <slangasek> for a conffile, dpkg takes care of the removal for you on purge
[00:57] <jderose> slangasek: so you want me to remove that first then?
[00:57] <jderose> okay
[00:57] <slangasek> I'm fixing it up here, just letting you know
[00:57] <jderose> remove the rm, that is :)
[00:57] <jderose> okay
[01:03] <simplew> when it will be possible to have video working in ubuntu precise? https://bugs.launchpad.net/pidgin/+bug/971867
[01:03] <ubottu> Launchpad bug 971867 in pidgin (Ubuntu) "No voice call or video call possible, due to recent farsight->farstream transition" [Undecided,Confirmed]
=== fuleo is now known as fuleo-work
[01:12] <slangasek> jderose: sleep 3> I'm including this change for now, but the right fix is to make the init script actually synchronous... or maybe to replace it with an upstart job which is guaranteed to be synchronous by nature
[01:14] <jderose> slangasek: yeah, i looked into this some, and it will require changing some pretty deep things in couchdb, from what i can tell. it's because of some issues with how erlang works
[01:15] <slangasek> well, an upstart job would be fairly easy :)
[01:16] <slangasek> since upstart provides real process supervision, and therefore can make sure the service has actually died before returning
[01:16] <jderose> slangasek: hmm, that would be awesome... i'm upstart dumb though :)
[01:18] <RAOF> It's surprisingly easy to upstartify something.
[01:19] <jderose> RAOF: any good tutorials? or what are good example packages to look at?
[01:19] <slangasek> in this case I suppose you'd need a 'pre-stop exec couchdb -d'... and probably some special signal handling
[01:19] <RAOF> Partially because it's an actual *init system*, rather than a pile of raw shell.
[01:19] <jderose> hehe :)
[01:20] <RAOF> jderose: The upstart cookbook's pretty good http://upstart.ubuntu.com/cookbook/
[01:22] <RAOF> But I'd just start with a random member of /etc/init/*.conf; all the ones I've looked at have been reasonably obvious what they're doing.
[01:22] <jderose> okay, cool
[01:23] <RAOF> It is *much* easier to write an upstart job than a sys-v init job.
[01:25] <scientes> or a systemd unit for that matter ;)
[01:26] <RAOF> I've not tried to write a systemd unit; is it really harder than an upstart job? I've thought they'd be of comparable difficulty.
[01:27] <scientes> oh i meant systemd units are easy to write
[01:27] <scientes> i've never succeeded at understanding what upstart actually does
[01:30] <RAOF> It's pretty easy; you stick your start conditions into "start on", your stop conditions into "stop on" and then "exec $YOUR_DAEMON", plus possibly some options to tell upstart what to expect the daemon to do (fork, fork twice, etc).
[01:32] <slangasek> jderose: have you seen this lintian warning?:
[01:32] <slangasek> W: couchdb-bin: init.d-script-not-marked-as-conffile etc/init.d/couchdb-bin
[01:32] <jderose> slangasek: hmm, no, i haven't... i don't think that shows up when i build on precise...
[01:32] <slangasek> hmm
[01:34] <slangasek> well, it's not actually in the package at all, so I wonder where it's getting that idea
[01:34] <slangasek> ah, because I broke something in debian/rules
[01:34] <jderose> ah, couchdb-bin.... weird
[01:35] <jderose> slangasek: that's what you get for merging :P
[01:35] <slangasek> nah, it was my own doing ;)
=== nigelb is now known as nigel-cloud
[01:41] <smoser> slangasek, cloud-init start-networking ... i have ot think about that.
[01:41] <smoser> it was done at SpamapS's suggestion, i know that
[01:41] <slangasek> hmm
[01:42] <smoser> (mainly, i certainly couldn't have made such an error)
[01:42] <smoser> :)
[01:42] <slangasek> SpamapS: ^^ why are you breaking everything! :)
[01:43] <smoser> i believe it was to protect from a race condition
[01:43] <slangasek> ironic
[01:50] <jderose> slangasek: so that libav fix was just pushed to quantal-proposed so far, right? could you back this change out, cancel it for now? there is more digging i need to do
[01:50] <jderose>  in working on a test case, i just discovered that this bug doesn't occur when i remove gstreamer0.10-plugins-bad... only when it's installed. so although there is an issue in libav, there is something more subtle going on from gstreamer, so i'd like to dig deeper into this before this hits quantal
[01:50] <slangasek> jderose: it's been pushed to quantal, and to precise-proposed where it sits in the queue
[01:51] <slangasek> do you think it's critical to back it out of quantal?
[01:51] <smoser> well, slangasek a bit more info
[01:51] <smoser> http://paste.ubuntu.com/1120635/
[01:51] <jderose> slangasek: probably not... but there is also another part to it the mans linked to in the comments
[01:52] <jderose> but i don't think it should go into precise yet, that's for sure.... there is more weirdness yet to track down :)
[01:53] <jderose> but there is also another part to it *that* mans linked to in the comments
[01:53] <slangasek> smoser: ok, that looks like a wrong workaround for bug #925122
[01:53] <ubottu> Launchpad bug 925122 in udev (Ubuntu) "container's udevadm trigger --add affects the host" [Medium,Fix released] https://launchpad.net/bugs/925122
[01:53] <slangasek> smoser: (or related bug)
[01:54] <smoser> yeah, i supsected it was probably fied elsewhere.
[01:54] <jocarter> jono: comments on your blog don't seem to work
[01:57] <jono> jocarter, oh really?
[01:57] <jono> let me check
[01:57] <jono> jocarter, it looks fine to me, what is the problem?
[01:58] <smoser> slangasek, thanks. stgraber thakn you for your help today too.
[02:06] <jocarter> jono: all of the disqus stuff is just gone, maybe it's ad blocked or something (checking...)
[02:07] <jocarter> jono: ah, it's back noe
=== nigelbabu is now known as nigelb
[02:12] <jono> jocarter, oh cool :-)
[02:23] <jderose> slangasek: anything else you need from me on the couchdb package?
=== beuno_ is now known as beuno
[03:16] <slangasek> jderose: nope - I just needed to build it with the right options to get accepted into the archiev
[03:16] <slangasek> doko_: have you seen https://code.launchpad.net/~james-page/ubuntu/quantal/icedtea-web/java7-transition/+merge/113959 ?  Should it be uploaded, or do you want to review it yourself?
[03:17] <jderose> slangasek: i'll run all my unit tests against that package after it builds, let you know if i find anything. thanks again!
[03:17] <slangasek> no prob - thanks for taking care of the package :)
=== smb` is now known as smb
=== amitk is now known as amitk-lunch
[07:37] <slangasek> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[07:38] <apw> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: apw
[07:39] <jodh> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jodh, apw
[07:39] <bkerensa> mm
=== amitk-lunch is now known as amitk
[09:13] <seb128> does anyone know if there are plans to change from gnutls26 to 28 this cycle?
=== mcclurmc_away is now known as mcclurmc
=== arand_ is now known as arand
=== mcclurmc is now known as mcclurmc_away
=== cpg is now known as cpg|away
=== doko_ is now known as doko
=== mcclurmc_away is now known as mcclurmc
[12:16] <apw> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jodh
=== _salem is now known as salem_
=== rsalveti` is now known as rsalveti
[12:38] <jodh> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[12:44] <zul> can an archive admin please review python-django-compressor, python-django-appconf, and python-warlock it will make horizon installable again (and ill buy them a beer when I see them next)
[12:44] <zul> and they have been sitting in binary-new for a while now
=== dendro-afk is now known as dendrobates
[13:27] <jibel> stgraber, cyphermox pete updated his machine yesterday running quantal and he has lost network since then
[13:27] <cyphermox> huh oh
[13:27] <jibel> network-manager was in the list of packages upgraded
[13:27] <cyphermox> jibel; would still need to see syslog somehow to know what's going on
[13:28] <sconklin> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin
[13:29] <jibel> cyphermox, ack, I'll file a bug with the logs, apparently the dnsserver is set to localhost and it doesn't work, on my machine it is set to a dns ip and it works
[13:29] <cyphermox> it should always be set to 127.0.0.1; but that needs dnsmasq to start.
[13:30] <jibel> cyphermox, there are 2 problems then :)
[13:30] <cyphermox> no
[13:32] <cyphermox> ah, I'm an idiot
[13:35] <jibel> cyphermox, bug 1031350
[13:35] <ubottu> Launchpad bug 1031350 in network-manager (Ubuntu) "[quantal] no network resolution after latest upgrade of network-manager" [Undecided,New] https://launchpad.net/bugs/1031350
[13:35] <cyphermox> thanks
=== dendrobates is now known as dendro-afk
[13:39] <cyphermox> jibel; how come does dnsmasq doesn't start on your system and you get the dns data in syslog? could you share your own syslog too?
[13:40] <stgraber> cyphermox: wouldn't that happen if dnsmasq is simply disabled in /etc/NetworkManager/NetworkManager.conf? (just guessing)
[13:40] <cyphermox> yes, that's what I want to make sure
[13:40] <cyphermox> but in pete's case dnsmasq fails to start; NM should handle it gracefully and set dns in resolvconf anyway
[13:42] <jibel> cyphermox, I attached my syslog
[13:44] <cyphermox> jibel: exactly, your syslog shows the failover being done properly.
[13:45] <cyphermox> it's for the same network... I wonder what else might be different to make one fail and not the other
[14:00] <SpamapS> slangasek: what did I do? (re "breaking everything" and I think cloud-init)
[14:00] <SpamapS> smoser: ^^ maybe you know?
[14:00] <smoser> http://paste.ubuntu.com/1120635/
[14:01] <smoser> SpamapS,  that was the fix we put in because cloud-init wasn't working inside containers (because the NIC was already up wehn init started)
[14:03] <smoser> per slangasek "that looks like a wrong workaround for bug #925122"
[14:03] <ubottu> Launchpad bug 925122 in udev (Ubuntu) "container's udevadm trigger --add affects the host" [Medium,Fix released] https://launchpad.net/bugs/925122
[14:03] <cyphermox> jibel: fix is building right now; but for a quick fix you can see if pgraner has a file /run/resolvconf/interfaces/lo.dnsmasq; if that's there, it should be removed (and then you can click the connection in NM again to reset it)
[14:03] <smoser> SpamapS, i'd have to dig some more and test, but if our fix is no longer necessary even in precise, then i'td be nice to get that update too.
[14:04] <cyphermox> a reboot would fix it too.
[14:15] <SpamapS> smoser: ok cool, I will standby then unless you think there's something I need to look at directly.
[14:15] <smoser> nah. but I *hope* this means we can just ditch those two lines and still be happy in lxc.
[14:34] <bluefoxxx> what language is dpkg primarily written in?
[14:34] <cjwatson> bluefoxxx: C for the core, Perl for developer scripts
[14:35] <bluefoxxx> ah.  Difficult, but not terrible.  I like C.
[14:35] <jpds> bluefoxxx: https://www.ohloh.net/p/dpkg
[14:35] <bluefoxxx> (I question its use for tihs particular application, but that's a daunting discussion)
[14:36] <bluefoxxx> The next question:  is it more appropriate for a restricted .deb format to keep the .deb--as have various changes such as lzma2 compression etc--or to get a different format, like .sdeb?
[14:38] <cjwatson> .deb already supports different compression formats
[14:38] <bluefoxxx> I have been hypothesizing a deb installation mechanism by which the pre-install and post-install and the entire installation process are carried out under a non-privileged account, with sandboxing, procedurally restricting actions to (say) bash scripts (possibly with a restricted interpreter)
[14:38] <cjwatson> we use different extensions for cases where the format is compatible but the policy is very substantially different
[14:39] <bluefoxxx> the ideal situation is one such that you can guarantee exactly one of two things:
[14:39] <cjwatson> I think for that extremely long-term project the extension is the least of your concerns ... :-)
[14:39] <bluefoxxx> A)  Everything that happens during installation is known and accountable
[14:39] <bluefoxxx> B)  Anything that happens during installation that could break (A) can be spotted ahead of time (just in time, even), halted, and warned about before it happens
[14:39]  * cjwatson heads off to try to get home adsl working again
[14:39] <jbicha> stgraber: would you be interested in sponsoring ubuntu-docs for me?
[14:40] <bluefoxxx> hm
[14:40] <ScottK> jbicha: dpm already hunted him down on -release.
[14:40] <stgraber> jbicha: waiting for a test build to complete
[14:40] <jbicha> oh cool, thanks!
[14:40] <dpm> hey jbicha :)
[14:40] <bluefoxxx> well my concern is that the behavioral policy of a debian package in such a situation would be SUBSTANTIALLY different
[14:40] <dpm> thanks for taking care of the ubuntu-docs upload
[14:41] <bluefoxxx> to the point that running a normal .deb under it may break
[14:41] <bluefoxxx> (though, it may also work quite well)
[14:42] <bluefoxxx> on the other hand, I want to get away from the situation where the pre-inst script is run as root and can i.e. silently modify the kernel image, setuid binaries, etc without informing the package manager of what it's up to
[14:42] <bluefoxxx> mostly dpkg and rpm seem to accept that "if you install it, you assume the risk"
[14:44] <bluefoxxx> which I can understand, but I'd like to not assume the position outright.
[14:49] <stgraber> jbicha: https://launchpadlibrarian.net/111550998/buildlog_ubuntu-precise-i386.ubuntu-docs_12.04.6_FAILEDTOBUILD.txt.gz
[14:49] <stgraber> jbicha: have fun ;)
[14:50] <stgraber> (the quantal one is still running, not sure if it'll be affected too)
[14:50] <jbicha> stgraber: it should build on quantal as those errors are ignored now
[14:51] <stgraber> jbicha: right, quantal worked fine. I'll upload that one for now then, let me know when precise is fixed.
[14:58] <dpm> jbicha, do you think you'd have time to get it to build for precise some time today? This way I could start building the language packs tomorrow, which should be ready by the 2nd Aug
[14:59] <jbicha> dpm: yes, but I don't think I'll get to it for a few more hours
[15:00] <dpm> jbicha, that's cool. Could you then follow-up with stgraber to sponsor the upload and with someone from the SRU team to get it to -proposed?
[15:01] <jbicha> yes
[15:01] <Sweetshark> doko: ping?
[15:01] <dpm> excellent, thanks jbicha!
[15:05] <Sweetshark> doko: it seems our (ubuntu/debian) gcc automagically makes paths relative in dependency files thus breaking nontrivial build systems (where make is called from different dirs). Is this intentional? it does not seem to happen on fedora at least ...
[15:07] <xnox> Sweetshark: bug # or example?
[15:13] <Sweetshark> xnox: well, a libreoffice build: the dep files generated by g++ contain a lot of paths like ../solver/... while the include paths passed to gcc are absolute.
[15:14] <doko> Sweetshark, I'm not aware of any patch that would do that
[15:14] <Sweetshark> xnox: I just tried to reproduce that with a minimal example, but that seemed fine. strange. I need to dig out what triggers it ...
[15:14] <Sweetshark> doko: thanks.
[15:15] <Sweetshark> hohum ...
[15:15]  * Sweetshark has an evil suspision: ccache!
[15:16] <xnox> ccache is indeed evil ;-)
[15:23] <mcclurmc> i have a package which needs a different patch applied to the upstream source depending on whether the package is being built for Ubuntu or Debian
[15:24] <mcclurmc> the other day, micahg recommended to me the method of having multiple series files (DEBIAN.series and UBUNTU.series)
[15:24] <mcclurmc> i just pushed a source package to a ppa, but launchpad didn't apply the correct series file
[15:25] <mcclurmc> is there something else I need to do to make this work?
[15:26] <tumbleweed> mcclurmc: it should be series.ubuntu and series.debian IIRC
[15:28] <mcclurmc> tumbleweed: does case matter?
[15:28] <tumbleweed> probably
[15:28] <tumbleweed> it tends to in unix
[15:30] <mcclurmc> tumbleweed: ha, yes. i meant to ask, do i need upper or lower case on the vendor? this blog uses upper case: http://raphaelhertzog.com/2010/11/05/managing-distribution-specific-patches-with-a-common-source-package/
[15:30] <tumbleweed> oh, no it is ubuntu.series
[15:31] <mcclurmc> tumbleweed: great, thanks
[15:31] <tumbleweed> I don't see upper-case there
[15:31] <tumbleweed> anyway, this is covered in a comment near the bottom http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/#comment-3673
[15:35] <mcclurmc> hmm, where did i get the idea it was in caps? oh well, thanks for setting me straight
=== dendro-afk is now known as dendrobates
=== Ursinha` is now known as Ursinha
=== beuno is now known as beuno-lunch
=== beuno-lunch is now known as beuno
=== babyface_ is now known as baby_face
=== baby_face is now known as babyface_
=== mcclurmc is now known as mcclurmc_away
[17:27] <infinity> TheMuso: Does anyone plan to actually maintain linux-lowlatency in precise?  It's never been rebased to keep in line with master SRUs since release.
[18:02] <dobey> infinity: is there any way to just get it built from the main kernel builds? it seems to only change a couple of config options, and it would be nice to have it automatically kept in line with security fixes and such
[18:02] <infinity> dobey: It adds a patch that can't reconcile with master.
[18:02] <infinity> dobey: If someone changed that to a twiddlable config option, that would go a long way.
[18:03] <micahg> infinity: that's done in quantal AIUI
[18:03] <micahg> but it might be limited to a newer kernel
[18:04] <apw> i believe we are carrying the patch still in effect, as its still separate
[18:04] <apw> but the reality is its a simple job to rebase it and upload it, the hard part is making sure
[18:04] <apw> it gets the testing it needs to get released.
[18:04] <apw> i can show anyone on the studio team how to get their kernel up to date
[18:04] <infinity> micahg: Yeah, it's still a conflicting patch in quantal.  Just easier to rebase, see Andy.
[18:05] <apw> there is little point in repeatedly uploading kernles to just languish in -proposed
[18:05] <micahg> apw: well, it needs to be uploaded by either the kernel team (through your special repo) or the security team (when security relevant)
[18:06] <micahg> sorry, if security relevant and not going through the kernel team
[18:06] <infinity> micahg: Neither of those is true.
[18:06] <apw> micahg, not really we don't support it for security anyhow, so just uploading it to -proposed and it'll get there
[18:06] <infinity> micahg: You or I could upload it right now.
[18:06] <apw> people on non-supported things cannot expect to get -security can they ?
[18:06] <micahg> infinity: yes, I know, the point is, are kernels not built against -security only when pushed there?
[18:07] <micahg> apw: sure they can, they have to supply a debdiff
[18:08] <micahg> IMHO, the most compelling reason to update lowlatency is for security patches
[18:08] <apw> micahg, what i mean is if the security team is not supporting the package they cannot expect to add only -security pocket to their system and expect it to mean anything
[18:08] <micahg> apw: why not?
[18:09] <micahg> they only want security fixes, not random updates from the archive
[18:10] <apw> but we arn't doing security fixes for that kernel, its not supported
[18:10] <micahg> apw: right, but wouldn't they get them for free from a rebase?
[18:11] <apw> yes if the kernel is updated to match the tip of our tree it would get security because our master tree has them in
[18:11] <apw> but that wouldn't get them into -security
[18:12] <micahg> apw: I think we could ask the ubuntustudio people to test the kernel and sign off on the update
[18:12] <apw> and if they don't sign off on it who is going to do the work then
[18:13] <micahg> apw: that's their problem, it's seeded for them alone, it's their responsibility
[18:14] <apw> micahg, in which case they can do the rebase and upload it, or not as they see fit ?
[18:16] <micahg> apw: well, if it's easy enough for the kernel team to do the initial upload, I'm sure they'd appreciate it, otherwise, yes (and in cases of security relevant updates, pass a debdiff/signed package to the security team for sponsorship)
[18:17] <apw> micahg, i'll take it offline with scott and see what we can come up with
[18:17] <micahg> apw: sounds good, thanks
[18:32] <toabctl> jbicha, is there a reason why seahorse has still version 3.4?
=== cpg|away is now known as cpg
[18:34] <jbicha> toabctl: it's packaged, it's just waiting on bug 1030335
[18:34] <ubottu> Launchpad bug 1030335 in libsecret (Ubuntu) "[MIR] libsecret" [Wishlist,Triaged] https://launchpad.net/bugs/1030335
[18:35] <bdrung> BenC: i saw that you did the last uploads of ghc. do you know when 7.4.2 will hit quantal?
[18:37] <toabctl> jbicha, so lp:~ubuntu-desktop/seahorse/ubuntu is no longer in use for seahorse?
[18:38] <BenC> bdrung: No idea. I was told "any day" a week or two ago
[18:38] <BenC> bdrung: I don't normally handle it, I was just fixing ppc
[18:39] <bdrung> BenC: k, then i have to wait for Laney come back
[18:41] <jbicha> toabctl: except for having a newer version we're in sync with Debian so I don't know if we'll use the desktop branch or not
[18:41] <toabctl> jbicha, ok. thx
[19:06] <pgraner> Rush 2112
=== cpg is now known as cpg|away
=== hrww is now known as hrw
=== cpg|away is now known as cpg
=== cpg is now known as cpg|away
=== panda is now known as Guest28076
[21:19] <dobey> "missing-build-dependency-for-dh-addon python2 => python | python-all | python-dev | python-all-dev" <- why would this show up in lint, when python (>= 2.6.6-3) is in the Build-Depends?
[21:21] <micahg> dobey: do you actually have python >= 2.6.6-3
[21:22] <dobey> micahg: i would hope python 2.7 is newer than that, yes :)
[21:22] <ScottK> dobey: Separate issue.
[21:22] <ScottK> python and python2.7 are different packages.
[21:22] <ScottK> You need python >= 2.6.6-3
[21:23] <dobey> yes, and precise only has 2.7, so the python package is 2.7.3, and yes it is installed
[21:24] <ScottK> Right, but you still need to specify the minimum build-dep
[21:25] <dobey> eh? my question ended with "when that is listed in Build-Depends" :)
[21:25] <micahg> dobey: can you pastebin the whole build depends?
[21:25] <dobey>  python (>= 2.6.6-3~) | python-support (>= 0.6.4),
[21:25] <tumbleweed> well, there's your problem
[21:26] <micahg> hrm, no, that should be enough..
[21:26] <tumbleweed> unless python-support is installed
[21:26] <micahg> unless the lintian check is broke
[21:27] <ScottK> Is this lintian or lintian4python?
[21:27] <dobey> lint check from debuild -S
[21:27] <tumbleweed> lintian should really complain about the use of alternative build-depends at all
[21:28] <micahg> well, Debian ignored them, right? :)
[21:28] <micahg> *ignores
[21:28] <tumbleweed> AFAIK, yes
[21:28] <slangasek> why should it complain?
[21:29] <slangasek> they're a long-permitted technique
[21:29] <dobey> well i have another package with the same build-depends that doesn't show that lint error
[21:29] <tumbleweed> permitted, but not encouraged
[21:30] <slangasek> I don't know what you mean by encouraged
[21:30] <slangasek> it was never *dis*couraged
[21:31] <dobey> well, if i didn't have a need to make it as easy as possible to build the latest version of the stuff i'm maintaining, on all supported versions of ubuntu, i'd be happy to just drop the | python-support from it. but yay, lucid.
[21:32] <dobey> i guess i'll just ignore it for now
[21:32] <slangasek> +1
=== salem_ is now known as _salem
[21:36]  * micahg is glad someone reads lintian output
[21:45] <sconklin> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[21:47] <Bluefoxicy> お＿お
[21:47] <Bluefoxicy> ... uh.
[21:48] <Bluefoxicy> so the next version of Ubuntu is Quantum Quezacotl or sommat?
[21:49] <Bluefoxicy> Then Temporal Tezcatlipoca?
[21:56] <slangasek> you're thinking of Handsome Huitlacoche
=== dendrobates is now known as dendro-afk
=== cpg|away is now known as cpg