[00:13] <SpamapS> hrm.. python experts of ubuntu fame.. where is all the missing time going: http://paste.ubuntu.com/680217/
[00:36]  * hallyn curses whoever decided it was ok to overwrite power setting on a package upgrade so as to enable suspend (aka unclean reboot) after 30 idle mins
[00:45] <TheMuso> Hrm. Dealing with source format 3 packages with patches in packaging branches is somewhat painful.
[00:45] <TheMuso> Seems that 1) the .pc dir is included with the merge, and 2) some of the files that are meant to be in the .pc dir to point to debian/patches are not getting included.
[00:46] <SpamapS> TheMuso: indeed, the two things seem to conflict constantly. If you keep the patches unapplied in the branch, its simpler (but then you don't see patched files in the branch.. which can have its own barrel of worms)
[00:46] <micahg> TheMuso: there's an option to not include patches applied in the .pc dir
[00:47] <TheMuso> SpamapS: Yeah. Just working on a fix from a contributor, and had to do it the conventional way, just to keep my sanity.
[00:47] <TheMuso> micahg: There is?
[00:47] <TheMuso> In packaging branches?
[00:47] <micahg> TheMuso: pure packaging or UDD branches?
[00:47] <TheMuso> micahg: pure packaging.
[00:47] <TheMuso> Sorry, distributed development
[00:47] <TheMuso> so udd
[00:48] <micahg> well, either way actually, there was some discussion a while back on debian-devel I think, it's part of source format 3
[00:48] <micahg> or wait, maybe it's a debhelper option
[00:48] <micahg> I know there's some way to do it...
[00:49] <TheMuso> micahg: Well whatever it is, I think we need it for udd branches.
[00:49] <TheMuso> So we don't have to deal with the mess of .pc contents.
[00:50]  * micahg wonders if that's git only...
[00:50] <micahg> TheMuso: http://raphaelhertzog.com/2010/11/18/4-tips-to-maintain-a-3-0-quilt-debian-source-package-in-a-vcs/
[00:50] <micahg> option 2
[00:51] <TheMuso> micahg: Right we need that for UDD>
[00:51] <TheMuso> But its somewhat different, because when you branch a UDD branch, it has the .pc directory in it.
[00:52] <TheMuso> tahts my point.,
[00:56] <ion> Too bad that doesn’t mention git-dpm. It’s really nice.
[00:57] <ion> Oh, it does mention it. :-)
[01:03] <slangasek> hallyn: dunno what caused the behavior change, but this seems to have fixed it for me: gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
[01:22] <smoser> slangasek, or SpamapS you west coasters, if you'd like to review https://code.launchpad.net/~smoser/ubuntu/oneiric/ifupdown/lp838968/+merge/73741
[01:22] <smoser> i just uploaded the cloud-init portion
[01:25] <smoser> it results in something like:
[01:25] <smoser> http://paste.ubuntu.com/680239/
[01:54] <hallyn> slangasek: thanks, i'll have to look into that.  (i did meta-a and picked 'power' which brought up the powe rsettings, and picked nothing there.  but prefer a cmdline)
[01:56] <hallyn> soren: hi, regarding the libvirt not starting VMs bc it couldn't create a cgroup this morning - if you still have a box you can test this on, could you try the package from http://people.canonical.com/~serge/libcgroup-fix-libvirt
[01:56] <hallyn> if that works, i'll commit that for bug 828061
[02:15] <hallyn> smoser: ^ you also might be good tester?
[03:01] <TheMuso> @pilot out
[04:09] <slangasek> ScottK: you said you could reproduce Debian bug #633461 - I can't, with the current python2.7 in experimental
[04:09] <slangasek> ScottK: is this really still an issue?
[04:10] <ScottK> It is, but as long as we remember to binNMU it after 2.7 is default it will go away.
[04:10] <ScottK> Since 2.7 is the last python, I think that's an adequate solution.
[04:14] <slangasek> ScottK: hmm; how/why is it an issue?  (given that I can't reproduce it)
[04:19] <pitti> Good morning
[04:21] <ion> that.
[04:30] <ScottK> slangasek: I don't recall.  Heading to bed now, I'll see if I can remember to try it again tomorrow.
[04:30] <slangasek> ScottK: ok, 'night
[05:27] <micahg> pitti: or slangasek could I get one of you to please copy thunderbird lucid from ubuntu-mozilla-security to lucid-security?
[05:32]  * micahg wonders if any other archive admins are available
[05:34] <pitti> micahg: doing
[05:34] <micahg> pitti: thanks
[05:36] <pitti> micahg: done
[05:36] <micahg> pitti: thanks!
[05:37] <didrocks> good morning
[06:45] <doko_> pitti, is the libindicate build failure on powerpc transient?
[06:47] <pitti> doko_: very well possible, the new gobject-introspection was lagging behind yesterday
[06:48] <pitti> doko_: retried
[06:48] <pitti> if it fails again, I'll investigate
[07:26] <dholbach> good morning
[07:28] <pitti> yay, libo built on powerpc
[07:28] <pitti> Sweetshark: ^ nice!
[07:28] <pitti> hey dholbach
[07:31] <htorque> RAOF: killed X on intel
[07:31] <htorque> oops, wrong channel, sorry
[07:34] <dholbach> hey pitti
[08:17] <soren> pitti: I just noticed a bunch of you guys just expired from the techboard, but I don't recall any mention of an election during your meetings?
[08:20] <doko_> pitti, libindice still ftbfs on powerpc
[08:20] <geser> huh, we have no TB anymore?
[08:24] <pitti> yeah, we mentioned it to sabdfl, he needs to re-new our membership for about four weeks
[08:24] <pitti> elections will be held soon
[08:24] <pitti> doko_: ah, ok; I'll tell Ken
[08:26] <soren> pitti: Ok, cool. I really just wanted to make sure I hadn't missed it. :)
[09:49] <jml> kirkland: v92 works. Thanks!
[10:09] <hrw> shit. quilt/oneiric works different then quilt/lucid ;(
[10:09] <hrw> gcc-4.[56]/oneiric fails to patch on lucid
[10:13] <pitti> ev: FYI, I landed pygobject 2.90 in oneiric yesterday, this breaks ubiquity; I have a branch which fixes most of it, but this afternoon I'll go through the whole installation to check for more breakage; you should have a merge proposal from me by Monday
[10:13] <ogra_> hmm, no mvo ...
[10:14] <pitti> ogra_: holidays
[10:14] <ogra_> update-manager refuses to upgrade here, complaining it cant find a -meta
[10:14] <ogra_> but ubuntu-desktop is installed
[10:23] <anthony_dev> hi guys. I got a problem and I think its a bug of Libre Office. where I should post info about this?
[10:28] <ion> anthony_dev: Run ubuntu-bug /usr/bin/libreoffice
[10:29] <anthony_dev> ion thanks, I'll try it later at home. at work I have Windows.
[10:32] <hrw> ok, found
[10:43] <hrw> doko_: gcc-4.[45]/debian/patches/gcc-multilib64 patch does not apply under non-multiarch systems
[10:49] <hrw> doko_: gcc-multiarch.diff is applied always - so looks like gcc-multilib64-multiarch should also be applied always
[11:24] <bambee> hello, these days on oneiric, I've strange problems with my mouse. Sometimes the mouse freezes completely (the keyboard works and the system too), a workaround is to unplug/replug the mouse, and then it works again
[11:24] <ion> Anything interesting in the X log or syslog?
[11:31] <bambee> My X log : http://paste.ubuntu.com/680481/
[11:32] <ion> At the point of the mouse disappearing, that is.
[12:09] <doko> pitti, bryce_ bryceh, cjwatson: is there a reason that xcb-util-renderutil is not in oneiric? and if yes, what is the replacement for it?
[12:14] <doko> hmm, still in libxcb-util0-dev ?
[12:22] <doko> didrocks, pitti: uploaded unity to fix the b-d on libxcb-icccm4-dev, but I get a bzr error to check in the change. could you check in the change?
[12:24] <didrocks> doko: did you push it to the vcs? I don't find your change
[12:24] <doko> didrocks, did you read my message???
[12:24] <didrocks> "check in the change", ok
[12:27] <didrocks> doko: waiting for the diff to generate and then will check it in
[12:27] <doko> thanks!
[12:28] <didrocks> yw :)
[12:31] <bambee> ion: it happens again, I just saved my syslog and my Xorg.log : http://paste.ubuntu.com/680520/, http://paste.ubuntu.com/680522/
[12:32] <doko> didrocks, pitti: feel free to work on bug 839526, if it's not for the dx team
[12:32] <didrocks> cnd: once you are around ^
[12:33] <bambee> ion: perhaps "Sep  2 14:28:45 linux-EX58-UD4P acpid: client 1267[0:0] has disconnected"
[12:44] <doko> and promoted libxcb-icccm4 libxcb-icccm4-dev
[12:52] <cjwatson> doko: xcb-util-* got merged into xcb-util upstream, AFAIK
[13:01] <pitti> ev: I just finished two ubiquity test installs with my pygobject fix branch, they both succeeded now; MP sent: https://code.launchpad.net/~pitti/ubiquity/pygobject-2.90/+merge/73802
[13:02]  * pitti -> back to travel/weekend
[13:03] <smoser> hallyn, is there a reason you'er not using grep -q ? but rather [ -n "`grep ..`" ] ?
[13:08] <hallyn> smoser: nope
[13:10] <smoser> - if [ -n "`grep "/sys/fs/cgroup" /proc/mounts`" ]; then
[13:11] <smoser> + if grep /sys/fs/cgroup /proc/mounts; then
[13:11] <smoser> + if grep -q /sys/fs/cgroup /proc/mounts; then
[13:11] <smoser> obviously not a big deal.
[13:14] <smoser> cjwatson, i'm told you know some tool to check what upload permissions someone (I) have
[13:14] <OdyX> smoser-has-upload-on ?
[13:15] <micahg> smoser: edit_acl.py in lp:ubuntu-archive-tools
[13:15] <cjwatson> what he said
[13:15] <hallyn> smoser: yeah i'm usually more comfortable with 'test' ('[') i guess but i'll make the other change you mentioned, get rid of '.sh' suffix
[13:16] <hallyn> smoser: but if you can verify that it works for you then i can ask someone to push :)
[13:16] <cjwatson> much more efficient to test exit code vs. testing length of string output
[13:17] <hallyn> that way leads to system-d :)
[13:17] <hallyn> not just testing length, also forking off a task to do it
[13:17] <hallyn> (iow - agreed)
[13:17] <smoser> cjwatson, i don tknow about "much" more efficient
[13:18] <smoser> but definitely at least char compare better.
[13:18] <smoser> hallyn, i will test.
[13:18] <cjwatson> well, ok :)
[13:18] <hallyn> \o/
[13:19]  * hallyn takes on some Daviey-isms
[13:19] <kirkland> jml: \o/
[13:19] <kirkland> jml: thanks for ALL of your help
[13:19] <kirkland> jml: that bug had 4 dupes
[13:21] <jml> kirkland: :D
[13:21] <Daviey> hallyn: :o
[13:27]  * Chipzz wonders what's up with .sh/.pl/.py extensions for programs anyway
[13:31] <Chipzz> don't we have shebangs for a reason? and shouldn't wether a program is in perl/python/shell/whatever be an implementation detail the user doens't care about?
[13:36] <OdyX> Chipzz: that's 10.4 of the Debian policy: "(…) scripts (…) in the system PATH (…) should not include an extension (…)"
[13:37] <Chipzz> OdyX: right. but the tool micahg was talking about probably isn't packaged even
[13:38] <OdyX> ah yeah, sorry; I lacked context.
[13:38] <cjwatson> *shrug* not that important.  maybe some day we'll get round to renaming them
[13:41] <Chipzz> cjwatson: I was actually more wondering why ppl do that than complain
[13:42] <Chipzz> it's rather ugly imho
[13:43] <Daviey> edit_acl.py isn't packaged, i just have it symlinked into ~/bin/ .. There are more importiant disasters in the world than fixing unpackaged file extensions :)
[13:43] <Daviey> Chipzz: If you fix that, you will break my symlink, and for that, i will hate you.
[13:43] <Chipzz> Daviey: I don't even remotely have access to that machine :)
[13:44] <Daviey> Chipzz: you do, if i pull a branch where someone 'fixes' it.
[13:46] <doko> Sweetshark, http://people.canonical.com/~ubuntu-archive/NBS/  please look at the libreoffice* packages, and remove these in the OOo build
[13:46] <Chipzz> Daviey: no interest in "fixing" it, like I said, rather more wondering why ppl do it. but I think I'm going to shut up about it, only adding noise to the channel :)
[13:59] <lenios_> sorry if that's not the best place to place, but does anybody know how to disable dh_shlibdeps (looks like it's now default on 11.10) when packaging with pbuilder cdbs?
[14:00] <cjwatson> that's generally a really bad idea
[14:00] <lenios_> i know
[14:00] <cjwatson> and it's been the default forever
[14:00] <cjwatson> why would you want to disable it?
[14:00] <lenios_> i need i386 libs to run a lotus notes on an amd64 system
[14:00] <cjwatson> doesn't look like cdbs offers a way to disable it in general
[14:01] <cjwatson> what's the package you're building?
[14:01] <lenios_> i need to run lotus notes
[14:01] <cjwatson> with 11.10 you should use an i386 version of it with multiarch
[14:01] <lenios_> can't change this one, so i'm trying to package libs and put them in /opt/lib32
[14:02] <cjwatson> better to just build it as a straightforward i386 package
[14:02] <cjwatson> 11.10 supports installing i386 packages on amd64 systems
[14:02] <cjwatson> and hopefully has enough multiarch-capable libraries to support whatever you need
[14:03] <lenios_> i need old libs
[14:03] <cjwatson> you could multiarchify them; http://wiki.debian.org/Multiarch/Implementation
[14:03] <lenios_> for example libeel2-2, which is only in hardy
[14:03] <cjwatson> probably no more difficult than trying to bodge something together with /opt/lib32
[14:04] <cjwatson> in fact I suspect it'd be easier since it's a fairly standard process
[14:09] <lenios_> wait, /usr/lib is going to be /usr/lib/<triplet> for all libs?
[14:09] <lenios_> notes is hardcoding /usr/lib path
[14:11] <lenios_> i hope it can work with LD_LIBRARY_PATH=/usr/lib/i386 like it works with LD_LIBRARY_PATH=/opt/lib32
[14:13] <cjwatson> you shouldn't need LD_LIBRARY_PATH for that
[14:13] <cjwatson> the toolchain already knows about it
[14:13] <lenios_> i'll try
[14:13] <cjwatson> (and it's /usr/lib/i386-linux-gnu/, or /lib/i386-linux-gnu/)
[14:13] <lenios_> oh, i've seen that
[14:43] <SpamapS> smoser: so, re the new behavior of dhclient to have -1 passed.. how do we know when to retry bringing up that interface? I strikes me that this changes the behavior quite fundamentally
[14:43] <SpamapS> smoser: currently, if I 'ifup eth0' .. it will eventually get an IP and find its way to DHCP land.
[14:44] <SpamapS> smoser: but with this change, it won't have that chance.. it will just fail, and I'll have to manually 'ifup eth0' after plugging it in.
[14:45] <smoser> SpamapS, i thought the same, but slangasek said its busted, fix it.
[14:45] <smoser> now, it will try for 60 seconds and then say "yes i did that"
[14:45] <smoser> which i agree is fundamentally broken.
[14:46] <smoser> (if you were not plugged in)
[14:46] <SpamapS> Its also the suck if you have dark network cables that you plug in and let time out..
[14:47] <SpamapS> Not sure why somebody would do that, but as a change in critical behavior, I think we'll need to mention it in the release notes.
[14:58] <doko> o xcb-util-wm: libxcb-ewmh1 libxcb-ewmh1-dev
[14:58] <doko>    [Reverse-Depends: Rescued from xcb-util-wm, libxcb-ewmh1-dev]
[14:59] <doko> kees, are you ok to promote this (no other mir team member here)
[15:11] <kees> doko: promote which? all 3?
[15:11] <doko> kees, right
[15:14] <kees> doko: i will go read there over quickly, one sec
[15:21] <kees> doko: +1 it's pretty small
[15:24] <hallyn> smoser: http://people.canonical.com/~serge/libcgroup-fix-libvirt2 has the fixes you suggested.  D'oh, without credit in the changelog, sorry.
[15:30] <cjwatson> zul: bug 798925 / bug 805656 - how about xenwatch?  is it intrinsically specific to xen 3.3 or would it be straightforward to update to 4?
[15:30] <zul> cjwatson: lemme have a look
[15:31] <smoser> hallyn, if [ -n "`status cgconfig | grep "start/running"`" ]; then
[15:31] <smoser> if status cgconfig | grep -q "start/running"; then
[15:32] <cnd> didrocks, interesting, I'll upload a fix for gesturetest
[15:34] <hallyn> smoser: no
[15:35] <smoser> no?
[15:35] <hallyn> no, bc if it's not running, 'status' will print garbage to stderr
[15:35] <hallyn> and in dash i could find no clean way to get rid of that
[15:36] <hallyn> 2>&/dev/null doesn't seem to work
[15:36] <smoser> 2>/dev/null
[15:37] <hallyn> i think it complainted about that
[15:37] <hallyn> complained even
[15:37] <hallyn> lemme try
[15:37] <cjwatson> 2>/dev/null is portable
[15:37] <hallyn> right, and & means fd :)  so what i typed was wrong in any case
[15:37] <smoser> you need to redirect the first half.
[15:37] <smoser> status cgconfig 2>/dev/null | grep -q "start/running"; then
[15:38] <hallyn> well id on't know why it complained in my euca instance, unless i had a typo there too.  but it works here
[15:38] <hallyn> i'll change that IF you test it successfully :)
[15:39] <hallyn> (and then i can credit you too :)
[15:42] <bambee> bdrung: ping, debuild is totally borked with parallel jobs
[15:43] <bambee> I don't know if it has something to do with your last revision, but it worked just fine before
[15:52] <Laney> bambee: 'borked' doesn't say much.
[15:54] <bambee> Laney: when I try to build a package with "debuild -j8", there is only a single job
[15:54] <bambee> same thing with pbuilder (using a correct .pbuilderrc)
[15:54] <tumbleweed> debuild takes -j options?
[15:55] <tumbleweed> bambee: you are aware of DEB_BUILD_OPTIONS?
[15:55] <bambee> it did... at least few months ago it worked fine
[15:55] <Laney> dpkg-buildpackage does
[15:55] <tumbleweed> oh, neat, I just have it in my bash profile...
[15:55] <bambee> tumbleweed: yes I am
[15:56] <bambee> http://paste.ubuntu.com/680665/
[15:56] <bambee> my pbuilderrc
[15:56] <Laney> try it with just dpkg-buildpackage. it's unlikely to be anything to do with devscripts. (likely the package in question)
[15:56] <tumbleweed> the package should also be following DEB_BUILD_OPTIONS not MAKEFLAGS (according to debian policy)
[15:56] <bambee> Laney: trying
[16:08] <SpamapS> smoser: so, re bug 839595 .. if we're going to raise it above 30 seconds, I'd actually think more like 2 minutes .. the thinking being that there may be complex and slow network configs going on leading up to the minute of DHCP waiting..
[16:08] <smoser> SpamapS, i think that is reasonable.
[16:08] <smoser> one other "benefit" for it being larger
[16:08] <smoser> is that if the user has misconfigured /etc/network/interfaces, they're more likely to know
[16:08] <smoser> and fix it
[16:09] <SpamapS> smoser: I'm still concerned about the fact that we're not going to fork dhclient off to re-try the auto interface's dhcp forever.. maybe we need to start our own daemon to do that.
[16:10] <SpamapS> smoser: yeah I'd love to actually print a plymouth message at 90 seconds saying something like "Boot waiting 30 more seconds for network interfaces to be configured.." so that they see it very clearly.
[16:10] <smoser> SpamapS, cloud-init-nonet does something like that.
[16:10] <smoser> but not a plymouth message
[16:10] <smoser> just an echo.
[16:10] <smoser> sleep 30 , echo a message, sleep some more
[16:13] <jtaylor> is glib2.0 not multiarch coinstallable anymore?
[16:13] <jtaylor> trying to install it will remove half the system since .18
[16:14] <smoser> SpamapS, ^ will tha tnot do what you wanted ? or did you mean something special by "plymouth message". if there is a command to do it, just substitute for echo.
[16:16] <shbk> hello, does anybody know where I can find  in /proc (another place) information about my keyboard,motherboard,video card, peripheral devices? for example I found info about processor (/proc/cpuinfo),RAM(/proc/meminfo)
[16:16] <cjwatson> device information is more likely to be found in /sys
[16:18] <cnd> doko, I can't reproduce your build failure for utouch-gesturetest
[16:18] <cnd> I used bzr bd --builder=pdebuild from our packaging branch
[16:18] <cnd> and with an updated oneiric pbuilder chroot
[16:19] <doko> cnd, did you change the b-d?
[16:20] <cnd> doko, no
[16:20] <cnd> why do I need to change the b-d?
[16:20] <cjwatson> because libxcb-icccm1-dev is no longer built by any source package and thus is due to disappear from the archive.  see http://people.canonical.com/~ubuntu-archive/nbs.html
[16:20] <doko> cnd, because it's gone, only the binary -dev package is still in the archive
[16:21] <cnd> oh
[16:22] <cnd> doko, I'm curious, why is libxcb-icccm1 gone now?
[16:23] <cjwatson> upstream changes
[16:23] <cnd> cjwatson, ok, but why now?
[16:23] <infinity> Replaced by libxcb-icccm4-dev/libxcb-icccm4?
[16:23] <cnd> it seems late in the cycle
[16:23] <cjwatson> it was actually ages ago
[16:23] <infinity> I assume.
[16:23] <doko> cnd, well, as you can see from the build log, incompatible changes, and packages are renamed for that reason
[16:24] <cjwatson> it's just that we haven't managed to clean up the NBS packages until now
[16:24] <cnd> ahh
[16:24] <cjwatson> this is the point in the cycle when we traditionally sit for ages fighting to do that
[16:24] <cjwatson> if people haven't noticed and sorted it out earlieer
[16:24] <cjwatson> *earlier
[16:24] <hallyn> smoser: is cgroup-bin+libvir testing ok for you?
[16:25] <smoser> hallyn, i'll test now.
[16:25] <smoser> i suppose the bzr branch is broken for that?
[16:26] <hallyn> you know it might not be.  it's broken for the things i touch most often so i tend not even check right now
[16:27] <hallyn> smoser: i can push a bzr tree, gimme a min
[16:28] <hallyn> you know what's broken?  Alt-friggin-tab in unity
[16:28] <bambee> Laney: I found, "warning: jobserver unavailable: using -j1.  Add `+' to parent make rule."
[16:29] <cjwatson> hallyn: I got fed up and just turned it off ...
[16:30] <cjwatson> ccsm -> Ubuntu Unity Plugin -> Switcher -> Key to start the switcher -> Disabled
[16:30] <hallyn> does that bring alt-tab back for actual application switching?
[16:30] <hallyn> I assume there's a way to fix it in the compiz manager...
[16:30] <cjwatson> I suppose I should have filed a bug but given that it was exposed as a preference I assumed it was just a "some people hate this, we know" kind of thing
[16:30] <cjwatson> yes, and that *is* the compiz manager
[16:32] <hallyn> doh. right.
[16:33] <hallyn> cjwatson: yay!  thx
[16:34] <cjwatson> welcome
[16:35] <hallyn> smoser: lp:~serge-hallyn/ubuntu/oneiric/libcgroup/fix-libvirt
[16:49] <infinity> cjwatson: Remind me again exactly when and how a Mac user wants amd64+mac versus amd64?
[16:49] <cjwatson> infinity: if they don't want their system bricked
[16:50] <cjwatson> (depending on the exact vintage)
[16:50] <infinity> So, they always want +mac, is what you're driving at?
[16:50] <cjwatson> infinity: also if they want the image to boot (again depending on the exact vintage, and that's why it was created)
[16:50] <cjwatson> infinity: yep
[16:50] <tjaalton> amd build of latest unity somehow failed to build unity-common and unity-services
[16:50] <tjaalton> sorry, unity-services is fine
[16:50] <Laney> is there a private contact address for the TB?
[16:51] <cjwatson> infinity: I went into more detail in http://askubuntu.com/questions/37999/what-is-different-about-the-mac-iso-image
[16:51] <infinity> cjwatson: Irksome, since we only build it for ubuntu.
[16:51]  * infinity scraps suggesting trying kubuntu and xubuntu to his mac friend.
[16:53] <tjaalton> *amd64 build of unity, somehow broken. archive has unity-common 4.12.0-0ubuntu1, while unity is -0ubuntu2. and this one confirms that no unity-common got built: https://launchpad.net/ubuntu/+source/unity/4.12.0-0ubuntu2/+build/2761299
[16:54] <tjaalton> ..which breaks upgrades, unity wants to deinstall itself
[16:55] <cjwatson> infinity: mjg59 did figure out how to make it unnecessary, and I have a to-do item somewhere to explain that to the xorriso developer so he can implement it
[16:55] <cjwatson> s/the /a/
[16:55] <infinity> tjaalton: Hrm?
[16:55] <infinity> tjaalton: Common is arch:all, no?
[16:55] <infinity> tjaalton: Which would be from the i386 build.
[16:56] <tjaalton> infinity: ah.. ok :P but still, not in the archive
[16:56] <infinity> tjaalton: Define "the archive".  Mirrors suck. :P
[16:56] <tjaalton> the main one
[16:56] <tjaalton> mirrors suck, yes
[16:57] <tjaalton> at least for the devel series
[16:57] <infinity> unity-common | 4.12.0-0ubuntu2 |       oneiric | all
[16:57] <infinity> It's in "the main one".  When I say "mirrors suck", that includes our own.
[16:57] <infinity> archive.ubuntu.com is still a bunch of mirrors. :P
[16:57] <infinity> (moral of the story: patience)
[16:57] <tjaalton> heh, ok
[16:58] <tjaalton> that was an unfortunate dinstall run, then
[16:58] <infinity> cjwatson: Would be pretty shiny to make it go away, if for no other reason than to allow flavours to boot on mac without us building N more images (which we won't do)
[16:58] <tjaalton> anyway, thanks for confirming
[16:59] <cjwatson> infinity: indeed, I don't *like* its presence, it's just necessary right now
[17:04] <cnd> doko, cjwatson: would I need an FFe for a micro-release update of utouch-gesturetest, the only change being the ftbfs against newer xcb-icccm?
[17:05] <infinity> cnd: No.  If the only change is literally just the FTBFS fix.
[17:05] <cnd> ok
[17:05] <infinity> (Unless you consider "it builds now!" to be a new feature)
[17:06] <cjwatson> indeed.
[17:07] <cnd> the FF process says microreleases that just fix bugs like this are "okay", but it's unclear if that means "okay without and FFe", or "usually they are okay to get an FFe"
[17:12] <cjwatson> cnd: no need for an FFe, since they don't contain new features
[17:12] <infinity> cnd: Fair enough.  And we do appreciate caution over the alternative.  But yeah, strictly bugfixes that don't implement new features (or change old ones) are fine without an exception.
[17:13] <Laney> The part of the version string that changes has no bearing on whether the upload needs an exception or not. I guess that paragraph is there because people were unclear about whether they could upload new upstream releases.
[17:14] <cjwatson> Would anyone like to take on bug 789268?  I've posted an explanation of what needs to be done, but given that the reporter's LP display name is "deleted" and username "to-delete", I'm guessing they're no longer interested
[17:16] <zul> cjwatson: xenwatch has been updated to libxen-dev, with regards to xenner it wont build with the new xen library and there hasnt been a new version in like 2 years so we might as well drop it
[17:17] <cjwatson> zul: yeah, I know there's a removal request for that, that's fine
[17:17] <cjwatson> zul: thanks, I'll process those once xenwatch has built so that the reverse-depends chain is clear
[17:17] <cjwatson> I just don't like breaking the archive by removing stuff, especially at this point in the cycle
[17:23] <zul> cjwatson: ok
[17:23] <doko> jtaylor, why didn't you upload your fix for debian bug 632114?
[17:23] <doko> jamespage, did you get FFe's for the maven syncs?
[17:25] <jtaylor> doko: I have no upload rights
[17:25] <jtaylor> its sitting in the sponsor queue
[17:41] <doko> jtaylor, you should get some ;-) asked MOTU about this?
[17:42] <jtaylor> yes, I'll apply for motu soon
[17:45] <bdrung> bambee: what was the result with dpkg-buildpackage?
[17:46] <jtaylor> doko: my unfinished(!) application is here in case you already want to endorse https://wiki.ubuntu.com/JulianTaylor/MOTUApplication
[17:48] <SpamapS> smoser: congrats btw!
[17:53] <bambee> bdrung: same thing
[18:17] <doko> barry, what is your obsession with pyside? ;-P
[18:34] <pdtpatrick> 11.10 really hates nvidia drivers doesn't it .. keeps getting stuck on Checking battery state if u use nvidia-drivers. And this is using the Additional drivers feature
[18:36] <san_1989> i am going to  develop device driver for usb bridge cable in linux(ubuntu 11.04)...any suggessions?any good reference sites?..or any good channel that handling it..?
[18:38] <SpamapS> slangasek: an old, ugly bug seems to have reared its head.. can you review my comments just posted to bug 462169 ?
[18:38] <barry> doko: i take that bug as a personal affront :)
[18:40] <san_1989> anyone help me...
[18:40] <smoser> slangasek, your comments / re-review and of would be appreciated (https://code.launchpad.net/~smoser/ubuntu/oneiric/ifupdown/lp838968/+merge/73741)
[18:41] <Daviey> adam_g: Did someone from foundations look at your branch for bug 818177?
[18:51] <adam_g> Daviey: hasn't gotten any response on LP, but i believe lynxman spoke to someone from foundations here yesterday
[18:51] <lynxman> Daviey: jhunt reviewed it and he thought it was okay if we added a timeout on wait_for_udev
[18:52] <lynxman> Daviey: did you go to SL6 yet? I could still go :P
[18:55] <slangasek> SpamapS: reviewed :)
[18:55] <Daviey> lynxman: Not yet.. but am closer.
[18:55] <lynxman> Daviey: :)
[18:57] <SpamapS> slangasek: that is incredibly confusing.. UGH... thanks though.
[19:01] <slangasek> SpamapS: so that new bug report needs an smbd.log and the smb.conf showing what exactly they're doing, because smbd is not supposed to need the interface up before it starts, in the general case
[19:03] <slangasek> smoser: my opinion on the ifupdown merge hasn't really changed; I think returning results in global variables is a horrible pattern in any language, and I don't think that's a change to be made during Feature Freeze
[19:03] <smoser> wait. what? slangasek ?
[19:04] <smoser> i thought i said yesterday that i thought it was too late in a release for this.
[19:04] <smoser> and you said otherwise.
[19:05] <smoser> you're really objecting only on the basis of a global variable ? after complaining about forks other places ?
[19:05] <smoser> i'm fine to change that, but my personal feeling is that _RET as a return variable in shell is completely acceptable.
[19:07] <slangasek> smoser: I think it's perfectly appropriate to fix the bug at this point in the cycle, but inappropriate to restructure the code like that in the process
[19:08] <smoser> well, i'm more than willing to put it back the way it was, but I think restructuring of that loop is several orders of magnitude less likely to cuase fallout than adding '-1' to dhclient.
[19:08] <smoser> but i will shut up now
[19:08] <smoser> as i want that change in
[19:09] <slangasek> I agree, it is less risky - but there's also less benefit, as in none that I can see :)
[19:09] <smoser> do you also disagree to the check for mkdir ?
[19:10] <slangasek> I do, but it's not worth arguing about because it's clearly low risk
[19:14] <smoser> slangasek, ok. i'm going to ditch the mkdir also
[19:14] <slangasek> smoser: ok, cheers
[19:14] <smoser> but not because you said to
[19:14] <smoser> :)
[19:14] <slangasek> :D
[19:14] <smoser> only because if there were a trailing slash on it anyway then it would actually make the lock dir
[19:14] <smoser> ie if someone did: MARK_STATIC_NETWORK_EMITTED=/run/network/mylock/
[19:14] <smoser> and i dont want to deal with that now.
[19:15] <slangasek> adam_g: 818177> fwiw, doesn't look like you'd set foundations as a reviewer, so I've only seen it now because the bug was assigned
[19:15] <slangasek> adam_g: anyway, I talked about this issue with someone (hallyn, I think?) a couple of weeks ago... this change only moves the race, it doesn't fix it :/
[19:15] <slangasek> smoser: heh, fair enough
[19:17] <slangasek> ah no, it was smoser, I was just having another conversation with hallyn at the same time
[19:18] <adam_g> slangasek: ah, right. i figured it was just a bandaid but worth submitting to get discussion going, since its a nasty one
[19:19] <slangasek> more like smacking bubbles in the wallpaper than a bandaid :)
[19:19] <adam_g> well, a bandaid for my specific boo-boo :P
[19:20] <slangasek> :-)
[19:20] <slangasek> adam_g: I would recommend talking to udev upstream about this, and maybe check what dracut is doing as far as udev handling in initramfs... maybe this is a known solved problem already, or maybe it needs an upstream fix
[19:21] <smoser> bug 818177
[19:22] <smoser> slangasek, ok. please take one last glance at that MP and then i can upload.
[19:25] <slangasek> smoser: looks good, ship it! :)
[19:26] <smoser> thank you for not objecting to the new comments
[19:27] <smoser> :)~
[19:27] <slangasek> haha
[19:27] <slangasek> smoser: also, congrats on the new core-dev status :)
[19:28] <cjwatson> quick, assign him some bugs
[19:28]  * slangasek grins
[19:29] <slangasek> well, ifupdown being one's second upload as a core-dev isn't too shabby :)
[19:32] <cjwatson> "brave"
[19:32] <stgraber> ;)
[19:35] <stgraber> slangasek: oh, just noticed that iscsi bug, seems like I'll be having some fun next week ;) Only briefly played with iscsi back in 8.04 and tried very hard to avoid it since then.
[19:36]  * cjwatson breathes a sigh of relief since I handled the last n iscsi bugs
[19:36] <cjwatson> it's usually networking being torn out from under iscsi at some inconvenient time
[19:55] <slangasek> smoser, SpamapS: we still need to deal with the flipside of this bug, which is that during normal operation, a network interface that's properly configured and is going to come up should *never* hit the dhclient timeout - whether we deal with that by treating the ifup command as succeeding or failing
[19:55] <slangasek> (as SpamapS has pointed out)
[19:56] <slangasek> cyphermox, cjwatson, stgraber: what would the consequences be outside ifupdown (i.e., NM + installer) if we raised dhclient's initial timeout limit from, say, 60 seconds to 300?
[19:57] <slangasek> stgraber: you mean you don't have airborne nanomachines in your office that boot over iscsi?! The illusion is shattered
[19:58] <cyphermox> hehe
[19:58] <cyphermox> slangasek: I think NM has it's own timeout, I'll check
[19:59] <slangasek> cyphermox: right, that's what I would hope - ideally we could have dhclient called with -1 everywhere and an infinite timeout, and let the network managers (whichever they are) handle timeouts
[20:00] <slangasek> smoser: the other question is, why is it taking >60s for your interface to prime itself :)  kernel bug?
[20:00] <smoser> yeah. apparently you can add some kernel flags to help the driver, per Daviey.
[20:00] <smoser> but it was useful in that we found this.
[20:00] <slangasek> indeed
[20:01] <slangasek> has anyone asked the kernel team about setting those flags by default, or otherwise dealing with the slowness?
[20:02] <smoser> i dont think so. but i know nothing more than i thought i'd found a time warp to 1995 when daviey said "I had to add some kernel flags to make dhcp work"
[20:02] <stgraber> I have some switches that currently need somewhere between 30 and 45s to negociate a link, "by design" :)
[20:02]  * slangasek chuckles
[20:03] <stgraber> at least most servers run with static IPs so I only use dhcp at install time where I usually need between 2 and 3 retry before they get an IP...
[20:04] <stgraber> I'm not sure how netcfg handles the dhcp timeout but if it has its own, I'd suggest it be raised to some higher value (twice what it currently is would be nice, you can easily skip it anyway)
[20:05] <slangasek> stgraber: could you check into netcfg and see?  It'd be nice to close this out today
[20:05] <slangasek> and if everything that calls dhclient does its own timeout, I'd rather raise dhclient's internal timeout exponentially instead
[20:05] <slangasek> to avoid any risk of false negatives
[20:07] <stgraber> slangasek: ok, from a quick read of netcfg's code, it's starting "dhclient -1" with a custom configuration "-cf xyz" that contains a custom timeout set to the value of netcfg/dhcp_timeout in debconf
[20:07] <slangasek> ok, cool
[20:08] <cyphermox> slangasek: yup, NM already has a timeout set to 45 s
[20:08] <slangasek> excellent, so we can update dhclient with impunity
[20:09] <cyphermox> stgraber: if your switches take 30 to 45s to negociate for client nodes, turn portfast on to those ports ;)
[20:10] <Apteryx> Hi everyone. When packaging new release of a software, what's to do with old patches?
[20:12] <stgraber> cyphermox: yeah, I guess I'll simply turn STP off entirely on all my switches. All unused ports are shutdown anyway and most of the others require 802.1x, so it's pretty unlikely that a loop would appear ;)
[20:12] <cyphermox> Apteryx: you'd then want to see if those are still needed, and if so, try to apply them / fix them so they work on the new release.
[20:13] <Apteryx> cyphermox ok... man this is hell, there's like 44 patches to track.
[20:13] <cyphermox> stgraber: heh, you never know when a link stops working. stp is good to have, but it's up to you. portfast on cisco hardware (and I'm sure there's an equivalent on others) makes sure it skips the stp stuff and comes up usually in < 15 s
[20:14] <cyphermox> stgraber: also, any luck with DHCPv6 and my patch to deal with DUIDs ? ;)
[20:14] <stgraber> I guess I'll start by turning portfast on then (I'm currently using small cisco gigabit switches)
[20:15] <stgraber> cyphermox: I'm "almost" there ;) I now have my scripts generate my test VMs automatically, just need to get the d-i preseeding done and it'll be NM's turn.
[20:16] <Apteryx> cyphermox, but will the patches even apply? The versionning is different and is often found in filenames.
[20:17] <cyphermox> Apteryx: depends on software, but usually the version number for the software is irrelevant (though if it bumps a lot then the code base is likely very different and thus the patches might be more difficult to apply)
[20:19] <Apteryx> cyphermox, I'll give it a try, thx!
[20:20] <cyphermox> Apteryx: sure. it may well look worse than it is, but you really need to try to know. what application is that for?
[20:36] <Apteryx> cyphermox, this is pulseaudio
[20:37] <Apteryx> cyphermox, I'm having a hard time understanding Ubuntu's versionning scheme. I want to update pulseaudio version from 0.9.22 to 0.99.3-0.1. Old package version was: 1:0.9.22+stable-queue-24-g67d18-0ubuntu3.1
[20:37] <Apteryx> What's the leading '1:' ?
[20:37] <cyphermox> Apteryx: is the upstream version number 0.99.3-0.1?
[20:38] <Apteryx> cyphermox, 0.99.3 and 0.1 is kind of a release candidate version.
[20:38] <cyphermox> the leading 1: is the epoch value which you usually shouldn't change. if it's there for a package, you'll need to keep it
[20:39] <Apteryx> I understand that the digit following 'ubuntu' in the version number is for the ubuntu package specific revision, what about the leading digit of 'ubuntu'? (in this case 0)
[20:40] <Apteryx> Would "1:0.99.3-0.1-0ubuntu1" be a sane version number?
[20:41] <cyphermox> nope, the - has a special meaning.
[20:41] <cyphermox> I'm not sure where you get the 0.1 from, but 0.99.3 appears to be the lastest version available for pulseaudio
[20:42] <cyphermox> so you'd use 1:0.99.3-0ubuntu1 for version number, assuming you'd use http://freedesktop.org/software/pulseaudio/releases/pulseaudio-0.99.3.tar.gz as the source tarball
[20:43] <cyphermox> the - and following numbers are used for package revisions in Debian and Ubuntu, so you can't really have it in version number for the upstream project
[20:44] <Apteryx> cyphermox, Yeah, I think I made up the 0.1 xD, sorry about that.
[20:44] <cyphermox> np :)
[20:45] <Apteryx> cyphermox or at least can't find trace of it anywhere now.
[20:53] <Apteryx> Apparently I have a missing /usr/share/cdbs/1/rules/autoreconf.mk file on my system. Shouldn't this come with cdbs?
[20:55] <jtaylor> no dh-autoreconf
[21:01] <Apteryx> jtaylor, thank you!
[21:15] <SpamapS> slangasek: indeed I must have jumped the gun a bit on that duplication.. smbd does have the ability to bind to a specific IP tho, right?
[21:15] <SpamapS> n 15
[21:16] <slangasek> SpamapS: yes, it does, but it's not enabled by default - if you want to be conservative, I suppose you could make smbd wait for the all-auto-interfaces event, though I'm inclined to think someone fiddling these parts of smb.conf should also update the upstart job for their specific (non-standard) requirements
[21:19] <SpamapS> slangasek: that sounds very... strange to me, that one would have to update the start script order just for what is basically a normal very common config change.
[21:19] <slangasek> SpamapS: I don't see why you would say this is a very common config change
[21:20] <slangasek> I think most people who make this change are doing so without a good reason
[21:20] <SpamapS> Like not wanting samba on the insecure network.. ?
[21:21] <slangasek> that can be specified with 'interfaces = eth0' - no hard-coding of IPs
[21:21] <SpamapS> same problem though
[21:21] <slangasek> I don't think so
[21:21] <slangasek> I believe you'll find the behavior differs
[21:22] <SpamapS> It just polls until eth0 has an IP?
[21:22] <slangasek> I believe that's what it does, yes
[21:22] <SpamapS> so its the one well behaved daemon that does it right. ;)
[21:25] <SpamapS> slangasek: I believe you, I really do... I'm just worried that we're unnecessarily burdening people.. what good reason is there to start smbd before all network interfaces are up?
[21:27] <slangasek> in the pathological case, because the machine has loopback smb mounts in /etc/fstab? :)
[21:28] <slangasek> I don't feel too strongly about doing it this way, honestly; the current start condition predates the availability of the "all interfaces" event
[21:29] <SpamapS> slangasek: I'm fairly convinced that we can simplify everyone's life by simply moving most things to runlevel 2
[21:29] <SpamapS> slangasek: the few things that *need* to start before then already do.
[21:30] <slangasek> well, smbd can't be moved to runlevel 2
[21:30] <slangasek> because it *could* block the filesystem event
[21:31] <slangasek> waiting for all interfaces merely slows down the boot; waiting for filesystem could block it entirely
[21:33] <SpamapS> Right.. hm.
[21:33] <SpamapS> loopback to the local smbd .. thats just.. nuts. ;)
[21:34] <slangasek> no more nuts than hard-coding ip addresses in your smb.conf ;)
[21:35] <infinity> Loopback to local smbd isn't as uncommon as you'd think.
[21:35] <infinity> Though it sounds odd.
[21:35] <SpamapS> I still think thats a pretty common use case and not one to derride.
[21:35] <SpamapS> the ip thing, not the loopback samba mount
[21:35] <SpamapS> the loopback samba mount sounds crackers to me. ;)
[21:35] <infinity> And, I dunno, binding to interfaces SHOULD be more common than binding to IPs.
[21:36] <infinity> But I can't say what people actually do.  Just what they should. :P
[21:36] <slangasek> SpamapS: why would you hard-code the IP?
[21:36] <SpamapS> infinity: unless you want just a specific IP on a specific interface.
[21:36] <SpamapS> because eth0 has 20 IPs, and you only want to provide smbd on one of them.
[21:36]  * slangasek thinks about this
[21:37] <slangasek> why would you not configure alias interfaces in that case, if you mean to provide different services?
[21:37] <infinity> By "eth0", you mean "eth0 and 19 aliases", or actually eth0?
[21:37] <SpamapS> if you also added interfaces = eth0 .. would it wait to bind() until eth0 was fully configured.. how would it even know that the ip you wanted was ready
[21:37] <SpamapS> slangasek: you think it would be easier to have 'interfaces = eth0:14' instead of binding to the IP I mean?
[21:37] <infinity> SpamapS: Yes.
[21:38] <SpamapS> lol.. ok
[21:38] <SpamapS> I guess I think differently.
[21:38] <infinity> SpamapS: Since eth0:14 might have your IPv4 and IPv6 IPs for all the services associated with that alias.
[21:38] <infinity> (For instance).
[21:40] <SpamapS> I never grouped things like that.. but I did make multi-tenant systems where IP was the method of separation .. not interface.
[21:41] <SpamapS> Its far enough off from the generic case that I think its ok to just let people figure it out.. but "all static network interfaces are up" does seem better to wait for than "a network interface is up"
[21:42] <slangasek> the latter does mean smbd will be up and ready to go sooner for users who don't have that particular scenario
[21:42] <slangasek> but I'm not going to fight it if you go with the more conservative start rule
[21:43] <SpamapS> problem is, this guy who started this conversation has a static IP via network manager, which the new event doesn't touch
[21:43] <slangasek> hah
[21:44] <SpamapS> and for good reason.. too hard to predict what n-m is doing. :p
[21:44] <slangasek> yep
[21:45] <SpamapS> For now I think we can just rely on smbd's robustness and not change anything yet
[21:47] <slangasek> I've at least asked for a copy of the relevant config on the bug, so we can verify that it really only happens under the circumstances I've suggested (namely, 'bind interfaces only = yes' + 'interfaces = $IP')
[22:09] <dupondje> mmmm did gnome-shell just break ?
[22:09] <dupondje> segfaults here :(
[22:11] <cjwatson> slangasek: yeah, as stgraber said, d-i already sets its own DHCP timeout
[22:11] <bdrung> bambee: then it's not a problem of debuild. either your package fault or dpkg-buildpackage
[22:12] <cjwatson> I wouldn't advise raising the netcfg default further, because it's synchronous and long timeouts annoy people without a DHCP server
[22:12] <cjwatson> the current value is a compromise, already raised a bit from what's in Debian
[22:13] <stgraber> cjwatson: yeah, I didn't know the timeout was configurable through debconf before. I now changed my default pxe settings for d-i to set it to 120s, that should fix my problem
[22:13] <slangasek> cjwatson: oh yes, I wasn't intending to change any timeouts in netcfg, didn't realize that's what stgraber was referring to
[22:14] <slangasek> I am bumping the timeout in isc-dhcp though
[22:15] <stgraber> slangasek: I just mentioned that the 60s timeout was a bit short for me in d-i and that I wouldn't mind it being 120s but I can see that being annoying for quite a few users ;)
[22:16] <slangasek> stgraber: yeah, a timeout in the installer critical path has a slightly different role :)
[22:20] <bambee> bdrung: the package is kde-workspace, it's not a package fault. Already checked with downstream and upstream. The error comes from make itself
[22:20] <bambee> the makefile is generated by cmake, it does not make sense
[22:21] <bdrung> so it's a cmake bug?
[23:03] <slangasek> -
[23:06] <Apteryx> Hello, is commenting the patch in the file debian/series (quilt used as patching system) enough to prevent it being merged?
[23:07] <Apteryx> I thought so, but pbuilder keeps failing on an already commented out patch!
[23:08] <cjwatson> should be.  quilt(1) says: "Lines in the series file that start with a hash character (#) are ignored."
[23:08] <cjwatson> perhaps your working tree is inconsistent in some way
[23:08] <cjwatson> I would suggest checking that 'quilt pop -a' then 'quilt push -a' works, for starters
[23:09] <Apteryx> cjwatson, I'll check this.
[23:57] <DoctorPepper> hi guys !!!