[01:17] <yao_ziyuan> i wonder if ubuntu can employ a mixed development model
[01:17] <yao_ziyuan> update core packages slowly,
[01:17] <yao_ziyuan> but app packages quickly
[01:18] <yao_ziyuan> apps such as gimp, pidgin, supertuxkart
[01:18] <yao_ziyuan> their latest versions better be released fast
[01:18] <yao_ziyuan> so you can have both stability and cutting-edge
[01:21] <LaserJock> yao_ziyuan: I think that happens fairly naturally anyway
[01:21] <LaserJock> yao_ziyuan: having 6 month releases allows core packages to go slowly but app packages to go quicker
[01:22] <yao_ziyuan> but apps such as pidgin are still outdated
[01:23] <yao_ziyuan> ubuntu pidgin is 2.5.2
[01:23] <yao_ziyuan> latest pidgin is 2.5.5
[01:24] <yao_ziyuan> how can you say apps get updated fast?
[01:24] <Nafallo> jaunty  development  main  release  1:2.5.4-2ubuntu2
[01:25] <Amaranth> yao_ziyuan: that doesn't sound too out-dated
[01:25] <Amaranth> Unless they rewrote pidgin between 2.5.2 and 2.5.5
[01:25] <LaserJock> so we are 0.0.1 behind :-)
[01:26] <yao_ziyuan> i'm interested in finding another repository that offers latest apps
[01:26] <yao_ziyuan> getdeb.net is one but not sure if it has a repository
[01:26] <LaserJock> and 2.5.5 was released 2 days ago
[01:26] <yao_ziyuan> is there a ppa.launchpad.net repository for my purpose?
[01:26] <LaserJock> so we're all ove 2 days behind :-)
[01:26] <LaserJock> *of
[01:27] <LaserJock> yao_ziyuan: you can go to launchpad.net/ubuntu/+ppas and search for it
[02:36] <TheMuso> c
[03:40] <LaserJock> you know, I wonder if it'd be possible for the CD autorun thing to compare the Ubuntu version that's on the CD with the one that's currently running
[03:41] <LaserJock> I just put in a gutsy CD and it wanted to know if I wanted to upgrade :-)
[04:03] <ScottK> Maybe it just has a poor opinion of the release you're running?
[04:11] <TheMuso> heh
[04:13] <TheMuso> ROCK ON ALESSIO ABOGANI! You have made my day dude! We, (or at least I), have a bootable i386 RT kernel!
[04:13] <TheMuso> woops wrong channel
[04:13]  * TheMuso has too much excitement atm. :p
[04:14] <bryce> pitti: are you really sure the patch for 218671 should go to hardy and intrepid?  The patch isn't taken upstream and looks to me like it'd cause regression for all current users of -elographics?  I can put it in if you're certain it's the right fix, but personally I think it needs more work to not cause regressions.
[04:33] <bryce> pitti: commented on 218671.
[06:56] <didrocks> mdke: I will have a look today at it
[07:53] <pitti> Good morning
[07:54] <pitti> ScottK: stracciatella> I'm a package bug contact (or at least I'll watch them), but I'm of course interested in getting subscriptions to bugs which interact with it
[07:54] <StevenK> Morning pitti!
[07:55] <pitti> bryce: no, not at all; apparently I misunderstood it as "came from upstream", and since I can't really judge it, I asked you to have a look
[07:56] <bryce> pitti: ah ok
[07:56] <bryce> pitti: yeah it's a confusing bug, but I think going upstream is the next step for it
[07:57] <pitti> absolutely, and we shouldn't backport it too fast; it should at least spend some time in jaunty
[07:57] <pitti> hey StevenK
[08:04] <mdke> didrocks: many thanks
[08:05] <didrocks> mdke: that's very strange, the context of the patch didn't change too much. I was pretty confident. I will have a deeper look this evening :)
[08:08] <mdke> didrocks: ok.
[08:25]  * slangasek waves to pitti from the far side of Debian bug #215219
[08:28] <pitti> slangasek: ugh, that's ages old :) great that it came to a good end eventually
[08:42] <doko> seb128, slomo_ : I didn't follow https://bugzilla.redhat.com/show_bug.cgi?id=470000 . Is this applied?
[08:43] <slomo_> doko: gst-plugins-good 0.10.14 should have this fixed
[08:43] <slomo_> doko: and 0.10.13-something
[08:43] <seb128> doko: yes
[08:43] <doko> thanks!
[08:44] <seb128> slomo_: should we sync 0.10.14? is that a bug fix version?
[08:44] <slomo_> seb128: what's the current version in ubuntu?
[08:46] <slomo_> seb128: 0.10.13.2-1, ok... compared to that it's a bugfix release, yes
[08:47] <seb128> slomo_: ok, good to sync then? ;-) what about vala 0.1.7?
[08:47] <slomo_> good to sync, yes... same goes for gst-plugins-bad0.10 0.10.10-3 (or -2, whatever the latest is)
[08:48] <seb128> ok thanks
[08:48]  * seb128 does syncing
[08:48] <slomo_> vala 0.1.7 has many bugfixes but also some new features iirc... but for such a new language that's ok i guess ;)
[08:50] <seb128> yeah, I don't think it will break lot of things
[09:04] <directhex> afaik thefre's only one app in the archive built using vala
[09:04] <directhex> so test that for buildability with 0.1.7, if it's fine, i see no pressing reason not to update it
[09:04] <directhex> a good vala dev environment is a nice thing to have for jaunty
[09:24] <slytherin> asac: hi, do you maintain network-manager-openvpn package?
[09:28] <asac> slytherin: ?
[09:29] <slytherin> asac: any idea where could I forward this bug 285138
[09:30] <asac> slytherin: bugzilla.gnome.org
[09:31] <asac> slytherin: have you checked the NM on jaunty?
[09:32] <YokoZar> jcastro: I hope you don't mind me applying for sponsorship on the very last day.  I've been out with some particularly nasty food poisoning the past week
[09:49] <slytherin> asac: no I haven't. I will do today.
[09:51] <asac> slytherin: yes, please do that. maybe its fixed
[09:52] <slytherin> asac: I feel this is more of the plugin issue. Still I will check.
[10:00] <asac> slytherin: not sure why you think that plugin hasnt changed in jaunty ;)
[10:00] <asac> just check before forwarding ... thanks
[10:00] <slytherin> sure
[10:02] <slytherin> by the way, has anyone seen ath_pci causing kernel panic at boot time? I faced this issue on an acer laptop yesterday. searched google but didn't find sufficient information.
[12:05] <ogra> cjwatson, "Don't disable /dev/ramzswap* swap devices." in partman ? why is that ?
[12:08] <ogra> oh, that means it shoudnt swapoff ?
[12:15] <cjwatson> ogra: this is a change that's been there for ages
[12:15] <cjwatson> ogra: yes, indeed, it inhibits swapoff on those
[12:15] <ogra> right, i was just wondering, and then did remember the actual change
[12:17] <mnabil> guys ,i customizing intrepid alternate cd , i added some packages to the /pool/extras and i did every thing using else using uck , my question is how can i install these package automatically  i mean what is the statement to do this in the preseed file
[12:18] <directhex> d-i     pkgsel/install-pattern  string ~n^pkgname$|~n^anotherpkgname$
[12:18] <directhex> mnabil, ^^
[12:18] <cjwatson> goodness, why would you use such a complicated syntax
[12:18] <cjwatson> d-i pkgsel/include pkgname anotherpkgname
[12:18] <directhex> dunno, an old sarge d-i guide i think
[12:19] <directhex> it'd help if d-i syntax didn't change between every build
[12:19] <cjwatson> doubt it, I think that was an Ubuntuism
[12:19] <cjwatson> you can use Kickstart if you want a stable syntax
[12:21] <mnabil> k
[12:21] <mnabil> thanks
[12:22] <directhex> cjwatson, i had to switch target distro twice during the project, so whatever it came from initially, it works in etch
[12:24] <cjwatson> directhex: pkgsel/install-pattern is definitely not supported in etch; pkgsel/include is
[12:24] <cjwatson> (see e.g. http://svn.debian.org/wsvn/d-i/branches/d-i/etch/packages/pkgsel/debian/pkgsel.templates?op=file&rev=0&sc=0 and http://svn.debian.org/wsvn/d-i/branches/d-i/etch/packages/pkgsel/debian/postinst?op=file&rev=0&sc=0)
[12:24] <directhex> i might be looking at an old revision of the seed
[12:25] <directhex> well guessed. i was looking at the dapper version of the file
[13:11] <pitti> cjwatson: do you know where /etc/usplash.conf is written during install?
[13:13]  * mneptok guesses /etc
[13:13] <pitti> cjwatson: usplash's postinst attempts that, but that wouldn't normally run when installing with ubiquity?
[13:13] <pitti> mneptok: right, sorry; I mean "how", "what part of the install", and "which resolution does it use"
[13:15] <mneptok> pitti: sorry, i try to be egalitarian and fair when spreading snarky comments. ;)
[13:15]  * mneptok hugs pitti 
[13:15]  * pitti hugs back mneptok
[13:17] <ogra> pitti, just a gues ... update-initramfs ?
[13:18] <ogra> *guess
[13:18] <ogra> (i didnt look, just speculating)
[13:18] <pitti> ogra: good shot; however, /usr/share/initramfs-tools/hooks/usplash doesn't have detection code
[13:19] <pitti> it just copies /etc/usplash.conf into the initramfs
[13:19] <ogra> hmm
[13:19] <pitti> ideally it would be written in the installer, according to the currently dtected/configured X.org resolution
[13:20] <mneptok> pitti: wouldn't a dpkg-reconfigure of usplash call whatever piece you're looking for?
[13:20] <pitti> and I *think* that's what happens, but kwwii asked me to confirm
[13:20] <ogra> either that or by initramfs on boot
[13:20] <pitti> mneptok: yes it would
[13:20] <Keybuk> my favourite bug of the day
[13:20] <Keybuk> bug #336762
[13:20] <ogra> if the .conf doesnt exist yet
[13:20] <directhex> wasn't there some magic non-sucky replacement for usplash being mentioned?
[13:20] <pitti> directhex: KMS and plymouth, but not for jaunty
[13:20] <mneptok> pitti: OK, so i would think there would be a way to watch that happen.
[13:20] <pitti> Keybuk: lol
[13:21] <mneptok> Keybuk: my favorite bug of the day slipped back beneath the underwear waistband before i could find tweezers. :/
[13:22] <directhex> pitti, something which can handle widescreen without rescaling badly 3 times would be welcome
[13:22]  * Keybuk hands mneptok the Derbac
[13:22] <pitti> directhex: you mean mode switching; and yes, KMS should provide that eventually
[13:22] <mneptok> Keybuk: in better news, from what i could see, he has your eyes.
[13:22] <pitti> but it's not quite there yet
[13:23] <cjwatson> pitti: ubiquity explicitly runs dpkg-reconfigure usplash, so the postinst is run
[13:24] <pitti> cjwatson: ah, that solves it; thanks
[13:24] <cjwatson> and it removes /etc/usplash.conf first to force regeneration
[13:24] <cjwatson> a bit like Doctor Who
[13:24] <directhex> i need to mangle usplash.conf manually on my laptop or i get corruption on screen when booting
[13:26] <Keybuk> cjwatson: following up on your rant
[13:27] <Keybuk> I wonder whether the triage tendancy to post to any bug older than a few weeks asking whether it's still present ...
[13:27] <Keybuk> ... is what causes people to keep posting to my bugs saying "THIS BUG IS STILL PRESENT IN JAUNTY! OMGZ!"
[13:27] <directhex> O NOEZ!
[13:27] <cjwatson> there seems to be a vast misestimation of available developer effort somewhere
[13:27] <cjwatson> leading to people believing that if a bug hasn't been fixed then this must be because it's no longer relevant
[13:28] <directhex> cjwatson, every user assumes every other user is a developer (and they're the only "mooch")?
[13:45] <Mirv> should the "Incomplete Language Support" light bulb be appearing in jaunty too, after installation? which package it's a problem of, as it does not? language-selector still has the strings at /usr/share/language-support/incomplete-language-support-gnome.note but those are not shown/triggered.
[13:49] <Mirv> I guess it would be ubiquity, and I'd file a bug about it if cjwatson doesn't object. I don't know how things should go with the new notification systems etc.
[13:53] <RainCT> Btw, apport shows a notification which says "click the icon". Shouldn't the bubble and the notification icon be replaced directly by window?
[13:53] <AnAnt> Regarding debian bug #411851 , I tried the pm-utils hook script but it didn't work, does Ubuntu something else other than pm-utils for suspend/resume ?
[13:55] <MacSlow> how do I create a pbuilder environment for jaunty (under jaunty again)?
[13:55] <cjwatson> Mirv: ubiquity does have code to do that, so bear that in mind when you file the bug - we'd need to figure out why the existing code isn't working
[13:55] <huats> I am experiencing a weird issue :  when I am building a package in my pbuilder it builds fine, but in soyuz it fails because it cannot find a bdeps (liblocale-gettext-perl). This package is installed on my pbuilder, so why is it not installed in soyuz ?
[13:55] <MacSlow> what's the exact pbuilder command again?
[13:56] <RainCT> MacSlow: with pbuilder-dist or plain pbuilder?
[13:56] <ScottK> MacSlow: One of the easiest ways to do it is with pbuilder-dist.
[13:56] <MacSlow> pbuilder --distribution jaunty --create
[13:56]  * ScottK notes RainCT must type faster than he does.
[13:56] <primes2h> doko: Hi, I just added a link to the diff in bug 333727
[13:57] <MacSlow> hm... no pbuilder-dist command here
[13:57] <RainCT> ScottK: Heh. Yeah, I have "learn Dvorak" on my TODO :)
[13:57]  * MacSlow does "sudo apt-get install ubuntu-dev-tools"
[13:57] <primes2h> doko: This bug prevents me from translating the application correctly because I can't add a printer.
[13:57] <MacSlow> *sigh* why did that not survive my upgrade to jaunty?
[13:57] <AnAnt> RainCT: isn't that the keyboard layout in UK ?
[13:58] <ScottK> If you have pbuilder-dist (it's in ubuntu-dev-tools) it's just pbuilder-dist jaunty create
[13:58] <cjwatson> AnAnt: *blink* no
[13:58]  * MacSlow and packaging *sigh³*
[13:59] <MacSlow> hey tedg
[13:59] <AnAnt> where should I ask about suspend/resume & pm-utils  ?
[13:59] <RainCT> AnAnt: No. See dvzine.org
[13:59] <tedg> Good morning MacSlow
[14:00] <RainCT> MacSlow: With pbuilder-dist, you can also create a symlink to it called pbuilder-<distro> and then use  pbuilder-<distro>  directly instead of  pbuilder-dist <distro>
[14:01] <ogra> MacSlow, hey, remember my "notificatons pup under the panel issue" ? ... delaying the startup of notify-osd by 5 secs solves it (i simply added a wrapper script around notify-osd that gets called by the dbus service file and lets it sleep 5 secs)
[14:01] <ogra> *pop
[14:01] <cjwatson> Keybuk: can I poke you to vote on my TB Landscape resolution?
[14:01] <MacSlow> ogra, there is a temp. fix in place now, but it's not a wrapper-script
[14:02] <ogra> MacSlow, yeah, wrapper scripts are hacks anyway, just wanted to give you a hint ;)
[14:03] <MacSlow> ogra, don't worry I know about many issues :)
[14:04] <ogra> oki :)
[14:06] <doko> primes2h: please let Till review and upload
[14:07] <primes2h> doko: ok, I asked you because he is not here today.
[14:08] <lool> I just did a deboostrap and saw it detect new required base dependencies with the move to python2.6
[14:08] <lool> I think python2.6 needs promotion to priority important and -minimal to required
[14:09] <lool> And python2.5 ones should be demoted
[14:09] <lool> Is an archive admin around to change that?
[14:10]  * MacSlow remembers why he hates packaging
[14:10] <MacSlow> a command like "pbuilder-dist jaunty create" has do be done with sudo, right?
[14:11] <Hobbsee> yes
[14:11] <MacSlow> *sigh*
[14:11] <MacSlow> "nice" that it does not complain if I start it without sudo
[14:11] <MacSlow> just diligently does thing and wasts time
[14:12] <Laney> pbuilder-dist calls sudo itself, no?
[14:12] <MacSlow> Hobbsee, Laney: well it certainly did not create this /var/pbuilder/something/base.tgz
[14:13] <MacSlow> Hobbsee, Laney: well it certainly did not create this /var/pbuilder/something/base.tgz
[14:13] <MacSlow> ups
[14:13] <Laney> It makes them in ~/pbuilder/
[14:14] <Hobbsee> hrm.  You might be right there, actually
[14:14] <MacSlow> Laney, how can I instruct pbuilder to use that  ~/pbuilder instead of /var/pbuilder/something?
[14:14] <Laney> pbuilder --basetgz (IIRC)
[14:14] <MacSlow> I have that actually
[14:14] <Laney> but why not just use pbuilder-dist to build stuff?
[14:15] <MacSlow> Laney, I honestly have no idea what I'm doing right now
[14:15] <MacSlow> the last package I did is months ago
[14:16] <Laney> MacSlow: What are you trying to do? build a package?
[14:17] <MacSlow> Laney, well I want to use pbuilder to verify my package before I upload it to the build-server
[14:17] <MacSlow> PPA rather
[14:17] <Laney> ok, well
[14:17] <Laney> pbuilder-dist jaunty build xxx.dsc I believe
[14:18] <directhex> ooh, xxx
[14:18] <Laney> 18+ source package
[14:18]  * Laney covers directhex's eyes
[14:19] <MacSlow> no I've to use pdebuild I think
[14:19] <MacSlow> I don't yet have a .dsc
[14:19] <MacSlow> file
[14:20] <Laney> just run debuild -S inside the package dir and it will spit one out for you
[14:20] <directhex> Laney, hot-babe 0.2.2-3ubuntu1?
[14:20] <MacSlow> pdebuild -- --basetgz /home/mirco/pbuilder/jaunty-base.tgz
[14:20] <Laney> guh, if you like
[14:20] <MacSlow> packaging is like using git
[14:21] <RainCT> Btw, poweroff / reboot don't work anymore here since I updated my laptop to Jaunty ("halt" works, though)
[14:21] <Laney> simple and intuitive?
[14:21] <maxb> I like --use-pdebuild-internal, which builds straight from a directory, doesn't need a source package
[14:21] <MacSlow> it only makes sense to people who do it on  a daily basis ... not if you only do it every 6 months
[14:22] <directhex> Laney, git is as intuitive as DIY laser eye surgery
[14:22] <directhex> and more painful
[14:22]  * RainCT is away for 2 hours
[14:22] <RainCT> directhex: +1 :)
[14:22] <Laney> HMM
[14:22] <Laney> IDEA! pdebuild-dist
[14:22] <maxb> The scary thing is how git starts to make sense after a while.... and you wonder how warped your brain has become :-)
[14:22] <Hobbsee> MacSlow: the trick is to keep the scripts around, use sed on them, then upgrade them from there - not recreate from scratch each time ;)
[14:23] <Laney> all it does is figure out your pbuilder-dist basetgz location and pass that to pdebuild, parsing changelog to get the right release
[14:24] <AnAnt> RainCT: that was a nice comic !
[14:24] <AnAnt> thanks
[14:25] <cjwatson> lool: done the priority changes, thanks. (BTW, http://people.ubuntu.com/~ubuntu-archive/priority-mismatches.txt)
[14:25] <lool> cjwatson: ah didn't think it would check for that
[14:26] <cjwatson> now, what on earth is pulling gtk into standard
[14:26] <lool> cjwatson: one thing the mismatches report doesn't mention is the db4.2
[14:26] <lool> I: Found additional base dependencies: libdb4.2 python2.6
[14:27] <cjwatson> if the report doesn't mention it, that's a good sign that something weird is going on ...
[14:27] <cjwatson> lool: which architecture, to save me time?
[14:28] <lool> cjwatson: armel
[14:28] <lool> cjwatson: It's a foreign debootstrap of jaunty BTW
[14:28] <MacSlow> hm... what's -I meaning for debuild?
[14:28] <lool> debootstrap --arch=armel --keyring=/usr/share/keyrings/ubuntu-archive-keyring.gpg --verbose --foreign jaunty .
[14:28] <lool> MacSlow: Ignore vcs files when building the .tar.gz for native packages
[14:28] <MacSlow> the manpage to debuild doesn't state this paramter
[14:28] <lool> MacSlow: it's a dpkg-buildpackage flag
[14:29] <cjwatson> debuild's manual page says that most of its parameters are passed on to dpkg-buildpackage
[14:29] <MacSlow> lool, ah I was thing of -I (nclude) like in gcc
[14:33] <ogra> dpkg-preconfigure: unable to re-open stdin: ...
[14:34] <ogra> hmm, i wonder if that needs to worry me
[14:38] <MacSlow> dput is stuck
[14:39] <MacSlow> can one savely Ctrl-C a hanging dput?
[14:39] <cjwatson> ogra: probably not overly
[14:39] <pitti> MacSlow: yes
[14:39] <cjwatson> MacSlow: yes
[14:40] <MacSlow> hm... damn ... lp is dog-slow or so
[14:40] <MacSlow> no idea what's wrong
[14:40] <MacSlow> must be UIF causing tons of uploads :)
[14:41] <MacSlow> is there some local log I can look up to see why it might be hanging?
[14:42] <seb128> MacSlow: using edge or normal server?
[14:42] <MacSlow> ppa.launchpad.net
[14:46] <sistpoty|work> MacSlow: can you ftp to ppa.lp.net? if so, you can just upload the 4 files with ftp, (.changes file must be last) and see what's going wrong... dput does actually the same thing
[14:49] <pitti> asac: are we actually using the modem prober in jaunty now?
[14:50] <pitti> asac: I wonder what to do with bug 291333
[14:50] <pitti> with just hal-info, I'm between a rock and a hard place
[14:50] <pitti> you can't fix it for everyone :(
[14:50] <asac> pitti: could be that the latest package has a build system bug still
[14:50] <asac> pitti: do you have /lib/udev/nm*probe*
[14:50] <asac> ?
[14:51] <pitti> asac: no, I don't
[14:51] <pitti> ah, that's where it should be?
[14:51] <asac> hmm. ok thats the problem then
[14:51] <asac> pitti: yes
[14:51] <asac> pitti: todays upload will certainly have that then
[14:51] <pitti> asac: so it's meant to be used in jaunty, awesome
[14:51] <asac> yes for sure
[14:52] <pitti> asac: how does that work wrt. priorities? n-m uses the modem prober, and if that doesn't find anything, falls back to reading hal fdi?
[14:52] <pitti> or the other way round?
[14:52] <asac> pitti: yes. i played a bit around with changing that to "try hal" first, then udev
[14:52] <asac> but i guess we should at least have the "upstream" order in beta
[14:52] <asac> so we see if there are issues
[14:52] <pitti> asac: hm, so that way around I'd actually need to remove those hal-info entries
[14:52] <pitti> asac: *nod*
[14:53] <asac> pitti: i think we will prioritize udev over hal from what i can see now
[14:53] <pitti> asac: i. e. if the hal-info is wrong for some people (like in above bug), the nm-prober wouldn't fix it
[14:53] <asac> pitti: yeah. thats why we should use udev first
[14:54] <pitti> asac: ok; let's see how that works; if we need to swap the priority (in case the udev prober needs overrides for some hardware), please let me know, and I'll remove that fdi entirely
[14:54] <asac> pitti: let me check if dan already tagged rc3. i can upload that then
[14:55] <asac> seems not. i will prod him to do that now
[14:55] <MacSlow> sistpoty|work, I need the .dsc (1st), .tar.gz (2nd) and .changes (4th) ... what's the third file (.diff)?
[14:55] <ScottK> Yes
[14:55] <sistpoty|work> MacSlow: .diff.gz (in case you have it)
[14:55] <pitti> asac: ah, just found Dan's reply on the hal ML; he also says that hal is a fallback
[14:55] <sistpoty|work> MacSlow: basically all files mentioned in the .changes iirc
[15:02] <MacSlow> sistpoty|work, I'm not sure my manual ftp transfer triggered anything
[15:03] <sistpoty|work> MacSlow: triggered as in triggered a problem in dput, or as in makes the upload work in ppa?
[15:04] <MacSlow> sistpoty|work, makes the upload work in the ppa (e.g. I have yet to see it appear in the PPA-page or get an upload-confirmation email
[15:07] <sistpoty|work> MacSlow: ah, sorry... I just saw that the files need to be put to the remote directory "~%(ppa)s/ubuntu" (but I'm not exactly sure to what the ~%(ppa)s expands to
[15:08] <sistpoty|work> +)
[15:08] <BUGabundo> any reports of intel wifi 4965 stop working on Jaunty after linux-backports-modules-2.6.28 (2.6.28-8.7 upgrade?
[15:11] <sistpoty|work> MacSlow: however I assume that dput -s should give the hint of what it expands to ;)
[15:12] <pitti> james_w: o_O http://jameswestby.net/weblog/debian/09-for-the-record.html
[15:15] <ogra> james_w, liar
[15:15] <ogra> ogra@osiris:~$ apt-cache show crap|grep -i maintainer
[15:15] <ogra> W: Unable to locate package crap
[15:15] <ogra> E: No packages found
[15:30] <pitti> asac: do you have a lock on bug 317860 or shall I do that now?
[15:32] <asac> pitti: yes. antti is currently moving
[15:32] <asac> i wanted to get all the pending stuff from launchpad committed
[15:32] <pitti> okay
[15:32] <pitti> just saw it on the sponsoring queue
[15:32] <asac> but probably we have to prepatch that then
[15:33] <directhex> tseliot, tested it, nvidia 180 from jaunty works perfectly on intrepid, so is ripe for SRUdom
[15:33] <asac> sure. thanks for the prod. i have an update round on my high-prio todo list :)
[15:33] <asac> (not that its a short list)
[15:34] <tseliot> directhex: I'm not sure as to whether we should do an SRU for this. Have a look at this bug: https://bugs.launchpad.net/bugs/335879
[15:35] <directhex> tseliot, erm... what an odd bug
[15:35] <pitti> asac: wasn't meant to be a prod, I'm happy to do the upload; just checking whether anything should block it
[15:35] <tseliot> directhex: maybe you could file a backport request instead
[15:36] <emgent> it's official.. http://marketing.openoffice.org/ooocon2009/cfl/results.png
[15:36] <directhex> tseliot, if it's breaking systems, perhaps i should wait
[15:36] <asac> pitti:  i wanted to take all the other submissions we had. but given the long number of bugs we should just do it i guess
[15:36] <directhex> tseliot, it's in my PPA so i can use it that way
[15:36] <tseliot> directhex: even better ;)
[15:37] <directhex> tseliot, i put the latest upstream fglrx in there too for kicks
[15:37] <tseliot> directhex: good work :-)
[15:37] <asac> pitti: hmm. seems the bzr branch is broken :(
[15:37] <asac> sigh
[15:37] <directhex> tseliot, which needed gentle massage to compile *cough* superm1, that's your cue *cough*
[15:37] <asac> pitti: i guess you can just branch it and the pull the rest from playground
[15:37] <asac> or do it the old way
[15:37] <pitti> asac: broken how?
[15:38] <pitti> well, I'll figure it out
[15:38] <asac> pitti: all bzr playground syncs are broken on launchpad
[15:38] <asac> pitti: https://code.edge.launchpad.net/~network-manager/mobile-broadband-provider-info/trunk
[15:38] <directhex> tseliot, http://www.nvnews.net/vbulletin/showpost.php?p=1946545&postcount=46 implies 180.35++ should be fine
[15:38] <pitti> asac: ah, that; ok, no prob
[15:38] <asac> which is kind of a shame now that gnome mirrors everythng there
[15:39] <tseliot> directhex: good to know. This means that I won't have to revert to a previous version in Jaunty
[15:39] <directhex> tseliot, assuming the next revision happens before release
[15:39] <tseliot> directhex: yes, of course ;)
[15:39] <directhex> tseliot, got anyone you can poke into pushing a 180.36?
[15:40] <asac> pitti: just use http://bzr-playground.gnome.org/mobile-broadband-provider-info/trunk to get the latest or svn ;)
[15:40] <pitti> asac: yep
[15:40] <tseliot> directhex: usually I file a FFE and bug pitti for the upload :-P
[15:41] <directhex> tseliot, i meant at nvidia, to let them know you really really need 180.35++ before april
[15:42] <tseliot> directhex: there's Aaron Plattner and he's subscribed to that bug report
[15:44] <MacSlow> sistpoty|work, so now the manual upload worked
[15:44] <sistpoty|work> :)
[15:44] <MacSlow> sistpoty|work, still no idea what's wrong with dput
[15:45] <calc> doko: ping
[15:45] <sistpoty|work> MacSlow: maybe firewall problems (in case dput doesn't use passive mode)? (there should be an option to force passive mode for dput as well, can't recall right now)
[15:45] <Keybuk> cjwatson: the problem isn't the proposal, it's the length of it
[15:45] <Keybuk> I'm easily distracted
[15:45] <Keybuk> so if the proposal is pretty long and complicated, by about half way do..ooh, shiny
[15:45] <calc> anyone in here know how to tell ant to compile java app to a specific source version of java (eg javac -source 5 foo)?
[15:46] <ScottK> MacSlow: I'm finding LP very slow today, so it may just be hitting some internal timeouts.
[15:46] <doko> calc: ?
[15:46] <MacSlow> scottK: hm... manual ftp was super fast and responsive
[15:47] <calc> doko: do you know how to tell ant (i guess via build.xml?) to compile code using a specific java version eg javac -source 5 ?
[15:47] <ScottK> Maybe what sistpoty|work said about passive FTP then.  Dunno.
[15:47] <calc> doko: i am trying to port some old java code over to using default-jdk
[15:48] <doko> calc: javac -source 1.5
[15:48] <sconklin> asac (or anyone): I'm seeing some new and wrong behavior on my Intrepid desktop that apparently started with a recent update - as  kernel guy I'm not sure how to debug or report it. The little applet displays in the window manager panel aren't being displayed correctly. My screen is two displays which are tiled (laptop display and an external monitor).  If anyone can suggest what to report it against I'll put in a full descriptio
[15:48] <calc> doko: but how do i stick that into a cdbs rules that uses ant to build? :)
[15:49] <asac> sconklin: can you get me a screenshot that shows the problem
[15:50] <sconklin> well, it will take a photo because of the two screens.
[15:50] <sconklin> but yes
[15:50] <doko> calc: see the cdbs page, there is a marcro called ANT_ARGS or something like that
[15:50] <calc> doko: ok
[15:59]  * cjwatson buys Keybuk some attention span
[16:00] <Keybuk> you can buy that shit?
[16:03] <mneptok> DUDE! wait ... what?
[16:06] <superm1> directhex, what was missing from fglrx?  do you have some stuff needed for packaging?
[16:06] <directhex> superm1, ftbfs without xinerama added to build-deps
[16:07] <directhex> the binary lib, not the dev headers
[16:07] <Pici> 00
[16:07] <directhex> superm1, for catalyst 9.2, this is
[16:07] <sconklin> asac: sent screenshot link and description by  email
[16:08] <directhex> superm1, dpkg-shlibdeps: failure: couldn't find library libXinerama.so.1 needed by debian/xorg-driver-fglrx/usr/lib/libatiadlxx.so (its RPATH is '').
[16:08] <directhex> http://launchpadlibrarian.net/23372288/buildlog_ubuntu-hardy-amd64.fglrx-installer_2%3A8.582-0ubuntu1~intrepid~dhx1_FAILEDTOBUILD.txt.gz
[16:08] <superm1> directhex, did you check if phorogit had that already resolved?
[16:08] <superm1> directhex, http://www.phorogit.com/index.php?p=fglrx-packaging.git&t=097e896bf9c55b440b907541f6e3e18ff1414748
[16:09] <directhex> superm1, never heard of it!
[16:09] <superm1> directhex, yeah it looks like the packaging that got included in the 9.2 was a little behind what was in phorogit.  AMD regularly takes snapshots when they do releases
[16:10] <asac> sconklin: instead of mail you could have opened a bug directly ;)
[16:11] <savvas> erm.. is the default locale dir /usr/share/locale or /usr/share/locale-langpack ?
[16:11] <sconklin> asac: I will, just don't know what to report it against
[16:12] <slangasek> seb128: desktop ISOs grew 4 MB overnight, with most of the new packages coming from GNOME; any ideas what grew?
[16:12] <asac> sconklin: if its the applet its network-manager-applet to start with
[16:12] <asac> sconklin: let me look at mail. wait a sec
[16:13] <directhex> superm1, so i'm just behind the times, then. still, 9.2 packages for intrepid \o/
[16:13] <asac> sconklin: whats the subject?
[16:14] <sconklin> screenshot.
[16:14] <sconklin> no period
[16:14] <superm1> directhex, yeah i wish there was a good way to get those scripts updated on demand.  if you've got ideas, i'd be open
[16:16] <seb128> slangasek: no
[16:16] <seb128> slangasek: there was no major changes in GNOME packages as far as I know
[16:16] <slangasek> seb128: ok; I'll dig into it (and grumble some more about how we should store the package size info with the builds or in the logs :)
[16:17] <directhex> graph it, per package, using historic data from launchpad!
[16:21] <directhex> throw in some magic to let you see how much space a given dep tree used on a given timestamp, do it with ajax or flash or silverlight or something & make it responsive enough to be useful...
[16:26]  * directhex tickles jcastro 
[16:28] <ttx> slangasek: I just read your comment @ https://bugs.launchpad.net/ubuntu/+source/samba/+bug/254151/comments/4 -- I suppose we should abandon the proposed 'fix' in bug 312449, then ?
[16:31] <slangasek> ttx: yeah, no matter how obvious it might seem to restore a config file whose absence breaks the package, doing that automatically breaks one of the assumptions about how config files work in Debian...  if we think this is needed, then I would like it to get wider discussion on ubuntu-devel
[16:33] <ttx> slangasek: it's not really needed, it's just we keep on getting samba bug reports about it, so it's a triage effort to educate users to apt-get purge samba-common
[16:33]  * ttx ponders echoing a more useful error message
[16:33] <BUGabundo> apw: ping
[16:33] <BUGabundo> https://bugs.edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/193970?comments=all
[16:34] <BUGabundo> I'm one of those that lost WiFi
[16:34] <apw> BUGabundo, lets take that to #ubuntu-kernel
[16:35] <ttx> slangasek: Failing with <<Not replacing deleted config file /etc/samba/smb.conf -- run "sudo apt-get purge samba-common">> might help...
[16:35]  * ttx will adjust patch.
[16:36] <slangasek> ttx: should we tell them to purge the package, or just cp /usr/share/samba/smb.conf /etc/samba/smb.conf?
[16:36] <ttx> slangasek: cp sounds more productive.
[16:37] <savvas> About locale translations directory: should a program read /usr/share/locale-langpack as well as /usr/share/locale ?
[16:37] <liw> is there an .ics feed somewhere that actually has ubuntu release dates such as UI freeze?
[16:37] <ttx> "cp and dpkg --configure -a"
[16:38] <slangasek> liw: http://people.ubuntu.com/~vorlon/JauntyReleaseSchedule.ics
[16:38] <liw> slangasek, I have that configured in evolution, it doesn't show anything about a UI freeze :(
[16:38] <liw> no, wait
[16:39] <liw> webcal://people.ubuntu.com/~vorlon/UbuntuReleaseSchedule.ics
[16:39] <liw> that's what I have
[16:39] <slangasek> liw: that's not JauntyReleaseSchedule :)
[16:39] <liw> slangasek, so I need both?
[16:39] <cjwatson> or 'dpkg --force-confnew -i /var/cache/apt/archives/samba-common_whatever.deb'
[16:39] <cjwatson> UbuntuReleaseSchedule is the 10000-foot view
[16:39] <cjwatson> JauntyReleaseSchedule has the details
[16:39] <slangasek> cjwatson: is ucf going to honor --force-confnew?
[16:39] <cjwatson> slangasek: oh, ucf? probably not then
[16:40] <slangasek> it might! but I haven't tried :)
[16:40] <Mithrandir> we could teach it to, but currently dpkg doesn't pass it to subprocesses.
[16:40]  * slangasek nods
[16:40] <liw> cjwatson, slangasek: so I only need the JauntyReleaseSchedule one?
[16:41] <Keybuk> you could walk your pid and read its cmdline
[16:41] <Keybuk> ppid
[16:42]  * liw seems to have a long evening ahead of him, to fix a few UI problems in computer-janitor before tomorrow
[16:42] <slangasek> liw: you only need the {Jaunty,Karmic,Lackadaisical}ReleaseSchedules
[16:42] <slangasek> Keybuk: hiss
[16:42] <liw> slangasek, ok, thanks
[16:43] <seb128> slangasek: did you figure what changed between yesterday and today?
[16:43] <slangasek> seb128: not yet
[16:57]  * RainCT is back
[16:57] <RainCT> >> Btw, poweroff / reboot don't work anymore here since I updated my laptop to Jaunty ("halt" works, though)     -     Any idea?
[17:11] <slangasek> seb128: gnome-games-data grew by 2M
[17:11] <slangasek> seb128: I guess that's not really bloat and we should find room for it :)
[17:12] <seb128> slangasek: I guess that's extra translations and screenshots
[17:12] <slangasek> ah
[17:13] <slangasek> gnome-user-guide also grew by 1.6M
[17:14] <seb128> likely same story
[17:14] <seb128> I'm downloading the gnome-games-data to make sure
[17:15] <seb128> slangasek: gnome-games could be another good candidate for documentation split if we still want to win some CD space
[17:15] <_MMA_> Can anyone tell me if there's a written policy for installing *anything* to /root?
[17:16] <highvoltage> Has *anyone* at canonical actually looked at http://www.ubuntu.com/education/management#licence ?
[17:16] <slangasek> seb128: we're not desperate for CD space - I definitely have some langpacks I can kick off as needed - I'm just trying to stay on top of the size changes as they happen since that's way easier than figuring out where the space went afterwards
[17:16] <highvoltage> It says "All Ubuntu software is released under GPL, which means it is effectively licence free as opposed to free licence. "
[17:16] <Keybuk> cjwatson: been doing a bit of research into the whole /etc/adjtime thing
[17:16] <Keybuk> cjwatson: what was ppc using that for?
[17:16] <highvoltage> it also says "# Ubuntu is Licence Free"
[17:16] <Keybuk> because afaict, the contents of the file are never actually used by default
[17:16] <Keybuk> just kept up to date
[17:16] <slangasek> seb128: anyway, getting evolution off of python 2.5 is the first priority as far as space :)
[17:16] <slangasek> _MMA_: "don't"
[17:16] <seb128> slangasek: well, one of the things I would like for jaunty is as many language packs on the CD as possible
[17:17] <seb128> slangasek: doko said a rebuild would be enough and we did upload a new version?
[17:17] <Chipzz> _MMA_: I think it is considered a homedir just like other users' homedirs
[17:17] <Chipzz> which you shouldn't touch
[17:18] <Chipzz> slangasek: on that note, debian-installer DOES install a .profile etc in /root
[17:18] <Chipzz> or at least, sth does
[17:18] <_MMA_> slangasek: I need more than that. :) Why I worded things the way I did. Is what Chipzz said pretty much the reason? (the only one I could think of also)
[17:18] <calc> doko: how do i determine what the default -bootclasspath is so i can override it sanely?
[17:18] <slangasek> seb128: ah - must not have been a livefs rebuild yet with that version of python; I do see that the alternate CDs have come down in size
[17:18] <calc> doko: is there a way to have eg javac tell me?
[17:19] <seb128> slangasek: right, the current jaunty version depends on libpython2.6
[17:19] <slangasek> Chipzz: 'adduser' is what creates it in /root, using /etc/skel
[17:19] <Chipzz> slangasek: I don't think it is
[17:20] <Chipzz> slangasek: because the .profile etc for root differ from the .bash_profile for regular users
[17:20] <cjwatson> Keybuk: I think it was the same as x86, but don't honestly remember for sure - the powerpc-utils package is probably more useful than I
[17:20] <seb128> slangasek: gnome-games-data
[17:20] <seb128> Installed-Size: [-43088-] {+40264+}
[17:20] <seb128> Version: [-1:2.25.91-0ubuntu1-] {+1:2.25.92-0ubuntu1+}
[17:21] <cjwatson> highvoltage: meep. Is there a website bug on this?
[17:21] <Chipzz> ie regular users get a .bash_profile, root gets a .profile (which is substantially different from, and shorter than, the .bash_profile)
[17:21] <Keybuk> cjwatson: you said you found that ppc was putting magic times in there to cope with obscenely old clocks
[17:21] <seb128> slangasek: weird that the deb got bigger
[17:21] <Keybuk> and that ppc-utils was moving the file around?
[17:21] <slangasek> _MMA_: it is a homedir, and you shouldn't install things to it from a package for that reason, yes
[17:21] <cjwatson> Keybuk: and then I said that I'd said that without looking at the code, and when I looked at the code I found that it was basically just a hwclock clone
[17:21] <seb128> slangasek: in fact they added quite some localized screenshots
[17:21] <slangasek> seb128: hmmm, strange
[17:22] <Keybuk> cjwatson: oh, so it doesn't even use util-linux-ng's?
[17:22] <slangasek> seb128: unless the 'installed-size' between the two has been calculated on two different machines with different block sizes
[17:22] <cjwatson> Keybuk: but I also said that there was a problem unique to powerpc where hardware battery failures could result in negative Unix time after boot, which means that it's particularly important on those systems to ensure a vaguely current time even if the network is not avaiable
[17:22] <cjwatson> available
[17:22] <Keybuk> cjwatson: right, but if it's not using hwclock, it's nothing to do with me - right? :p
[17:23] <doko> slangasek: what are the current sizes?
[17:23] <slangasek> Chipzz: well, .profile != .bash_profile, obviously; I could be mistaken about whether d-i uses adduser when setting up the root account, but that seems like it'd be doing things the hard way
[17:23] <highvoltage> cjwatson: LaserJock has just alerted news2000, I'll check check with him whether there's a bug
[17:23] <cjwatson> Keybuk: the reason various people mentioned you was that the removal of adjtime broke installation of the powerpc-utils package
[17:23] <cjwatson> Chipzz: base-files installs /root/.profile in its postinst
[17:23] <Keybuk> cjwatson: but I only changed the util-linux-ng postinst
[17:23] <Keybuk> not ppc-utils
[17:23] <seb128> slangasek: dpkg-deb -x and du gives 27 to 29 megas
[17:23] <Chipzz> slangasek: hrrrm I was mistaken too; regular users get a .profile; but it's still different
[17:23] <seb128> slangasek: I guess the "installed-size" is not smart about symlinks?
[17:24] <cjwatson> Keybuk: didn't you arrange for /etc/adjtime no longer to be created at installation?
[17:24] <doko> calc: why would you want to override it? afaik _rene_ did do some experiments on this, so maybe ask him
[17:24] <Keybuk> cjwatson: no, just removed on upgrade
[17:24] <Keybuk> in the util-linux postinst
[17:24] <slangasek> doko: currently, 715/717 MB for the desktop CDs; python2.5 is still on there, looking into that now
[17:24] <seb128> slangasek: the new version added some localized screenshots, which means symlinks replaced by real files
[17:24] <_MMA_> slangasek: Thanx man. There's a desire floating around to make the theme look more "cautious" when using su/sudo/root. Something like some of the XFCE apps do. It involved having a theme in /root. On to find plan "b".
[17:24] <Keybuk> I don't know what creates it
[17:24] <Chipzz> cjwatson: thx :)
[17:24] <Keybuk> you suggested base-files
[17:24] <Keybuk> but I haven't looked into that
[17:24] <cjwatson> Keybuk: all I know is that TheMuso said stuff now broke
[17:24] <Keybuk> :)
[17:24] <cjwatson> I no longer have a functioning powerpc system to try it out myself
[17:25] <slangasek> seb128: hrm, it certainly should account for symlinks, AFAIK 'installed-size' is meant to be equivalent to 'du' :)
[17:25] <Keybuk> me neither
[17:25] <cjwatson> installed-size is implemented with du -k -s
[17:25] <Keybuk> cjwatson: base-files does create one though
[17:25] <seb128> slangasek: well it's not
[17:25] <cjwatson> or 'cd $builddir && du -k -s .' really
[17:25] <seb128> $ du -ksh 91
[17:25] <seb128> 27M	91
[17:25] <cjwatson> Keybuk: yes
[17:25] <Keybuk> in its postinst
[17:26] <seb128> $ dpkg -I gnome-games-data_2.25.91-0ubuntu1_all.deb | grep Install
[17:26] <seb128>  Installed-Size: 43088
[17:26] <Keybuk> cjwatson: and, in fact, hard-codes an assumption that the hardware clock is in UTC :p
[17:26] <seb128> where 91 is a dpkg-deb -x deb 91
[17:26] <Keybuk> bet the installer doesn't change that
[17:26] <cjwatson> Keybuk: I suspect the correct fix is to migrate whatever changes are in clock (the powerpc-utils one), migrate those to util-linux-ng, and then find whatever's calling the one from powerpc-utils and make it call the one from util-linux-ng insteas
[17:27] <cjwatson> instead
[17:27] <Keybuk> right
[17:27] <cjwatson> I don't think anyone is particularly attached to there being a separate version
[17:27] <Keybuk> *separately* to that
[17:27] <Keybuk> we need to decode whether or not we want an /etc/adjtime on our system
[17:27] <Keybuk> if we do, I'll remove the rm from the util-linux postinst
[17:27] <Keybuk> if we don't, we should remove its creation from the base-files postinst
[17:27] <TheMuso> cjwatson: I don't think the utility from powerpc-utils actually gets used any more, so far as I checked. i.e its not used as an alternative, however I'll have to check that again.
[17:28] <slangasek> seb128: ok, I have no idea.  Maybe the buildd it builds on is using very large blocks
[17:28] <Keybuk> I removed it because it's not *used*
[17:28] <Chipzz> cjwatson, Keybuk: on a seperate note, I'm doing automated installs using debian-installer and preseeding. in some cases I want to install configs in /etc . what should be the preferred way to do that?
[17:28] <Keybuk> hwclock just keeps updating it
[17:28] <Keybuk> which incurs a time cost
[17:28] <seb128> slangasek: ok, anyway the change is extra screenshots for localized documentation
[17:28] <Keybuk> so I saved a few tenths of a second on boot and shutdown by not using it
[17:29] <Keybuk> cjwatson: what are your thoughts here?
[17:29] <cjwatson> Keybuk: the remaining value in base-files' creation of /etc/adjtime is that it gives a vaguely sane lower bound on the possible system time. I suggested that we replace this by having hwclock compare the system time with the timestamp on its own executable
[17:29] <cjwatson> or something similar
[17:30] <Keybuk> ah
[17:30] <cjwatson> since the executable timestamp will be preserved during installation when extracting it with tar
[17:30] <Keybuk> you're missing the key piece of evidence
[17:30] <Keybuk> you can put whatever you like in that file
[17:30] <Keybuk> *hwclock doesn't use it*
[17:30] <cjwatson> clock (from powerpc-utils) does
[17:30] <Keybuk> so right now, the only purpose creating that file has, no matter what you put in it, is to slow down the boot and shutdown by a few tenths
[17:30] <cjwatson> that being the point of its postinst
[17:30] <Keybuk> that may be the key difference
[17:31] <cjwatson> I suggest that you go and read its source; it should not take long
[17:31] <Keybuk> if the ppc hwclock uses it as a baseline
[17:31] <Keybuk> but TheMuso says ppc doesn't use it anymore?
[17:31] <cjwatson> it will certainly be faster than debating it with me, who has only gone and glanced over it :)
[17:31] <Keybuk> cjwatson: what's the source package name?
[17:31] <cjwatson> powerpc-utils
[17:31] <TheMuso> powerpc-utils
[17:31] <Keybuk> not debating, seeking advice
[17:31] <cjwatson> I'm not actually asserting that powerpc's clock setup is bug-free - not in the slightest
[17:31] <cjwatson> it is entirely possible that it does not work properly
[17:32] <cjwatson> nevertheless, this is a well-understood problem for those who have dealt with powerpc systems :)
[17:32] <cjwatson> we used to get Ubuntu bug reports fairly frequently that people rebooted their Mac and then the desktop wouldn't start
[17:32] <cjwatson> and this turned out to be due to the clock
[17:32] <cjwatson> so even if it doesn't get handled correctly right now, I think it should
[17:33] <cjwatson> Keybuk: I think what you're missing is that I'm trying to describe what I think the correct state of affairs should be, rather than what the current state of affairs is :-)
[17:33] <ogra> seb128, hey, i'm finally able to reproduce that gnome-keyring-daemon hang here ... getting the dbg version now and will attach some info to the bug
[17:33] <cjwatson> I can no longer remember whether clock is called from anywhere
[17:33] <seb128> ok thanks
[17:33] <Keybuk> TheMuso: does ppc still use this clock util instead of hwclock?
[17:33] <seb128> ogra: upstream is very responsive if you want to take that to bugzilla directly
[17:34] <ogra> strace just tells me FUTEX_WAIT if i attach to the process
[17:34] <cjwatson> but something along the lines of the above is the obvious way to fix this class of bugs
[17:34] <TheMuso> Keybuk: as I said above, I don't think so, but I would need to check on a working system.
[17:34] <seb128> ogra: would avoid having somebody doing the bug tracker pingpong for nothing
[17:34] <ogra> seb128, understood
[17:34] <seb128> ogra: and they know their code better
[17:34] <ogra> yup, though i'D love to know if its really only arm
[17:35] <Keybuk> TheMuso: right, there's no init script in this package
[17:36] <seb128> ogra: we got no ubuntu desktop user running into that yet
[17:36] <seb128> ogra: so it's setup or arch specific
[17:36] <ogra> seb128, yeah, thats what i thought
[17:38] <liw> I'm working on a new description for computer-janitor-gtk's main window. How does this sound: "This application helps you find and remove software packages that might not be needed anymore. It also suggests configuration changes that might benefit your system."
[17:38] <cjwatson> I haven't thought hard about it, but just in case nobody else says, "anymore" => "any more"
[17:38] <Keybuk> cjwatson: some brief packaging archaeology indicates that Ubuntu has *never* used clock on ppc
[17:38] <Keybuk> it's always used hwclock
[17:38] <cjwatson> Keybuk: ok
[17:39] <Keybuk> and Debian hasn't for almost 8 years either ;)
[17:39] <Keybuk> +powerpc-utils (1.1.3-4) unstable; urgency=low
[17:39] <Keybuk> +
[17:39] <Keybuk> +  * Actually change maintainer name this time.
[17:39] <Keybuk> +  * No longer divert hwclock.sh; Debian kernels have included CONFIG_PPC_RTC
[17:39] <Keybuk> +    for a long enough time now.  Document the issue.  (Closes: #99875).
[17:39] <Keybuk> +  * Builds on current unstable now.  (Closes: #99735).
[17:39] <Keybuk> +
[17:39] <Keybuk> + -- Daniel Jacobowitz <dan@debian.org>  Sun, 15 Jul 2001 22:01:36 -0700
[17:39] <cjwatson> would it be worth ensuring that the necessary magic from clock.c is now in hwclock.c?
[17:39] <Keybuk> cjwatson: that's the thing, there isn't any "necessary magic"
[17:39] <liw> cjwatson, I'll change it to "any more"
[17:39] <cjwatson> Keybuk: aha
[17:39] <Keybuk> you could do the same by just calling hwclock --adjust on boot
[17:40] <cjwatson> in that case I see no reason why we can't just delete the adjtime stuff from powerpc-utils.postinst
[17:40] <Keybuk> and we know why we don't want to do that :p
[17:40] <Keybuk> cjwatson: TheMuso already has
[17:41] <Keybuk> cjwatson: so separately to that, do we want to patch hwclock to use a common timestamp as a lower-bound for whatever it sets the system time to?
[17:42] <cjwatson> Keybuk: I'm just thinking about how it will appear to users
[17:42] <cjwatson> obviously we want to ensure that Unix time is always >= 0
[17:42] <cjwatson> but it occurs to me that it might be rather confusing if it gets set to a (to a user) essentially random time
[17:42] <cjwatson> which happens to be sometime around the release of your operating system
[17:43] <cjwatson> maybe the correct approach is if (time < 0) time = 0;
[17:43] <cjwatson> that way they say "hey, my computer says it's in January 1970" and we can easily say "ah, your hardware battery appears to have been eaten by a gorilla"
[17:44] <cjwatson> and a lot of people would recognise "clock in January 1970" as a symptom of a hardware bug, whereas "clock in March 2009" maybe not so much
[17:44] <cjwatson> yes, I have persuaded myself
[17:45] <Keybuk> why would time be < 0 ?
[17:45] <Mithrandir> because macs are special.
[17:45] <Keybuk> I'm just tracing the effect of the current adjtime file on hwclock
[17:46]  * slangasek raises his fist at the battery-eating ape. "Koooooooooong!"
[17:46] <Keybuk> base-files sets last_adj_time = <bignum>
[17:46] <Keybuk> and last_calib_time = <same bignum>
[17:46] <Keybuk> but drift_factor=0.0 and not_adjusted=0.0
[17:47] <Keybuk> only drift_factor and last_adj_time are used
[17:48] <cjwatson> Keybuk: the reason why time might be <0 is that the Mac epoch is somewhere in 1904
[17:48] <Keybuk> and last_adj_time is subtracted from the current time and multipled by the factor
[17:48] <Keybuk> which is 0
[17:48] <cjwatson> so if a Mac's CMOS-battery-equivalent fails, it starts up with the hardware clock in 1904 by default
[17:48] <Keybuk> so the adjustment will always be 0
[17:48] <Keybuk> thus the current base-files adjtime does nothing useful to hwclock
[17:48] <cjwatson> I believe you
[17:48] <Keybuk> it just says "hey, the clock last had 0 drift at <some time>"
[17:48] <Keybuk> I suspect this is a regression from clock.c
[17:49] <cjwatson> I'm not saying that /etc/adjtime in base-files is the right approach :)
[17:49] <Keybuk> I know, I'm just following through all the lines to make sure I'm not missing the pachyderm in the pantry
[17:50] <Keybuk> *blink*
[17:50] <Keybuk> err
[17:50] <Keybuk> clock.c multiplies by the drift factor as well
[17:52] <Keybuk> so unless I'm mistaken
[17:52] <Keybuk> this "writing some standard time into adjtime" has no effect
[17:52] <Keybuk> and didn't have any effect on ppc either
[17:53] <cjwatson> maybe that wasn't the intent at all
[17:53] <cjwatson> I never actually saw a reason for it, and was extrapolating based on a best guess
[17:53] <Keybuk> the field it puts it in is just a comment, basically
[17:53] <Keybuk> hwclock and clock.c only use it to avoid adjusting more than once a day
[17:53] <cjwatson> perhaps the adjtime increments on all of Santiago's base-files uploads were for some other reason - an attempt to minimise drift?
[17:53] <Keybuk> again, wouldn't have any effect; the drift factor being 0.0 would tell hwclock to start afresh
[17:55] <Keybuk> does Santiago IRC? :p
[17:59] <Keybuk> (ie. could we ask him why he periodically updates it)
[18:00] <slangasek> no, he doesn't
[18:04] <LaserJock> james_w: what do you mean by "LTS doesn't know what LTS+1 is going to be called"?
[18:05] <james_w> to implement it by mime types you would need to name the type for each cd differently
[18:05] <RainCT> LaserJock: Karmic+1 has no name yet
[18:05] <james_w> e.g. x-content/ubuntu-cd-jaunty
[18:05] <LaserJock> why don't we use the release numbers?
[18:05] <james_w> I guess you could
[18:06] <cjwatson> Keybuk: usually fairly responsive to mail IIRC
[18:06] <Keybuk> int rtc_valid_tm(struct rtc_time *tm)
[18:06] <Keybuk> {
[18:06] <Keybuk>         if (tm->tm_year < 70
[18:06] <Keybuk>                 || ((unsigned)tm->tm_mon) >= 12
[18:06] <Keybuk>                 || tm->tm_mday < 1
[18:06] <Keybuk>                 || tm->tm_mday > rtc_month_days(tm->tm_mon, tm->tm_year + 1900)
[18:06] <Keybuk>                 || ((unsigned)tm->tm_hour) >= 24
[18:06] <Tm_T> LaserJock: james_w: release numbers maight move too
[18:06] <Keybuk>                 || ((unsigned)tm->tm_min) >= 60
[18:06] <Keybuk>                 || ((unsigned)tm->tm_sec) >= 60)
[18:06] <Keybuk>                 return -EINVAL;
[18:06] <Keybuk>         return 0;
[18:06] <Keybuk> }
[18:06] <Keybuk> EXPORT_SYMBOL(rtc_valid_tm);
[18:06] <Keybuk> oops
[18:06] <Keybuk> overpaste
[18:06] <Keybuk> but anyway, the kernel itself rejects any hardware clock with a year < 1970
[18:06] <LaserJock> Tm_T: how do you mean?
[18:06] <james_w> LaserJock: really the issue is that the spec doesn't have room to say x-content/ubuntu-cd-${something you find from the disk, i.e. release number}
[18:07] <Tm_T> LaserJock: I know it's not expected, but remember 6.06 (:
[18:07] <LaserJock> Tm_T: no, but there's logic ther
[18:07] <james_w> LaserJock: if you read the shared-mime-info spec and can come up with a workable solution then please propose it
[18:07] <LaserJock> well, I don't care about the mime stuff
[18:07] <LaserJock> I think we need logic
[18:07] <LaserJock> I don't care where it is
[18:07] <LaserJock> just have the mime call a wrapper that does the proper logic
[18:08] <slangasek> cjwatson: what does this error point to?: Missing debootstrap-required python2.5-minimal
[18:08] <slangasek> (alternate CD build failure)
[18:08] <james_w> LaserJock: ok, please provide that logic in such a way that it can be reasonably integrated in to Ubuntu and I will happily review it. I couldn't see a way to achieve what you want given the current state of things
[18:09] <kees> does anyone know the right magic for CDBS to run test.py from a python package?
[18:10] <Keybuk> kees: three chicken livers, a raw egg and twice widdershins by candle light iirc
[18:10] <LaserJock> james_w: I would think x-content/ubuntu-cd could call a wrapper script that checks /etc/lsb-release and the .iso contents and pops up the appropriate dialog
[18:10] <LaserJock> james_w: does that make sense?
[18:10] <elmo> speaking of clocks, it's never been clear to me why something (userland or kernel) doesn't automatically slew the time to 2009-01-01 12:00 if it finds the clock is set earlier than that
[18:11] <elmo> it would avoid the mac 1904 thing breaking your desktop, if nothing else
[18:11] <Keybuk> elmo: that's pretty much the discussion we're having
[18:11] <elmo> oh, ok
[18:11] <elmo> sorry
[18:11] <james_w> LaserJock: apart from the fact that you are talking about a string running code, yes. Please go look at what is available and you will see that that is not so easy in the current framework.
[18:11] <Keybuk> it looks like santiago regularly updates /etc/adjtime in base-files with a value Colin *thinks* is precisely for that purpose
[18:11] <Keybuk> but nothing will use that
[18:12] <elmo> \o/
[18:13] <LaserJock> james_w: I didn't say it was easy, I just said that seems like the most logical way to handle use cases and be non-confusing to users
[18:13] <james_w> LaserJock: I agree
[18:14] <james_w> LaserJock: my proposal was something that for little effort could improve the situation. If you want to put in more effort and improve it further I have no problem with you doing so.
[18:15] <LaserJock> james_w: I just don't want the Ubuntu Education CD to open nautilus, if our current popup still happens then I'm certainly OK with what you're doing
[18:15] <cjwatson> slangasek: usually wrong priorities (see priority-mismatches.txt); but I already adjusted those priorities today
[18:15] <cjwatson> slangasek: so I think that that should clear itself up tomorrow
[18:15] <slangasek> ok, thanks
[18:16] <james_w> LaserJock: well, that's not what I understood from your email
[18:16] <slangasek> I'll probably do another CD build run today, to check sizes
[18:16] <LaserJock> james_w: that my only real concern
[18:16] <LaserJock> james_w: "what'd be nice" is different ;-)
[18:17] <james_w> LaserJock: in fact reading your email again I still don't get that message
[18:17] <kees> Keybuk: I hate adding chicken livers to the build-deps
[18:18] <LaserJock> james_w: oh? I certainly wasn't attacking your proposal
[18:19] <TheMuso> ab/c
[18:19] <LaserJock> james_w: just saying that perhaps we can do even better (whatever the time frame) by adding more logic
[18:19] <james_w> LaserJock: no, but you seemed to be talking about the other thing more, and I completely missed the fact that you didn't want nautilus to open
[18:20] <LaserJock> james_w: well, that's because I just have the one use case in the Edu CD
[18:20] <LaserJock> so I was trying to speak generally
[18:21] <LaserJock> but the Edu CD is a concern for me regarding how the CD is opened
[18:21] <LaserJock> as that's actually our "installer"
[18:53] <sconklin> TheMuso: I have a bug reported against alsa and I'm not familiar with the structure or how to tell if it's kernel vs. userspace - if you suspend and resume with the headphones plugged in, you never get the speakers back on no matter whether the headphone is unplugged. Any advice?
[18:53] <sconklin> I need a skooling in alsa
[18:55] <TheMuso> sconklin: bug number?
[18:56] <sconklin> TheMuso: in another chat
[18:56] <TheMuso> sconklin: gotcha
[18:57] <superm1> sconklin, wouldn't that likely be an EAPD bit not getting set correctly on the kernel side most likely after resume?
[18:58] <sconklin> superm1: could be, I've not dealt with sound at all really
[19:08] <mvo> doko: re the python relaeated upgrade question you asked during the meeting. there is currently #337705 pending, that needs to get resolved before we can give green light for upgrades again
[19:17] <kirkland> mvo: hi there, around?
[19:18] <mvo> kirkland: yes, but almost ready to leave for the evening
[19:19] <kirkland> mvo: okay, could you please point me to the file that updates /var/run/updates-available?
[19:19] <kirkland> mvo: there's a minor tweak i'd like to test, and send you a patch for
[19:19] <kirkland> mvo: basically, removing that file is giving me problems;  would be much better if it printed "0 updates available" instead ...
[19:21] <tedg> So why am I blocked from calling ConsoleKit's "GetSessions" when I can just introspect on the ConsoleKit object and get the paths that are on the object anyway?
[19:22] <Keybuk> a bug?
[19:22] <tedg> Just the latter one forces me to parse the strings to determine which are sessions (oh, and all the XML)
[19:22] <mvo> kirkland: debian/99update-notifier removes it again
[19:22] <mvo> kirkland: (in the lp:update-notifier source)
[19:22] <kirkland> mvo: awesome, thanks.
[19:23] <kirkland> mvo: i'll get this tested, and have a patch for you to review tomorrow
[19:23] <tedg> Keybuk: Hmm, so you don't see any reason?
[19:23] <mvo> kirkland: ok, thanks
[19:23] <Keybuk> tedg: no formal reason
[19:23] <Keybuk> it's either a bug that you can introspect
[19:23] <Keybuk> or a bug you can't call getsessions
[19:23] <mvo> kirkland: on desktop system this should not be a issue because update-notifier is running all the time and notices that the cache changed and that it needs to update that file
[19:24] <mvo> kirkland: for the server it is of course
[19:24] <tedg> Keybuk: Do you know of any security issues with knowing how many sessions there are?
[19:24] <Keybuk> *shrug*
[19:24] <Keybuk> not off hand ;)
[19:24] <ogra> ck-list-sessions showsw them all anyway
[19:25] <mvo> kirkland: it would be nice if the calcuation would not be duplicated, ie. if the running u-n picked up the change already it should not be done agan by update-motd (but we can talk how to do this tomorrow)
[19:25] <tedg> ogra: Hmm, so why can I do that, but I can't call it over DBus.  Does 'ck-list-sessions' not do DBus?
[19:25] <ogra> no idea :)
[19:25] <ogra> i just know that it shows all sessions
[19:26] <kirkland> mvo: you bet
[19:32] <tedg> Heh, so ck-list-sessions doesn't call "GetSessions" it calls "GetSeats" and then "GetSessions" on each seat, which I'm allowed to do :)
[19:33] <liw> slangasek, are you around? I'd like to ask about an ffe for computer-janitor, for some UI fixes
[19:33] <slangasek> liw: hi
[19:39] <liw> slangasek, this is embarrassingly basic, but... I'd like to have a new version of computer-janitor uploaded, with three UI changes and a package description change, all pretty small; should I file bugs to request freeze exception before the package gets uploaded, or should the upload happen first?
[19:40] <beuno> liw, computer-janitor!  I'm happy to see you solved it  :)
[19:40] <tedg> Keybuk: Do you know where that policy is set?  It seems like the consolekit stuff in /usr/share/PolicyKit/policy doesn't set these functions.
[19:40] <liw> beuno, I failed to solve the more glaring usability problems, alas
[19:41] <slangasek> liw: bug first; if you upload, the package will go straight into the archive, so that gives the release team no opportunity to object
[19:41] <beuno> liw, did my suggestions not really fix the problem?
[19:41] <Keybuk> tedg: that sounds like simple dbus policy
[19:41] <Keybuk> so /etc/dbus-1/system.d
[19:41] <liw> beuno, I failed to find a good way to implement them and the UI freeze snuck up on me, since I had subscribed to the wrong calendar and I generally suck
[19:42] <gencho> by default ? :)
[19:42] <beuno> liw, argh, sorry to hear that. Let me know if I can help you at all at any point
[19:42] <liw> slangasek, ack; and should I file bugs for the UI change that didn't have a bug, and the package description change?
[19:42] <liw> beuno, sure, thanks
[19:42] <slangasek> liw: well - we're not in UI freeze yet, could those changes get in before tomorrow without a UIFe?
[19:43] <slangasek> liw: in any case, it's preferable from my end to have a single bug documenting all the changes in the upload, so I can review it at once
[19:43] <liw> slangasek, hm, I'm confusing myself, I think... they're not really feature changes, either, so perhaps I don't need feature freeze exceptions either
[19:44] <slangasek> liw: if that means adding information to the existing bug, or filing a completely new bug with a summary, either is fine for me
[19:44] <slangasek> liw: but if you can upload it without a freeze exception at all, even better, that saves us both time on paperwork :)
[19:45] <liw> slangasek, I'll decide that I don't need freeze exception at all, thanks; now I just need to find someone to upload this to main
[19:45] <tedg> Keybuk: Yup, that's what I wanted, thanks!
[19:46] <slangasek> liw: if you don't find anyone else, throw it at me and I can commit to uploading it before end of day
[19:46] <liw> slangasek, thank you
[19:46]  * liw waves to mvo
[19:49] <jelmer> didrocks, ping
[19:50] <didrocks> jelmer: pong
[19:50] <slangasek> liw: please be explicit that you're doing this, of course, so I know it's on my todo list :)
[19:50] <liw> slangasek, of course
[19:50] <liw> slangasek, I'll e-mail you if I can't lure mvo into uploading for me
[19:50] <slangasek> ok
[19:53] <davmor2> meh I just found a bug but I'm not sure what to report it against.  If you use the youtube plugin in totem and get the codec update so it works you then can't install ubuntu-restricted-extras from add/remove? So what is at fault is it totem for installing the wrong thing, add/remove for poor package management or the codec that is causing the issue?
[19:55] <slangasek> pitti, doko: FYI, I'm taking care of transitioning postgresql-8.3 to python 2.6
[19:56] <davmor2> D'oh wrong channel I need to look up from time to time :(
[19:56] <didrocks> jelmer: ? :)
[19:57] <jelmer> didrocks: sorry
[19:57] <jelmer> didrocks, I was wondering what's left to be done for evolution-mapi
[19:58] <didrocks> jelmer: it's ok, it will entered soon the archives. seb128 gave the FFe
[19:58] <jelmer> didrocks: cool, thanks!
[19:58] <didrocks> jelmer: you're welcome :)
[19:59]  * didrocks is striking on a yelp regression…
[20:12] <jdstrand> doko: fyi-- I responded to your questions in bug #337705 (letting you know here since I didn't see you were subscribed to the bug)
[20:21] <pitti> slangasek: /away -all
[20:21] <pitti> argh, sorry
[20:21] <pitti> slangasek: oh, ok; will grab the diff from LP then and commit it to Debian
[20:21] <slangasek> pitti: the diff is "build1"
[20:21] <pitti> :)
[20:22] <mvo> jdstrand: I outlined a possible workaround there as well (not a great one, but good enough)
[20:22] <mvo> jdstrand: the upgrade test is still running
[20:22] <jdstrand> mvo: you mean python conflicting with versioned ufw?
[20:23] <mvo> jdstrand: yes
[20:24] <jdstrand> mvo: it seems we are seeing this primarily because ufw is a python app that uses triggers...
[20:24] <jdstrand> mvo: it would be best if this could be handled within ufw, since we know there will eveentually be other python transitions
[20:25] <calc> ugh i crashed strace
[20:25] <mvo> jdstrand: I think it will be less of a issue with the next transition because now it has "Depends: python (>= 2.5), python (<< 2.7)
[20:25] <calc> it helps if debugging utilities weren't buggy themselves, lol :)
[20:26] <mvo> jdstrand: this will ensure that on the next transition ufw will get updated to a new version before the new python gets installed
[20:26] <mvo> jdstrand: I put that as a altnernative (less good) solution to issue a update for the intrepid version that does the same (for python (<< 2.6)
[20:27] <doko> mvo, jdstrand: well, but it won't help if we have only one python version in the distro?
[20:27] <mvo> jdstrand: more robustness inside ufw is always a plus of course :) I'm not sure what the best way to handle this is inside ufw, I do not enough enough about it
[20:28] <mvo> doko: what would not help? the >= 2.5,  <<2.7 depends?
[20:28] <jdstrand> mvo: I suppose I could program defensively around frontend.py not being available, but it would necessarily have to exit
[20:28] <jdstrand> mvo: and we lose the trigger...
[20:28] <doko> mvo: ahh, ok, but then the package could be updated in intrepid as well?
[20:29] <mvo> jdstrand: I guess the question is what does a missed trigger mean
[20:29] <doko> jdstrand: are the iptables still in place when the package is removed?
[20:29] <ivoks> seb128: ping
[20:29] <jdstrand> mvo: it ends up being called later in the upgrade, so I don't think it would be too horrible
[20:29] <mvo> doko: right, I put that as a solution into the bugreport, its not ideal though because people may upgrade without intrepid-updates (e.g. when they do CD->CD upgrades without network)
[20:30] <mvo> jdstrand: sounds like a good solution then, does not help for the problem with the intrepid version though
[20:30] <jdstrand> doko: yes. default is set to ACCEPT on purge
[20:30] <seb128> ivoks: contextless ping gives no reply
[20:30] <mvo> we could do some magic in update-manager (e.g. killing the trigger before the upgrade or something ugly like that). but I would prefer a solution that avoids that
[20:30] <ivoks> seb128: evolution-mapi didn't work at all; evolution crashed on authentication
[20:30] <doko> ok, so the rules stay intact during upgrade
[20:30] <ivoks> seb128: right, sorry
[20:31] <jdstrand> doko: heh, I meant 'no. default is set to ACCEPT on purge'
[20:31] <seb128> ivoks: oh? did you get a stacktrace?
[20:31] <seb128> ivoks: thanks for testing
[20:31] <doko> jdstrand: but not on remove?
[20:31] <doko> or upgrade
[20:31] <ivoks> seb128: not yet, i'll test more... i got vpn connection to that site, so i'll investigate more these days
[20:32] <jdstrand> doko: putting triggers aside, remove and upgrade does not touch the iptables rules
[20:33] <doko> jdstrand, mvo: another solution would be to create another symlink farm in /usr/share/ufw/lib or something like this, and fall back to this if the module cannot be found on sys.path. ugly as well ...
[20:33] <seb128> ivoks: thanks!
[20:33] <mvo> doko: and would mean to update the intrepid version again :/
[20:34] <tedg> It seems that ConsoleKit is failing to build, but I'm reasonably certain I didn't do it :)  Is there any reason the documentation would fail to build?  http://www.tighturl.com/c1w
[20:34] <doko> mvo: please could you update python-defaults then? I'm away then. so it's not a packaging helper problem.
[20:35] <mvo> doko: sure, is it maintained in bzr or should I just use the package
[20:35] <mvo> doko: no helper problem, just a general upgrade problem
[20:36] <ivoks> seb128: np
[20:36] <mvo> (I initially though it was a unpack/configure race, but that was not it)
[20:36] <mvo> tought
[20:36] <mvo> thought *sigh*
[20:36]  * mvo needs sleep
[20:36] <jdstrand> heh
[20:37] <jdstrand> mvo: I can certainly fix jaunty and do an SRU for intrepid which would minimize the impact
[20:38] <jdstrand> mvo: but if you are adjusting python deps, I guess the SRU is not needed
[20:38] <jdstrand> s/deps/conflicts/
[20:38] <mvo> jdstrand: yeah, I think so too
[20:38] <mvo> jdstrand: the sru is not sufficient to deal with all users so we can as well skip it and add the workaround
[20:39] <jdstrand> mvo: can you add a task to the bug for whatever python package needs updating? will you handle the change to that package or shall I?
[20:41] <mvo> jdstrand: I can do the python update
[20:41] <calc> anyone know why i see weird stuff in my strace log like this: 22379 14:39:51.796775 read(56, "\1\0\0\0\2\0\0\0\0\0\0\0\20\0\0\0output.strace\0\0\0"..., 1024) = 32
[20:41] <calc> it looks like strace is dumping some of its own info into the strace output file
[20:41] <jdstrand> mvo: cool, thanks. I'll fix up ufw
[20:45] <davmor2> Meh launchpad keeps timing out on me :(  is there anyway that libavcodec52 and libavutils49 can be replaced by lbavcodec-unstripped-52 and libavutils-unstripped-49
[20:46] <davmor2> meh sorry hit enter. when upgrading from totem's codec install to ubuntu-restricte-extras
[20:47] <davmor2> s/restricte/restricted
[20:53] <oliver_g_1> hi
[20:53] <oliver_g_1> I tried running `bzr  branch "http://package-import.ubuntu.com/v/vino/jaunty"` on my Debian Lenny system, and it complained that "Bazaar Branch Format 7 (needs bzr 1.6)"...
[20:54] <oliver_g_1> is there a mirror available of these repos which works with older bzr versions as well?
[20:54] <oliver_g_1> (bzr on my system is at 1.5-1.1)
[20:55] <oliver_g_1> or, do you know another way to quickly see the changes between Vino from Intrepid and Vino from Jaunty?
[21:02] <Rocket2DMn> pitti, ping, can I borrow a moment of your time?
[21:03] <LaserJock> oliver_g_1: you could grab the actual source packages and debdiff
[21:04] <oliver_g_1> LaserJock: sounds good
[21:05] <oliver_g_1> LaserJock: what would be the command to get a diff between two source packages?
[21:06] <LaserJock> oliver_g_1: debdiff <first package>.dsc <second package>.dsc
[21:07] <calc> how do i set a breakpoint for c++ code that has weird parameters?
[21:10] <oliver_g_1> LaserJock: thanks, that worked nicely
[21:10] <oliver_g_1> with 2x dget and then debdiff
[21:17] <pitti> persia, TheMuso: could you please pull lp:~pitti/usplash-theme-ubuntustudio/usplash-theme-4/ into lp:~ubuntustudio-dev/usplash-theme-ubuntustudio/ubuntu ? I just uploaded it
[21:17] <TheMuso> pitti: sure, will take care of that now.
[21:18] <pitti> TheMuso: thank you
[21:22] <LaserJock> pitti: were you planning on updating edubuntu's usplash?
[21:22] <pitti> LaserJock: yes, I'm doing them all
[21:23] <LaserJock> pitti: don't bother, I'm removing it altogether
[21:23] <pitti> LaserJock: oh, ok; shall I remove the package now/
[21:23] <pitti> ?
[21:23] <LaserJock> pitti: if you want
[21:23] <pitti> LaserJock: what shall I put as rationale?
[21:24] <LaserJock> we decided with our status as an addon and the maintanence burden that we'd just get rid of our usplash
[21:24] <TheMuso> pitti: pulled and pushed to our branch, thanks a lot.
[21:24] <pitti> okay
[21:24] <LaserJock> it doesn't make sense to change all branding when we're just an addon
[21:24] <pitti> right
[21:24] <LaserJock> and I don't want to mess with usplash bugs ;-)
[21:25] <pitti> TheMuso: thanks
[21:27] <slangasek> pitti: why did you mark bug #217504 as 'triaged' again for linux?  AFAICS there's no change we're going to make to the kernel for this
[21:28] <pitti> slangasek: I thought we'd still need acpi-support for all the ACPI events that the kernel doesn't (yet) convert to key events?
[21:29] <pitti> if we instead want to fix all those in the kernel, I'm more than happy to drop the acpi_fakekey hack
[21:29] <slangasek> pitti: then that would be a bug on acpi-support, or am I missing some reason it should be assigned to linux?
[21:29] <pitti> slangasek: it's meant to be on acpi-support, yes
[21:29] <slangasek> the acpi_fakekey hack is already broken; are you proposing to revert the upstream kernel change?  oh, ok
[21:29] <pitti> sorry if I screwed up something
[21:29] <slangasek> I was just confused because it was still listed against linux :)
[21:30]  * TheMuso should have a play with plymouth at some point.
[21:31] <pitti> superm1: hm, I'd like to fix mythbuntu-artwork-usplash, but the Vcs-Bzr: field is wrong; do you have the correct branch, or shall I just upload and send you the diff?
[21:31] <superm1> pitti, try lp:~mythbuntu/mythbuntu/mythbuntu-artwork-usplash
[21:32] <superm1> what's it listed as?
[21:32] <pitti> superm1: meh, I just typoed, sorry
[21:32] <Daviey> pitti: What's up with it?
[21:34] <pitti> Daviey: I uploaded a new usplash which defines a new theme version, so I need to update/rebuild all usplash themes
[21:36] <Daviey> pitti: okey, cool. Thanks
[21:57] <pitti> Rocket2DMn: pong
[21:57] <pitti> superm1: can you please pull lp:~pitti/%2Bjunk/mythbuntu-artwork-usplash-theme-4/ into lp:~mythbuntu/mythbuntu/mythbuntu-artwork-usplash/ ?
[21:59] <superm1> pitti, sure
[22:04]  * calc tries to get OOo to compile in full debug mode for debugging gvfs/gio breakage
[22:04] <superm1> pitti, merged, you can trash your branch now if you want
[22:04] <pitti> superm1: thanks
[22:06] <didrocks> mdke: I found the issue in yelp. It's related to a new .in upstream file. Fixing it now
[22:06] <calc> it appears debug mode doesn't work it causes the build to fail, lovely :\
[22:07] <calc> yet another reason to attempt to switch to upstream version (/me bets this is ooo-build breakage)
[22:10] <calc> actually this looks like upstream never builds with debug mode (i think?) doesn't look like ooo-build broke it
[22:15] <gencho> good night guys and gals :)
[22:23] <Rocket2DMn> pitti, ping back
[22:29] <pitti> good night everyone
[22:31] <Rocket2DMn> ah, good night, I'll talk to you tomorrow pitti
[22:38] <mdke> didrocks: yay!! thanks a lot
[23:36] <mathiaz> slangasek: which test was failing for openldap 2.4.15 in debian? test034-translucent?
[23:36] <slangasek> mathiaz: no, it was a concurrency test
[23:36] <slangasek> i.e., it had 'concurrency' in the name
[23:36] <slangasek> (easy to guess why it failed, since it hung - non-trivial to debug, though)
[23:37] <mathiaz> slangasek: hm ok. 2.4.15 fails to build because test034-translucent fails on jaunty
[23:38] <slangasek> hmm, not reproducible in sid
[23:47] <avb> guys, does gnome still use libgnome to play sound events?
[23:47] <avb> i figured out that only libgnome2-0 now depends on libesd
[23:48] <avb> so, once this functional is already depricated its probably will be good reason to drop this dependency and build it with --disable-esd
[23:48] <TheMuso> avb: no it now uses libcanberra, as of the verfsion in intrepid
[23:48] <avb> so it will be possible to drop libesd and esound-clients package from ubuntu-desktop
[23:49] <TheMuso> avb: No, because of pulseaudio's esound compatibility.
[23:49] <TheMuso> esound-clients maybe, but certainly not libesd
[23:49] <TheMuso> but again, I could be wrong.
[23:50] <TheMuso> it may no longer be needed.
[23:50] <TheMuso> haven't looked that deaply into it.
[23:50] <avb> i feel it should be more deeply researched.
[23:50] <avb> its hard to say for sure
[23:50] <avb> so just a thought for now
[23:51] <TheMuso> avb: certainly an idea for karmic.
[23:51] <avb> libesd will be installed as a dependency for an applications which it requires. and its nothing to do with pa esound  emulation, i feel
[23:51] <TheMuso> ok
[23:51] <avb> yes, i will research more what is what
[23:51] <avb> and will send a mail to a ml
[23:52] <avb> probably its a non needed job, coz i feel for gnome 2.28 libgnome will be completly deprecated
[23:54] <TheMuso> I don't know anything about that.
[23:54] <avb> http://live.gnome.org/ProjectRidley
[23:54] <avb> http://live.gnome.org/LibgnomeMustDie
[23:58] <giaco> hello
[23:59] <giaco> how can I use the debug symbols I've downloaded from the mesa-swx11-dbg package now located in /usr/lib/debug/usr/lib/libGL.so.1.5.070200
[23:59] <giaco> ? please
[23:59] <slangasek> they're used automatically by gdb.
[23:59] <azeem> that's a new one. Escalating from (I guess) #ubuntu to #debian and then to #ubuntu-devel