#ubuntu-devel 2005-03-28
<mdz> it asks the question OK as expected when RECONFIGURE=true
<mdz> Kamion: if you can verify that it doesn't cause any other weirdness for you, that'd be appreciated
<mdz> I'll prepare a casper upload
<daniels> if that fixes it, I'll incorporate that into -5, head back to bed for an hour, and will incorporate that into -5
<daniels> and upload -5 more or less as originally planed
<daniels> or planne
<daniels> or planned.
<mdz> daniels: please post debdiffs from -2->-3 and -3->-4
<daniels> mdz: for the source?
<Kamion> mdz: CD nearly written, will do
<mdz> daniels: yeah, debdiff foo.dsc bar.dsc
<mdz> Kamion: I just hand-edited it in the ramdisk
<Kamion> that was my plan also
<mdz> there's enough time between casper unpack and 20xconfig to get in there and do the job :-)
<Kamion> I meant the base live CD :)
<mdz> gotcha
<Kamion> oh, don't worry, I do this sort of shit all the time for d-i ...
* Kamion does an unedited boot for control purposes
<mdz> casper upload standing by
<daniels> mdz: p.u.c/~daniels/xorg/; just noticed another micro-regression
<mdz> I'm getting a revert-to-6.8.2-2 kind of feeling
<Kamion> what regression?
<daniels> Kamion: the mkfontdir manpage fell out
<Kamion> oh, can so live without that
<daniels> yes
<Kamion> screw that :)
<daniels> i'd rather stick with -4 plus the nasty hack
<mdz> there are 2 other places where RECONFIGURE has an effect, more untested code
<Kamion> mdz: reverting to -2 breaks Greek installs again, plus something like five or six other languages; I'd really rather not
<daniels> mdz: the onnly other spot is making it back the old xorg.conf up and write a new one when it's non-zero, which is desired behaviour anyway
<daniels> between that and the i810 changes, which make life far more pleasant for lots and lots of people, I'd really rather not revert to -2
<mdz> Kamion: what fixed Greek installs?
<daniels> mdz: moving mkfontscale from xbase-clients to xutils
<mdz> oh, that
<Kamion> reverting that is highly undesirable for Replaces reasons anyway
<daniels> mdz: mkfontdir uses mkfontscale exclusively; the former is in xutils, the latter in in xbase-clients, and xutils can't depend on xbase-clients because that defeats the entire purpose of xutils
<Kamion> Replaces ping-pong is no fun :)
<mdz> daniels: I know, I filed the bug ;-P
<daniels> it's been broken ever since xbase-clients and xutils were split
<zul> hey
<mdz> zul: hi
<zul> hey mdz 
<mdz> zul: I wanted to ask your opinion about CONFIG_MEGARAID_NEWGEN
<mdz> I just had a friend test on a Dell PE2850, and the CONFIG_MEGARAID_LEGACY doesn't work, while the NEWGEN one does
<Kamion> daniels: have Debian fixed that one? I'd be amazed if they hadn't had to - unifont depends on xutils in Debian just the same as it does in Ubuntu
<mdz> unfortunately they seem to be mutually exclusive
<daniels> Kamion: nope
<daniels> Kamion: i'll report a bug in debbugs
<zul> i think CONFIG_MEGARAID_LEGACY is backwards compatible but ill check on that
<daniels> Kamion: but afaict, it's still ther ein unstable
<Kamion> daniels: how do Greek installs in Debian work, then?
<Kamion> daniels: they *do* work I'm pretty sure, they've been autotested
<daniels> Kamion: well, it's still in xbase-clients in unstable
<mdz> if MEGARAID_NEWGEN=n
<mdz> config MEGARAID_LEGACY
<daniels> Kamion: i dunno how it works, but apparently it does
<Kamion> and Arabic, Bulgarian, Chinese, Farsi, Hebrew, Japanese, Korean
<mdz> Kamion: clear to upload new casper?
<daniels> Kamion: *shrug*, maybe it gets installed by some lucky accident along the way
<Kamion> mdz: sec
<mdz> I don't guess there's any hurry until :33
<zul> mdz: megaraid_newgen doesnt recognize the older controllers
<Kamion> I've done the control, not the real test yet
<mdz> zul: ouch
<mdz> I wonder why they're mutually exclusive, then
<mdz> the only reason I could think of was that they would be loaded for the same PCI IDs
<zul> heh...ill go check
<mdz> thanks
<Kamion> mdz: seems to work fine
<Kamion> mdz: (although it worked here before that patch, too)
<mdz> uploaded casper 0.54
<daniels> ok, i'm going back to bed until 0030, but still pingable on my mobile
<mdz> Kamion: bug #299811 -> didn't you correct me recently that bare conditionals didn't interfere with set -e?
<mdz> daniels: ok, thanks
<Keybuk> test -f /not-exist
<Keybuk> will fail
<Keybuk> so will [ -f /not-exist ]  && ...
<zul> mdz: as far as i can tel megaraid_newgen works with megaraid_mm which is a management module the provides ioctly and sysfs support raid controllers
<zul> the legacy ones uses proc support i think
<Keybuk> (the [ will exit 1, so the && bit doesn't run ... the result of the pipe is 1, so set -e causes the script to fail)
<mdz> zul: LEGACY gets us megaraid.ko, NEWGEN gets us megaraid_mbox.ko (driver which seems to support more cadrs) and megaraid_mm.ko (management module)
<Keybuk> [ ! -e file ]  || mv $file /var/log/setuid
<Keybuk> would work (the || will eat the 1)
<zul> mdz: i could be wrong ;)
<Kamion> mdz: you were talking about ||
<Kamion> IIRC
<mdz> Kamion: ah, ok
<Kamion> bash(1) says that 'false && true' or whatever does not trigger 'set -e'
<Kamion> this appears to be true in bash and dash, but I have a recollection that it may not be true in all shells
<Kamion> AFAIK false || ... is safe everywhere
<Keybuk> Blinn says "false && true" will break set -e
<Mithrandir> Keybuk: naturally, false && $whatever is false so it breaks set -e
<Kamion> Keybuk: I can't find any shell in which that actually happens though
<Keybuk> Kamion: zsh
<Kamion> I tried zsh
<Keybuk> descent scott% false && true
<Keybuk> zsh: exit 1
<Kamion> yes, but it does not trip set -e
<Keybuk> scott@descent:~$ false && true
<Keybuk> scott@descent:~$ echo $?
<Keybuk> 1
<Kamion> exit 1 from a pipeline doesn't trip set -e by itself
<Keybuk> yeah, most shells tend to make that one work
<Kamion> an && or || guard appears to be sufficient to avoid that in any shell I've tried
<Keybuk> it's not portable though
<Kamion> no, I can believe that
<Kamion> just wondering where the submitter of #299811 managed to find a shell where it broke
<zul> mdz: according to the changelog fabio disabled to avoid regressions
<mdz> zul: :-(
<Kamion> $ zsh -c 'set -e; false && true; echo hello'
<Kamion> hello
<Keybuk> busybox ?
<zul> of course that was in 2.6.9 i dont know if it has gotten any better 
<mdz> zul: I read that as "try to avoid regressions by using the old driver rather than the new"
<mdz> overall, though, this is a regression from 2.4 (which had megaraid and megaraid2, at least one of which would work on these boxes)
<Keybuk> nope, busybox on my wrt seems ok
<Keybuk> *shrug*
<Keybuk> he probably tried very hard :p
<zul> mdz: ah i see
<mdz> zul: looks like probably NEWGEN was introduced in 2.6.9
<zul> mdz: https://www.redhat.com/archives/taroon-list/2004-November/msg00145.html
<mdz> zul: what a mess
<zul> mdz: yep 
<mdz> a bug report about this should arrive soon, but it sounds like we can't do much for Hoary
<zul> should look at 2.6.11 if its any better
<amu> mdz: you still need me atm? Or is it 6h laters also possible? 
<Kamion> is all the kubuntu stuff in the archive now, including binaries?
* Kamion notes lack of autopurging of old Kubuntu CDs, and fixes
<zul> mdz: megaraid supports only a limited number of controllers megaraid_mbox supports a whole whack of controllers (including dell perc, lsi, intel raid controllers, fsc and acer raid controllers)
<amu> Kamion: nope, need another upload of kdebase
<infinity> mdz : DO you have a clever way to mass-reassign all bugs relating to a source package to a specific bugzilla user?... Searching by components is painful. ;)
<Riddell> Kamion: why do you ask?
<Kamion> Riddell: was wondering if you guys were ready for preview-release CD builds to happen
<amu> Riddell: i guess a possible build will fail atm
<Riddell> Kamion: not yet, is it different from the nightly builds?
<Kamion> Riddell: releases are always blessed nightly builds (even if those "nightly" builds happen to be triggered manually)
<Kamion> Riddell: but we often trigger stuff by hand coming up to a release, to speed things up
<Kamion> Riddell: lamont, mdz, and I can trigger installer initrd / live filesystem rebuilds; mdz, daniels, and I can trigger CD image builds
<robertj> Kamion: if there is a really, really sucky bug in Gnome upstream, what are the chances of getting it fixed by an Ubuntu staffer and applied before hoary ;)
<Kamion> robertj: we're still making GNOME changes; you'd have to talk to seb128 or jdub though, I know very little about the specifics
<Kamion> "really, really sucky" is often relative :-)
<robertj> Kamion: the connect to server dialog is b0rk out of the box for sftp
<seb128> works here
<robertj> seb128: Its broken on the LiveCD and I had a rawhide user come up with the same result
<Kamion> I found that if I didn't have an appropriate key in an ssh-agent, the initial connect failed
<seb128> you mean the dialog displayed when you click to validate ?
<robertj> Kamion: we decided that was probably it
<Kamion> but it then works thereafter
<robertj> seb: when you connect it whines about not having an appropriate handler
<Kamion> I'm not quite in a position to come up with specifics right now
<robertj> I think the real problem is it's an unknown host
<daniels> mdz: (save yourself the expense of a call; i'm up now)
<seb128> robertj: and it works after that
<robertj> yes, after that it will ask you for your password and work happily
<seb128> the dialog issue is already in bugzilla
<seb128> that's quite of ugly but not a big issue
<robertj> any chance of it getting fixed?
<robertj> I think this one is over my head
<seb128> if you send a patch sure
<seb128> if you don't send a patch and don't get fixed in a new upstream tarball not sure
<seb128> s/and/or/
<Kamion> Keybuk: do you know of a portable way to make shell aliases be expanded?
<seb128> depending of the other bugs to fix before
<Keybuk> Kamion: nope, because shell aliases aren't portable shell
<robertj> seb128: is this something that bounty money could be used for to make the world go round?
<seb128> no
<zul> brb
<Kamion> I thought all Kornish shells implemented them interactively at least
<seb128> that's something that somebody bothered by the issue can fix quite quickly
<seb128> ie: every bug fix is not bounty material
<Keybuk> Kamion: no idea, my shell-fu ends where portable scripting ends -- unless it's zsh weirdness :p
<Kamion> Keybuk: I think this is hard because I'm trying to implement a very weak kind of exception raising in shell ;)
<Kamion> I want something that prints an error and returns out of the current function, basically
<Keybuk> set aliases -- zsh
<Keybuk> set expand_aliases -- bash
<Keybuk> etc.
<Kamion> yeah, I bet busybox doesn't have that
<Keybuk> use variables
<Keybuk> portable shell expands spaces in variables
* robertj reboots and will be back in a bit
<Kamion> Keybuk: can't expand a variable to 'foo; return' though
<Kamion> can I?
<Kamion> no, I can't
<Kamion> it's really to avoid having to do || { warn foo; return; } or whatever the syntax is all over the place
<Keybuk> you can with some trickery
<Keybuk> msg="foo" $throw
<Keybuk> or something
<Keybuk> msg="foo" eval $throw
<Keybuk> you may have to do
<infinity> Kamion : What's wrong with _exception() { echo $1; return 1; } ?
<jbailey> infinity: It only returns you out of the subfunction.
<infinity> Oh, duh.
<Kamion> Keybuk: nice trick
<infinity> jbailey : Of course, s/return/exit/ solves that.
<Kamion> infinity: exit is what I'm doing, but it's too big a hammer
<Kamion> and I need to save state between calls to the function, so I can't use a subshell
<infinity> Kamion : I need to read better.  You wanted to only return from a function, not the script.  Check.  I'll shut up and go back to work. :)
<jimmer_> hello all!
<jimmer_> anybody here interested in hearing some stuff about my experiences with hoary 5.04?
<Kamion> jimmer_: in this channel, we're most interested in hearing stuff that comes with patches :-)
<mdz> infinity: do a search, then "change several bugs at once"
<Kamion> bugzilla's best for bug reports, or ubuntu-users@lists.ubuntu.com for general reports
<quarupt> Is there a Project Manager for Ubuntu?
<jimmer_> Kamion, well, that can be fixed... it's just that I don;t know if I want to be an actual part of the Ubuntu effort...
<mdz> Kamion: ready for new CD builds?
<Kamion> quarupt: what do you mean?
<Kamion> mdz: checking
<mdz> Kamion: casper-udeb 0.54 is in the archive
<quarupt> Well most Open Source projects have one person who Organizes things like meeting releases and such?
<mdz> quarupt: why do you ask?
<Kamion> right, you could have meant either a program (project management application) or a person :-)
* mvo -> bed
<quarupt> Just wondering...
<mdz> mvo: night
<mvo> night all
<schweeb> who  would be in charge of initrdds?  I'm wondering if there's any technical reason that devfs is used still rather than udev, or if it's just not been gotten around to
<Kamion> schweeb: me; and we do not use devfs any more, we use udev
<Kamion> if you mean the installer initrd, that is
<quarupt> devfs is more stable and more documented
* mdz gapes at quarupt
<Kamion> mdz: new live CDs building
<Kamion> quarupt: the two-headed developer known as mdz and jdub handles that function. :-)
<quarupt> well i dun like udev since it works entirely in userspace
<Kamion> fortunately one head is awake on Pacific time, and the other on Australian time, which is uncommonly useful
<Keybuk> since when is jdub on Australian time ?!
<Kamion> well, theoretically
<schweeb> kamion: no the kernel initrd... generated by mkinitrd when you install a kernel
<quarupt> udev will not automatically load a driver if a /dev node is opened
<quarupt>    when it is not present like devfs will do
<Kamion> schweeb: ah, that would be jbailey
<Kamion> schweeb: I believe we're switching to hotplug/udev in initramfs post-hoary
<mdz> schweeb: it's a sensitive component and it hasn't been migrated yet
<Kamion> quarupt: nevertheless, we have good reasons to switch to udev throughout the entire system and fix the few problems that result
<quarupt> Whatever works
<mdz> not the least of which is that devfs is deprecated upstream
<Kamion> one being that devfs is liable to be removed from the kernel any time soon
<Keybuk> quarupt: actually, that's one of the biggest udev/devfs myths known to mankind
<quarupt> It should be around until .12
<Keybuk> devfs had nothing to do with the automatic module loading
<Keybuk> it just happened to massively-populate /dev
<Kamion> quarupt: so, hoary+1
<Keybuk> so the device node tended to exist when you tried to open it
<quarupt> Really?
<Kamion> quarupt: might as well get it out of the way now
<Keybuk> you can do exactly the same with udev by making the device-nodes exist before time
<daniels> mdz: fwiw, I've just dug up my xresprobe 0.5 branch and dragged back the test support for it, so I can fake various fun situations (DDC failing, DDC from a specific EDID file, a laptop probe from a specific log file), so I can test this sort of thing better in the future
<mdz> Keybuk: no, devfs actually has its own madness in that department
<quarupt> udev isnt for loading kernel modules anyways
<Keybuk> mdz: well, yes, as it had its weird filesystem -- but the kernel will load modules when any device node is opened
<mdz> Keybuk: with devfs, it loads modules even if the device node doesn't exist
<quarupt> mdz, didnt i just say that?
<mdz> quarupt: no?
<jimmer_> for those of us that don't have a clue what the whole devfs/udev fussis about... like me... http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
<Kamion> he did
<Kamion> 00:23 < quarupt> udev will not automatically load a driver if a /dev node is opened
<Kamion> 00:23 < quarupt>    when it is not present like devfs will do
<Keybuk> the answer these days is that if you don't have the module loaded, clearly there's something wrong preventing the hardware from being detected, so loading the module when you try and open the device is going to fail anyway
<Kamion> but really, this argument is so six months ago ;)
<quarupt> lol true dat
<mdz> daily-live rsyncing
<quarupt> Hotplug works fine 99% of the time in Hoary anyways
<quarupt> Can't say that about many other distro's not out of the box anyways
<Keybuk> meh; so you can't Replace a directory with a non-directory
<Keybuk> how do we handle that on the backwards equivalent
<Kamion> we still have several regressions from discover to fix
<schweeb> mdz: ah, thanks... ran in to problems with Xen and devfs on my systems... mostly cause I didn't compile devfs in, and it took me a few to diagnose the problem, heh
<quarupt> Do any of you guys actually code for a living?
<zul> uh yes
<Kamion> most of the people talking with you at the moment do
<mdz> stand back, we're professionals
<schweeb> lol
<quarupt> The most coding I get to do at my job is writing some lame vb script to change something in the AD or system policy
<quarupt> I hate my job
<quarupt> If we could just run at least our web server on linux id be happy
<quarupt> This is so off topic
<quarupt> sorry
* schweeb changes channels to #it-angst
<quarupt> So are we getting close to a release or what?
<Keybuk> alt.sysadmin.recovery
<Kamion> quarupt: dude; "are we nearly there yet" doesn't go over well in this channel; just letting you know :)
<Keybuk> meh, I'm so just going to ignore this
<quarupt> Well Hoary seems pretty stable
<schweeb> quarupt: just sit back and enjoy the ride
<Kamion> quarupt: the release schedule is on the wiki
<Keybuk> "can't install banana because it would mean if you'd done this the other way round I'd've broken because you would've replaced a directory with a non-directory ..."
<mdz> quarupt: the release date for Hoary was set 6 months ago
<mdz> and we are on track to meet our target
<quarupt> I wanna deploy Ubuntu at my work on some workstations but he wont let me install anything that is "Beta, Testing, Unstable"
<mdz> quarupt: how about "Ubuntu 4.10", our officially supported stable release, then
<quarupt> Because Warty is nothing compared to Hoary
<mdz> it's "released"
<mdz> it's "supported"
<jimmer_> quarupt, just install and change /etc/motd and /etc/issue
<mdz> it's "stable"
<mdz> it gets "security updates"
<quarupt> So Hoary is Stable right now too, just not officially
<mdz> it "works"
<mdz> quarupt: the people you are addressing have a much better idea of Hoary's stability
<mdz> because they are the people who are stabilizing it
<quarupt> I have had it running for like a month staright running my web server myy ftp and and ssh with over 40 connections a day
<quarupt> and it takes it like a man
<mdz> thanks for testing it
<crimsun> quarupt: seriously, we're straying into off-topic...
<quarupt> Im sure they do have a better Idea, Im not complaining Im just trying to say I think its looking awesome
<quarupt> Okay sorry again
<quarupt> well non-developers cants say much that is on "topic"
<mdz> that isn't true
<quarupt> Im just another annoying line in someones scroll back buffer trying to catch up on what they missed, when they were sleeping
<Kamion> certainly people who aren't yet Ubuntu developers can, and do; it's just that this is not a general chat channel, it's a development channel, and thus development-oriented conversation is appreciated :-)
<mdz> that's how you're behaving right now, yes.  but you could easily be helping us to test this milestone we're preparing
<Quarupted> How
<Kamion> cdimage.ubuntu.com/daily/current/, cdimage.ubuntu.com/daily-live/current/; burn, test, report
<mdz> http://cdimage.ubuntu.com/daily/current/ and http://cdimage.ubuntu.com/daily-live/current/
<Quarupted> I allready use almost 80% of my 4gigs of ram running all sorts of servers and desktop applications
<infinity> quarupt : For web servers, there's very little change between warty and hoary, except a few bugs fixed here and there, and a couple incremented features.  With the snail's pace at which server software evolves, combined with a 6-month release schedule, I can't see how upgrading to hoary buys you anything esxcept for missing security updates.
<infinity> Quarupted : On the other hand, I'll never turn down someone's offer to beta test things. :)
<Quarupted> I love Beta testing
<Quarupted> I was there with Potato, Sarge, and now SID
<Quarupted> so you want me to burn that image try to install it and report?
<Kamion> that's certainly what I've been spending the last few hours on
<Kamion> but we can only cover so many cases ourselves
<Quarupted> I dont have any free Partitions, but i do have a VMware ready to go
<Quarupted> Do you guys have allot of people testing your AMD64 live cd?
<Quarupted> I can do that
<Kamion> it does get testing, but I'm sure rather less than i386
<mdz> amd64-live successful
<mdz> Quarupted: yes, please do
<Quarupted> im on it
<mdz> Quarupted: burn and test as many of those images as you are able
<Quarupted> I can only test live ones now, untill i do some resizing on mp Partition table
<Quarupted> 666.0 Megs for the AMD64 Live now thats an Omen
<Kamion> it's perilously close to being oversized is what it is
<Kamion> in fact it's precisely on the mark
<Quarupted> yup at 500k its gunna take like 8 Minutes
<Kamion> mdz: anything we can take out of that? the next live cloop build will probably overflow it, given partimage breakage
<Keybuk> Unpacking banana (from banana_1.0_all.deb) ...
<Keybuk> Replaced by files in installed package banana-icecream ...
<Keybuk> yayyy
<Kamion> mdz: in fact I'm pretty sure we've overflowed the 74min disk limit, judging from what cdrecord is telling me
<Kamion> Keybuk: nice
<Keybuk> let's try this with one of pitti's PACKAGES OF DOOM
<mdz> powerpc-live: success
<mdz> Kamion: the amd64 cloop suffers from size creep
<mdz> we can reset it, at the expense of rsyncability
<Kamion> mdz: yeah, I know
<Kamion> but we reset it quite recently
<Kamion> and the WinFOSS stuff has made its size jump right up
<mdz> yeah, then we upgraded X
<mdz> the only thing we could realistically remove from the cloop would be language packs
<Kamion> let's ask lamont to reset it tomorrow then
<mdz> Kamion: mail pitti to consider trimming language packs in the morning
<Kamion> I question whether we can release with it over the limit
<Kamion> I suppose we could make it an erratum
<Kamion> (Array 7, I mean)
<mdz> Kamion: amd64 install dumped me to the menu at time zone configuration
<Keybuk> Unpacking language-pack-cy (from language-pack-cy_20050310_all.deb) ...
<Keybuk> Selecting previously deselected package language-pack-cy-base.
<Keybuk> Unpacking language-pack-cy-base (from language-pack-cy-base_20050310_all.deb) ...
<Keybuk> Replaced by files in installed package language-pack-cy ...
<Keybuk> Setting up language-pack-cy (20050310) ...
<Keybuk> Setting up language-pack-cy-base (20050310) ...
<Kamion> mdz: version of tzsetup-udeb?
<Kamion> Keybuk: rock
<mdz> Kamion: 2.62ubuntu12
<mdz> after a successful base-install
<mdz> tzsetup-udeb succeeded but requested to be left unconfigured
<mdz> is this the rtc issue?
<Kamion> no, shouldn't be
<Kamion> please send me /var/log/syslog
<mdz> powerpc-install made it to archive-copier
<Kamion> you might need to put 'set -x' at the top of tzsetup-udeb.postinst and rerun to make it meaningful
<mdz> Kamion: emailed
<mdz> Kamion: shall I retry from the menu, then?
<mdz> (with set -x)
<Kamion> mdz: please
<mdz> Mar 17 01:09:10 main-menu[4300] : (process:13447): RET=10 tzconfig/gmt doesn't exist
<mdz> Kamion: mailed you the full log (take 3)
<Keybuk> meh, it breaks with more than one file
<mdz> Kamion: tzconfig/gmt is in debconf's db in the chroot, but not in cdebconf's in the initrd
<Kamion> bleh, ok, wonder how that worked for me
<mdz> wonder how it worked for me on i386
<mdz> I mean powerpc
<mdz> oh, it didn't
<mdz> it dropped me back to the menu after archive-copier
<mdz> I thought tzsetup-udeb came first, for some reason
<mdz> I propose that if it worked for you, you had different software on your CD
<Kamion> that's so weird, I had 3/3 working
<Kamion> and rsync says nothing
<Kamion> oh
<Kamion> none of my installs were on a system where Ubuntu was the only OS on the CD
<Kamion> I mean on the hard disk
<Kamion> that is the case that fails
* Kamion hunts down the scratch box
<Kamion> looks like an install CD delay, then :(
<mdz> no d-i build necessary, though, right?
<Kamion> nope
<Kamion> mdz: this is all down to the GMT-suppression thing being a nasty hack, of course :( it should just lower the priority ...
<Quarupted> mdz, im about to boot into the AMD64 live, what kinda things should I test once im in?
<daniels> hm, only in pool/main/m, and still got xorg to go
<daniels> Quarupted: well, X will only start in 1024x768, so hope to hell that works on yoru stup
<daniels> your setup, even
<Quarupted> it should
<Quarupted> i run 1280x1024 now
<Quarupted> Actually nvm, the Image didnt even burn to a disk
<daniels> rad
<Keybuk> Unpacking language-pack-cy-base (from language-pack-cy-base_20050310_all.deb) ...
<Keybuk> Replaced by files in installed package language-pack-cy ...
<Keybuk> snarf is keeping existing `./usr/share/locale-langpack/cy/LC_MESSAGES/gok.mo'
<Keybuk> snarf is keeping existing `./usr/share/locale-langpack/cy/LC_MESSAGES/messages.mo'
<Quarupted> Weird
<Keybuk> yayy, fixed that bug
<mdz> Quarupheiz; http://www.ubuntulinux.org/wiki/QAtesting
<mdz> Keybuk: 164595?
<Keybuk> mdz: indeed
<mdz> cool
<mdz> Keybuk: how afraid do we need to be about putting that fix into hoary?
<Quarupted> well i wont be able to test it if i cant get the Image to burn
<Keybuk> the fix is getting smaller and smaller
<Keybuk> so I'm actually pretty confident that it's safe
<Kamion> Quarupted: as I said above, if you only have 650MB disks then it won't burn
<Kamion> bah
<mdz> Kamion: if you want to build it without the winfoss on it, I've no problem with that
<mdz> as a quick and unintrusive fix
<Kamion> just temporarily for array 7?
<mdz> the winfoss on the amd64 CD is much less interesting than on i386
<mdz> Kamion: yeah
<mdz> or even permanently, if we could better use the space
<mdz> though I imagine we'd trim it rather than remove it entirely
<Kamion> Quarupt: 01:25 < Kamion> Quarupted: as I said above, if you only have 650MB disks then it won't burn
<Quarupt> there 700MB
<Kamion> mdz: ok, removed, rebuilding
<Kamion> I'm not going to make :33 I'm afraid
<Quarupt> I think its gunna burn alright this time
<mdz> Kamion: I can kick cron.daily if necessary
<Kamion> ok
<Kamion> need to test first
<mdz> feel free to send a udeb my way if you need confirmation
<Kamion> -               db_fset tzconfig/gmt seen true
<Kamion> +               target_debconf sh -c '
<Kamion> +                       . /usr/share/debconf/confmodule
<Kamion> +                       db_fset tzconfig/gmt seen true'
<Kamion> that's the diff to tzsetup-udeb.postinst
<Kamion> (basically)
<elmo> mdz: I am here, btw
* mdz hides
<mdz> Kamion: would target_debconf_communicate or similar be a less ugly way of accomplishing the same thing?
<Kamion> mdz: yes; but that code will go away soon anyway
<Kamion> as previously mentioned it's a buggy approach
<Kamion> thully has a bug open on it, wrong expert-mode behaviour
<mdz> on a related note, /me adds "cdebconf-copydb" to the list for breezy
<Kamion> hell yeah. sadly it needs a total rewrite of cdebconf's rfc822db
<mdz> anything else to add to the "gross hacks that should go away" BOF while I'm there?
<Kamion> the linux-{386,686,k6,k7,powerpc,whateverthehellelse} grep in base-installer
<zul> lol
<mdz> done
<mdz> I think we ought to specify this stuff in Sydney to ensure that we allocate development time for it
<daniels> [FC4T1]  To add insult to injury, opening Firefox greeted us with: "There ought to be release notes for Fedora Core 3.90 here, but there aren't. In the meantime, we bring you this ASCII art hat."
<mdz> otherwise we'll be forever implementing new features and not fixing the old ones :-P
<Kamion> mdz: yeah
<elmo> mdz: but but but fixing things isn't sexy
<Kamion> oh, FFS
<Kamion> it's so much faster to hit the reset button than it is to wait for the System menu to get its act together and actually appear on the live CD
<jbailey> evms-udeb has a binary that depends on ncurses, but I don't see an ncurses udeb.  Where should that be provided from?
<Kamion> jbailey: ncurses, I imagine ...
<elmo> yeah, can we like, prio-RT whatever is the gnome menu bar process?
<elmo> it's so lame that it's always swapped out and takes so long to come up
<Kamion> does it *really* want to have its own UI, though? I think not
<mdz> evms-udeb is an idea that never actually materialized
<wasabi_> evms's interface is pretty decent on it's own. I was thinking of plugging that into it
<wasabi_> and just jumpting to it from the partitioner
<mdz> elmo: mlockall()
<Kamion> should be integrated into partman
<wasabi_> I mean, if you want ENTERPRISE volume management... =)
<wasabi_> Kamion, partman should show the /dev/evms device certainly, but I really think the evms gui can alter them fine
<mdz> it would be feasible to do the things that partman can do with lvm, with evms
<jbailey> ah, a'ight.  I'll stop trying to get it to work and figure out why it broke then. =)
<mdz> but if you want to do the additional stuff EVMS can do, I think that's madness
<Kamion> no, we have enough bugs about back-and-forth in the installer breaking stuff without having another totally unintegrated UI in there
<mdz> jbailey: it's never even been in the same room as working
<wasabi_> =(
<Kamion> I'm fine with using the evms logic and stuff, but it needs to plug into partman
<wasabi_> one of these days i'll put it together. ;0
<wasabi_> the evms logic is HUGE heh.
<Kamion> anyway, I cannot discuss this now
<Kamion> that tzsetup-udeb fix was wrong and I need to fix it
<Riddell> does ubuntu have a menu entry for running the file manager as root?
<jbailey> mdz: 'kay thanks.
<zul> mdz: speak of the devil there is an update to megaraid_mmbox
<zul> er..megaraid_mbox
<Quarupt> The live CD hung up at loading isofs
<Quarupt> :(
<Quarupt> Must not like my Hardware
<Quarupt> dunno
<Keybuk> mdz: ok, so what's the plan for this patch?
<Keybuk> have done some pretty rigorous tests, and works fine
<mdz> Keybuk: cry about the fact that we can't possible test it enough :-(
<mdz> s/possible/possibly/
<Quarupt> So sorry I couldnt Test it, but i don't think it likes my hardware
<mdz> Quarupt: it's a live CD, it likes all hardware
<Quarupt> well it wouldnt load isofs tried 3 times wait 5 minutes each time
<Keybuk> mdz: heh, but do you want it uploaded or not?
<mdz> Keybuk: why the hell not?  we're DOOMED
<Keybuk> rofl
<mdz> Keybuk: (read: after array 7)
<Keybuk> wouldn't before give us more testing?
<mdz> Quarupt: that module has nothing to do with your hardware; I strongly suspect the problem is with your media
<daniels> wow, I had no idea how bad the stat() damage from the new langpack stuff was
<mdz> Keybuk: we're literally preparing it right now
* Kamion idly murders Keybuk
<daniels> without strace, starting totem takes under a second on my amd64
<jbailey> daniels: It's pretty brutal.
<Quarupt> daniels, didnt i mention i tried 3 different copies?
<daniels> it takes a bit over 15 seconds with strace, because gnome-terminal just can't handle the staggering amount of crap being spewed to the terminal
<daniels> Quarupt: not to me, no
<Kamion> mdz: uploaded. don't look at the code
<mdz> Kamion: cue elmo?
<elmo> cron.daily runing
<Kamion> elmo: buildds could probably squeeze in before the next cron.daily, if so ...
<elmo> Kamion: buildds pre-dep on cron.daily
<Kamion> yeah, I mean if cron.daily mysteriously went off now ;)
<elmo> ah
<Kamion> assuming it's through cron.unchecked anyway
<Kamion> or whatever it's called
<mjg59> Suspend to disk and suspend to RAM work perfectly on robot101's obscenely crap craptop
<mjg59> TOTALLY RAD LAPTOP SUPPORT
<Kamion> oh, crap, tzsetup-udeb.prebaseconfig has the same problem
* mdz high-fives mjg59
* Kamion goes off to cry
<mdz> Kamion: showstopper?
* daniels consoles Kamion.
<Kamion> yes, prebaseconfig crashes
<daniels> Kamion: i feel your pain
<mjg59> robot is upset that he had to go and buy an X40 and it turned out that his laptop worked anyway
<mjg59> Totally rad laptop results in decreased life expectency and depression
* Robot101 needs to do some computationally intensive stuff and see if it crashes :P
<daniels> mdz: ok, confirmed that xserver-xorg 6.8.2-5 works fine for a) complete DDC failure (asks and respects the mode question), b) upgrade (leaves your config alone), c) ddc (writes the right thing out), and d) laptop (writes the right thing out)
<mdz> daniels: sounds good (after array 7)
<daniels> mdz: (yeah)
<mdz> Kamion: are you sure you don't want to sleep and do this tomorrow?
<Kamion> mdz: does the timezone setup thing in casper/pre.d actually do any good whatsoever?
<Kamion> yes, sure
<daniels> Kamion: if there's anything I can usefully do, let me know
<mdz> I'm not fussed if array 7 is delayed by a day
<Kamion> because it does fuck-all good in d-i right now, and I want to delete it
<mdz> we might as well put in xorg 6.8.2-5 and Keybuk's new dpkg
<mdz> and I can undo the casper damage
<mdz> Kamion: I have no idea
<mdz> Kamion: I haven't tested preseeding a time zone on the live CD, and if it doesn't work for final, I'm not going to cry over it
<Kamion> ok, let's leave it until tomorrow :( sorry about this, my fault
<mjg59> paracetamoxyfrusybendroneomycin
<mdz> Kamion: no worries, thanks for staying up
<mdz> daniels, Keybuk: fire when ready
<daniels> Kamion: eh, xorg was tanked as well
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals | Kubuntu on #kubuntu-devel | Hoary preview release: http://releases.ubuntu.com/hoary/ | Array CD 7 2005-03-17; please test uploads to main carefully | Release Candidate: March 30th
<daniels> mdz: you might as well kick that horror show hack out of casper, then
<mdz> daniels: <mdz> and I can undo the casper damage
<daniels> mdz: right
<daniels> should I cram dbus and dbus-mono in as well?  or since they're for universe shit anyway, probably worth waiting until after just to be totally sure
<Kamion> I'd wait
<Kamion> if it isn't too much hassle to do so
<daniels> (not to demean universe; just using 'shit' as any random grouping of stuff)
<daniels> Kamion: yeah
<daniels> Kamion: not at all
<Kamion> I'm going to stay up a bit more to get these fixes tested properly, then crash
<mdz> Kamion: oh, if you're going to do that, then I'll build some candidates later
<mdz> (assuming you upload it)
<Kamion> mdz: thanks, that'd be good
<Kamion> shall I disable the daily cron jobs?
<daniels> ok, 6.8.2-5 is up
<Kamion> Ubuntu daily/daily-live CD build cron jobs disabled, build 'em manually if you want 'em
<sladen> with the amd64 cloop;  can somebody just SCP it across to an i386 machine, partimage -e it and scp it back again.  Hackery, but it'd solve the problem and not loose the rsync status
<Kamion> (or run the i386 version with ia32-libs)
<Robot101> wow, the fan actually works too
<zenwhen> when clean installing hoary, should optical drives beusing dma by default? Mine weren't.
<mjg59> robot101's laptop is now entirely love
<mdz> mjg59: just how oddball a laptop is it?
<mdz> zenwhen: no
<zenwhen> oh ok
<mdz> zenwhen: #3672
<zenwhen> My oddball 266Mhz 4010CDS runs GREAT with hoary.
<zenwhen> :)
<zenwhen> In all its dual scan lcd glory.
<Kamion> mdz: ok, base-config 2.62ubuntu14 should actually work; tested in as many faked-up configurations as I could think of
<mdz> Kamion: ok, cheers
<mjg59> mdz: It's some ancient FIC thing with a Celeron 366
<mjg59> So probably circa 2000
<mdz> I should get out my old toshiba and see how it fares with Hoary
<mdz> I've been slack on i386 install testing anyway because I don't want to clobber my laptop
<zul> toshiba with a a flakey keyboard?
<mjg59> Only issue is that the contrast is strange on resume, but it does the same on apm
<mjg59> I'm a touch amazed, really
<Kamion> hm, s-t-d seems to hang on the Averatec
<mjg59> The avaratec is almost as bad as the craptop
<Kamion> yeah, via throughout
<mjg59> Can you edit /etc/default/acpi-support and switch off dpms, then try s-t-d again?
<mjg59> You ought to get more output that way
* Keybuk watches the Dr Who trailer for the gazillionth time
<Kamion> mjg59: that time it suspended, but didn't resume; just came back up normally
<mjg59> Kamion: Is this a clean Hoary install? Or an upgrade?
<Kamion> mjg59: does it care if my resume partition is mistakenly type 0x83 rather than 0x82?
<Kamion> mjg59: clean hoary, and has RESUME= in mkinitrd.conf before you ask
<mjg59> Hrm. Possibly.
<mjg59> I'd be a bit surprised, though.
<mjg59> Possibly that path ought to have more debugging in it...
<mjg59> Can you try it with 0x82 and see if it makes a difference? (I'd be surprised, but...)
<Kamion> sure, one sec
<Kamion> mjg59: changing the type did it
<Kamion> mjg59: and it appears to be able to s-t-r, but not resume
<Quarupt> the entire first episode of Dr.Who is on Limewire
<Kamion> which I guess isn't saying much
<zul> later all
<mdz> Kamion: what do you think we should do about the en_US/en_GB issue?
<mdz> (#4271)
<daniels> shit, I forgot to eat
<daniels> bbiab
<mjg59> Kamion: It worked with a different type? Excellent
<mjg59> What's the failure mode on resume from RAM? It just boots instead?
<mdz> infinity: are you able to test live or install CDs?
<Robot101> /./me i
* Robot101 whistles innocently
<Keybuk> Quarupt: is incomplete pre-edit version, which rumour has it the BBC leaked deliberately to gain publicity
<adamh> I'm thinking of switching over to Ubuntu from Debian. One of the benefits I think I'd get is that I wouldn't have to jhbuild all of GNOME just to hack at Epiphany. Am I right? Are there any GNOME hackers here who switched to Ubuntu? :)
<HrdwrBoB> yse
<adamh> No more need for jhbuild?
<jdub> adamh: quite a few; it's heaps easier tracking the package releases on the development branch, and building just what you need
<adamh> jdub: Development branch? <-- hoary?
<mdz> currently, yes
<adamh> Well, if it works for jdub it's good enough for me! Here we go... goodbye Debian :)
<adamh> (The irony here is that I'm going through the trouble of reinstalling my OS just because I'm too lazy to do a kernel recompile)
<lamont> Kamion/mdz: reset of amd64 cloop?
<Kamion> lamont: not yet please, array 7 not yet done
<Kamion> mjg59: just boots instead
<lamont> Kamion: just say when.
<Kamion> mdz: I have a plan for that one; intending to make localechooser's fallback for English just 'en', so you get LANGUAGE=en_GB:en for British English and en_US:en for American English, etc.
<Kamion> mdz: the downside is that en_(other than GB|US) won't get either of en_GB and en_US, which in practice means they'll get American translations rather than British ones, which will probably irritate some people
<Kamion> mdz: but for the time being I think that's tolerable
<mdz> Kamion: I think that's the best we'll do for hoary
<mdz> I'm not even sure what we should do long-term
<Kamion> yeah
<Kamion> maybe store a list of which countries prefer which variants of English
<mdz> it seems like the correct solution would involve identifying the locale of the untranslated strings
<Kamion> so en_ZA => en_GB:en, say
<Kamion> (warning: may not be true)
<Kamion> en_ZA:en_GB:en, rather
<Yomic> What version of Python is in Hoary?
<mdz> Yomic: 2.4.1a0
<Kamion> Yomic: http://higgs.djpig.de/ubuntu/www/
<Yomic> Thanks.
<Kamion> lamont: tomorrow sometime
<Kamion> lamont: would running the i386 partimage binary, as sladen suggested, be feasible?
<lamont> Kamion: as a manual action, yes.
<Kamion> why not automatic?
<mdz> xorg bulit on i386 and amd64
<elmo> and ppc
<mdz> once those are accepted, we'll roll new livefs builds and install CD builds
<infinity> mdz : No burner currently.
<mdz> elmo: when can I expect X to reach mirnyy?
<Quarupt> if the Acrhive Manger wont open a rar, and either will ark, Ark says unrar isnt in my PATH?
<Quarupt> oops wrong chan
<elmo> mdz: should be there now
<mdz> elmo: hmm, anonftpsync on little doesn't bring it in
<mroth> zulcss@gmail.com is "zul" on here, right?
<Yomic> To update to hoary, all I have to do is change all the 'warty's to 'hoary's then 'apt-get dist-upgrade' ?
<mdz> mroth: yes
<mdz> Yomic: HoaryUpgradeNotes in the wiki
<Yomic> in the repositories*
<Yomic> Okay, thanks.
<mroth> mdz: seen him around lately
<mdz> mroth: he was here earlier, but is gone for the night
<elmo> oh for christ's sake
<mroth> mdz: righteo, thanks
<elmo> mdz: sorry - I skillfully broke the main archive while setting up the test one; it's syncing now, I'll shout when it's done
<mdz> elmo: I'm glad you didn't go to sleep :-)
<elmo> mdz: should be good
<mdz> syncing little
<mdz> elmo: should be clear for livefs builds as well?
<mdz> I don't know where they point
<elmo> rockhopper's in sync too
<elmo> so yeah
<elmo> err, auckland, blah
<Yomic> In the update to hoary I recieved two 404 errors:
<Yomic> Failed to fetch http://ubuntu-bp.sourceforge.net/ubuntu/dists/hoary-backports/main/binary-i386/Packages.gz  404 Not Found
<Yomic> Failed to fetch http://ubuntu-bp.sourceforge.net/ubuntu/dists/hoary-backports/universe/binary-i386/Packages.gz  404 Not Found
<lamont> Kamion: hrm.. I was thinking of moving the 2GB fsimage over to an i386 box, running it there, and then pushing it back...  I suppose we could just run the 32-bit i386 binary given the right motivation...
<lamont> elmo: livecd rootfs build points at jackass... 
* elmo runs aways screaming
<elmo> lamont: because of the md5 mismatch crap or just 'cos?
<lamont> because all the other chroots  on the buildd's do too.
<lamont> and _that's_ because of the timing issue on the mirror push vs w-b freeing up packages
<elmo> yeah, I know why buildds do it, just not sure why live rootfs would need to, but meh, doesn't matter
<lamont> the truthful answer is that the same script built the chroot for the livecd fs build...
<lamont> and ISTR we had reasons for not wanting the buildd machines hitting a.u.c.  if it should change, it's not a big deal
<Quarupt> If I make a script for upgrading to hoary, could you guys put in in the sources or maybe somewhere on the page?
<Quarupt> just something that changes all the instances of Warty to Hoary in the sources list, and runs apt-get update and apt-get dist-upgrade
<tseng> something like that should be handled by a competent admin really
<tseng> or at least someone who has read over the doc once or twice and is comfortable watching it
<tseng> some things shouldnt be scripted, imo
<wasabi> I want an Ubuntu business card.
<fabbione> morning
<Keybuk> fabbione: removing that ipmi patch seemed to fix my laptop
<fabbione> Keybuk: seems or it fixes?
<Keybuk> well, it's behaving normally now
<Keybuk> which I guess counts as "fixed" :)
<fabbione> ok thanks
<fabbione> -stolen-from-head_053-ipmi_unhandled_message_counting
<fabbione> this one right?
<Keybuk> yup
<fabbione> ok
<fabbione> can you give me a short descr of the problem? so i can include it in the changelog..
<Keybuk> Missed interrupts causing HP laptops to not correctly set the initial number of fans after boot
<fabbione> thanks
<fabbione> done
<Keybuk> cool, thanks :p
<fabbione> no problem
<Keybuk> right, time to crash I think
<Keybuk> or at least veg for a few hours, and try to push my body clock round to real hours a bit
* infinity watches what he hopes is his last php4 build of the week (month?)
<infinity> Not holding my breath, mind you.
<daniels> Pah, php4's a doddle. ;)
<infinity> Trying to fix every (real) bug I know of in one upload is always a curious challenge. :)
<infinity> ... and bound to fail.
<daniels> Well, it fixes every bug you know of, and introduces three tha tyou don't.
<infinity> Generally that's the issue, yes. :)
<infinity> Though I tend to catch several new bugs on the way too, so I think I still end up ahead.
<infinity> Somehow.
<daniels> I'm working on fixing bugs I don't know about at the moment.
<infinity> Always the worst part. :)
<infinity> Especially since you spent all that time creating those bugs in the first place, only to go remove them later.
<daniels> Heh.
<infinity> No one appreciates the effort that goes into writing buggy software anymore.
* infinity digs back into his.
<infinity> Oh, actually, looks like it's home-time.
<infinity> daniels : You around tomorrow morning?... I may need a mess of stuff sponsored at some point.
<daniels> mdz: i'm just about to head out; i'll be back at about 1400 UTC.  i'll theoretically be reachable on my mobile, but it would be good if it could wait.  i'll be a good 2h from connectivity even if urgent stuff pops up.
<daniels> infinity: yeah, SMS/call if I'm not awake
<infinity> daniels : Will do.
* infinity kisses Monash's fair network goodbye for the day.
* lamont sleeps
<mdz> array 7 candidate is up, please test
<infinity> daniels : Oh, that reminds me.
<daniels> inf	Oh?
<daniels> mdz: 20050317?
<infinity> daniels : Bring me installer/live CDs to test on my shitty old laptop when you hook me up with the hard drive.  <bat lashes>
<mdz> daniels: daily/20050317
<infinity> (No burner until we unbox the amd64 beast)
<mdz> daily-live/20050317.2
<mdz> daily/current and daily-live/current
<daniels> inf	Sure.
<infinity> daniels : Danke.
<dholbach> goooood morning
<infinity> mdz : You're welcome to reassign anything even vaguely httpd (libapache*, apache{,2} php, etc) to me, unless thom really objects.  I'm digging through every seriously-irritiating rc-ish bug I can think of in the whole apache dependency chain right now.
<infinity> s/httpd/httpd-related/
<dilinger> and loving every minute of it, no doubt
<infinity> The worst offender being a completely broken php4, of course.
<infinity> dilinger : I pretend to enjoy apache2.  The rest drive me near suicide, but that's nothing new. ;)
<mdz> daniels: don't go anywhere
<mdz> I just did a live CD test and X configuration failed
<daniels> define 'failed'
<daniels> i.e. what machine is it on, what method is it expected to use, how did it get configured, logs, configuration
<mdz> daniels: it's the BusID bug from ilke 3 months ago, returned
<mdz> AGAIN
* daniels frowns.
<Quarupt> what directory did ya guys stick the kernel headers in?
<mdz> Quarupt: support questions in #ubuntu
<Quarupt> No one knows there
<daniels> mdz: if you could re-run with DEBUG_XORG_PACKAGE="developer", that would be much appreciated
<mdz> Quarupt: then wait; this is not a support channel (not even a second-tier one)
<daniels> mdz: if [ "$1" = "reconfigure" ]  || [ -n "$DEBCONF_RECONFIGURE" ] ; then
<daniels> this is not triggering, from xserver-xorg.config.in
<Quarupt> Just tell me where the stupid header files arre its a devel question
<mdz> Quarupt: I will not explain again
<Quarupt> Im asking here because there not in the default location
<Quarupt> mdz i dun care about your power trip, this is a dev channel im asking dev questions
<mdz> Quarupt: there are developers here who are trying to work, and you are being a nuisance
<mdz> I am asking you to take your questions to a more appropriate forum
<Quarupt> Please dont speak to me anymore
<Quarupt> The headers are not in /usr/src  thats the default, so where are they?
<infinity> Quarupt : 'apt-cache search kernel headers', and kindly stop being so abrassive.
<dholbach> Quarupt: stop being impolite and use apt-file, dpkg -c, locate, find or whatever to find out - since you're asking developer questions, you should know
<Quarupt> no i mean on my machine im not looking for new headers
<Quarupt> screw this ill ask in Debian-dev
<mroth> I bet they'll love him there.
<infinity> I don't see him there.
<mdz> daniels: we cannot continue with these 4-hour test cycles
<mroth> He's probably asking in xchat-dev how to join a new channel first.
<daniels> mdz: four-hour test cycles?
<mdz> daniels: where you upload a new xorg, we wait for it to build, build CDs, I download them, and test them
<daniels> mdz: if you can get the dpkg-reconfigure thing run with DEBUG_XORG_PACKAGE="developer", or get xserver-xorg.config run with sh -x (i.e. change its shebang), I can tell you exactly where the problem lies
<mdz> I'll have your debug output in a moment\
<daniels> mdz: either $1 isn't "reconfigure", DEBCONF_RECONFIGURE isn't set, XORG_FORCE_PROBE is set to some value other than "yes", or db_reset is not doing its thing
<daniels> thanks
<mdz> $1 is never "reconfigure" in postinst
<daniels> this is config, not postinst
<mdz> XORG_FORCE_PROBE is not set
<daniels> config has code to run db_reset on every xserver-xorg template if -n "$RECONFIGURE"
<daniels> and, in turn, RECONFIGURE=true if $1 = reconfigure or -n $DEBCONF_RECONFIGURE
<mdz> xserver-xorg postinst warning: overwriting possibly-customised configuration
<mdz>    file; backup in /etc/X11/xorg.conf.200503170650
<mdz> dexconf: error: cannot generate configuration file;
<mdz> xserver-xorg/config/display/default_depth not set.  Aborting.  Reconfigure the
<mdz> X server with "dpkg-reconfigure xserver-xorg" to correct this problem.
<mdz> xserver-xorg postinst warning: error while preparing new Xorg X server
<mdz>    configuration file in /etc/X11/xorg.conf.dpkg-new; not attempting to
<mdz>    update existing configuration
<sabdfl> morning all
<mdz> I typo'd the variable name, so I don't have the debug output, but that's stderr
<mdz> daniels: I jumped the gun in blaming the BusID thing; it's just not updating the configuration file _at all_
<mdz> so it's the one generated on the buildd
<mdz> both the busid and everything else
<fabbione> morning mdz
* daniels stares at default_depth.
<fabbione> hey sabdfl 
<daniels> sabdfl: g'morning
<fabbione> sabdfl: having fun?
<daniels> mdz: sh -x'ing postinst is onw the interesting bit
<daniels> actually, no it's not
<mdz> daniels: yes, I'm booting the live CD again, and trying to edit the script during the 10-second window, again
<mdz> stand by
<dholbach> good morning fabbione, sabdfl 
<mdz> I refuse to believe that this is specific to the live CD
<mdz> did you test dpkg-reconfigure on these packages?
<daniels> mdz: humour me -- edit xserver-xorg.postinst.in, look for if [ "$RET" = "false" ] ; then\ndb_set xserver-xorg/config/display/default_depth $DISPLAY_DEPTH\nfi
<daniels> mdz: change $DISPLAY_DEPTH to $DEFAULT_DEPTH
<mdz> and build new X packages and new CD images again?
<mdz> not tonight
<daniels> mdz: yes.  tested dpkg-reconfigure and a fresh install with all of a) forced ddc failing, b) forced ddc succeeding, and c) forced laptop succeeding on amd64 and i386; tested upgrades with my standard configuration
<daniels> mdz: so I assume there's no way you could edit it before it gets invoked
<mdz> xserver-xorg.postinst.in is not a part of the installed package, afaik
<daniels> s/.in$//
<mdz> daniels: I cannot spend more time on this
<mdz> we are going to need to revert, as I said in the first place
<mdz> we just blew 5 hours because of this
<mdz> and the day after the milestone was due is no time to be debugging the scripts
<daniels> mdz: as I said, it works fine here
<mdz> it breaks the live CD completely, trust me
<daniels> my current bet is on extreme weirdness with the live CD's cdebconf, et al
<mdz> the live CD's cdebconf worked spectacularly with 6.8.2-2
<daniels> yes, and is now broken with it
<daniels> we'll revert back to 6.8.2-2 for array 7, as much as I think that a bad idea
<daniels> and I'll keep chasing up this cdebconf stuff
<fabbione> hold on....
<fabbione> can't we just do in such a way that X detect that it is a liveCD
<fabbione> and take appropriate action to explude that kind of code that is "delicate"?
<fabbione> instead of bouncing -2 -5 no -3.1?
<fabbione> explude -> exclude
<daniels> fabbione: i'm pretty sure that I know how to work around the cdebconf breakage, but I'm not too keen on a four-hour cycle, unless ...
<daniels> mdz: is there any chance I can convince you to unpack the iso, make a one-line change, and test that?
<daniels> mdz: if so:
<daniels> 06:55 < daniels> mdz: humour me -- edit xserver-xorg.postinst.in, look for if [ "$RET" = "false" ] ; then\ndb_set                  xserver-xorg/config/display/default_depth $DISPLAY_DEPTH\nfi
<daniels> 06:55 < daniels> mdz: change $DISPLAY_DEPTH to $DEFAULT_DEPTH
<daniels> if not, I'll revert the debconf code to -2 and we'll ship with that
<fabbione> i had the feeling i was melting.. it's over 5C
<mdz> daniels: we need to roll back
<daniels> mdz: ok.  if you can do that testing anyway, it would help me hugely.
<mdz> we have a milestone to release and this code isn't ready; I'm not going to go through another round of tweaking it
<daniels> even if it's academic at this point, we need to do this at some stage, so anything you can do towards that end would be a huge help.
<mdz> I need for you to be able to do this testing without me
<daniels> i am wget'ing the live cd now
<mdz> I cannot be xorg debug proxy on top of the other things I need to do
<daniels> unfortunately this takes a fairly long time, even on dsl
<daniels> which is why i'm not doing it myself
<fabbione> daniels: i am going to test with you
<fabbione> mdz: don't worry.. i will test with daniels
<daniels> fabbione: basically, if you have the live CD, just make that change mentioned above to xserver-xorg.postinst before dpkg-reconfigure gets invoked and it should work
<fabbione> daniels: first i need to see if it is broken here
<mdz> daniels: you should be able to use a hoary preview live CD and swap in X
<mdz> since you have locally-built packages
<mdz> fabbione: it'll be broken unless you have an ati card on 0:5:0 or whatever the buildd has
<fabbione> mdz: ok.. than i can test :-)
<fabbione> as soon as archive allows me to rsync
<fabbione> daniels: i have issues to rsync from archive. too many lusers connected
<fabbione> daniels: let's revert as mdz suggested and i will test with you later.
<fabbione> daniels: does it sound a good plan?
<fabbione> daniels: of course only the bits the break
<daniels> fabbione: yeah, I'm just in the middle of uploading now
<fabbione> daniels: not the entire thingy, since i can see from the changelog that some important stuff went in -4
<daniels> i've just kicked xserver-xorg.{config,postinst}.in back to what -2 was
<fabbione> ok
<fabbione> sounds good
<daniels> md5sums match and all
<mdz> daniels, fabbione: emailed casper log showing DEBUG_XORG_PACKAGE=developer output
<fabbione> mdz: perfect. thanks
<daniels> mdz: yeah, it's what i thought
<fabbione> ok.. rsycing now...
<fabbione> ah damn...
<fabbione> sparc was just uploading Xorg -5
<fabbione> that means another build in a few hours
<daniels> yeah, and lots of mirror pain
<daniels> given the rapid sequence of -4, -5, -5.1, and then -6 to come reaosnably soon as this code needs testing
<mdz> we gambled, and we lost.  now we need to play it safe.
<daniels> hence -5.1
<dholbach> morning d3vic3 
* fabbione sighs....
<fabbione> ah there it is.. liveCD
<fabbione> yummy
<stockholm> fabbione: when do you get up nowadays?! (c:
<fabbione> stockholm: 6am usually...
<stockholm> fabbione: but no children yet? that is why we get up so early.
<fabbione> nope.. no mini-fabbione around ....
<fabbione> yet
<d3vic3> morning dholbach 
<fabbione> hey d3v1c3
<d3vic3> hey fabbione 
<daniels> fabbione: right, so you'll need to unpack the live CD and cloop as explained in LiveCDCustomizationHowto and then make that change to /var/lib/dpkg/info/xserver-xorg.postinst within the cloop, then rebuild it all
<daniels> fabbione: you need a fair bit of disk space and a LOT of ram (or a lot of swap)
<stockholm> fabbione: i am going to riccione on saturday, playing beach volleyball!
<fabbione> daniels: ok don't worry....
<fabbione> daniels: can you just only send me the change again via email?
<fabbione> daniels: it will take a little while before i will get there
<daniels> fabbione: sure
<daniels> fabbione: that's fine
<fabbione> stockholm: riccione? in march?
<fabbione> are you on somekind of crack?
<fabbione> daniels: i have ram and disk space... so that's not an issue
<daniels> fabbione: awesome ... email sent
<stockholm> fabbione: there are allmost 20C now!
<stockholm> while here we had 20cm snow over night.
<daniels> fabbione: ok, i've gotta go now, already an hour late for dinner with gf's parents and i'm too exhausted to think any more anyway
<daniels> fabbione: i'll be back a bit after 1400 utc, have mobile on me if urgent
<fabbione> stockholm: ehhee
<fabbione> daniels: ok don't worry.
<fabbione> daniels: i will sms you if there are problems
<Hannes_> whoo, -12C
<Hannes_> and snowung
<Hannes_> *ing
<Hannes_> and 10-25cm of snow
<stockholm> Hannes_: where is that?
<Hannes_> Pori, finland
<stockholm> is that north of wasa?
<Hannes_> south of
<Hannes_> ~200km
<Hannes_> on the coast
<stockholm> ok, not *that* far away.
<Hannes_> no
<Hannes_> in the middle of vasa and bo (turku)
<medwards_> Is it appropriate to ask here about the LiveCD construction system?
<dholbach> hey mvo 
<fabbione> medwards_: http://www.ubuntulinux.org/wiki/LiveCDCustomizationHowTo
<mvo> hi dholbach, morning all
<fabbione> hey mvo
<amu> hey mvo 
<fabbione> amu: i get an error starting up kdm
<amu> fabbione: apt-get install kubuntu-default-settings
<fabbione> amu: "Cannot open theme file /usr/share/apps/kdm/themes/kubuntu"
<fabbione> amu: it should probably installed automatically or as Depends:
<fabbione> it's anybody working on it?
<mvo> hi fabbione, hi amu
<mvo> array-7 is not out yet? can I help with testing candidate?
<amu> fabbione: yep, dependswas added 
<fabbione> mvo: liveCD is borked and we are fixing it
<fabbione> it's a problem with X
<fabbione> much much better :-)
<fabbione> amu: it looks good
<mvo> fabbione: install is ok? should I test? or is it already blessed?
<fabbione> mvo: please test the install
<fabbione> more test is always good
* mvo is rsyncing
<cc> fabbione: ohh no. i'm relying on the livecd :P though i'm using a much older snapshot and it seems to work
<TerminX> how can I disable being forced to go through the entire Xorg configuration 3 times whenever the packages are upgraded?  I'm getting real tired of hitting escape
<fabbione> sorry jane, do you have one of my emails in which i did this calculation before?
<fabbione> ops
<svenl> Kamion, mdz: i have a question for you with regard the powerpc kernels.
<svenl> Right now, they ship a .coff kernel, which is between 1 and 2 MB big, multiplied by the 6 powerpc flavours.
<svenl> Debian removes this file.
<Treenaks> what is it used for?
<svenl> i believe that with the initrd-kernel concept, it is not only not usefull on any ubuntu supported hardware, but additionally it will not even work, not having the initrd.
<svenl> Treenaks: it was for pre-yaboot/quik booting of oldworld powerpc through the serial console OF prompt.
<svenl> Treenaks: i doubt it has ever been used in the last 3-6 years, and the mkvmlinuz support allows to generate the .coff from the vmlinux kernel and include the initrd.
<Treenaks> svenl: which nobody does nowadays, because of yaboot/quik
<svenl> Treenaks: exact.
<svenl> Treenaks: fabbione feels uneasy removing it though, this near the hoary release.
<svenl> Treenaks: but it would save around 10MB on the powerpc iso, so ...
<svenl> which is why i ask Kamion or mdz about it, Kamion as powerpc porter or whatever, and mdz because he mentioned the powerpc iso space limit.
<psy_> hi
<psy_> does anyone know how you should use gettext in combination with libglade?
<dholbach> psy_: the guys in #gtk+ on irc.gnome.org probaly know more about it
<psy_> :)
<psy_> ty
<dholbach> de rien :-)
<pitti> Hi guys
<dholbach> hi pitti
<dholbach> hi seb128 
<pitti> Hi seb128 
<seb128> hey
<pitti> seb128: I know what's wrong with g-vfs, I found the bug :-)
<pitti> seb128: (wrt adding harddisk partitions to fstab)
<seb128> pitti: oh, cool
<seb128> pitti: what is it ?
<thom> infinity: oddly, i have no objection :-)
<pitti> seb128: initially user_visible is 1, but then gvfs calls a hal_modify_drive (or so) function which sets it to 0
<fabbione> hi pitti
<fabbione> hey seb
<fabbione> morning thom
<pitti> seb128: invalid drives work because there is no hal drive
<thom> morning folks
<pitti> seb128: but valid partitions can't be seen by hal, so the policy sets it to invisible
<pitti> seb128: I'm fixing hal for this and also fix gvfs to fix the crash when updating fstab
<pitti> Hi fabbione, how are you
<fabbione> pitti: busy :-)
<seb128> pitti: k, thanks
<pitti> fabbione: surprise :-)
<fabbione> pitti: do you have anything for me today?
<pitti> fabbione: I worked offline until now (modem), I did not read mail yet; but not right now
<pitti> fabbione: you prepare a new kernel?
<fabbione> ok
<fabbione> yeah working on it.. but it won't be uploaded before Array7 is out
<dholbach> see you later
<ogra> morning
<fabbione> ogra: hey dude
<pitti> Hi ogra
<ogra> seb128, pog
<ogra> pong even
<seb128> hi
<ogra> :)
<seb128> should I ping you about the xscreensavers issues ? 
<ogra> yup
<ogra> i'll start with them today again..
<seb128> a sec, I've one 
<seb128> https://bugzilla.ubuntu.com/show_bug.cgi?id=7658
* ogra looks
<ogra> hmm, wondering how i can reproduce that for testing.....
<jordi> mvo: have you talked to jdub and whoever else needs to decide about nano?
<ogra> seb128, thanks :)
<mvo> jordi: not yet, everyone is busy with array-7
<jordi> mvo: that is so minor :P
<seb128> ogra: np :p
<seb128> hey jordi 
<jordi> hi seb
<seb128> jordi: not too desapointed by the maintainer upload for your almost new package ? :)
<mvo> jordi: compared to get magnificent nano editor :P
<jordi> seb128: so happy :)
<jordi> seb128: now I wonder if the suid root -> sgid mail fix I introduced in evo will persist when he ploads 2.2
<pitti> fabbione: just finished security review, no new kernel stuff today
<seb128> jordi: ah ah
<fabbione> pitti: thanks
<pitti> hey, postgresql 8 in experimental
<pitti> thanks elmo/Kinnison
<Treenaks> cool
<seb128> do we have an upload freeze for the new array ?
<seb128> or that's ok to upload ?
<fabbione> seb128: freeze i think
<seb128> k
<fabbione> it also depends what you need to upload
<seb128> I don't need anything
<seb128> there is some new versions for GNOME stuff, no hurry
<seb128> (ie: glade2)
<fabbione> probably better to wait after Array7
<seb128> yep
<seb128> thanks
<fabbione> no problem
* fabbione starts to cook some food
<jordi> mvo: there are further fixes in CVS.
<mvo> ping jdub 
<mvo> jordi: let's see if jdub is around
<jinty> hoi doko__
<sivang> jinty: hoi :)
<jinty> hey sivang
<jinty> looks quiet in here
<sivang> jinty: I guess everybody are busy or soemthing
<fabbione> hey jinty 
<ogra> jinty, nah
<jinty> hola all
<jinty> so there is life
<doko__> jinty: schoolbell in the works ... ;)
<jinty> great, thanks, just had a mail on the list asking which repository to use
<jinty> now I can reply
<Simira> mornin fabbione
<Simira> fabbione: how is the temperature in DN nowadays?
<mvo> Kamion: "Looking for keymap to install:\nNONE" after the reboot to stage2 in the installer shouldn't be NONE, right?
<fabbione> hi Simira 
<fabbione> Simira: it's 2 days that is around 6/7 C
<fabbione> Kamion: are you around?
<Kamion> fabbione: please do go ahead and remove vmlinux.coff; I can think of no reason to keep it
<fabbione> Kamion: can you please build livecd with xorg 6.8.2-5.1?
<Kamion> mvo: yeah, I don't know what that is, sorry
<fabbione> Kamion: we need it for Array 7
<fabbione> 6.8.2-5 was borked
<Kamion> yeah, just a sec
<fabbione> Kamion: ok. i can remove the coff thingy.... i have no issue with that other than breaking something :)
<Kamion> I only just woke up
<fabbione> Kamion: sure. let me know when i can rsync for testing
<pitti> daniels: why is it -5.1 and not -6, BTW?
<Simira> fabbione: how wonderful!
<amu> Kamion: please also a kubuntu run :)
<Kamion> fabbione: svenl's right there, it's an old thing for oldworld
<pitti> daniels: the fractions are generally security updates
<fabbione> pitti: because he has -6 ready somewhere else
<Kamion> and unuseful
<pitti> ok
<fabbione> Kamion: ok. i am just a bit conservative at this point in time
<Kamion> Ubuntu live CDs kicked
<fabbione> Kamion: wonderfull
<Kamion> fabbione: I think the space saving would indeed be very useful
<Kamion> amu: after I'm done with Ubuntu, sure
* Kamion will kick install CDs too now
<fabbione> Kamion: done
<fabbione> svenl: ^^
* fabbione -> food.. brb
<fabbione> re
<mvo> Kamion: I have a "X failed to start" in my test-install of the current cdimage. I guess that's a known issue already (because of the b0rked X)?
<fabbione> mvo: mostlikely yes
<Kamion> mvo: I guess ...
<Kamion> it's all rebuilding at the moment
<mvo> shout when it's ready :)
<svenl> fabbione: ok, thanks.
<svenl> fabbione: need to investigate the gigabit ethernet issue now, will keep you informed, and fix the hotplug thingy.
<fabbione> svenl: i would also like to understand what a user is supposed to do with the mkvinitrd thing
<fabbione> ok.. we ship the files.. and ?
<fabbione> is it something that happens automatically or does the user have to build his own thing
<svenl> fabbione: decide he would like to install ubuntu on a prep box, even if you don't support it officially ? 
<Kamion> fabbione: it goes in a kernel-package postinst hook
<fabbione> Kamion: yes.. i got that and i can see it
<svenl> fabbione: so you can ship yaboot-less one file netboot images for powerpc, especiall for ibm-rs6k, whose firmware is buggy and can netboot only one file, thus no yaboot and separate kernel and initrd.
<svenl> Kamion: the mkvmlinuz in hoary (12) does not have the postinst hook magic though, and maybe it is better so.
<Kamion> svenl: yeah, we aren't going to change that now I think, it can wait until post-hoary
<svenl> Kamion: definitively.
<fabbione> svenl: ok, so basically we ship these extra files as helper, but we don't use them directly (yet)
<svenl> Kamion: especially as ubuntu has no official support for non-yaboot powerpc.
<svenl> fabbione: exact.
<fabbione> svenl: how big are they?
<svenl> fabbione: we could build netboot chrp and prep images though.
<fabbione> we killed the 1~2Mb coff thingy....
<Kamion> the extra files are tiny AFAIK
<svenl> fabbione: a couple of .o files, let me check.
<svenl> 328k uncompressed for debian 2.6.10.
<fabbione> last 2 questions... is the tool to create such image aware of the .o location?
<svenl> so maybe 100K, don't kno.
<svenl> fabbione: you can pass it by -d option (which is done in debian-installer), but it will also locate it from the kernel path.
<fabbione> since i move them to linux-<whatever> instead of kernel-
<svenl> fabbione: read the manpage, it is rather complete.
<svenl> fabbione: i can provide a patch for that, or you could.
<Kamion> it hardcodes kernel-image-*
<Kamion> we'll have to fix that
<svenl> Kamion: easy to fix though.
<fabbione> Kamion: ok. what package is?
<fabbione> svenl: ok. last question.. can you give me a detailed entry for the changelog? :-)
<svenl>     # try a default location, then use the current directory
<svenl>     if objdir=/usr/lib/kernel-image-$release; test -d $objdir; then
<svenl> this one, at line 135 or thereabout needs changing, nothing more.
<svenl> just for mkvmlinuz support ? 
<fabbione> svenl: yes please
<svenl> yes, the above line is the only one needing change.
<fabbione> yes.. in which package?
<svenl> mkvmlinuz.
<svenl> /usr/sbin/mkvmlinuz
<svenl> its a shell script.
<fabbione> ok
<fabbione> svenl: i want the changelog entry for the kernel package :-)
<svenl> will you make it version 12.1 or something such as to not introduce version skew with debian later when you sync ? 
<fabbione> svenl 12ubuntu1
<fabbione> we have a standard version scheme
<pitti> ogra: yay, fixed the fstab bug
<fabbione> Kamion: are you ok if i upload it now?
<fabbione> (not the kernel...
<fabbione> mkvmlinuz)
<seb128> pitti: you rock :)
<pitti> seb128: you too :-)
<seb128> :)
<massarino> #ubuntu-it
<svenl> fabbione: ok, cool.
<svenl> fabbione: i would go ahead, nothing really uses it anyway, so ...
<fabbione> svenl: that is not the issue. we are building CD
<fabbione> for Array 7
<fabbione> i know nothing uses it
<svenl> Kamion: does ubuntu's base-installer already not have the mkvmlinuz call ? 
<fabbione> but each package that goes in now, might delay testing
<fabbione> let's just wait
<fabbione> it is more wise
<svenl> fabbione: yep, it is not needed anyway right now.
<ogra> pitti, WOOT
* ogra applauds pitti
<ogra> :)
<seb128> keep some applauds for this afternoon, he's going to squash the libgnomecups bug :p
<pitti> brb
<Kamion> fabbione: mkvmlinuz> sure, it's not on the CD
<Kamion> svenl: not for any subarches I care about, and mkvmlinuz is not on the CD, so
<fabbione> ok
<fabbione> how is it going with the CD's?
<Kamion> install CDs building, live cloops are done
<fabbione> rocking
<Kamion> however I'm now in the pub so all is much better :)
<fabbione> ahhhh
<fabbione> ehhehehe
<dholbach> Kamion: what time is at your place? 13:14? :-)
<fabbione> beer++
<Kamion> dholbach: 12:14
<dholbach> Kamion: oh yes... i see :-)
<Kamion> I generally work with Kinnison on Thursdays, and he wanted to attend his meeting from the pub :)
<dholbach> german craftsmen say "Kein Bier vor vier!" (no beer before 16:00) - but i won't stop you ;-)
<pitti> sjoerd: here?
<thom> Kamion: pub within wifi distance of your house?
<thom> nice
<Treenaks> dholbach: in dutch it's "Bier uur" (sounds/looks like "Vier uur") ;)
<pitti> dholbach: and what about the "Elferzug"? :-)
<Kamion> thom: nope, pub with free wifi
<thom> ah, even better
<Kamion> dholbach: here we talk about the sun being over the yard-arm (i.e. after 12:00)
<dholbach> Kamion: sounds much better to me :-)
<pitti> #u-devel - where you can learn invaluable cultural facts :-)
<dholbach> pitti: quite luckily i live far away enough from cologne to NOT know what the elferzug thinks about it :-)
<Kamion> aha, and the bandwidth is better here than at home, too
<pitti> Kamion: btw, yesterday I tested the PowerPC DVD, it does not boot at all. does it work for you?
<svenl> Kamion: IBM pseries and netbooting ? 
<Kamion> pitti: never tried it
<Robot101> pub with wireless, I wonder... :)
<Kamion> svenl: no idea; mkvmlinuz is in the archive though, so theoretically doable
<svenl> Kamion: like said, netboot pulled it in.
<seb128> mvo: there is a bug open about improving gksu dialog: #7385. I don't know if you are interested by it, feel free to Cc you and comment if you are :)
<Kamion> svenl: right
<cc> has kernel-team mail just dropped like crazy, or are there no kernel bugs?
<Treenaks> cc: the kernel is officialy Bug Free
<svenl> Kamion: not that important, since you are not pulling in mkvmlinuz 13.
<cc> Treenaks: or is bugzilla broken :)
<fabbione> the kernel does NOT have bugs
<fabbione> it's all fault of your buggy hardware
<Kamion> cc: kernel-bugs@ now
<trukulo> fabbione, 2.6.10 ?
<Kamion> pitti: I'll give the DVD a go when I get a chance, but it'll take a while ...
<cc> Kamion: oh, didn't realise. someone should've posted to kernel-team. i will now :P
<fabbione> Kamion: is install completed?
<Kamion> I do have a DVD reader in this laptop, just not a burner
<mvo> seb128: thanks, I'll have a look
<Kamion> fabbione: yeah, just done
* fabbione rsync
<pitti> Kamion: i386 dvd works fine btw (just tested the live part so far)
<seb128> mvo: thank you
<fabbione> mvo: can you test too please?
<Kamion> daily 20050317.1
<Kamion> pitti: cool. wonder what broke with powerpc
<Kamion> pitti: thanks for testing that though
<pitti> is it just me, or do other people also get apt-get authentication errors?
<mvo> fabbione: rsyning now
<thom> elmo: can you sync lsof 4.74.dfsg.2-1 (in incoming currently)
<Kamion> pitti: there's still a low but worrying frequency of those
<pitti> Kamion: for ppc, after pressing "c" for CD-ROM boot, I just get a small error message and are immediately thrown back to OF
<thom> elmo: (yes, please blow away the ubuntu changes)
<dholbach> fabbione: if you have the time, could you maybe have a look at   http://ubuntu.gplan.info/fuse  - the new version changed slightly and i'm not sure if it needs additional changes
<fabbione> dholbach: sorry.. not today. please remind me tomorrow
<dholbach> fabbione: alright... will do and prepare python-fuse for now
<fabbione> guys can you please hold the uploads? we are trying to get Array7 out...
<pitti> okay
<Kamion> pitti: oh, powerpc didn't build in the last run
<pitti> Kamion: I have an older version (dholbach: which one?)
<Kamion> pitti: 20050312 looks nominally OK
<pitti> dholbach: which version did you send me?
<daniels> has anyone tested xorg 6.8.2-5.1 with the cds?
<Kamion> daniels: they're still building
<pitti> Kamion: for downloading the DVD I tunneled IP-over-snailmail :-)
<Kamion> heh
<daniels> Kamion: ok
<fabbione> daniels: i did it locally
<fabbione> daniels: upgrading the livefs from 5 to 5.1
<pitti> Kamion: I have 20050308
<fabbione> and i did send you the sms :-)
<daniels> ok, i'll hang around until the new cds are built, and i can rsync and test the live cd
<daniels> yeah, just want to be sure
<fabbione> so do i
<fabbione> upgrading isn't the same
<daniels> last time i went to sleep before something was finished i got woken up a couple of hours later and didn't end up getting back to sleep
<daniels> yah
<mvo> install-cd is here
* mvo burns
<daniels> well, we'll find out
<Kamion> I'm rsyncing, but I won't be able to actually test for a couple of hours
<fabbione> Kamion: is the live up?
<Kamion> fabbione: yes, just
<Kamion> daily-live 20050317.3
<fabbione> is current linked to it?
<fabbione> ah there it is
<fabbione> come down baby
* fabbione sucks from a fat pipe
<daniels> for some reason , I'm getting a whopping 14kB/sec, so I haven't actually finished 0317.2 yet.  sigh.
<koke> mmm, my inotify is not working, how can I force the menu to re-read the applications thir without killing the panel??
<koke> if it's possible :)
<Mithrandir> why not just kill the panel?
<koke> IIRC some KDE apps in the systray behave strange after killing it. And maybe the update-notifier
<mvo> koke: update-notifier should be fixed (it should just restart when the panel was killed)
<mvo> koke: please file a bug if not :)
<koke> mvo: OK, I'll try
* fabbione burns the live
<koke> mvo: it's ok. only disappeared kmail and akregator :)
<mvo> koke: thanks :)
* pitti works offline for a bit, cu later
<dholbach> elmo: thanks for getting new libgdamm1.3 through 
<mvo> elmo: thanks for the nessus sync!
<fabbione> elmo: thanks for your bank account code.. let the packages for the others :-)
* mvo chuckles 
<Mithrandir> Kamion: is there some way to make ssh grab its password from a pipe/fd?
<Kamion> Mithrandir: SSH_ASKPASS?
<Mithrandir> Kamion: that's not for passwords, just for passphrases, it seems?
<Mithrandir> (and I can't put a public key there, since it's an ssh-accessible public svn repo)
<Kamion> Mithrandir: you sure? ssh calls the read_passphrase() function when replying to a password prompt
<Mithrandir> SSH_ASKPASS=ssh-askpass ssh root@10.5.0.1
<Mithrandir> Password:
<Mithrandir> SSH_ASKPASS=ssh-askpass ssh root@10.5.0.1
<Mithrandir> Password:
<Mithrandir> (sorry for the double)
<Kamion> oh, no, it turns off the RP_USE_ASKPASS flag in that code path
<Kamion> oh well
<Mithrandir> yeah
<pitti> seb128: bah, jody changed very much in the new libgnomecups, it's not a simple bugfix
<Mithrandir> I should whack the hula people to provide a secret key one can use anonymously for accessing the svn
<Kamion> dunno if you can do it with a keyboard-interactive device
<pitti> seb128: what is jody's nick? "jody"?
<jdub> pitti: yes
<seb128> pitti: right
<pitti> hmm, he's not online
<pitti> I looked in #gnome
<seb128> /whois 
<seb128> --- [jody]  idle 08:09:57, signon: Thu Mar  3 00:02:18
<seb128> you can probably drop a message in query
<seb128> jdub: hey !
<seb128> jdub: https://bugzilla.ubuntu.com/show_bug.cgi?id=7279, do we want this entry in the menu ?
<jdub> seb128: no, in fact i was just about to ping you about a few of those
<jdub> seb128: cd database, database properties, multimedia systems -> should be killed
<jdub> i had trouble killing stuff from the prefs menus, but perhaps recent changes in gnome-menus has helped
<seb128> jdub: BTW have you seen the panel update ? :)
<jdub> yes, saw your upload :-)
<seb128> jdub: what trouble ? adding a NoDisplay=true is not enough ?
<seb128> we can also drop the entries
<jdub> seb128: wanted to do it in gnome-menus rather than individual packages
<sivang> pitti: I seem to have a problme with cdbs-edit-patch, I think it's not applying one of the patches I have on d/p 
<pitti> sivang: it does not apply patches which come lexicographically _after_ the patch you are editing
<pitti> sivang: this is an important feature, not a bug
<jdub> anyway, i should go back to bed :-)
* fabbione goes live
<sivang> pitti: I wasn't suggesting this was a bug, would you care to explain the rationale?
<doko> is there an easy way to determine, if a user is running a KDE or a Gnome environment?
<seb128> jdub: I'll mask "cd database, database properties, multimedia systems" for the moment
<jdub> doko: not in a particularly sane way, no
<Treenaks> doko: you shouldn't need to
<Simira> jdub: ping
<Simira> jdub: mewants ubuntu-no mailing list!
<pitti> sivang: because the patches that come after the one you are editing are also applied later; so the edited patch must not depend on changes from later patches
<Treenaks> Simira: how about a "no-ubuntu" mailing list!
<jdub> Simira: requests via email please
<Simira> Treenaks: ha ha... would that really be a good idea?
<I-Rock> YAY
<doko> sane or not doesn't matter ;) just want to call the correct email client from OOo evolution or kmail ...
<I-Rock> Kamion: LiveCD is go here
<Kamion> arch?
* Mithrandir sniffs over Simira not being happy with his @ubuntu.no lists.
<Simira> jdub: I have done that... two weeks ago
<I-Rock> going to test on the other 2 boxes
<sivang> pitti: ah right! 
<sivang> pitti: nice :)
<Kamion> bah
<jdub> doko: there's no appropriate way to detect
<jdub> Simira: i don't have an email from you
* jdub has to go back to bed, or will continue to be a zombie for the rest of the week ;)
<sivang> not good being a zombie
<Simira> jdub: I even sent it on Valentines day!!!
* Mithrandir wonders what a zombie jdub would act like, considering his usualy craziness. :)
<daniels> jdub: yeah
* Simira feels unloved by jdub
<sivang> Simira: don't take it personally, he loves only seb128
<sivang> :-)
<mvo> Kamion: I just booted the live-cd and I still don't have a german keyboard on the console (X is fine though)
<pitti> "still"?
<Simira> sivang: but... but... I'm nice! And I want my mailing list!
<Treenaks> Simira: just mail him about it then :)
<mvo> pitti: "still" means, got that yesterday too
<Simira> *sigh*
* Mithrandir hugs Simira 
* Simira doesn't feel any warm arms around her
<mvo> Kamion: otherwise it looks fine
<fabbione> mvo: did the install work?
<Kamion> mvo: ok, I'll have to try that out later; probably not an Array 7 blocker, but could you file a bug please?
<mvo> fabbione: stage1 finished, stage2 is running right now
<daniels> fabbione: is live any good?
<mvo> Kamion: sure, not a big issue, I'll file a bug (install seems to have the same problem in stage2)
<Kamion> 'k
<Kamion> hm, interesting breakage though
<mvo> daniels: just worked fine for my test (X came up with correct keyboard and stuff)
<fabbione> daniels: read above "I-Rock"
<Kamion> fabbione: what architecture was that?
<fabbione> Kamion: i386
<fabbione> that's the only one i have here
<zul> hey
<fabbione> LiveCD is go on 2/3 boxes
<daniels> thanks guys, goodnight
<fabbione> gnight daniels
<dholbach> bye daniels 
<zul> night daniels
<mvo> night daniels 
<pitti> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=170673
<pitti> seb128: this is too much for me; maybe we should rather downgrade to libgnomecups 0.1.4 for now
<seb128> pitti: utch, want to epoch for that ?
<seb128> on several packages ?
<zul> someone was looking for me?
<pitti> seb128: hmm, rather not epoch. maybe 0.2+really0.1.4 or so :-)
<pitti> seb128: this could require a g-c-m downgrade as well, since g-c-m 0.3 depends on libgnomecups 0.2
<seb128> yeah
<pitti> *sigh*
<seb128> that kind of suck
<pitti> let's see what jody says before
<seb128> I'll let some days to upstream to reply on that before going in this way
<pitti> seb128: indeed, that was what I wanted to propose :-)
<pitti> seb128: downgrading is safe and can be done quickly
<seb128> right
<seb128> thanks pitti
* pitti goes to university to get actual bandwidth
<pitti> seb128: np; but no applause today :-(
<pitti> :-)
<thom> man, redhat's bugzilla is so sweet
<seb128> how ?
<thom> it's fast, doesn't make my eyes hurt, the interlinking stuff is nice, search is actually useful...
<Treenaks> thom: especially the last part is nice
<amu> seb128: I found your brother "Riddell, he broke my KDE-panel"
<seb128> thom: how, is there a difference in the search ?
<seb128> amu: bah, that's normal for KDE, isn't it ? :p
<Treenaks> amu: that sounds like a t-shirt quote: "Ridell broke my KDE panel"
<thom> seb128: dunno, but it's the only bugzilla i've found that finds stuff that i'm actually looking for :/
<seb128> you search for words
<amu> seb128: no it isnt such easy ;)  
<seb128> perhaps people put useful bugs in it ? :p
<thom> that's also possible
<seb128> ie: nice description with the right words to find stuff :)
<thom> seb128: you mean all the bugs i file shouldn't have "iz gtk boog" as the description?!?
<thom> ;-)
<amu> Treenaks: hehe, those cafepress? 
<Treenaks> amu: ask Keybuk :) he has a "seb128" one
<amu> Treenaks: yep saw them, we can order them for all and give them away in .au? 
<Treenaks> amu: you could, but I'm not going there :(
<amu> Treenaks: you stay so close to me, we could arrange a meeting, and we celebrate the panel day
<dholbach> hellas jani 
<fabbione> Kamion: ok. 3/3 livecd is GO
<jani> hi dholbach
<amu> fabbione: did you test with my QA doc? :) 
<fabbione> amu: ehm... what QA doc?
<amu> http://www.ubuntulinux.org/wiki/QAtesting
<Kamion> fabbione: cool, thanks
<lamont> pitti been around?
<fabbione> Kamion: no problem. please hold the images for mdz to approve
<Kamion> ?
<Kamion> he's normally happy for me to do Array releases by myself
<fabbione> Kamion: i think he will test them too
<fabbione> ok
<Kamion> well, we'll see how my testing goes, back home now
<Robot101> lamont: missed him by about 20 mins
<lamont> grumble
<pitti> re
<thom> that's impressive timing
<jani> was it decided that evince replaces xpdf as default?
<Kamion> mdz was unhappy about making that change at this stage
<fabbione> amu: just to fill that page, it would take me more time than writing AI 
<Treenaks> jani: is it fully featured then?
<jani> It was just my impression at the Friday meeting
<dholbach> yes
<jani> but see it's still in desktop
<jani> but Kamion explained it so ok
<jani> anyone here with toolchain building experience?
* mvo thinks that some kind of progress thing for scrollkeeper would be nice. it takes _ages_
<Treenaks> mvo: yes! and for ldconfig too
<Treenaks> (ldconfig takes AGES on my P3-600 laptop)
<mvo> Treenaks: my test-machine is a p2-400 :p
<pitti> mvo: IMHO it should rather be done with nice 19 in the background
<Treenaks> pitti: that breaks when you shutdown immediately after upgrade on a slow machine
<mvo> and it seems to try getting stuff from the net :/
<Treenaks> (and yes, people will do that)
<mvo> Kamion: install-cd is fine here (except the console keymap problem). X comes up, sound looks good and X-keymap is fine too
<pitti> Treenaks: hmm, right
<pitti> Treenaks: however, I assume it's always the same result after desktop installation? Maybe there can be some sort of pre-caching (not for Hoary, of course)
<Kamion> pitti: also don't think it's a good idea to do it in the background because that's exactly the time when people are most likely to try to use the machine and review its responsiveness
<pitti> Kamion: hmm, yeah
<pitti> Kamion: btw, do your USB devices (WLAN, flash drive, etc.) work after resuming from sleep?
<Kamion> I believe that's known-broken on powerpc at the moment
<Kamion> benh has said it's non-trivial
<pitti> Kamion: if it happens for other folks as well, then I'd like to upload my workaround
<ogra> pitti, great news, so we can close all these hal bugs ? :)
<pitti> Kamion: #7619 contains my workaround and it works fine for me for about a week now
<pitti> ogra: erm, not all of them, I think
<pitti> ogra: I just fixed the "drives in /etc/fstab" don't appear" one
<ogra> oh, i thought the eternal restartting of gnome-vfs-daemon too....
<pitti> ogra: oh, that one too, yes
<Kamion> pitti: the suggestion in comment #2 seems reasonable, yeah
<pitti> ogra: but I don't know whether this actually fixes something
<ogra> so this should match more then 50% of them
<Kamion> the "resume script only" one
<Kamion> pitti: I haven't tried it myself I'm afraid
<ogra> pitti, i think the "my CD player starts over and over again" one at least :)
<pitti> Kamion: indeed, that's what I'm using for a week now
<pitti> ogra: hmm, I doubt that it's this one; it has not anything to do with g-vfs-daemon
<pitti> ogra: that's a g-v-m issue
<ogra> doesnt it trigger g-v-m ?
<pitti> no, hal triggers g-v-m
<ogra> hm
<pitti> g-vfs-daemon is just responsible for the computer/places/menu magic
<thom> please make it so i can leave a cd in the drive. KTHXBYE
<seb128> :)
<dholbach> oh yes: http://tseng.ath.cx/log/?p=9 :-)
<sivang> thom: why would? I enjoy knowing what there is in the cdrw before writing onto it :-))
<thom> sivang: you enjoy being reminded every 5 minutes? 
<pitti> thom: EWORKSFORME
<pitti> thom: I need a full hal/gvm debugging output 
<sivang> thom: not actually, hence the :-)) 
<pitti> thom: http://wiki.ubuntu.com/DebuggingRemovableDevices
<sivang> thom: I should haev used <sarcasm></sarcasm> probably
<thom> pitti: i'm trying to find a cd that won't annoy me by stealing focus
<pitti> thom: turn down the volume :-)
<seb128> there is not focus stealing
<pitti> mental focus, I assume
<seb128> stop the FUD thom :p
<sivang> pitti: LOL
<thom> seb128: cd player steals focus
<thom> seb128: just tested it :P
<seb128> roooh
<seb128> booog
* pitti fetches his "don't blame me for GTK bugs" shirt
<thom> pitti: i'm not blaming you for that :-)
<pitti> sure :-)
<smurfix> Another X update, three more rounds of pointlessly debconf-answering every X question in existence. Shouldn't that be fixed by now?
<Kamion> we had to revert
<pitti> thom: however, I'm very interested in the debug outputs, otherwise I can't do anything about it
<smurfix> Kamion: Ouch.
<Kamion> smurfix: live CD breakage was more important
* smurfix reluctantly agrees with that prioritization
<sjoerd> pitti: pong
<thom> pitti: yup, running now
<pitti> sjoerd: http://bugzilla.ubuntu.com/7641
<thom> seb128: want a bug filed or will you just fix it?
<pitti> sjoerd: this fix should interest Debian as well
* thom puts money on it not happening this time
<sivang> lol
<seb128> thom: put it in bugzilla please
<sjoerd> pitti: k, i'll take a look at all the ubuntu stuff for the next package anyway..
<dholbach> bbl
<thom> is it just me or is bugzilla hating the world currently
<seb128> pitti: jody seems to be interested by #6520, let me know if you have an idea on it :)
<pitti> seb128: didn't deal with it yet, I have to catch up on security
<seb128> k
<thom> seb128: https://bugzilla.ubuntu.com/show_bug.cgi?id=7793
<pitti> I slacked with security updates for two days now...
<seb128> thom: thanks
<thom> seb128: enjoy ;-)
<seb128> :p
<Burgundavia> jdub: there is a related bug filed by me about naming it
<thom> pitti, ogra: just updated #6002
<Burgundavia> jdub: nev mind, for some reason xchat hadn't been rolling with the new changes
<pitti> thanks
<lamont> pitti!
<Mitario> hello everyone
<ogra> thom, thanks, the log data looks ok to me...
<pitti> Hi Mitario 
<pitti> ogra, thom: this looks as if your CD-ROM module was unloaded after some time...
<ogra> pitti, callout.c:318: Invoking /etc/hal/device.d/40-hal-hotplug-map.hal
<ogra> 14:51:59.037 [I]  callout.c:330: Child pid 14002 for 40-hal-hotplug-map.hal
<ogra> 14:51:59.038 [I]  callout.c:173: Child pid 14002 terminated
<ogra> what about this, seems to occur more then once
<pitti> 14:51:56.619 [I]  linux/block_class_device.c:931: Removing volume for no_partitions device /dev/hdc
<pitti> this one is the interesting stuff
<Mitario> mvo, ping
<pitti> it occurs about 15 minutes after the CD was inserted
<mvo> hey Mitario 
<Mitario> mvo, hi :-)
<mvo> hi :)
<Mitario> mvo, any updates on update-manager?
<fabbione> Kamion: i need to go to the bank.
<fabbione> Kamion: i will be back in one hour or so i think
<fabbione> can you tell mdz when he wakes up?
<Kamion> ok, all looking good here
<Kamion> yeah
<fabbione> perfect
<Kamion> I have a meeting at 4
<Kamion> (one hour)
<mvo> Mitario: no, no feedback from cvsmaster. and I tried the import too but it looks like it does not accept my ssh-key
<fabbione> we should be back more or less at the same time
<Mitario> mvo, do you get an error?
<fabbione> later
* fabbione &
* pitti tests crack-of-the-day ppc live cd
<mvo> Mitario: no
<Kamion> the evolution splash screen that says that this version is not yet stable is still there
<Kamion> I thought that was supposed to have gone away with 2.2?
<mvo> Mitario: I get prompted for a login password
<Mitario> mvo, ah
<mvo> Mitario: so it looks like my key is not yet accepted
<Mitario> hmm weird, have you contacted the cvsmaster?
<mvo> Mitario: not yet, was busy with other stuff 
<Mitario> mvo, ok
<mvo> Mitario: will try later
<Mitario> mvo, ok :)
<torkel> Kamion: I think there was a patch for it on evolution-patches that got accepted, so it will probably be resolved in the next release
<pitti> 17.3 live CD for ppc rocks
<lamont> mdz: awake yet?
<Nafallo> powernowd is screwed again here. I take a look at it.
<Kinnison> Hi guys. Any word on when the jimmac cursor theme will be back?
<tseng> its back
<Kinnison> It is?
<tseng> its just missing the file to make it default.
<tseng> try gcursor
<Kinnison> aah
* Kinnison installs
<Kinnison> hmm, mine still look duff
* Kinnison will restart X
<ogra> Kinnison, logout is enough
<Nafallo> hmm, I'll restart and see if things are solved.
<Kinnison> ogra: didn't seem to do the trick
<Kinnison> my cursor in GDM at least still looks cack
<ogra> yeah, gcursor only applys to your session
<Burgundavia> can I ask for some advice on: https://bugzilla.ubuntu.com/show_bug.cgi?id=7455
<Kinnison> ogra: aah; can I make it the default theme overall?
<ogra> Kinnison, blame jdub.... industrial engine has a packaging bug
<Kinnison> ogra: *pout*
<ogra> but it is known and will get solved...gcursor is only a workaround
* Kinnison tries logging in again
* Burgundavia pats Kinnison on the head
<Kinnison> Aaah yes; logged in it looks okay. Thanks ever so much guys
<ogra> :)
<Kinnison> Burgundavia: I might be a developer; but I'm still a picky user too :-)
<Burgundavia> Kinnison: that is good. The day you stop being a picky user, that is the day I find a new distro
<ogra> Kinnison, oh ? i thought youre a poet
<Kinnison> ogra: whatever gave you that idea?
<Kinnison> Burgundavia: meep
<sivang> Kinnison:   :-)
<Kinnison> Burgundavia: pile the stress on why don't you?
* Kinnison sobs
<Burgundavia> Kinnison: I meant that generally for all devs
<Kinnison> sivang: and that demonstrates that pterm has reverted :-(
<Kinnison> sivang: My right-to-left support is broken :-(
<ogra> Kinnison, your jabberwocky recitation in mataro ;)
<sivang> Kinnison: oh oops, sorry 
<Kinnison> sivang: Not your fault
<Burgundavia> did anyone look at my bug or not?
* Kinnison glares at the pterm maintainer (who is across the table from me right now)
<sivang> Kinnison: I said "Hi Daniel"
<sivang> Kinnison: where are you in?
<lamont> sivang: I bet Kamion's flat
<Kinnison> lamont: Well; Kamion's back room
<Kinnison> lamont: of a three story house.
<lamont> there's 3 floors there?
<Kinnison> yip
<lamont> basement, or am I truly that clueless some days?
<Kinnison> lamont: ground + two floors upwards
<lamont> hrmpf.
<lamont> well, ground + more is what I remember - kinda assumed total of 2. :-)
* Kinnison grins
* lamont learns something new every day
* lamont fetches a set of cd images, goes to get ready to fetch them.
<Kinnison> time for me to go
<sivang> Kinnison: nice, so you have like a miniconf there :)
<Kinnison> c'y'all later
<Kinnison> sivang: every thursday pretty much
<ogra> Kinnison, ciao
<sivang> Kinnison: woo cool
* sivang is amazed to find out his net connection is virtually unusable for uploading/downloading files.
<sivang> Riddell: are you having download problems from muse ?
<sivang> Riddell: I'm getting rideculeous downstream..
<Riddell> sivang: my screen session on muse it running fine
<sivang> Riddell: argh, then it's my ISP's fault. I can't even use the screen session itneractively
<pitti> seb128: can you please review http://muse.19inch.net/~sivan/g-c-m/sivan-gcm-crack.diff ?
<pitti> seb128: the code looks fine to me, but now the patch was bloated by update-po
<thom> *COCK*
<ogra> huh ?
<Nafallo> thom: ping?
<thom> i needed to swear about my favourite subject
<thom> yes
<Nafallo> thom: am I correct if I say powernowd's init-script was changed for ubuntu12?
<thom> no; the cpufreq detection script was changed
<Nafallo> thom: hmm. I try to debug why powernow-k8 doesn't get modprobed.
<jordi> muuuu
<thom> Nafallo: sudo sh -x /usr/share/doc/cpufreq-detect.sh and attach the output to the bug
<sivang> thom !
<sivang> :-)
<jordi> silly question. Is the new array CDs available already, or not yet?
<seb128> pitti: k
<jordi> and if so, is today's daily safe?
<mvo> jordi: no release yet, but some of us tested the dailes and they are mostly fine
<Nafallo> thom: done
<jordi> mvo: today's?
<mvo> jordi: yes
<jordi> http://cdimage.ubuntulinux.org/daily-live/current/ <--- ie, this
<mvo> jordi: yes :)
<jordi> ok :)
<Kamion> lamont: you wouldn't have noticed the third unless you were paying attention - this house makes good use of what others would consider roof space
<Kamion> lamont: although it's somewhat taller than your average two-storey house
<Kamion> jordi: today's daily will likely be array 7, tests are good so far
<thom> Nafallo: so just running /usr/share/doc/cpufreq-detect.sh returns powernow-k8?
<jordi> Kamion: great
<Nafallo> thom: I can see nothing wrong with the detection-script. Seems to find me.
<Nafallo> thom: nope.
<Nafallo> thom: We're a laptop\ powernow-k8
<Nafallo> thom: the init-script tries to load "We're a laptop" then? ;-)
<thom> aaargh, i knew i should fix that
<thom> thanks
<Mithrandir> Kamion: could the amd64 scsi-modules-udeb include the i2o drivers as well?
<Kamion> Mithrandir: erm, guess so, can't check now though
<Nafallo> thom: works when I edited /usr/sbin/laptop-detect not to echo :-).
<Mithrandir> Kamion: should I rather file a bug, just?
<Kamion> Mithrandir: yeah, might as well
<Mithrandir> thanks. :)
<mdz> lamont: here
<mdz> Kamion: how is it going?
<pitti> Morning mdz
<zul> hey mdz 
<HiddenWolf> Ugh. lots of issues with gamin right now. :S
<mdz> morning folks
<Nafallo> thom: no problem. bug assigned instead of NEEDINFO :-).
<ogra> morning mdz
<Nafallo> mdz: morning :-)
<sivang> morning mdz
<mvo> morning mdz 
<Mithrandir> argh, why can't I file a bug on scsi-modules-udeb?
<pitti> mdz:  nice to see the new dpkg with fixed Replaces: :-)
<mdz> pitti: yes, hopefully we will find some time to test it before release ;-)
<pitti> mdz: I'll do ASAP
<pitti> mdz: and we can drop the Pre-Depends again and instead introduce the circular dependency
<pitti> mdz: if my local tests work, I upload update packages for broader testing :-)
<mdz> Mithrandir: because my bugzilla component-o-matic is a quick hack and doesn't look at the d-i Packages files
<Mithrandir> mdz: ok, I just filed it against debian-installer.
<Mithrandir> hopefully it won't drown there. :)
<mdz> I must have just missed Kamion
<mdz> seb128: are you here?
<seb128> mdz: yep
<zul> lunch
<mdz> seb128: can you help Jeff with #6172?
<mdz> seb128: (the cursor fix)
<fabbione> re
<Nafallo> thom: nice fix on 7771! :-D
<fabbione> mdz: good morning
<mdz> fabbione: morning, how is array 7?
<fabbione> mdz: ready to go.
<pitti> gooooood on ppc
<thom> mjg59: i think we need to run ifrename during resume
<mdz> fabbione: Kamion is satisfied with it?
<pitti> mdz: keyboard works great now on live CD :-)
<fabbione> we were waiting for you to release but Kamion had to go out for an hour or so
<mdz> I am rsyncing now
<mdz> pitti: great!
<mdz> ok, since he is out anyway I will do a quick test
<fabbione> mdz: we are go for i386 both live and install
<seb128> mdz: does he need some help, or is that a "can you see with him to get that fixed now" ? :)
<fabbione> mdz: Kamion did his round of tests and reported no problems
<mdz> seb128: both; it is a non-trivial fix because it uses alternatives and the packaging needs to un-break the alternative
<fabbione> mdz: there is only one bug on console keymaps, but we consider it a non stopper
<seb128> mdz: k, will have a look
<fabbione> mdz: so everything looks good for A7
<mdz> fabbione: regression from preview?
<fabbione> mdz: the console keymap is not correct after the selection, but X gets it right
<mdz> seb128: currently the alternative points to a nonexistent file and so has reverted to manual mode, due to an upgrade issue some time ago
<fabbione> it is exactly the opposite problem we had with warty
<fabbione> Kamion was sure to have fixed it, but apparently it wasn't
<mdz> seb128: what I believe we need to do is have gtk2-engines-industrial notice this and switch the alternative back to auto
<fabbione> and it did show up only on .de keyboards
<mdz> seb128: then it should switch itself to the highest priority one as it should be
<seb128> mdz: ok
<mdz> seb128: we talked about it some in this channel; I can paste you from my log if it would be helpful
<seb128> yes please
<pitti> fabbione: darn, I didn't test this when I tested the live CD; shall I try this?
<fabbione> pitti: if you can..
<seb128> and I've not played with the alternatives out of the normal bits before
<pitti> fabbione: sure, rebooting now into live CD
<pitti> brb
<mvo> the keymap issue is reported as #7790
<mvo> (just FYI)
<fabbione> ok
<fabbione> thanks mvo
<mdz> mvo: how is the upgrade work going?
<mdz> mvo: also I just remembered yesterday that we have not dealt with libgnome2-perl
<mvo> mdz: pretty good. I added a comment to #7419 how the removal of ubuntu-desktop can be worked around, I added a debdiff for #7743 (fontconfig upgrade). I can upload after the array-7 release :)
<mvo> mdz: about the libgnome2-perl, I can add that as a dependency and upload (I need to look into a synaptic bug anyway). I didn't until now because I wasn't sure if we shouldn't just add libgnome2-perl to the desktop seed
<pitti> mdz, fabbione, mvo: .de console keyboard on ppc/live works fine for me; the only regression is that the Apple key does not work like a AltGt
<pitti> but all the other keys are correct
<pitti> s/AltGt/AltGr/
<mdz> amd64-live looks good
<pitti> however, I did discover an ugliness
<mdz> mvo: I am not sure either
<mdz> mvo: probably the desktop seed, since it should be possible to remove it without removing synaptic
<pitti> when using the "Check keyboard layout" without having used the "type a few keys" selector first, you get an error
<pitti> relatively easy recovery, though
<pitti> smurfix: ^
<mvo> mdz: nod
<smurfix> pitti: Is the correct keyboard name displayed in the first line?
<pitti> smurfix: before the bug, it's "Deutsch"; after checking the keyboard, it's "de-latin1-nodeadkeys"
<pitti> smurfix: this is ugly as well, btw :-)
<mdz> mvo: I am very worried that that frontend has not received sufficient testing, though
<mvo> mdz: what frontend? gnome-debconf? 
<mdz> mvo: yes.  how many people are using it?
<mvo> mdz: it's around for a long time in debian, I use it for all my work. I don't think it will be a problem. but I agree, we should switch to it fast 
<mvo> mdz: I can upload a synaptic with that dependency today if you want (I don't think that I can change seeds, can I?)
* pitti never saw gnome debconf
<pitti> mvo: you can
<mvo> pitti: oh, nice
<bluefoxicy> Hello
<mvo> mdz: I would be interessted in your opinion in #7419 (no rush, when you have time)
<smurfix> Gah. pitti: that doesn't happen on i386
<jordi> mvo: ok, mailed david telling him current CVS seems quite sane (unless you state the contrary), and asking about what's left for 1.3.6
<pitti> smurfix: and on your pb?
<bluefoxicy> Simply:  Should Ubuntu require a very very fast multi-gigahertz CPU to stay out of the 100%+ range of CPU usage?
<ogra> pitti, its ugly, but better then terminal for users
<mvo> jordi: thanks!
<mdz> powerpc-live looks good
<mdz> mvo: ok, let's switch to it immediately after array 7
<smurfix> pitti: I do not *have* a powerbook at the moment, though I can grab one tomorrow.
<mvo> mdz: ok
<bluefoxicy>   PID USER      PR  NI  VIRT  RES  SHR S PU %MEM    TIME+  COMMAND
<bluefoxicy> 26252 bluefox   25   0  6264 4984  856 R 40.9  0.6   6:46.17 gam_server
<bluefoxicy>  7675 bluefox   25   0 19452 8888 6384 R 40.5  1.1  72:20.71 gnome-settings-
<pitti> smurfix: oh, what happened to yours?
<mdz> mvo: I had forgotten about it for a while; we should have done it before array 7 :-/
<jordi> mvo: now you get your release dudes to think about this change :)
<bluefoxicy> err, only wanted the last 2 lines
<pitti> mvo: ubuntu-devel@lists.ubuntu.com/seeds--hoary--0
<jordi> mvo: in any case, the latest test deb should get some publicity so people test it.
<bluefoxicy> But this is pretty continuous, should these two be using 100% CPU together most of the time while I'm not doing anything in particular?
<smurfix> Somebody thought my backpack would make a nice addition to his collection. Unfortunately he didn't ask me first.
<mdz> jordi: hmmm?
<bluefoxicy> (mlnet and X have the other 10%, and rhythmbox)
<pitti> smurfix: bah, what a nice guy
<mdz> smurfix: no laptop in it, I hope
<bluefoxicy> they've been holding 100% CPU usage for a day or so now
<fabbione> bluefoxicy: please stop joining the chan and pasting stuff like this. use #ubuntu for support
<bluefoxicy> fabbione:  #ubuntu for bugs?
<smurfix> mdz: Sure there was.  :-(  :-(
<fabbione> bluefoxicy: if it is a bug you use bugzilla.u.c
<mdz> smurfix: oh no! :-(
<bluefoxicy> fabbione:  does it count if nobody actually ever responds to anything I ask that seems to be a technical issue in #ubuntu?
<fabbione> bluefoxicy: not all developers are here at the same time
<bluefoxicy> though they do respond to "How do I ..." questions readily.
<bluefoxicy> fabbione:  well I wanna make sure this isn't normal :o
<smurfix> mdz: My thought exactly.
<fabbione> bluefoxicy: open the bug. if it is not a bug, you will be notified by the maintainer
<bluefoxicy> fabbione:  and I already tried the bugzilla; firefox sat there for 5 minutes and d idn't download a single byte of bugzilla.ubuntu.com
<bluefoxicy> :(
<lamont> bluefoxicy: this is the channel to discuss your patch to fix the problem.
<bluefoxicy> lamont:  oh, sorry nota  programmer?
<mvo> mdz: jordi is working with upstream to get a nano with utf-8 support
* bluefoxicy goes back to writing a C++ program that he needs done by 5 today
<mdz> mvo: ah, this does not sound like a hoary change :-)
<mvo> mdz: yes, I don't have a good feeling about it. OTOH we'll ship with a broken $EDITOR by default (that can't handle e.g. umlauts)
<mdz> mvo: better than risking an editor which has bugs with ascii :-)
<jordi> (with a UTF-8 locale)
<mdz> nano is the only editor available in the installer
<mdz> I don't think there is time to test it sufficiently
<jordi> mdz: this mostly affects nano, not nano-udeb.
<mdz> jordi: oh?
<mdz> do we even ship nano?
<jordi> but I agree this is quite late.
<jordi> mdz: I guess.
<jordi> what's you're easy to use text editor if not? vi?
<mdz> hmm, apparently we do
<jordi> your even
<smurfix> pitti: Can you grab d-i and build a powerpc-netboot ISO for me?
<fabbione> smurfix: is that mkvmlinuz thingy?
<doko> mdz: we are missing a lot of myspell-<lang> and openoffice.org-hyphenation-<lang> packages for important languages like af, zu and da (well, maybe da is not important). ok to add these packages?
<smurfix> fabbione: No, I need to debug a few keyboard selector snags
<fabbione> smurfix: ah ok
<mdz> doko: ->pitti
<sivang> pitti: we have a problem with users-admin, another one :-(
<mdz> doko: those packages should be dependencies of the language-support-* packages
<pitti> doko: fine for me
<smurfix> (or anybody else who's got a ppc box)
<jordi> pitti: umh.
<pitti> doko: "missing" -> not in the archive, or not in main?
<doko> not in the archives
<pitti> uh
<pitti> in sid?
<sivang> pitti: John Richard Jose noted it on the mailing list, when you read it, let me know what you think. the fix doesn't seem small
<doko> no
<jordi> pitti: someone just downloaded today's daily and he says the translations appear to be incomplete or from stone age
<jordi> ie, the GNOME panel menus are not translated at all
<jordi> not even "Places", etc.
<pitti> jordi: hmm, works fine for me
<pitti> jordi: which language?
<jordi> Are the mo files those coming from the tarballs?
<jordi> ca
<pitti> jordi: yes
<jordi> gnome-panel is 18:18 < josep> 2.10.0-0ubuntu5
<jordi> pitti: weird.
<pitti> jordi: are the mo files correct?
<jordi> checking with msgunfmt
<pitti> doko: I have no problems with new locale packages, they are usually uncritical
<pitti> doko: as soon as they are in hoary, I can add them to the support packages
<seb128> jordi: you should kick the GNOME ca translators :p
<jordi> seb128: I'M NOT KICKING MYSELF DUDE :P
<seb128> you should DUDE
<jordi> seb128: besides we were finished translating a week early
<jordi> DUDE
<jordi> :P
<mdz> i386-live is good
<seb128> BTW have you strace -e open it to see what translation file is used ?
<seb128> gnome-session-remove gnome-panel
<jordi> seb128: the guy testing tells me the mo files are old :(
<seb128> strace -e open gnome-panel
<pitti> jordi: version of language-pack-ca-base?
<seb128> k
<jordi> pitti: in a second
<jordi> seb128: it's either your fault or thom's fault.
<seb128> WTF ?
<pitti> IZ GTK BUG
<seb128> iz pitti beeing lame again
<seb128> after breaking gnome-cups-manager 
* seb128 hides
<pitti> jordi: no, seriously, I need to know whether the mo files are outdated, or it's pickign the wrong mo file
<jordi> pitti: uh, not installed
<pitti> HAH
<seb128> lol
<jordi> this is live cd
<pitti> hmm
<seb128> we have ca translations on the liveCD now ?
<pitti> jordi: I added the package two days ago
<jordi> pitti: hopefully he downloaded the correct iso
<pitti> ~/ubuntu/seeds-hoary$ grep ca live
<pitti>  * language-pack-ca [powerpc ia64] 
<pitti> oops
<seb128> lol
<pitti> jordi: not for live i386
<pitti> jordi: ENOSPACE
<jordi> 17:10 < jordi> http://cdimage.ubuntulinux.org/daily-live/current/ <--- ie, this
<jordi> pitti: oh
<seb128> buy a decent machine
<seb128> ie: PPC
<pitti> jordi: there is a huge bulk of WinFOSS crap which takes space :-/
<jordi> pitti: meh
<pitti> jordi: sorry :-(
<jordi> ok, he's going to love this :D
<pitti> jordi: however, -install has it
<jordi> pitti: I will suggest that ca replaces de at some point
<seb128> bah, nobody uses de, that's an ugly language
<seb128> just drop it
<pitti> jordi: squash bug #1, then we don't need WinFOSS any more :-)
<pitti> seb128: almost as ugly as fr :-)
<seb128> der/die/das, WTF is that :p
<seb128> you always pick the wrong one :)
<ogra> hehe
<jordi> pitti: oh, I remember. Firefox and stuff for windows
<jordi> pitti: hmm, #1 is pretty long term.
<jordi> I can't wait that much.
<seb128> :)
<jordi> :)
<pitti> jordi: not for hoary at least :-)
<smurfix> Umm, so can somebody please build a ppc netinst ISO for me (please add strace while you're at it)? I would like to avoid downloading the whole CD
<ogra> seb128, its to confuse the french, we especially invented it for that :-P
<seb128> ahah
<mdz> amd64-install good
<jordi> ok
<Kamion> mdz: back now
<fabbione> mdz: they are all good...
<fabbione> we rock!
<fabbione> :)
<jordi> so after he installs the package via apt-get, what's an intelligent way of restarting the session without rebooting?
<Kamion> was about to do amd64/powerpc live tests if we care
<mdz> Kamion: 4/5 successful, powerpc install in stage 2
<pitti> mdz: I now up, down, sidegraded langpacks in every possible order, works fine now
<Kamion> but I've tried everything else
<mdz> Kamion: (that's amd64-live, powerpc-live, amd64-install, i386-live and powerpc-install)
<pitti> new dpkg rocks
<pitti> Keybuk rocks :-)
<mdz> pitti: great, thank Keybuk
<Kamion> let me run upstairs and try amd64-live briefly, won't bother with powerpc-live
<jordi> pitti: so what did you actually add?
<jordi> the ca langpack to the base seed?
<pitti> jordi: no, to ship
<jordi> ie, everyone will get it installed, or how does that work?
<mdz> pitti: do we have space for it on the live CD?
<jordi> pitti: please elaborate :)
<mirak> jordi: salut
<jordi> hi mirak 
<pitti> jordi: the installer will try to install l-pack-$YOURLANG
<jordi> pitti: nod
<mirak> jordi: do you know jordi ?
<pitti> jordi: if it's on the CD, you have it and it will always be installed for ca users
<pitti> jordi: so not everybody gets every langpack :-)
<jordi>      1. To incline or bend, as the head or top; to make a motion
<jordi>         of assent, of salutation, or of drowsiness with; as, to
<jordi> oops
<mirak> jordi was a young singer child
<mirak> in france
<sivang> mirak: a baby!
<mirak> the songs were crap of course
<sivang> mirak: "_
<jordi> mirak: hmm. no.
<sivang> mirak: a baby doing pop music :)
<jordi> But I know a miriad of other jordis :)
<mirak> not pop music
<mirak> crap musi
<jordi> pitti: ok :)
<mirak> music
<mirak> crap with a crap techno beat
<sivang> mirak: yes.
<pitti> mdz: I filled them up pretty well, up to 630 MB
<pitti> mdz: I reserved some space for Xh, though
<mdz> pitti: but it would make jordi so happy :-)
<mirak> je m'appelle Jordi, j'ai 5 ans et je suis petit
<pitti> mdz: i386 is at 636 mb
<pitti> mdz: if you are fine with using the spare space, I'll add it immediately :-)
<mdz> pitti: how much space?
* pitti would love to make jordi happy
<jordi> mdz: yeah. :)
<pitti> mdz: 24 MB left
<mdz> 7M installed
<pitti> mdz: langpack will take about 4 MB deb
<pitti> (roughly)
<mdz> so ~2-3M clooped
<jordi> I mean, I'm trying to promote this live cd around here so people stop using the Catix crap, which is knoppix/kde based.
<mdz> plus the locales, so yeah, maybe 4
<mdz> pitti: let's do it
<jordi> but it's difficult with such crappy translations inclided :)
<mdz> jordi: we don't have enough space for mozilla/openoffice translations, though
<pitti> mdz: Installed-Size: 7272
<mdz> only the base language pack
<jordi> mdz: GNOME would be good
<jordi> for a live cd
<mdz> jordi: gnome is included
* pitti adds ca to all live CDs
* mvo -> dinner
<mdz> pitti: kubuntu too? ;-)
<pitti> hmm, shall I?
<Riddell> ca?
<jordi> mdz: is it?
* pitti never looked at Kubuntu CD sizes
<jordi> mdz: you mean now, or it was already?
<jordi> because the GNOME translations included seem to be very, very outdated.
<mdz> jordi: gnome is part of the base language pack, which pitti is adding now
<jordi> oh, so now.
<pitti> jordi: in fact they are not outdated, but not present
<jordi> that's great guys :)
<pitti> jordi: we strip translations from debs
<jordi> pitti: some of them are included
<mdz> pitti: I think the kubuntu team will need more supportability reviews for main
<pitti> jordi: yeah, the still unstripped pacakges
<jordi> don't tell me how. But you get bits and pieces in catalan.
<mdz> pitti: will you be available for some time tonight?
<pitti> mdz: I don't see kubuntu seeds
<pitti> mdz: I'm still at the Uni, they will throw me out in about an hour
<pitti> mdz: (still no network but modem at home)
<Kamion> amd64-live's good
<pitti> mdz: but I can work though ssh tonight
<seb128> thom: WTF
<Kamion> pitti: several binaries from kdepim in particular need reviews urgently in order to be able to build the live CD again
<Kamion> mdz: good to go?
<mdz> Kamion: my powerpc install is almost finished
<pitti> Kamion: okay, will do ASAP
<pitti> mdz: btw, we don't strip kde-i18n, and the KDE translatiosn are not in the langpacks
<seb128> thom: #7791 #7792 #7793 .. is that enough for you focus bug ? or do you want some extra dups ? :p
<pitti> mdz: so Kubuntu will get the translations for the non-kde/gnoome packages, but with much redundancy (all gnome translations, too)
<mdz> pitti: hmm, ok
<mdz> Kamion: we might as well wait the 3 minutes to be sure it succeeds
<Kamion> sure
<mdz> Kamion: unless you need to go
<Kamion> nope
<Kamion> I was away earlier at a meeting with our wedding caterers; nothing on now, until I go to the pub this evening :)
<pitti> jordi: committed, the next live CD will contain l-p-ca :-)
<jordi> mdz: just to clear the nano thing, it's a no-no, right? It appears to be stable as 1.2 here, but it's development.
<jordi> pitti: yay. :)
<mdz> mvo: can you check whether it is possible to disable the aptitude "RECOMMENDED BUT NOT INSTALLED" warning non-intrusively?
<Riddell> pitti: non encryption ones need to move into main https://www.ubuntulinux.org/wiki/KubuntuPackagesForMain
<mdz> mvo: it confuses many people
<mdz> jordi: if it doesn't affect nano-udeb, then it's a possibility
<pitti> Riddell: ugh, we need all these packages?
<jordi> mdz: that needs to be tested. The best way to test it is to test nano-tiny, which is exactly the same.
<Kamion> I can't see how it would not affect nano-udeb
<Riddell> pitti: all four of them
<Kamion> same source package and all that
<mdz> Kamion: but jordi told me so! :-(
<Riddell> pitti: and eventually probably the rest too but not for today
<Kamion> jordi: can you try building the debian-installer package with your nano-udeb in build/localudebs/?
<pitti> Riddell: what about the encryption ones?
<pitti> ah, ok
<Kamion> mdz: depends what you mean by "affect" :-)
<jordi> Kamion: I don't have a local setup here to build a d-i right now.
<Riddell> pitti: we're removing encryption from kdepim for today to try and get this preview release out
* fabbione -> dinner
<jordi> and tomorrow is vacation.
* jordi installs nano-tiny 1.3.5
<Kamion> jordi: ok, can you mail me details of where I can find a source package, so I can test that stuff still builds?
<pitti> Riddell: what about lipstik and gpgsm? is it also needed for the preview release?
<jordi> Kamion: yes.
<jordi> Kamion: build-depends changed, libncursesw5-dev added, but -tiny/-udeb still builds with slang
<Riddell> pitti: no to gpgsm, lipstik would be nice (so we can track down kubuntu screenshots)
<mdz> elmo: available for some seed syncage?
<pitti> Riddell: okay, I start with the non-encryption ones now
<jordi> Kamion: it doesn't affect nano udeb in the sense that it's going to suck for utf-8 still
<mvo> mdz: I'll have a look into aptitude, I'm pretty confident that it's not too hard
<Kamion> jordi: ok
<Kamion> jordi: fair enough
<thom> seb128: bleah, i dunno
<thom> seb128: i blame bugzilla
<jordi> Kamion: who knows if I could improve that too
<mdz> pitti: actually the kubuntu situation was much simpler than I thought; most of the new packages were simply new binaries of existing source that we had in main
<mdz> pitti: so we don't need any more review
<pitti> mdz: just finished OpenSLP security update, I will now look at the debs nevertheless :-)
<mdz> pitti: the only new source was a theme :-)
<pitti> ah, ok
<pitti> mdz: indeed; shouldn't that be handled through germinate automatically?
<Riddell> pitti: feel free to move onto the encryption packages in that case :)
<pitti> sure
<seb128> thom: you blame bugzilla, but "CD player viciously steals focus" for #7792 and "gnome-cd viciously steals focus." for #7793 :)
<seb128> thom: perhaps you should rather blame firefox :)
<mdz> ogra: shouldn't hwdb-client depend on hal?
<ogra> hmm, good idea...
<ogra> i'll add it 
<mdz> pitti: germinate only tells us which packages are in the list, not whether or not they are from new source
<pitti> Riddell, mdz: libktnef1 * libkcal2a * akregator * networkstatus debs are fine
<pitti> mdz: I meant, shouldn't the debs be automatically propagated to main?
<thom> seb128: naw, bugzilla didn't respond *at all* the first couple of times i submitted it
<seb128> bugzilla did apparently, firefox didn't :p
<Kamion> pitti: no
<Kamion> pitti: germinate says "please put this in main"; it doesn't automatically move the binaries into main
<pitti> ah, ok
<Kamion> pitti: hence mdz's periodic "seed syncage" conversations with elmo
<pitti> makes sense
<mdz> Kamion: STRUCTURE should be identical in ubuntu and kubuntu, right?
<Kamion> mdz: yes
<jordi> Kamion: people.debian.org/~jordi/nano has i386 binaries and source. If you find it's good enough, I can push David to release 1.3.6 or do a cleaned up version without a messy changelog.
<mdz> Kamion: it looks like they were added separately, so they have different file IDs and this creates a conflict
<mdz> Kamion: OK to remove the kubuntu one and merge the ubuntu one instead?
<Kamion> mdz: preliminary announcement text in http://riva.ucam.org/~cjwatson/tmp/array-cd-7
<Kamion> mdz: good point, yes
<Kamion> I just did 'baz add' everywhere and forgot about the peculiarities
<Kamion> mdz: have you finished your tests?
<mdz> Kamion: ah, yes, sorry.  powerpc-install is good
<mdz> 5x5
<Kamion> mdz: ok, will publish then if no objections
<mdz> none
<mdz> array 7 looks great
<mdz> thanks Kamion, fabbione, daniels
<Kamion> hooray
<ogra> yay
* ogra applauds
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals | Kubuntu on #kubuntu-devel | Hoary preview release: http://releases.ubuntu.com/hoary/ | Release Candidate: March 30th
<mdz> Kamion: I just merged ubuntu->kubuntu seeds again; since apparently I botched the installer stuff the last time, please take a look at it if you have a chance
<mdz> it looked entirely sane to me, though
<Kamion> mdz: I just checked with diff, as long as they're the same it should be fine
<Burgundavia> seb128: ping
<Kamion> mdz: looks fine
<lamont> mdz: thoughts on the other window when you have time
<lamont> robtaylor: any news on that bind patch and your issue?
<mdz> lamont: saw it, will get there.  lots of more pressing issues right now
<lamont> np.
<lamont> just wasn't sure if it was off the edge of the screen or something
<seb128> Burgundavia: pong ?
<Burgundavia> seb128: regarding bug7455, the xchat one
<lamont> Kamion: guess this means I can upload my e2fsprogs fix then?
<Burgundavia> seb128: I think we are not understanding each other
<Kamion> lamont: yep
<Kamion> back to normal feature freeze status now
<dholbach> re
<Kamion> thanks for people's patience while the CDs got done
<seb128> Burgundavia: why ?
<Treenaks> 3
<Treenaks> hm
<Burgundavia> seb128: I just reopened that bug, as it is one, IMHO
<seb128> grrrr
<kent> seb128, hello. Its me who reported the bug with gthumb. I can try with cvs version of it and see if it fixes my problem, but could you be so kind to tell me the line for cvs to download gthumb? I cant find any information on the sourceforge-page about how to get it via cvs. I have used cvs once or twise before, but I cant figure out how to fetch gthumb from cvs though. :(
<seb128> kent: I'll do a package and put it online if you want ... do you have a i386 ?
<seb128> Burgundavia: first the screen doesn't come every time, that's an option
<seb128> Burgundavia: second that's a property window (user, server, etc) so it follows the HIG
<kent> seb128, yes. i386.
<seb128> Burgundavia: and you don't provide any good argument out of the fact that you prefer it the other way, which doesn't make a bug
<seb128> Burgundavia: the argument of the same software is not good, open gedit's properties and look on the button
<seb128> or epiphany
<seb128> or whatever other GNOME app
<lamont> Pre-Depends: ${mount:Depends}
<lamont> that just says 'make mount pre-depend on everything that it should Depend: on'?
<Burgundavia> seb128: Common workflow is when the right most button is the one to make it go away. However, in this case we have 2 buttons to "make it go away". However, 95% of the time, the user wants to chat, and thus needs the connect button. The difference between this property windows and those others is that this is shown *before* the app is launched, and thus going away needs to make the app launch
<seb128> Burgundavia: that's your usecase
<Burgundavia> seb128: yes
<seb128> Burgundavia: I only open this dialog to make change and close it then
<Burgundavia> seb128: but the dialog comes up before launching the rest of xchat, no?
<seb128> opening it every time you run xchat is no sense
<seb128> usually people auto-login
<seb128> no
<seb128> that's a box to check
<Burgundavia> I see the box
<Kamion> lamont: only if you've a mount:Depends substvar
<Burgundavia> What I am saying is this is special properties windows, that usually appears before the app, and thus needs to be treated differently
<seb128> lamont: any idea of why gst-plugins0.8 doesn't promote the require Build-Depends to main to build ?
<Kamion> lamont: dpkg-dev doesn't create one by default, but your debian/rules might
<thom> seb128: is there a reliable way to check wheteher a user has a gnome deskopt running?
<lamont> Kamion: I didn't see it create one...
<seb128> thom: not afaik
<seb128> thom: ugly stuff like looking for gnome-panel running ? :p
<ogra> thom, ps ax|grep gnome-session ?
<seb128> Burgundavia: there is no "special properties windows"
<thom> ogra: no
<thom> ogra: it can be x-session-manager, too
<ogra> ah, just tried...
<thom> (my laptop is x-s-m and my desktop is g-s)
<seb128> thom: gnome-panel ?
<pitti> Riddell: the packaging of openct really has some bugs...
<thom> yeah, panel might be my best bet
<lamont> seb128: it's not automatic, you see...
<lamont> the correct process is: get approval, update the seeds, get elmo to promote it, then upload.
<lamont> or something like that.
<ogra> seb128, gnmoe-smproxy ?
<ogra> argh
<lamont> otherwise you get the looping-annoy-lamont byDate/today.html
<ogra> gnome-smproxy
<seb128> lamont: mdz said that the depends are automatically promoted IIRC
<lamont> seb128: in the report, that's true
<dholbach> thom: you get an indicator by using     ps ax | grep -E "(gnome-panel|gnome-sesion|..|..|..)" | wc -l       :-)
<seb128> ie: no need to update a seed
<lamont> and then the muppet does his magic behind the curtains, and it's there in the archive
<seb128> oh, k
<lamont> right - if it's only there because of build-deps, true
<seb128> I don't care of the "behind the curtains"
<seb128> as far as it work :)
<thom> dholbach: useful in a script :P ;-)
<Riddell> pitti: hmm, card terminal drivers, suspect we manage without that
<seb128> the current issue is gst-plugins0.8
<lamont> right.  the gst-plugins0.8 package needs a little muppet-love before it'll build
<lamont> and then it'll just happen
<ogra> thom, i would look for gnome-smproxy, it should get started by gnome-session
<Burgundavia> seb128: To me, the next logical thing should be the right most button. Most apps are laid out like that. Thus for most property windows, closing them is the next most logical thing to do. It is not for this case.
<lamont> Kamion: subst-vars has to be doing it - the only occurance of 'vars' in debian/rules is removing substvars...
<seb128> Burgundavia: for me I open xchat, it autologins and I open only this window to do some changes then close it 
<seb128> so the dialog is right
<Burgundavia> seb128: but the window opens by default and sits there until you do something
<seb128> not my problem
<seb128> argue with upstream, or jdub or whatever
<Burgundavia> seb128: ok
<Kamion> lamont: that's not conclusive :)
<Kamion> lamont: try grepping for mount:Depends
<Burgundavia> seb128: can we leave the bug open and I will open a bug upstream
<seb128> I close the bug, I've enough with 450 in my list without keeping bugs that I'm not going to close
<Burgundavia> seb128: ok
<seb128> no
<seb128> that's not a bug
<lamont> Kamion: only the debian/control line
<seb128> argue upstream but there is no interest to keep it open in bugzilla
<Kamion> lamont: is this in uploaded util-linux? I'll have a look
<lamont> yeah
<lamont> my specific quandry is that I'm trying to add a version to one of it's depends...
<Kamion> lamont: you're using dpkg-shlibdeps -pmount, etc.
<Kamion> lamont: that causes dpkg-shlibdeps to write out a mount:Depends substvar rather than the default shlibs:Depends
<lamont> yeah
<lamont> ah, way cool
<Kamion> lamont: debian/shlibs.local would be the traditional way to override that
<pitti> Riddell: opensc has several libraries in one deb, too
<lamont> you mean what it was doing, or what I want it to do?
<Kamion> if something's already mentioned in shlibdeps, but you want a newer version
<Kamion> what you want it to do
<lamont> and do I need shlibs.local, or mount.local (because of the -pmount)?
* lamont reads manpages
<Kamion> lamont: shlibs.local; if you want it somewhere else, use -L
<lamont> ok
<Kamion> frex if you wanted it in just one package, that would be a sensible thing to do
<Riddell> pitti: could you add these comments to that wiki page so we don't forget?
<pitti> mdz, Riddell: all packages from https://www.ubuntulinux.org/wiki/KubuntuPackagesForMain but openct and opensc are go
<pitti> mdz, Riddell: openct and opensc work security-wise, but they ship multiple libs in one deb, which is against our packaging standards
<pitti> mdz, Riddell: but if we need them, I accept them, too
<pitti> mdz, Riddell: I add a comment to the wiki page
<Riddell> pitti: thanks
<pitti> Riddell: lipstik is also ookay, I add it
<Riddell> amu, mdz: any thoughts?
<mdz> Riddell: specifically?
<Riddell> mdz: should we accept openct and opensc
<haggai> if we moved the libs to packages, would they get through NEW processing reasonably quickly?
* pitti added comments to https://www.ubuntulinux.org/wiki/KubuntuPackagesForMain
<mdz> haggai: assuming pitti approves, yes
<pitti> haggai: if these are split to separate debs, they have my blessing
<mdz> Riddell: what do we gain?
<pitti> mdz, Riddell: however, they deal with external hardware, thus if a bug destroys your smartcard, we will have a hard time 
<pitti> with debugging
<Riddell> mdz: gpg support in kmail again
<fabbione> haggai: http://people.ubuntu.com/~fabbione/openoffice.org2_1.9.76-0ubuntu4_20050315-0125.bz2  
<pitti> does gpg depend on smartcards?
<Riddell> I think leave them out today and we'll look at either removing the need of them from gpgsm or fixing them up
<fabbione> haggai: ^^^FTBFS on sparc
<mdz> fabbione: ->universe shortly
<fabbione> mdz: ok :-)
<pitti> Riddell: sounds good
<pitti> Riddell: if we can make it work without smartcards, that would rock
<pitti> Riddell: so the smartcard stuff can stay in universe
<mdz> pitti: what are your thoughts on supporting a gnupg CVS snapshot in addition to the current gnupg?
<Riddell> pitti: ok, will make a note to investigate that
<pitti> mdz: since it's not setuid any more, we only have algorithmical vulns
<pitti> mdz: as a coincidence, we just have a pending gnupg vulnerability
<mdz> pitti: yes, but likely not much sympathy from upstream
<pitti> mdz: isn't the cvs maintained properly?
<pitti> smurfix: what do you think about gnupg2 upstream support?
<pitti> mdz: we have the gnupg2 debian maintainer close to us :-)
<mdz> pitti: I mean that upstream may not accept responsibility for problems it in since it is unreleased
<pitti> oh, right
<sivang> pitti: is it you? :)
<pitti> sivang: smurfix
<sivang> pitti: ah , close enough 
<smurfix> sivang: ;-)
<mdz> Mithrandir: ping, re: utf8-migration-tool
<smurfix> It seems that lately (half year or so) upstream has mostly focused on gnupg1.4
<sivang> smurfix: :-)
<smurfix> I haven't done a review WRT 1.4 / 1.9 tagged / 1.9 CVS yet -- I should probably do that RSN
<pitti> smurfix: so gnupg2 is sort of dead upstream?
<jordi> pitti: shouldn't be
<pitti> Riddell: is it possible to use kmail with gnupg instead of -2?
<smurfix> At the moment, I recommend to stick with 1.4
<Riddell> pitti: not sure, amu's been looking after that package.  I would imageine so
<smurfix> pitti: yes
<smurfix> gnupg 1.4 works rather well with gpg-agent
<pitti> okay, then let's do that :-)
<smurfix> you just need a "use-agent" in its preferences
<smurfix> Caveat: I don't know whether that is true for smartcard support. I already pinged Upstream about that.
<pitti> smurfix: oh, we want to try to decouple it from smartcard support anyway
* smurfix doesn't have a gpg smartcard, USB sticks work well enough for me
<smurfix> pitti: Sure, but if you need to switch background support programs depending on whether the user has a smartcard or not, that'd be uncool
<pitti> hmm
* pitti does not like to support hardware-interaction programs
<pitti> smurfix: we kept out the Nokia communication stuff for the same reason
<smurfix> Anyway, I have to go and ubuntuize the neighbor's desktop box now, be back later
<mvo> array-7 is out? we can upload again :) ?
<Kamion> yep
<Mithrandir> mdz: pong?
<Mithrandir> mdz: it's still missing the C handling, I can upload with that disabled if you want that.  Then it should upgrade cleanly from all locales but C (and give a message saying "sorry, nocando" for C)
<mdz> Mithrandir: release candidate is in 13 days and we haven't really tested this at all :-/
<fabbione> jdub: ping?
<Mithrandir> mdz: I know and it's my fault. :(
<mdz> Mithrandir: I'm not entirely confident about making it a part of the default hoary upgrade path
<mdz> the current version in Hoary doesn't seem to run for me
<mdz> mizar:[~]  utf8migrationtool
<mdz> [...] TypeError: category LC_ALL is not supported
<Kamion> Mithrandir: release early, release often :)
<Mithrandir> Kamion: I hate to release stuff I know is partially broken
<Kamion> if it's an incremental improvement ...
<Mithrandir> ok, I'll upload what I have now and hack on the rest on the train tonight
<Mithrandir> mdz: does that sound ok?  It's not as good as I hoped to, but it will at least allow some testing
<mdz> mvo: still here?
<mvo> mdz: yes
<mdz> mvo: both workarounds in #7419 sound fine to me; please go ahead
<mdz> Mithrandir: ok.  we need to make a decision in the next few days whether we will use it for Hoary
<mvo> mdz: thanks a lot!
<mdz> mvo: maybe we should do both :-)
<mvo> mdz: hehe :) yeah!
<mdz> mvo: we should talk in Mataro about how to handle these issues in the future
<mdz> we should make some effort to make the metapackages a better upgrade mechanism (or use something different)
<mdz> perhaps for hoary+1 we can have a special upgrade tool which knows about the metapackages
<mdz> or do this as part of enhancing update-manager for inter-release upgrades
<dholbach> mvo: you were going to Mataro? :-)
<mdz> er
<mdz> s/mataro/sydney/ of course
<dholbach> hihi, nevermind :-)
<mvo> mdz: sounds good. update-manager is about to be ready for dist-upgrade, I just don't dare to enable it for hoary
<dholbach> mvo: you could add a note: "some packages are about to be removed; to adjust your needs, please run the package manager."
<mvo> mdz: this particular problem (gnomemeeting) was caused by libpt-plugins-v4l removed from the main component. if I enable universe the dist-upgrade works smooth
<mdz> mvo: interesting
<mdz> mvo: so if we put it back in main, that should work too?
<mvo> dholbach: I would rather avoid removing packages with the current update-managers UI. it's not really suited for that task 
<mvo> mdz: yes, I added a fake entry to the packages file and that was good too
<Mithrandir> mdz: 0.2 uploaded
<dholbach> mvo: i understood, that's why i pointed out you could have a message telling the user, update-manager was about to remove packages
<Mithrandir> now I need to pack
<mvo> Mithrandir: you travel? 
<Mithrandir> mvo: going to dk to visit little sister and Fabio
<mvo> mvo: I guess  we need to be extra carefull when moving packages between components
<mvo> Mithrandir: oh, sounds like fun! 
<Mithrandir> mvo: if you can test the 0.2 which hits the archive RSN for your rename troubles, I'd appreciate.
<mvo> Mithrandir: yes, sure. will do!
<Mithrandir> mvo: I'm going to be around on irc and read mail, so just privmsg me or drop me a mail
<mvo> Mithrandir: thanks! I look forward for a utf-8 clean system :) 
<Mithrandir> yay
<Mithrandir> :)
* mvo -> doing some laundry, brb
<pitti> mdz: I can't stay much longer here in the uni, and my stomach cries for some food, so I'd like to go home soon; is there anything urgent for me?
<mdz> pitti: no, thanks for staying
<mjg59> Kamion: Ok, that's a fairly common failure mode with some hardware. It's not clear what's going on.
<mjg59> thom: Urgh. Why?
<Kamion> mjg59: which?
<mjg59> Kamion: The Avaratec s-t-r thing
<mjg59> thom: Can you add a guard to /etc/acpi/resume.sh that only runs vbetool vbestate if the state file exists?
<Kamion> mjg59: right; I don't really understand how resume from s-t-r works, hardware-wise
<mjg59> Kamion: In theory, the chipset is woken up, reads a memory address from a register, passes that to the CPU and execution continues from there
<mjg59> Then the wakeup code does the job of restoring the registers and putting the CPU in protected mode
<medwards_> The wiki entry for LiveCD remastering resembles the "Knoppix way" of starting from a CD image and hacking it.  I was kind of hoping for a reproducible LiveCD build system.
<Kamion> lamont: is the live cloop build script you use public anywhere?
<medwards_> Is that something I can do from the outside, or is everyone skilled in the art too busy with the Hoary release to coach?  (I would understand.)
<medwards_> FWIW, I have built a customized installer around debootstrap previously, so I wouldn't need too much coaching.  :)
<Kamion> medwards_: it's basically debootstrap/ubuntu-base, install ubuntu-desktop, install ubuntu-live, build cloop from the result; I think there are a fair few fiddly details in there, though
<Kamion> which is why I was wondering if lamont had put his script anywhere, since that's the piece that builds our official live cloops
<medwards_> Kamion: how dependent is ubuntu-live on ubuntu-desktop?  I'm hoping to switch from HD-installed autobuilders to LiveCD, and would want to take out a lot of the desktop stuff and put in ecj, etc.
<mvo> mdz: I send you a patch for queueing in synaptic a while ago for review. do you want to go with that approach? then I'll upload a new synaptic tomorrow with it
<mdz> I haven't had time to review it
<mvo> mdz: no problem, I just wanted to ask :)
<mdz> it seems risky to change the language-support installation at this late stage
<mdz> the current behaviour is at least simple and predictable, and we can document its limitations
<mdz> and perhaps tackle it properly for Breezy
<Kamion> medwards_: you probably wouldn't want to use ubuntu-live as is any more than you'd want to use ubuntu-desktop as is, then
<Kamion> mdz: the current behaviour is a real problem when doing lots of installations at once; two parallel installations made my network unusable here
<Kamion> (which is a problem with my CBQ rules, but still)
<Kamion> I think we should fix it if at all possible
<mdz> Kamion: I'm not convinced it's worth the risk of last-minute feature creep
<lamont> Kamion: it's not released
<lamont> but I think it's on chinstrap
<zul> fyi there is a pretty good chance i wont be online tonight much
<medwards_> Kamion: I'm happy to hack on ubuntu-live (it can't possibly be worse than starting from Knoppix); I'm really just wondering if there's a strategy for enabling server-oriented derivative LiveCDs.
<mdz> zul: enjoy your evening
<Kamion> if lamont is happy to release his script, I think that would be valuable
<zul> mdz: thanks...must spend time with the wife ;)
<mdz> medwards_: for a server-oriented live CD, you probably want to build it yourself
<mdz> medwards_: for variations on ubuntu-live, the instructions in the wiki are quite reasonable
<medwards_> Kamion: I've been tracking sid for my base system for over a year, so it's been a lifesaver for me to have a fully baked auto-install CD that I can regenerate with "make clean && make".
<medwards_> Kamion: but since various bits of /etc are baked in, it's tied to certain things about the hardware (partition layout, SCSI vs. IDE, etc.)
<medwards_> Rebasing it on a LiveCD of some kind would be a win.
<mdz> I wonder how our TRLS compares to Linspire
<medwards_> mdz: the instructions on the wiki are exactly what they should be; most people are remastering for appearance, maybe to add a few pet packages (Marillat's mplayer?)
<Kamion> TRLS?
* lamont is reminded that he has an appointment in town from 2-3 (-0700), will be heading off in about 25 minutes or so
<Kamion> oh, totally rad
<mdz> medwards_: right, but it sounds like you want more than that
<lamont> TRLS?
<mdz> the process to build the CDs from scratch is fairly complex at the moment
<ogra> wb dholbach 
<ogra> *g*
<mdz> wow
<mdz> mjg59: my Satellite 2545XCDT comes back from STR
<mdz> pcmcia ethernet and all
<medwards_> mdz: if I can help simplify it (maybe merging in some code I have for following dependency chains associated with goal packages), it might be useful for you.
<mdz> medwards_: we have a pretty sophisticated system for that, called "germinate"
<mdz> there's some information in the wiki
<Kamion> damn, I meant to upload germinate to Hoary
<Kamion> might still be able to squeeze that in
<medwards_> mdz: yes, I'm impressed; mine's a little different, since it aims at build-depends and tries to do it in overlay stages.
<Kamion> medwards_: colin.watson@canonical.com--2004/germinate--mainline--0 in arch
<Kamion> does build-deps too :)
<Kamion> but I'd certainly be interested to look at other strategies for doing the same thing
<medwards_> Kamion: excellent.  Stacking translucent overlays to make a buildd chroot could really help with the whole buildd-corruption thing.
<medwards_> How does mini-fo compare with unionfs in that respect?
<mjg59> mdz: Excellent
<mdz> mjg59: we'll have some pretty rich data coming in from hwdb-client in Hoary, should be a good starting point for a STR whitelist for hoary+1 to enable it out of the box where it works
<ogra> mjg59, yeah, we should talk about it once, to make sure i collect the right data for you ;)
<lamont> mdz: it's called breezy :-)(
<Kamion> medwards_: we don't use mini-fo any more, we use device-mapper snapshotting
<lamont> mini-fo bad.  very evil.
<Kamion> medwards_: the code's in the casper source package
<ogra> mjg59, currently the dmi data is already collected...but i imagine you might like other stuff too
<mjg59> lspci would also be good
<medwards_> The thing I like about unionfs in principle is that, since it operates above the filesystem level, one can stack, say, jffs2 on a USB stick on top of a squashfs.
<mjg59> Kamion: Does d-i have any support for adding different boot options based on DMI data?
<ogra> mjg59, install hwdb-client and run hwdb-xml -d or hwdb-xml -a (all hal data)
<seb128> kent: http://pkg-gnome.alioth.debian.org/gthumb_2.6.3cvs20050317-0ubuntu1_i386.deb if you want to try with this package
<medwards_> Is there any way to get flash-friendly write balancing with device-mapper?
<medwards_> oh, by the way ... torrent for array-7?
<ogra> mjg59, should be the same as lspci....needs probably a filter since its everything
<mjg59> ogra: Ok, cool
<Kamion> mjg59: not that I know of right now, guess it wouldn't be hard
<Kamion> medwards_: damn, forgot
<mjg59> Kamion: I've got a couple of machines here that it would be insanely useful for
<mdz> mjg59: machines which will boot d-i with no options, but require options to work properly thereafter?
<mjg59> mdz: Yeah
<mdz> the toshiba craptop took quite a long time to swsusp, but it got there
<mdz> will know shortly whether it wakes up
<Kamion> mjg59: we have a dmidecode-udeb, could easily do shell scripting around that in the bootloader installers or something
<medwards_> Should I expect array-7 to support ipw2100 properly?  The only LiveCD I've ever seen work on this Centrino was Kanotix, and I couldn't get my remaster to work.
<mjg59> medwards_: Should work fine
<mjg59> Kamion: Any chance for Hoary?
<Kamion> mjg59: maybe, send me a spec :)
<medwards_> Same "couldn't find ipw2100-fw-1.3" error I got with Warty.
<mdz> flawless!
<ogra> wow
<mdz> both STR and swsusp, very impressive
* ogra applauds mjg59 
<Kamion> thom: could you do torrents for array-7 once they arrive on torrent.u.c? should be a few minutes from now
<medwards_> (and with Knoppix 3.8)
<medwards_> mjg59: thanks.
<mdz> thom: we really do need to automate the remainder of that; we ought to be torrenting the dailies at this point
<Kamion> mdz: I think a prereq for that is on my list, will look tomorrow
<Kamion> anyway I really have to run now, massively late
<pitti> yay, my home network is back *happy happy joy joy*
<mjg59> Kamion: Based on a regexp that matches either the manufacturer or model, we need to be able to add a command line option
<mjg59> I'll flesh it out and mail you
<Kamion> thanks
<mdz> thom: we'll need torrents for the kubuntu preview as well
<medwards_> Kamion: thanks much.
<mdz> lamont: terranova finished early building kubuntu livefs; please check
<mjg59> fabbione: Ok, looks like we really could do with that patch that keybuk tried
<mjg59> I've just nearly cooked a machine here
<zul> heh
<medwards_> mdz: swsusp with array-7?
<robtaylor> lamont: no news on my issue, apart from that patch not fixing it.. guess i'm gonna have to go get my hands really dirty ;)
<mdz> medwards_: an installed system upgraded from woody to the equivalent of array-7, yes
<thom> mdz: as kamion says, we need to have the smaller pool
<thom> mjg59: #7480
* mdz wonders idly about supporting hibernate on the live CD
<thom> mdz: when is kubuntu preview?
<mdz> as real functionality it'd be purely academic, but it could be useful for testing whether it works
<mdz> thom: today or tomorrow
<thom> ah, k
<mdz> depending on how these CDs turn out
<mdz> elmo: around?
<mdz> anyone else have an account on terranova besides lamont and elmo?
<lamont> mdz: you managed to collide with an archive update
<lamont> re-launched
<mdz> ah, ok
<mjg59> thom: Interesting. I honestly don't see how that can happen.
<medwards_> lamont: if you were thinking of releasing the live cloop build script, I'd like to play with it.  Maybe even try unionfs if I can get the module to build against the Ubuntu kernel (the miniroot changes from Knoppix 3.8 are pretty straightforward).
<mdz> lamont: are the royal and king ones screwed, then?
<mdz> lamont: if they are, please kill them and I'll restart
<lamont> mdz: the Release and Packages files, as fetched, were not from the same archive run.
<mjg59> thom: As far as I can tell, network modules really should be loaded and unloaded in the same order
<mdz> lamont: we need kdepim 4:3.4.0-0ubuntu3
<mjg59> I guess that it's reasonable to record the mac/name mapping beforehand and set it up again afterwards, though
<lamont> mdz: checking
<mjg59> thom: Did you check gdm-signal?
<mdz> thom: can you stick around tonight until we know whether kubuntu preview is happening?
<pitti> mdz: but where is the sense of putting hibernate on the live CDs and not on the install ones?
<lamont> mdz: 0ubuntu3 is being used in all 3 builds now
<pitti> mdz: at least, I only ever saw "hibernate computer" on live CDs
<mdz> pitti: we need the root filesystem in order to resume
<thom> mjg59: this is what i thought, but I don't see the harm in doing an ifrename just to make sure, since we have iftab anyway...
<doko> ok to uploade OOo1 now, or should I wait until after the Kubuntu preview?
<mjg59> thom: Oh, we have iftab? If so, then yeah
<mdz> mjg59: we write an iftab from d-i
<lamont> medwards_: gotta dot an i or two before I can release it.
<mjg59> Sure. Just ifrename it on resume, then.
<thom> mdz: i need to go out but it'll be local (friends over from the states until monday, prolly won't see em otherwise); sms me if you need me?
<thom> mjg59: yeah
<kent> seb128, installing that package right now. I will let you know soon if it works or not.
<thom> mjg59: not yet (gdm-signal)
<lamont> but as for what it does, it literally just does a debootstrap and a couple of apt-get's, then rsync's the result into an fsimage (rather than using loopfs for the install...), then compresses it.
<lamont> and a couple other housekeeping things
<mdz> thom: it's more likely than not that we'll need you; can someone else fill in?
<mjg59> thom: Ok. It's kind of important for machines without acpi sleep keys
<mdz> elmo isn't around
<mdz> lamont: thanks
<lamont> mdz: 2 minutes until I must run for ~2 hours.
<mdz> lamont: if builds are in progress with kdepim -0ubuntu3 I am happy
<lamont> yep.
<thom> mjg59: nod
<lamont> mdz: and not 100% trivial, but <machine>/~buildd/livecd/kubuntu/latest/*.out is the log file of the latest run
<medwards_> lamont: OK.  Is the package selection in the apt-gets, or are there virtual packages containing the important dependencies?
<thom> mdz: unsure, but local means 5 minutes walk from my pc
<lamont> s/latest/current/ for the last successful run
<medwards_> lamont: and thanks very much!
<mdz> thom: ok
<mdz> thom: "out" :-)
<lamont>         ubuntu)
<lamont>             LIST="$LIST ubuntu-base ubuntu-desktop ubuntu-live"
<lamont>     LIST="$LIST xresprobe laptop-detect"
<lamont>     case $(dpkg --print-architecture) in
<lamont>         amd64)          LIST="$LIST linux-amd64-generic";;
<lamont>         i386)           LIST="$LIST linux-386";;
<lamont> ...
<thom> mdz: very close pub :-)
<medwards_> (I presume ubuntu's debootstrap has the hoary base script.)
<thom> very close _irish_ pub, more importantly
<lamont> and some diversions to get things in the way out of the wya
<lamont> medwards_: certainly
<medwards_> lamont: excellent.  Thanks again.
<lamont> it's basically ubuntu-meta*, xresprobe, laptop-detect, and kernel
* lamont back in about 2 hours.
<lamont> mdz: can be online in about 1:40 or so, if you sms me...
<lamont> but hopefully no need.
<mdz> lamont-away: how can I check when the builds are done?
<lamont-away> wget machine/~buildd/livecd/kubuntu/latest and there should be more than one file in the list?
<lamont-away> if too long, and still just one file, wget that (.out), and see what went wrong.
<mdz> ok, thanks
* lamont-away checks on times
<lamont-away> ubuntu is about 35 minutes
<Seveas> hi
<Seveas> is anybody going to change the ubuntu website, so that it mentions 'breezy badger' as being the next release?
<lamont-away> mdz: and the last (good) kubuntu build to 27 min
* lamont-away flees, late
<medwards_> OK, time to dissect array-7 and see what lives outside the cloop.  Is there a sources.list entry that will give me an archive snapshot as of array-7?
<elmo> mdz: I am around btw
<mdz> elmo: ok
<mdz> lamont reappeared
<medwards_> elmo: Is there a sources.list entry that will give me an archive snapshot as of array-7?  Or is there another way to see a frozen archive when experimenting with the LiveCD mastering process?
<thom> mdz: array 7 checking, should be on torrent in a few minutes
<tseng> medwards_: the freeze isnt enforced by software afaik
<tseng> medwards_: its a understanding followed by the developers to just not add things to main while the cds are in progress
<elmo> medwards_: no, sorry
<mdz> medwards_: not apart from setting up a local mirror
<mdz> medwards_: (which is how we do the CD builds)
<mdz> the current archive is quite sane, though, and should remain so for the remainder of the release cycle
<medwards_> tseng, elmo, mdz: thanks.  I'll go with the moving target, and if I have trouble, I'll mirror locally.
<mdz> medwards_: if you're doing more than one build, you definitely want at least a cache, and probably a local mirror, anyway
<mdz> main for 1 architecture isn't all that large
<medwards_> mdz: of course I'll cache; save us both bandwidth.  :)
<medwards_> I'm getting about 8KB/s on the array-7 download; maybe I should just wait for the torrent?
<Mithrandir> elmo: could you please sync root-portal?
<dholbach> Mithrandir: yes!!! :-)
<elmo> [NOT Updating - Modified]  root-portal_0.5.0-3ubuntu1 (vs 0.5.2-1)
<elmo> ok to override?
<zul> later 
<dholbach> bye zul
<Mithrandir> elmo: yes, ok to override
<dholbach> Mithrandir: http://wiki.ubuntu.com/UniverseHowlRebuildTODO nearly sorted out :-)
<thom> elmo: did you see my sync request for lsof?
<Mithrandir> elmo: thanks.
<elmo> thom: yes, but the version you requested's now in limbo - I'll sync it when it hits a mirror
<thom> okey
<thom> thanks mate
<ogra> yeah, already 20 hwdb submissions :)
<dholbach> ogra: hang on... you'll have mine too in just a sec ;-)
<ogra> heh
<kent> jdub, it seems to not crash with that version from CVS. I started gthumb a while ago and it has had the slideshow on for some time now and it has not crashed. Though i have it on random, but it has always crashed rather quickly, so i think its ok now.
<seb128> kent: speaking about the new package ?
<seb128> kent: or that's a different issue you are fixing with jdub ?
* Mithrandir wishes he could download bugs from bugzilla to work offline
<ogra> Mithrandir, dont you get mails from buzilla ?
<kent> seb128, i meen the issue with gthumb and watchin slideshows. You posted a link to a debian package from CVS. I installed it and it seems to work now.
<ogra> +g
<dholbach> Mithrandir: RSS-ification!
<seb128> kent: ok, because you spoke to jdub, so I prefer to ask :)
<Mithrandir> ogra: stuff which I haven't gotten originally.
<ogra> ah, k
<Mithrandir> ogra: (I'm going to sit on a train and then a bus for a bunch of hours.  Would be nice if I could do useful stuff while doing that.)
<kent> seb128, oh.. sorry, i wrote to the wrong person then. haha, i forgot it was you i should have spoken to. haha :) sorry
<seb128> np
<seb128> now I need to find the fix in the diff :/
<HiddenWolf> Does anyone know what can possibly cause that ever ...ok notice during startup/shutdon is on a newline?
<ogra> Mithrandir, so pull down some bugs in advance
<HiddenWolf> every, even
<ogra> Mithrandir (i.e. save th BZ page or wget it)
<Mithrandir> yeah, that kinda works
<thom> mdz: bt torrenting away
<mdz> thom: thanks
<medwards_> thom: bt link?
<medwards_> (will seed in US)
<mdz> medwards_: http://cdimage.ubuntu.com/releases/hoary/array-7/
<doko> mdz: ok to uploade OOo1 now, or should I wait until after the Kubuntu preview?
<Mithrandir> doko: the 2.6 avm stuff freezes a lot.
<mdz> doko: if you can wait one hour, that would be good
<Mithrandir> doko: like, twice a day.
<doko> Mithrandir: does the card has it's own interrupt?
<Mithrandir>  12:      64399          XT-PIC  fcdslsl
<Mithrandir> looks like it
<doko> mdz: not sure, if I'm awake then. the packages are at chinstrap:~doko/uploads . would you mind uploading them?
<mdz> doko: ok
<mdz> doko: signed?
<Mithrandir> doko: it _might_ be something else; kinda hard to check when I don't have a console connected to the system.
<doko> Mithrandir: strange, I didn't havve these problems, after the card had it's own interupt.
<doko> mdz: yes, signed. thanks
<Mithrandir> doko: but since I've had that kill the system with 2.4 as well, I'm suspecting the fcdslsl card
<Mithrandir> doko: hmm.
<doko> mvo has another card (dsl2), maybe he can send it to you
<Mithrandir> I could possibly try with a better mobo with a real APIC instead of the XT-PIC shit.
<Mithrandir> it's just annoying, it's not a problem per se, I just wondered if I was the only one seeing this.
<Mithrandir> I can spend a bit more time trying to see if I can reproduce it or get a backtrace.
<seb128> kent: I'm uploading -0ubuntu2 with some fixes from the CVS version. Can you close the bugzilla bug if it fixes the crasher ?
<kent> seb128, I have never closed a bug, but ok.. If it works, I will look on bugzilla about how to close the bug.
<thom> woah, code.google.com
<Mithrandir> thom: shiny
<ogra> thom, oh they grabbed that one too ? there is a free site offering code snippet search since two years...
<thom> ogra: no, go look
<ogra> ah
<thom> right, i'm -> pub; sms if/when you need me
<kent> On bugzille it is written that bugreports against universe should be posted to ubuntu-users, is that correct? should not ubuntu-devel be the right place?
<jdub> uuuggghhh
<thom> kent: the message is correct
<kent> seb128, btw, I forgot,  did you say you will make a new package for me to try? I was in the middle of doing some things and I accidently shut down xchat :(
<seb128> kent: I've uploaded a new one for hoary, just let me know if this one work
<seb128> you will need to downgrade from the current cvs one
<kent> seb128, ok. Will do. 
<seb128> thanks
<kent> seb128, gthumb 2.6.3-1ubuntu1  ?
<seb128> no, ubuntu2
<seb128> it's probably building atm
<kent> seb128, ok. I should be going to bed soon. How long does it take for it to compile?
<seb128> kent: there is no hurry you can try tomorrow
<seb128> not long, should be in the archive in 20min
<kent> seb128, I'l rather wait for it then. Becaus im going home to my parents tomorrow after school so I wont have the time then.
<seb128> k
<smurfix> Grumble -- pitti's netboot image for powerpc didn't.
<ogra> oh,  1111111111 is near !
<ogra> (date +%s)
<dholbach> ogra: do we need a  wiki/UniverseDate1111111111CleanupTODO  or something?
<jdub> the status is: 1111096906
* jdub is abusing an old script ;)
<ogra> in case you got gtk-perl installed:
<ogra> !/usr/bin/perl
<ogra> use strict;
<ogra> use Gtk2 -init;
<ogra> use Glib qw(TRUE FALSE);
<ogra> my $window = Gtk2::Window->new;
<ogra> $window->signal_connect(delete_event => sub { Gtk2->main_quit; });
<ogra> my $label = Gtk2::Label->new('' . time());
<ogra> my $font = Gtk2::Pango::FontDescription->from_string("Sans Bold 48");
<ogra> $label->modify_font($font);
<ogra> Glib::Timeout->add(250, sub { $label->set_text('' . time()); TRUE; });
<ogra> $window->add($label);
<ogra> $window->show_all;
<ogra> Gtk2->main;
<seb128> urg
* mvo runs
<seb128> beeeurg
<smurfix> dholbach: Count me out, 111* is in the middle of the night here
* mvo kicks ogra 
<ogra> heh
* ogra hides
<seb128> WTF is that
* dholbach backs ogra up :-)
<smurfix> ogra: This is Ubuntu. Use Python.  ;-)
* jdub is happy, gets to do distro stuff today
<ogra> smurfix, :) i will for 2222222222 
<seb128> jdub: desktop files for g-a-i ?
<dholbach> ogra: have it running :-)
<jdub> seb128: aye!
<seb128> rock
<dholbach> smurfix: should be middle of the night here too :-)
<mvo> seb128: can I upload gnomemeeting without the libpt-plugins-v4l dependency? it breaks updates from warty (#7419)
<seb128> mvo: sure
<ogra> smurfix, btw, who should convert all the p*rl stuff if everybody only wants to touch py ?
<ogra> :)
<seb128> ogra: no need to read perl code to write py one :)
<ogra> hmm
<maswan> mmmm.. perl. :)
<medwards_> maswan: crunchy perl goodness.
<maswan> medwards_: exactly. :)
<smurfix> ogra: 2222222222 is >2^31. We'll have to do quite a bit of work if we don't want anything to break with *that*.
<ogra> *g*
<kent> seb128, this is the moment of truth..  im trying the slideshow now with the new version. Hopefully it will work.. 
<seb128> k
<kent> seb128, it seems to work for me with that version from the archive. Should I set it to fixed in bugzilla? There is no "closed" option, just the "reslove bug, changing resolution to [fixed] "
<kent> seb128, I wrote in the wrong channel first, haha :)
<seb128> fixed is fine, thanks
<seb128> I've replied in the other one :p
<medwards_> lamont: just posted an (untested) fix for 4504 (cupsys upgrade failures).  Does anyone know how to reproduce it?
<medwards_> (fix should probably be applied in debian package also; haven't picked a bug to attach it to)
<mdz> jdub: cursor theme fix?
<jdub> mdz: i've got the ubuntu-artwork end; you reassigned the previous package repair side to seb, didn't you?
<mdz> jdub: uploaded?
<jdub> no
<mdz> I didn't see it go up
<mdz> is seb128 going to have time to do that tonight?
<jdub> i have an icon drop to go up with it;
<mdz> I asked him to help you with it
<jdub> however, despite my earlier elation, i have to prepare for a meeting this afternoon
<jdub> if seb can't do the other end tonight his time, i'll do it tonight my time
<seb128> mdz: when you say tonight, that's now (it's midnight here) or tomorrow ?
<mdz> seb128: now
<seb128> k, I'll have a look and will get back to the other stuff after
<jdub> seb128: gtk2-engines-industrial just needs to kill off the alternative that wasn't killed off properly during upgrade
<mdz> and some testing
<seb128> ok
<jdub> i'll upload u-a this afternoon, post-meeting
<seb128> you fix this one ?
<seb128> I just need to remove the broken alternative in gtk2-engines-industrial ?
<jdub> yeha
<jdub> u-a is ok, just needs some updates and an upload
<mdke> hi guys. I just got an email from a guy who says this "I'm preparing an article for Newsforge about OpenOffice.org version 2.0's increased use of Java and how third-party redistributors are approaching the change." He wants a statement from ubuntu. Who can I forward this misdirected mail to?
<medwards_>  Does Java on Ubuntu get much testing?  It looks like java-package is from multiverse and kaffe and ecj are from universe.
<mdke> i just wanna know who has authority to answer this email
<mdke> the answer is pretty obviously not me
<ogra> medwards_, which shouldnt make it less tested then main apps ;)
<mdke> hi ogra
<ogra> hi mdke 
<mdke> :)
<medwards_> ogra: actually, I was writing that question before mdke came in.
<mdke> heh coincidence
<ogra> there is a JavaIntegration wiki page, jabiley leads the java team afaik
<ogra> oops, jbailey indeed
<medwards_> I'm really excited about java-in-main, especially since my day job is java-intensive and it's going to be up to me to convert them to free JDK.
<mdke> ogra, you have any recommendations? shall i just forward it to ubuntu-devel?
<jbailey> ogra: Heya!
<medwards_> The pretext is support for ARM and MIPS(el) embedded targets.
<ogra> mdke, jep, that would be the right place i guess
<mdke> ogra, ok
<mdke> hi jbailey perhaps you could advise me too
<jbailey> medwards_: It's getting better.  ecj and gij are going to go into main for Breesy.  We're trying to get a bunch of the packages in shape in prep for that.
<jbailey> JerryHaltom has been doing amazing work on that front.
<jbailey> medwards_: Have you looked much at free java stuff yet?
<jbailey> mdke: Oy, a statement from Ubuntu?
<mdke> apparently
<mdke> must be a journalist
<jbailey> mdke: Probably the best bet for that would be Chris Halls.  He knows OOo the best.
<mdke> true
<mdke> he'll follow the dev list i guess?
<jbailey> haggai: *poke* =)
<mdke> actually i'll ccopy him in
<jbailey> Let's see if he's around. =)
<ogra> mdke, yep, and he is very busy currently,, thats why i didnt point you dirctly towards him
<mdke> np
<mdke> i bet you're all pretty busy :)
<ogra> three weeks to go :)
<mdke> yep
<mvo> less than two for the preview ...
<ogra> yep
<mdke> you'll get there
<medwards_> jbailey: yes, I've been tracking java-in-main with much interest.
<jbailey> medwards_: Cool.  If you're interested in helping out, many of us (for both Debian and Ubuntu) are in #ubuntu-java
<medwards_> jbailey: OK, I'll show up there as soon as my immediate crisis (building a LiveCD with working JDK/ANT) is over.
<medwards_> jbailey: I'm trying to reduce my autobuilders to a LiveCD so that I can do scorched-earth rebuilds of the Apache suite with alternate JDKs.
<lamont> mdz: 4504 - still trying to actually reproduce it here..
<jbailey> medwards_: autobuilders?
<jbailey> medwards_: Do you run the gump tests?
<mdz> lamont: it's not going to be easy to reproduce; we just need to cripple that broken code
<haggai> jbailey: hey leave me to idle on this channel in peace :)
<jbailey> haggai: Yes, dear.
<medwards_> lamont: candidate fix in bugzilla.
<mdz> lamont: it should never abort the postinst
* haggai reads scrollback
<lamont> medwards_: yeah, reading it now
<lamont> mdz: right... I'll get something uploaded today.  gonna try to reproduce it again though, too...
<medwards_> jbailey: actually, autobuilders for day job (steaming-pile-of-java network management app)
#ubuntu-devel 2005-03-29
<medwards_> A subset is going to go on a small box (probably ARM or MIPSel) and I'm prodding them along towards free Java.
<mdke> ok sent to the list
<mdke> someone check it ot
<lamont> mdz: you want the bitchy message gone, or just the exit? :-)
<medwards_> lamont: any reason not to use killall -clean?
<mdz> lamont: both
<mdz> medwards_: it really just needs to write a @#$@ pid file
<pitti> night everybody
<lamont> medwards_: I don't see a -clean...
<mdz> but failing that, it shouldn't break
<ogra> night pitti 
<medwards_> lamont: the killall would probably do a better job of avoiding race conditions when it's spawning rapidly.
<medwards_> -clean is -TERM, 5 seconds, -KILL iirc
<lamont> make them smaller anyway
* lamont switches the ps aux| grep into pidof, removes the post-kill-9 check
<medwards_> I think killall contains logic to kill parents before children
<medwards_> (in the -KILL scenario)
<medwards_> if it doesn't, it probably should.
<medwards_> when one is resorting to -9, there's not much point in letting parents wait for children.
<medwards_> lamont: pidfile and decent handling of children on -TERM would be a good thing, all right.
<medwards_> lamont: but see http://bugs.debian.org/298040 for handling of chroot installs
<lamont> well, upgrade to the new version didn't die...
<lamont> mdz: thoughts? do we mind waiting until breezy to fix 298040?
<medwards_> The postinst kill code should probably also be made conditional on /etc/default/cupsys.
* lamont struggles to find it RC, fails
<medwards_> lamont: 298040 is closed upstream
<lamont> it should really just use a *&))^_& pidfile
<lamont> medwards_: in -7, hoary is derrived from -1
<medwards_> lamont: but the code in the postinst probably reintroduces it if it isn't conditional on FORCE_RESTART.
<medwards_> lamont: oh.  I see.
<lamont> start-stop-daemon is your friend. :-)
<mdz> lamont: is it too much to ask for proper preinst/postinst handling of the daemon, like every other package?
<mdz> at the very least it can kill reliably based on the inode
<lamont> inode?
<medwards_> yeah, I use start-stop-daemon in postrm and if I really need it dead I killall in postinst
<medwards_> lamont: inode of binary
<medwards_> lamont: none of this path BS
<lamont> mdz: it's a question of how invasive a change you want in the postinst...
<medwards_> killall in preinst, that is.
<lamont> given how familiar I am with it (not very), I'm disinclined to change it now for hoary, other than to make it not fail...
<smurfix> lamont: inode of the server process, i.e. it doesn't inadvertently kill ~me/foo/bin/thing instead of /usr/sbin/thing
* lamont wonders what pidof does
<medwards_> smurfix: and handles jailed processes correctly, too
<wasabi_> oh here i was talking to myself
<wasabi_> somebody said ant!
<wasabi_> oh not to mention somebody said my actual name too
<lamont> pidof uses the inode.  cooll
<medwards_> lamont: does it attempt to order by parentage?
<lamont> not that I see in 20 seconds of bouncing around in the code, nol.
* lamont uploads
<lamont> this should fix both issues (using pidof, and not checking)
<mdz> lamont: for hoary, the most important thing is that it not break upgrades
<mdz> lamont: if in some oddball circumstances the user needs to reboot because cupsys is horked, so be it
<lamont> mdz: ok.
<lamont> -1ubuntu11 should fix that..
<lamont> hrmpf.  should have put the bug # in the changelog. :-(
<medwards_> lamont: how does this fix get submitted to debian?
<lamont> by me updating the bug in debian...
<lamont> unless you want the pleasure...
<lamont> of course, step 1 is to verify that the bug still exists in sid, etc.
<medwards_> I looked for a corresponding bug#, but it probably hadn't been reopened.
<lamont> and, whether to blow up the upgrade or not may or may not be a maintainer decision in debian...
<xerox> Hi. I need to install a more recent version of SBCL than ubuntu's default one. I tryed with checkinstall but I didn't succeded. Debian unstable has a more recent .deb, how can I grab it? Would it be a good thing to do?
<medwards_> right, but using pidof and sleeping between -KILL and testing again will probably help.
<lamont> yes
<lamont> you want the pleasure?
<lamont> or shall I put it on my list?
<medwards_> will do.
<mdz> xerox: your first question would be more appropriate in #ubuntu, and the second question is answered in the FAQ
* mvo -> sleep
<dholbach> good night mvo
<xerox> mdz: #ubuntu told me to try #ubuntu-devel :) I'll try with the faq..
<mdz> xerox: if there is a bug in the version in Hoary that ought to be fixed, tell #ubuntu-motu
<mvo> night all
<xerox> mdz: the real problem is that sbcl version is rather old, and it has some bad bugs.
<dholbach> xerox: yeah... join #ubuntu-motu
<xerox> Reasking the same thing would be okay there?
<dholbach> yes
<ogra_dogwalk> yep
<mdz> ogra_dogwalk: walking your dog while you're on IRC?
<ogra_dogwalk> *g* just came in again :)
<mdz> oh, wonderful, I can't login to ubuntulinux.org anymore
<mdz> I wonder if that means ubuntu.com works now
<medwards_> lamont: want me to look at 4987, or is there something else I can do to help (and buy a little goodwill WRT LiveCD coaching)?  :)
<ogra> mdz, does it tell you soure actually logged in ? 
<jdub> hrm, thully can even be a pain when he closes bugs...
<ogra> argh
<mdz> nope
<ogra> jdub, we have him in -motu quite often recently
<mdz> Sign-in failure
<mdz> You are not currently logged in. Your user name and/or password may be incorrect. 
<jdub> mdz: oh man :|
<mdz> jdub: has someone made changes in the past few hours?
<ogra> mdz, http://www.grawert.net/wiki_error.png
<mdz> ogra: no, that's the old ubuntu.com/ubuntulinux.org error
<mdz> this is different; it doesn't even accept my login/password
<lamont> medwards_: 4987 just needs a sync... /me composes mail
<jdub> mdz: not that i know of
<ogra> i always log in through https and ubuntulinux.org, never used ubuntu.com
<mdz> ogra: everyone does, because ubuntu.com doesn't work
<mdz> it never has
<ogra> ah, ok
<mdz> but now ubuntulinux.org is borked too
<ogra> yep
<mdz> if you're logged in, don't log out ;-)
<ogra> lol
<jdub> "the ssh method"
* mdz thinks better of keeping his notes in the wiki
* ogra thinks he should update the HardwareDatabase page soon
<smurfix> Didn't that login problem happen a few weeks ago already?
<ogra> smurfix, months ago already
<dholbach> did anyonce perceive a slight out-of-sync-ness of the archive?
<dholbach> like: <dholbach> i have   Version: 0.12.2-1
<dholbach> <dholbach> and   http://people.ubuntu.com/~lamont/buildLogs/l/linphone/0.12.2-2ubuntu1/   claims they all were successful
<dholbach> xerox states something quite similar about sbcl
<dholbach> and i'm not talking about the usual interval
* lamont sees  liblinphonegnome0_0.12.2-2ubuntu1_i386.deb
<lamont> but not for ppc or amd64
<ogra> dholbach, fyi Package: linphone, Version: 0.12.2-2ubuntu1
<ogra> seems ok here
<dholbach> on an amd64
<dholbach> daniel@bert:~/blue$ apt-cache show linphone | grep Version
<dholbach> Version: 0.12.2-1
<dholbach> daniel@bert:~/blue$
<ogra> dholbach, i am on amd64
<lamont> claimes they became installed about 2 hours ago
<dholbach> xerox talks about  Version: 1:0.8.17.4-1   of sbcl, where 0.8.18-1 should be recent
<ogra> argh, sorry, showsrc instead of show
<ogra> dholbach, youre right
<xerox> (I also note that 0.8.20 is stable now)
<lunitik> Any chance of getting http://higgs.djpig.de/ubuntu/www/ incorporated into Ubuntu site officially? its quite useful  :)
<lunitik> Note on previous message... not mine... guy has a link to contact him where you could ask permission... it really would be nice though... I still go to p.d.o to see whats in the archive when I'm not at my machine for instance, but its rather inacurate  :(
<mjg59> Gagh.
<mjg59> Ok, I've found how how Windows does suspend-to-disk when battery is low in suspend-to-ram
<jbailey> mjg59: OOoo.. Howhowhow?
<jbailey> Frequently wakeups?
<mjg59> It sets a wakeup time
<thom> mdz: take it no kubuntu?
<mjg59> I don't know how it calculates the wakeup time
<mjg59> So yeah, possibly it wakes up every 24 hours or so and checks the battery stats
<jbailey> mjg59: Could be every 30 minutes, check battery level?
<mjg59> Yeah
<jbailey> Hmm, would 24 hours be often enough?
<mjg59> Quite possibly not. 
<dholbach> sounds like a statistical solution would be a possible approach :-)
<Riddell> thom: kubuntu is good to go as far as I'm concerned
<tseng> amu: have you addressed boost like we discussed?
<medwards_> lamont: can you explain the relationship between initrd.list and initrd.gz?
* lamont guesses that .list would be a list of what's installed in .gz
<ogra> tseng, he might be asleep, its 1:20am here
<thom> Riddell: you have cds and torrents and stuff?
<tseng> well im guessing he'll see the message eventually.
<thom> Riddell: (I only care about the torrents, tbh)
<medwards_> Does that get rebuilt when making a new livecd?  And if so, using what tool?
<Riddell> thom: http://cdimage.ubuntu.com/kubuntu/daily-live/20050317.1/
<Riddell> http://cdimage.ubuntu.com/kubuntu/daily/20050317.1/
<mdz> medwards_: initrd.list and initrd.gz come from the installer builds
* thom just boggles at https://bugzilla.ubuntu.com/show_bug.cgi?id=7552#c7
<medwards_> mdz: the installer also builds the livecd initrd?
<mdz> medwards_: the installer and the live CD use identical initrds
<mdz> thom: we're making that determination on #kubuntu-devel
<lamont> medwards_: in fact, I think if you had a 1GB CD, and included casper and the livecd cloop on it, you'd have an install/live cd
<lamont> mdz: is true?
<medwards_> thom: gtk boog?
<mdz> lamont: the extra magic would be to add a boot parameter to switch casper on
<lamont> right
<mdz> in fact the DVD image is exactly that
* lamont wonders if casper now defaults to the right image.
<dholbach> thom: nice :-)
<thom> mdz: okey
* lamont notes that snapshot.debian.net is, um, slow.  even by my standards
<seb128> mdz: gtk2-engines-industrial uploaded
<mdz> thom: can you still see straight? ;-)
<mdz> seb128: wonderful, thanks
<seb128> you're welcome
<thom> mdz: heh, yeah :-)
<thom> the pub was so rammed that getting to the bar was the limiting factor ;-)
<tseng> mdz: oh, ive run a quick test of the weekly dvd on qemu btw
<tseng> nothing exploded
<mdz> bar bottleneck
<medwards_> thom: or the use of avi as a gdb stub? :)
<mdz> tseng: wow, that must have taken a long time
<thom> medwards_: the use of avi :-)
<tseng> hah yeah.
<thom> mdz: the centre point of the local irish community, on st patricks day. messy :-)
<mdz> thom: let the kubuntu torrents fly
<mdz> Kamion: are you around to do publishing magic?
<mdz> thom: do you need for me to make the metafiles on little?
<zenwhen> is there going to be a gtk1 clearlooks engine?
<thom> mdz: i can do it on orcadas, not a problem; are we just going with the daily Riddell posted, or republishing as a release?
<mdz> thom: I think I can decipher Kamion's scripts well enough to publish it as a release
<thom> ok; if you want to do that magic i'll wait for a bit
<jdub> mdz: (is this kubuntu build going to be announced more widely?)
<mdz> jdub: this is the kubuntu preview :-)
<jdub> excellent
* jdub puts on his pimp boots
<mdz> jdub: it is, you should check out a live CD
<medwards_> mdz: so if I want to try a unionfs livecd, I need to hack on ubuntu-installer (presumably the input to initrd.list as well as linuxrc)?
<zenwhen> I have to say... for a KDE dist... Kubuntu is really sweet.
<seb128> jdub: I've uploaded a fixed gtk2-engines-industrial
<jdub> seb128: ta
<seb128> jdub: bah, the effet on the desktop is not weird dude :p
<seb128> that's the same behaviour as all the other windows
<jdub> seb128: it totally is. bigarse 1px flashy shit on the left.
<jdub> it looks very pronounced on the desktop
<jdub> so many people have mentioned it
<jdub> even some french people
<jdub> ;-)
<seb128> oh right
<seb128> in fact it doesn't with my background
<medwards_> hmm .. how do I draw "smiley with beret" again?
<seb128> but it does with the calendar one :p
<jdub> seb128: ah, yeah, that makes a big difference ;)
* ogra looks at this disconcerting snake leather boots at jdubs feet
<Riddell> ogra: tested kubuntu yet?
<jdub> ogra: dude. *dragon* leather boots.
<mdz> thom: so should I make-torrents or no?  last time there was some confusion with the torrents being present in one place and not in another
<ogra> LOL
<jdub> ogra: this is kde pimping!
<ogra> LOOOL
<thom> mdz: if you're doing the release, do torrents to
<medwards_> jdub: the KDE dragon is a bastard child of Disney's Figment, neh?
<ogra> Riddell, not the newest, nope
<medwards_> (if you've been to EPCOT)
<jdub> it is not my place to comment on the kde mascot's parentage or lack thereof
<ogra> Riddell, i'll start the download before going to bed, test them tomorrow
<cc> hmm, so is the latest array 7 (?) livecd all working well?
<mdz> thom: ok
<mdz> cc: yes, it's pretty solid
<mdz> ogra: if you're leaving it on overnight, wait for a torrent ;-)
<cc> mdz: so the X issues are fixed. thanks. i shall resync now
<medwards_> cc: dunno yet, my torrent has said 3 hours to go for the last 3 hours.  :-(
<ogra> mdz, k
<medwards_> would be nice if torrents were distinguishable from one another on the tracker.
<cc> medwards_: isn't it easier to get it from cdimage itself, rather than a torrent?
<medwards_> e. g. hoary-array-7-live-i386.iso
<thom> medwards_: yes
<medwards_> cc: 8 KB/s
<thom> there are many, many ways that the tracker could be improved
<maswan> medwards_: you mean like this? http://cdimage.debian.org:6969/
<thom> medwards_: well, "./hoary-install-i386.iso.torrent": "seeding" (100.0%) - 5P3s0.165D u358.7K/s-d0.0K/s u1097012K-d598874K ""
<medwards_> thom: torrent is currently 28 kb/s (vs. 8 for cdimage.ubuntu)
<Burgundavia> where is the current kbuntu torrent
<Burgundavia> ?
<thom> Burgundavia: not in place yet
<Burgundavia> hmm
<medwards_> maswan: similar tracker, yes, but ubuntu livecds aren't named uniquely (which hoary-livecd-i386.iso.torrent is array-7?)
<maswan> medwards_: ah
<Riddell> medwards_: rumour has it that one of konqi's footprints started it's own desktop environment
<maswan> medwards_: well, that's kind of hard to solve in the tracker then.
<medwards_> So let me get this straight.  cloop is writable, and the livecd uses device-mapper to route written blocks to a ramdisk overlay?
<thom> maswan: you could probably get more useful metadata into the .torrent
<medwards_> Riddell: several desktop environments could live happily in one of konqi's (memory) footprints.  :)
<thom> Keybuk: you really are on .au time, eh?
<Keybuk> pretty much :-/
<maswan> thom: Well, you do have a text comment field
<jdub> Keybuk: western australian time ;)
<thom> maswan: (and you'd have to display that somehow in the tracker, but yeah)
<maswan> thom: these days I timestamp the weekly debian iso torrents with the date -u of when they are made.
<Keybuk> actually, I don't think I'm in any real timezone since I think it's Thursday
<jdub> heh
<medwards_> If unionfs worked (I can still trigger oopses with the Knoppix 3.8 version), it seems to me that it would be preferable;
<medwards_> stack jff2 on squashfs, for instance.
<medwards_> s/jff2/jffs2
* Keybuk prods bzr; it's not just me who's in a strange timezone -- it seems to think I'm in +0100
<cc> when ubuntu goes selinux, jffs2 might be a bottleneck
<ogra> hey only about an hour to unix time 1111111111 
<tseng> jffs3 is being developed and I hear that xattr is on the gameplan
<jdub> the status is: 1111107212
<tseng> jdub: are we there yet?
<elmo> root     21673  109  6.3  38428 32808 pts/0    R+   00:53   0:04  |                   \_ /usr/sbin/apache2 -k start -DSSL
<ogra> nearly
<elmo> 109%... neat
<medwards_> cc: I'm thinking in terms of server uses; one could afford to use a fresh chroot every sbuild run if it were just several overlaid package sets with a ramdisk on top.
<maswan> hmpf. elmo's apache is neater than mine.
<elmo> god damn I wish apache had some serious competition in the httpd market
<medwards_> jffs2 comes in when I want to persist, say, a client's data (including apt-getted packages) on a USB stick but get most of my bits off the livecd.
<maswan> inetd + echo&cat? :)
<medwards_> elmo: tomcat?
<medwards_> don't think there's a mod_php, though.
<maswan> ehm. tomcat? isn't that an apache webservice thingie?
<medwards_> maswan: java servlet container
<HrdwrBoB> tomcat isn't a realistic alternative in terms of a multifunction httpd
<maswan> medwards_: well, yeah, webservices is where I've been in contact with it.
<medwards_> maswan: sucks less than you would think for static content
<jdub> elmo: twisted. :-)
<tseng> elmo: hey would you mind syncing gtkpod 0.88?
<medwards_> HrdwrBoB: of course not -- when I have to deal with tomcat, I front-end it with apache+mod_jk{2,}
<elmo> tseng: done
<tseng> elmo: you rock!
<ogra> tseng, dont forget gnupod, and all the other pods ;)
<tseng> heh.
<thom> jetty isn't awful but is still java; apache is the only thing i'd trust for serving large data
<ogra> tseng, thanks for the thully work btw
<tseng> ogra: yeah np
<jdub> heh, thully work ;)
<thom> tseng: you poor guy
<medwards_> thom: agreed, although jetty is even more of a pain to build than jakarta stuff.
<HrdwrBoB> medwards_: yeah
<tseng> thom: better then HostingGeek at least
<thom> tseng: maybe
<jdub> thom: "ASF member announces: 'Apache only httpd I would trust'."
<lifeless> news @ 12
<mdz> jdub: in other news, Ubuntu developers running Ubuntu on critical systems
<medwards_> elmo: depending on how you define "competition", IIS  :-/
* maswan huggles AIX for ftp.gnome.org. :P
<HrdwrBoB> medwards_: IIS on win2k3 server is in some ways superior
<thom> IIS is great, barring the fact that having a web server in ring 0 is UTTER CRACK
<maswan> well, or ftp.se.d.o or ftp.acc.umu.se. :)
<jdub> mdz: hoary has been running admirably on my critical systems, btw.
<mdz> jdub: I run Warty on my servers
<mdz> and Hoary on my development systems
<HrdwrBoB> it's an embarrassment that IIS can run 500 websites all with their own users and apache can't
<medwards_> mdz: now if ubuntu ran on sparc, debian would have an infrastructure plan ... :-/
* maswan needs to get time and a new install server to go hoary all over work
<thom> HrdwrBoB: it's irritating
* jdub wants to make sure hoary server stuff doesn't suck :)
<mdz> medwards_: sparc.ubuntu.com
<jdub> like warty's dovecot.
<thom> HrdwrBoB: since perchild/metux has the potential to really kick ass
<HrdwrBoB> thom: yeah it looks great
<tseng> jdub: i use warty dovecot
<tseng> whats the deal with that?
<thom> but perchild is dead and the metux guys have no inclination to get their stuff upstream
<medwards_> HrdwrBoB: that's actually the sort of thing I would look to apache2+mod_jk2+tomcat5 for.
<jdub> tseng: hurts on lots of users, hurts on huge folders
<tseng> ah.
<thom> medwards_: why? it should be way lower level than application server
<HrdwrBoB> medwards_: all the file access should run as the user for that website
<medwards_> mdz: sparc64 strategy?  biarch?
<HrdwrBoB> so the permissions can be sane
<thom> medwards_: 64bit kernel, 32bit userland
<mdz> medwards_: following the same road as Debian so far; I don't think fabbione has given it much thought yet
<thom> HrdwrBoB: yeah, it'll be nice when it happens
<HrdwrBoB> I worked around this partially by using suexec and making php work by php calling php cgi
<HrdwrBoB> but you lose the mod_php features
<thom> "features"
<HrdwrBoB> and you still don't access the files the right way
<thom> nod
<mdke> *cough* website
<HrdwrBoB> oh, and I had to add a post upload script that made php files executable
<mjg59> daniels: Stock Hoary preview install, and I have no working dri on an i915
<mjg59> It says that it's initializing the SW cursor, which is probably a bad sign
<thom> HrdwrBoB: bleah
<thom> mdke: hrm?
<mdke> thom, something is up with the website. we can't log in
<medwards_> HrdwrBoB: tomcat is not jboss.  :-)
<mjg59> daniels: Argh, cock. It's because it hasn't picked enough video RAM for DRI
<jdub> fontconfig/libfcontconfig1 postinst b0rkage is known?
<jdub>  libfontconfig1 depends on fontconfig; however:
<jdub>   Package fontconfig is not configured yet.
<mdke> maybe someone has hacked our website
<HrdwrBoB> never attribute to malice...
<mdke> HrdwrBoB, heh
<mdke> HrdwrBoB, maybe it needs a reboot
<mdke> *crosses fingers*
<mjg59> daniels: Something very wrong here. I set VideoRAM and it still claims that it needs more RAM.
<medwards_> mjg59:  that word is currently reserved for ij, iirc.
<elmo> the website should work now
<mdke> thanks elmo 
<mdke> elmo, nope :(
<elmo> mdke: works for me
<elmo> and I can see it working for others
<mdke> elmo, ok
<mdke> hmm
<mdke> elmo, yes sorry
<mdke> thanks a lot
<Burgundavia> jdub: I was working a user through that, I don't see it on my system though
<Burgundavia> jdub: didn't resolve anything
<ogra> lol
<ogra> <ssam> mark shutleworth is from space
<thom> may explain a few things
<ogra> heh
<HrdwrBoB> haha
<mdz> jdub: someone commented about it on another bug, but no proper bug yet
<mdz> jdub: mvo went to sleep; fixes appreciated
<HrdwrBoB> 1111111101
<HrdwrBoB> 1111111103
<ogra> yeah
<ogra> HrdwrBoB, not here yet
<HrdwrBoB> heh
<ogra> 1111111098
<tseng> 1111111102
<tseng> brandon@lappy:~$ date +%s
<tseng> 1111111111
<tseng> wee.
<maswan> whee
<ogra> yeah, happy 1111111111
* ogra recognizes thta this is really nearly his lifetime in seconds (minus 1,5 months)
<mdke> ogra, man you shouldn't be able to work that out
<ogra> :)
<mdke> heh
<Keybuk> mdke: *shrug* one assumes ogra was born in 1970
<ogra> yup
<ogra> mid of feb, to be precise
<ogra> man, i'm old...
<ogra> ...time for bed....
<ogra> night all
* Keybuk is 10 years younger than "unix time"
<Keybuk> (and, by inference, ogra)
<mdke> nite
* HrdwrBoB likewise
<ogra> like nearly everyone around
<mdke> how old is that?
<mdke> 111111111?
<thom> Keybuk: damn youngster ;-)
<Keybuk> mdke: roughly 332793000
<mdke> *head spins*
<ogra> hehe
* Keybuk gets thom's pipe and slippers ready for him
<mdke> what date is unix year dot?
<ogra> mdke, Keybuk is not the man i would argue with about numbers ;)
<mdke> ogra, no change, i don't have a clue
<mdke> *chance
<Keybuk> ogra: hmm?  I can barely count
<thom> Keybuk: thanks :P
<Keybuk> mdke: Sweetmorn, Chaos 1, 3136 YOLD
<mdke> *head spins*
<mdke> in christian time?
<Keybuk> that's boring :p
<Keybuk> and I suspect you really mean Gregorian time
<mdke> "he Unix epoch is the time 00:00:00 UTC on January 1, 1970"
<mdke> hmm
<schweeb> Keybuk: 14.4 yrs younger than epoch here, heh
<thom> 9.7 here
<mdke> 11.9
<mdke> you guys are clearly just having a good time in here, would anyone like to look at https://www.ubuntulinux.org/wiki/IdeasForNewFrontPageStructure and comment?
<mdke> see also subpages
<mdz> Keybuk: you are young
<zul> hey
<thom> g'night folks
<Riddell> thom: not staying up to set up torrents?
<thom> Riddell: already running
<Riddell> thom: URL?
<thom> http://torrent.ubuntu.com/kubuntu/preview/
<Riddell> thom: excellent, many thanks
<thom> np
<thom> sleeptime now
<infinity> 'Night thom.
<thom> ciao
* infinity laments a wasted morning that almost certainly spells "I'm working on Saturday to make up for it".
<mdz> infinity: please squash https://bugzilla.ubuntu.com/show_bug.cgi?id=7819
<mdz> infinity: highest priority
<mdz> looks like a regression in mvo's upload
<infinity> On it.  Was just catching up on bugzilla mail right now.
<calc> thom: here?
<usual> hey calc
<calc> hi
<usual> calc, do you have anything to do with kubuntu?
<calc> no :\
<usual> calc, ok, I remember you packaging kde in debian
<calc> yea
<calc> i tried to get a job with credativ but they don't appear to be hiring
<usual> ahh
<infinity> mdz : I don't suppose there's an ubuntu snapshot archive (like snapshot.debian.net), where one can easily grab old sources and diff to track regressions?
<usual> calc, you did a great job
<calc> thanks
<mdz> infinity: morgue.ubuntu.com
<mdz> calc: thom went to sleep
<calc> ok
<mdz> calc: credativ is not a prerequisite for kubuntu, you know
<calc> true, but with my current job i very little time to do anything else
<calc> at work 9hr+ and 3hr commute
<mdz> I know how that goes
<mdz> 3hr driving or transit?
<calc> driving
<mdz> ouch
<calc> yea if i could sleep for 3hr that would be fine ;)
<zul> calc: against traffic or with traffic
<calc> obviously with traffic or it wouldn't take 3hr ;)
* calc thinks they plan to fix the roads around here in about 3yr
<zul> calc: meh..
<calc> the place i work is only ~ 40 miles away
* calc is updating the debian ogg/vorbis stuff via chroot
<mdz> calc: someone was trying to coerce me into an updates libvorbis in hoary the other day
<mdz> s/updates/updated/
<calc> heh
<calc> jdub asked me about it a few days ago and so i tried rebuilding a chroot
<calc> the first time it took my box several hours just to download it must have hit a really bad mirror
<mdz> the vagaries of a time-based release schedule
<zul> mdz: like the ipw2200 driver?
<mdz> zul: yep, only more persistent than thully
<zul> more? oi vey...
<calc> mdz: so ubuntu hoary releases in about 2 weeks right?
<mdz> calc: April 6th
<mdz> release candidate on march 30th
<mdz> in otherwords, we're solidly in stabilization mode and not kowtowing to requests for new upstream versions ;-)
<zul> like ipw2200
<zul> oops..:)
<calc> mdz: ok
<calc> hmm yea a newer ipw2200 than from last dec would have been useful
<calc> its broken on amd64
* calc just did a local build to get it working on his box
<calc> fsck
<calc> i uploaded libao a debian native
<calc> stupid .orig renaming
* calc forgot to do it
<Amaranth> hey, doesn't anyone know where the gnome menus get their icons from?
<Amaranth> like the icon for the "Accessories" menu
<calc> it should be fairly easy to find out
<Amaranth> oh?
<Amaranth> appearently not, i'm lost ;P
<calc> look in /etc/xdg/menus
<calc> which would then point you to /usr/share/desktop-directories/Accessories.desktop
<calc> which then points you to the icon "gnome-util"
<Amaranth> *facepalm*
<calc> perhaps not everyone has ingrained the fdo specs into their brain ;)
<Amaranth> this is what i needed when i started on this stupid thing
* calc wrote the menu-xdg debian menu converter so learned a bit too much
<Amaranth> i hate fdo specs :P
<Amaranth> oh, you're the one responsible for that annoying Debian menu showing up last week?
<Amaranth> :P
<calc> hehe
<calc> i wrote it many months ago
<calc> i guess you installed it last week
<Amaranth> yeah
<calc> hey it works right
<calc> it took me a while to debug it to where it worked according to policy ;)
<Amaranth> the fdo menu spec is a pita, i'd just like to point that out
<calc> someone could easily make nice looking icons for it as well, i am not an artist though so didn't do that
<Amaranth> no wonder GNOME 2.10 didn't have a menu editor
<calc> its not that difficult to make changes to the menu
<Amaranth> my editor more or less works but it has some issues
<calc> though someone has to read the spec and actually grok wtf its talking about
<calc> well i mean wrt the user editting it in their $HOME and it actually merging them
* Amaranth spams http://www.realistanew.com/menueditor.png
<calc> manually editing the file in /etc/xdg is not a good idea
<calc> that makes it change for all users
<Riddell> http://www.kubuntu.org.uk/  Preview Released
<calc> Riddell: cool
<tseng> Riddell: go go gadget crack pipe
<tseng> good show.
<Riddell> :)
<mdz> Riddell: what is KGX?
<Riddell> KDE/GNU/Unix
<Riddell> the term never caught on for some reason
<mdz> is it in common use in the KDE community?
<calc> hmm can you call something Unix without paying someone?
<Riddell> mdz: only occational
<Riddell> calc: that's why it's just an X :)
<calc> heh
<jammcq> mdz: Hey, did you tell me that the Ubuntu live cd will look for a swap partition on a harddrive and use it?
<infinity> mdz : Do you want debdiff patches to the bug(s) in question, or should I find a sponsor and upload?
<mdz> infinity: the latter
<mdz> jammcq: that's correct
* infinity looks about for volunteers.
<jammcq> mdz: does it also create a swapfile on a FAT filesystem if it finds it?
<mdz> jammcq: no, it doesn't
<jammcq> we're discussing this over in #ltsp, to look for a harddrive and use it for swap, but we don't want to destroy any existing data
<mdz> infinity: you are not in the keyring yet?  did you mail elmo?
<mdz> jammcq: using an existing swap partition is quite safe; I'm not sure that I would create a swap file
<infinity> mdz : Unless he's added me silently, I'd go with 'no'... I'll bug him right now (Didn't do so earlier, due to the whole start date fiasco).
<mdz> if nothing else, it could be left behind occupying lots of space, in the event of a crash
<mdz> infinity: he's asleep if he has any sense
<infinity> mdz : His idle time disagrees.
<jammcq> ok, it just seems that it would be kind of rare for it to find a swap partition.  at least outside of the linux community
<mdz> infinity: I qualified that statement
<infinity> Heh.
<mdz> infinity: if no one else is around, i can sponsor you
<bob2> cool
<bob2> "rmmod hci_usb" hangs rmmod at 100% cpu
<infinity> mdz : elmo's alive.  I'm bugging him as we speak.
<bob2> and fails
<mdz> bob2: "then don't do that"
<srbaker> what's a good tool for non destructively resizing partitions?
<mdz> srbaker: parted (glad to talk about it further in #ubuntu...)
<bob2> mdz: hah
<infinity> srbaker : In theory, or practice?...  In practice, the best tool is backing up and doing repartitioning destructively. :)
<srbaker> infinity, hehe
<calc> ok all the new ogg/theora stuff is sitting in debian incoming now
<lamont> mdz: hoary-test is building on all 4 architectures.  we did leave one buildd of each _not_ trying, since there are some long builds near the top, and even at 1-per-run, they'd bottle neck everything occasionally....
<lamont> hoary-test is the last chosen, and only builds if nothing else wants to build.
<lamont> but it takes 10 things at a time
<mdz> lamont: sounds good; how long do you figure it will take to try everything?
<lamont> last time around it was on the order of 70 hours or so, using 3 buildd's, and no ccache..
<lamont> so probably about 2-3 days
<infinity> mdz : fontconfig fix up.
<lamont> possibly 4-5
<lamont> mdz: of course, I expect _main_ to be done sometime tomorrow
<lamont> would be sooner, but oo.o, oo.o2, kernel, xorg kinda add up :)
<lamont> i386 will be the leader, for sure
<elmo> I haven't even imported universe yet - that'll take like a quarter of a day, easy, I reckon
<lamont> woot
<lamont> mdz: if you want the test build to be done sooner, we can include that last buildd, but it might mean that you have to wait an hour or two for, say, a casper build...
<lamont> elmo: duh.  1400 pkgs would be !universe, wouldn't it... :-(
<calc> 1400 sounds less than even main
<calc> maybe just what fits on the cd?
<elmo> source packages
<calc> oh
<lamont> and it's really closer to 1500.  /me rounded agressively
<fabbione> morning
* lamont sleeps
<fabbione> night lamont 
<Cym> I have a question about the libavcodec package..
<Cym> it appears that libpostproc is not part of the packaging rules (which is makes sense to build at the same time as libavcodec) IMHO
<Cym> i figure that when I do a dpkg-buildpackage after "apt-get source libavcodec", then it should create packages for ffmpeg, libavcodec, and libpostproc
<Cym> then migrating these rules to cvs would be much easier to maintain
<fabbione> ah neat
<fabbione> sparc is only lagging 13 packages for main
<elmo> caught up fairly fast
<fabbione> with 15 days of downtime.. yeah
<fabbione> it was pretty good
<dilinger> what kind of build machines do you guys use for sparc?
<fabbione> my netra t1 :-)
<dilinger> 400 or 500mhz ultrasparc IIi?
<fabbione> 433 iirc
<dilinger> cool
<fabbione> mdz: any objection for a console-data port upload that does NOT touch any of the existing code?
<fabbione> it adds one rule in debian/rules
<fabbione> and sparc in debian/control for one package
<fabbione> jdub: ^^
<mdz> infinity: #7819 can be closed if you have uploaded the fix
<infinity> mdz : Just did so.
<mdz> infinity: thanks
* fabbione hears no objections and upload
<elmo> hmm, Assigned to Me is broken for me in bugzilla
<Cym> does the maintainer for ffmpeg/libavcodec visit this room?
<doko> good morning
<amu> moin2
<infinity> Mornin', doko.
<mdz> distrowatch says that linuxcd.org is selling kubuntu CDs already
<amu> mdz: heh 
<pitti> Morning
<doko> morning pitti
<doko> mdz: I assume the OOo upload should be safe now?
<pitti> doko: morning
<mdz> doko: yes, I have not uploaded it yet, feel free
<doko> mdz: ok, done
<doko> this 1.1.3, haggai didn't feel to comfortable upgrading to 1.1.4 at this point, and the major reports are fixed
<pitti> Riddell/amu: ping
* Mithrandir uploads utf8-migration-tool 0.3
<fabbione> Mithrandir: where are you now?
<Mithrandir> Oslo
<Mithrandir> my father's
<fabbione> did you have a nice trip?
<fabbione> i got the msg btw.. if the address is correct, it is very close to where i live
<Mithrandir> cool
<Mithrandir> nah, horrible trip.  Cold, people talking, uncomfy seats.
<Mithrandir> but I'm managing.  Karianne is sleeping a bit
<Riddell> pitti: hi
<fabbione> suckage
<pitti> Hi fabbione 
<fabbione> hey pitti
* fabbione hides from pitti
<pitti> Riddell: CAN-2005-0396 is fixed in Warty, but not Hoary
<pitti> fabbione: no reason to, I just wanted to say hello :-)
* fabbione reappears
<fabbione> ;)
* pitti has the feeling that he is considered unwelcome :-)
<pitti> Riddell: will you still do this?
<fabbione> only when you talk about CAN's
<Riddell> pitti: CAN-2005-0396 is "KDE version prior to KDE 3.4"
<Riddell> pitti: I'll not that in the changelog 
<Riddell> note
<pitti> Riddell: ah, ok
<pitti> Riddell: no need to, if it didn't require a change
<pitti> Riddell: I'll add it to the nonvuln list then
<pitti> Riddell: OTOH, a note in the changelog would be easier if you have to do another upload anyway
<Riddell> pitti: cool.  how come e.g. CAN-2005-0237 didn't set off your alarm?
<Riddell> pitti: I don't have another upload planned (I plan to go to sleep)
<pitti> CAN-2005-0237 	
<pitti> kdelibs	(hoary/main, warty-security/universe)
<pitti> ^ this is from my security radar
<pitti> so everything is in order for this
<pitti> ... it seems
<pitti> ogra: here?
<HiddenWolf> mvo?
<dholbach> gooood morning
<d3vic3> morning
<HiddenWolf> seb128: is it correct that that gtk-engine fix you did only fixes the ubuntu-themed mousecursor for the session?
<pitti> Hi seb128
<seb128> it does what is written in the changelog
<seb128> hi
<pitti> dholbach: Morning
<dholbach> morning seb128, pitti, d3vic3 
<pitti> dholbach: do you want to merge the Debian changes of grip to fix the security bug?
<dholbach> pitti: if it has time until i got some coffee, i'll do it :-)
<pitti> dholbach: oh, I'm not hurrying you :-)
<pitti> dholbach: just wanted to tell you about it
<HiddenWolf> Ugh. Firefox won't download anything anymore
<sivang> morning all
<dholbach> *grmbl* is gamin still on crack?
<dholbach> morning sivan!
<pitti> Hi sivang
<sivang> morning dholbach 
<sivang> pitti: Hey Martin 
<sivang> pitti: just saw the thread about the users-admin tool, I dojn
<sivang> pitti: suppose there a sane way to make an upgrade path upgrade if the admin didn't do custom configs?
<sivang> pitti: (or maybe we do not want this to be available at all as an upgrade path)
<dholbach> pitti: we can just sync it
<dholbach> elmo: could you please sync  grip  from sid?
<dholbach> morning mvo
<mvo> hi dholbach 
<mvo> morning all
* sivang high fives mvo
<Kamion> morning
<fabbione> morning Kamion
<fabbione> hi everybody
* mvo yawns
<dholbach> hi fabbione, Kamion 
<sivang> mvo: so tired you cannot low five back? :)
<mvo> sivang: I hadn't had my first cup of tea yet :)
* mvo tries a low five at sivang 
<sivang> mvo: hehehe , you're excused :-)
<Amaranth> hey, you guys wanna help me beat some bugs out of this menu editor i wrote? :)
<seb128> Amaranth: don't ask to ask, just ask
<Amaranth> http://dev.realistanew.com/menu-editor/menueditor_0.1-1_i386.deb
<Amaranth> heh
<Amaranth> it's not really i386, i just suck at making packages
<ajmitch> Amaranth: btw, did you use python-xdg for it?
<Amaranth> *facepalm*
<Amaranth> I probably will for the next version...
<ajmitch> I was hoping to work on an editor but real life got in the way :)
<seb128> http://denu.sourceforge.net/
<seb128> and there is one in C on the GNOME CVS
<seb128> that's just for information
<Amaranth> yeah, denu was just weird the the on in CVS doesn't really do anything
<Amaranth> and i don't know C :)
<seb128> denu works ?
<seb128> your one looks nice, but doesn't really do anything atm
<Amaranth> it can edit current entries and add new ones
<seb128> it doesn't display anything else than categories here
<seb128> Traceback (most recent call last):
<seb128>   File "./menu-editor", line 343, in editEntry
<seb128>     entry = self.entries[model.get_value(iter, 0)] 
<seb128> KeyError: 'Games'
<Amaranth> yeah, if you don't run it as root (gksudo or sudo) it uses ~/.local/share/applications/
<seb128> it should merge both
<seb128> you really want to use pyxdg
<Amaranth> seb128: Not if you aren't running as root...
<seb128> sure
<Amaranth> How could you edit them?
<seb128> read the spec
<seb128> by creating a new .desktop in ~/.local
<seb128> that's user first, then system
<Amaranth> oh, *facepalm*
<Amaranth> i only read enough of it to make what i have work :P
<seb128> ie: it takes the user change first and then merge the system entries
<seb128> ah ah
<Amaranth> 0.2 will be out tomorrow using python-xdg and doing that :P
<Amaranth> well, maybe saturday
<seb128> sudo apt-get install python-xdg
<seb128> python /usr/share/doc/python-xdg/examples/test-menu.py /etc/xdg/menus/applications.menu
<seb128> python-xdg already does a lot
<Amaranth> neat, but it gave me the german version
<seb128> ie this example builds the full application menu, you just have to display what it returns
<seb128> menu.setLocale("de") is used in the sources
<Amaranth> ah
<seb128> you can change that for whatever you want
<Amaranth> hey, where is that stored?
<Amaranth> in gconf or whatever
<seb128> /usr/share/doc/python-xdg/examples/test-menu.py
<Amaranth> so i can load the correct language
<seb128> sudo editor /usr/share/doc/python-xdg/examples/test-menu.py
<Amaranth> yeah, i've already got that open
<seb128> menu.setLocale is in the file
<seb128> it's not that big
<seb128> should be easy to find
* Amaranth tries to explain better
<Amaranth> how can i see what language the user is using so i can show the right info?
<seb128> use the locale settings
<Amaranth> where do i get those from? :)
<seb128> python -c "import locale; print locale.getdefaultlocale()"
<seb128> by example
<Amaranth> bleh, so simple
<Amaranth> why can't i find these things at 3:30am?
<sivang> seb128: what does that script do? (test-menu.py)
<seb128> sivang: just run it and see
<seb128> <seb128> python /usr/share/doc/python-xdg/examples/test-menu.py /etc/xdg/menus/applications.menu
<sivang> seb128: k, thanks :)
<sivang> ah! extracts the menu layout of the desktop
<pitti> dholbach: what about the howl removal from grip?
<dholbach> pitti: a rebuild sufficed :-)
<pitti> dholbach: ah, there were no actual changes? good
<dholbach> pitti: it's a dependency expanded by shlibs:Dependencies and libgnomevfs
<dholbach> pitti: just newer config.{guess,sub} 
<DM_Rado> hi everyone
<sivang> seb128: is there a way to make a toplevel menu when set as a checkbox act nicely? I tried using one as a checkbox but it requires 2 click to make it checked/unchecked which is kinda bad..
<Treenaks> sivang: toplevel menu? as in a checkbox in the menu bar?
<DM_Rado> i have an acer laptop, travelmate 730 series, ubuntu seems too have alot of errors when installing
<sivang> Treenaks: exactl
<seb128> sivang: I don't get the question. You want to put a checkbox in the menu bar ? that's ugly
<sivang> Treenaks: exactly, even
<sivang> seb128: true, nevermind.
<Treenaks> not only is it ugly, it's against the HIG :)
<DM_Rado> is there any way around this?
<sivang> Treenaks: shooosh, don't let anybody hear I suggested that :)
<Kamion> seb128: any chance you could make GNOME stuff depend on gs-esp | gs rather than just gs?
<doko> kamion: is there an easy way to determine the release date of a install/live cd?
<mvo> doko: there is /cdrom/.disk/info
<Kamion> seb128: I thought this was done for warty, but either it was incomplete or it's regressed
<doko> mvo: thanks
<Kamion> yeah, what mvo said
<Kamion> seb128: the reason for this is that otherwise DVD installations prompt in the second stage to reinsert the CD in order to install gs and gs-gpl; gs is a mixed virtual packages, and apt picks the real gs package rather than gs-esp in desktop
<Kamion> seb128: actually it's just gnome-gv and ijsgimpprint I think, so I'll do it if you want ...
<seb128> Kamion: yes please
<Alessio> sorry, who can i ask for add a link to this page http://www.ubuntulinux.org/community/forums/ ??
<Kamion> elmo: has hoary-changes been missing mails? I don't see anything about fontconfig 2.2.3-4ubuntu{6,7}
<fabbione> Kamion: neither do i
* smurfix hates DSL. When it fails to work, that is.
<dholbach> smurfix: i feel with you very much
* dholbach never had a flakey connection like in the last days
<ogra> pitti, now
<kiko> HERE COMES NOISE
<ogra> morning
<mpt_switzerland> rah rah rah
<kiko> morning ogra 
<pitti> ogra: nevermind, already dealt with
<kiko> how are these ubuntu people doing?
<pitti> ogra: Morning :-)
<ogra> :)
<pitti> kiko: one is banging his head with flawed PHP fixes
<kiko> pitti, just drop php from main. next problem?
<pitti> kiko: it seems that I just discovered that a security fix introduced another security problem *sigh*
<pitti> kiko: seconded :-)
<ogra> kiko, +++
<seb128> mvo: nice work on the icon when apt is working :)
<dholbach> seb128: yeah
<dholbach> morning ogra
<mvo> seb128: thanks. it's not perfect because it can't track the real apt lockfile (no permissions), but it tries hard to get it right
<ogra> hey dholbach 
<seb128> mvo: seems to work fine here
* mvo is happy
<kiko> pitti, that's what you get when blackhats supply your security fixes 
<Kamion> so who knows anything about mozilla-locale-{da,it,ptbr}?
<Kamion> looks like they need to be updated for new mozilla-browser
<Kamion> likewise mozilla-thunderbird-locale-nb
<pitti> kiko: the flaw is not in _my_ fix, but in upstream's :-)
<pitti> kiko: I just reviewed it before I applied it, the one I will release is correct :-)
<kiko> that's what I said! :)
<pitti> Kamion: I already asked and mailed elmo about it
<Kamion> elmo: xfree86-driver-fglrx and xfree86-driver-fglrx-dev should be demoted to multiverse, I think
<Kamion> since xfree86 is in universe
<pitti> Kamion: it's a matter of sync
<Kamion> pitti: ok, thanks
<Kamion> GNOME folks: shouldn't #7741 be the responsibility of the theme, or something?
<Kamion> and is there a better way to get that UTF-8 character than sticking UTF-8 characters in the source code?
<seb128> Kamion: http://bugzilla.ubuntu.com/show_bug.cgi?id=7714
<d3vic3> fabbione, ping 
<seb128> Kamion: I'm thinking to do that, but not sure if that's an issue for some fonts ...
<fabbione> d3vic3: pong
<d3vic3> fabbione, hdparm can it be uploaded ?
<Kamion> seb128: ok, shall I duplicate #7741 onto #7714 then? the font issues would be the same either way
<seb128> yep
<fabbione> d3vic3: it depends what are the changes
<Kamion> seb128: done, thanks
<seb128> np
<d3vic3> fabbione, Ubuntu #7829, pretty small change 
<ogra> crimsun around ?
<crimsun> ogra: pong
<ogra> yeah
<fabbione> d3vic3: yes. it sounds reasonable
<d3vic3> fabbione@ubuntu.com ?
<fabbione> yes
<d3vic3> incoming 
<ogra> crimsun, what do you think if we both sit down after release and wirte up a explanation how sound works (for dummies) on the wiki, people dont seem to understand it at all wich causes a lot of frustration
<crimsun> ogra: absolutely
<ogra> crimsun, great :-)
<crimsun> ogra: we'll discuss hardware->alsa->esd->gst->application, correct?
<ogra> yop
<crimsun> ok
<ogra> explaining the layer architecture and why its silly to switch from esd to alsa in ubuntu :)
<ogra> if they understand that they will not fuck it up (i hope)
* Kamion suddenly realises he forgot to turn the cdimage cron jobs back on
<ogra> oops
<Kamion> install CD builds for today running now
<dholbach> fabbione: shall i remind you of http://ubuntu.gplan.info/fuse/ today or tomorrow? :-)
<dholbach> fabbione: there's actually no haste, just wanted to inform you, like you requested :-)
<fabbione> dholbach: tomorrow is saturday :-) do you want me to free the dark side of the force from my wife?
<dholbach> fabbione: no... i'll ask on monday again ;-)
<fabbione> i am looking at it now
<dholbach> fabbione: don't want to unleash any domestic problems ;-)
<fabbione> ah but that's a brand new upstream version...
<dholbach> fabbione: it's needed for a newer python-fuse needed by gmailfs
<fabbione> amen
<seb128> pitti: here ?
<dholbach> dunno how gmailfs made it into the archive in the first place
<crimsun> gmailfs is uninstallable right now because of it
<dholbach> yes
<pitti> seb128: yep
* fabbione would really like to say that gmail is crap....
<dholbach> fabbione: i don't need it either
<seb128> pitti: do you know what version of the gnome-control-center mo file is in the language-pack-da ?
<crimsun> I don't have an acct myself, but I am supposed to transition it to python 2.4 ;-)
<dholbach> fabbione: but that's the unfortunate duty of a MOTU
<seb128> pitti: https://bugzilla.ubuntu.com/show_bug.cgi?id=7836, he's right, that's fine with my build and the langpack screw it
<tseng> dholbach: is gmailfs still have suid?
<fabbione> yes.. i am checking...
<pitti> seb128: it should be 1:2.10.0-0ubunu1
<pitti> seb128: s/unu/untu/
<tseng> dholbach: when it first came out a friend of mine reviewed it and was able to mount/remount anything as a normal user. id be interested to hear if thats still the case
<dholbach> tseng: i can't tell, crimsun is to blame, whatever gmailfs does wrong
<dholbach> ;-)
<crimsun> oh my
<crimsun> ;-P
<seb128> pitti: 
<seb128> -rw-r--r--  1 root root 58475 2005-03-08 02:45 /usr/share/locale/da/LC_MESSAGES/control-center-2.0.mo
<seb128> that's the 2.10.0 one
<seb128> -rw-r--r--  1 root root 60131 2005-03-10 15:13 /usr/share/locale-langpack/da/LC_MESSAGES/control-center-2.0.mo
<seb128> that's the langpack one
<dholbach> tseng, crimsun, fabbione: i consider gmailfs to be a hack of the category look-it-works--geeky-eh?
<fabbione> dholbach: checking now... i need sometime to be confident in it
<pitti> seb128: 
<dholbach> fabbione: take your time... it's not that urgent
<pitti> pitti@rookery:/srv/language-packs.ubuntu.com/sources-base/language-pack-da-base/data/da/LC_MESSAGES $ md5sum control-center-2.0.po
<pitti> e057b4b3abc9b3221d0bfe4ba7b81df0  control-center-2.0.po
<crimsun> fabbione: many thanks.
<pitti> seb128: indeed:
<pitti> $ grep -A 3 "Separate _group" control-center-2.0.po
<pitti> msgid "Separate _group for each window"
<pitti> msgstr ""
<seb128> $ grep -A 3 "Separate _group" da.po
<seb128> msgid "Separate _group for each window"
<seb128> msgstr "Separat _gruppe for hvert vindue"
<seb128> WTF ?
<pitti> seb128: this is from which version?
<seb128> control-center-2.10.0/po
<seb128> I've just apt-get source the current archive one
<seb128> 1:2.10.0-0ubuntu1
<pitti> seb128: langpack contains rookery:/home/lamont/public_html/translations/20050308/control-center_1:2.10.0-0ubuntu1_translations.tar.gz
<seb128> apt-get source on this version give a po/da.po with the translation
<seb128> and it works here with my non-stripped package before installing the langpack
<pitti> seb128: hmm, the tarball contains the translation. odd...
<seb128> should I reassing the bug to you ?
<pitti> seb128: yeah, please do
<seb128> thanks
<pitti> seb128: the tarball is correct
<seb128> I know :p
<seb128> apt-get source gives a po/da.po with the translation as said before
<seb128> so the source in the archive is correct
<pitti> seb128: argh, I know what's wrong
<seb128> are you sure you have this version in the language-pack ?
<pitti> seb128: the build accidentially used the version from 2.9.something
<seb128> ah ? what is it ?
<seb128> how ?
<pitti> seb128: my build scripts don't take epochs into account
<seb128> oh
<pitti> seb128: so it regarded 2.9 as newer than 2.10
<seb128> but the epoch is not new
<pitti> seb128: yeah, but somehow it was renamed s/1:2/1.2/
<pitti> seb128: was just an accident
<seb128> k
<pitti> seb128: I removed the broken tarball
<seb128> thanks
<seb128> jdub: dude, the bug is to close, the artwork part is #7715
<seb128> jdub: or dup it :)
<jdub> seb128: oh
<mvo> jdub: any news from the update-notification icon?
<seb128> an from the desktop files for g-a-i ? :)
<jdub> mvo: i hopefully have it in a tarball that arrived today - i will check :)
<jdub> seb128: had meeting today :|
<seb128> I can work on that if you want
<fabbione> dholbach: fuse looks good.
<dholbach> fabbione: rocking
<mvo> jdub: great, thanks
<dholbach> fabbione: thanks alot
<fabbione> no problem
<mjg59> Hrm. Why is ppp being odd?
<crimsun> fabbione: thanks!
<mjg59> It's not reading back any of the things it's expecting, but if I cat the modem node I can see the modem sending them back
<mjg59> And minicom seems very broken
<fabbione> i got the problem with minicom but i didn't bother to check it
<fabbione> since it's not the first time that does that
<medwards_> Should xvncviewer, xutils, and rsync suggest openssh-client, openssh-server, and openssh-client respectively instead of ssh?
<mjg59> If I do echo ATDT0845blah >/dev/modem, it dials and connects
<mjg59> If I try to use ppp, it doesn't read any of the stuff it expects
<mjg59> Hm. Nor does wvdial.
<mjg59> Something wrong here.
<fabbione> could it be related to the ppp security fix?
<mjg59> Dunno. Trying some debug now.
<fabbione> that would really make my day
<fabbione> btw.. it seems that the acpi change doesn't break the ABI
<mjg59> Cool
<crimsun> medwards_: xutils-> -server seems a bit odd, but I suppose to maintain the Suggests, both openssh-server and openssh-client would be present
<fabbione> no, it doesn't
<Kamion> medwards_: rsync for one might well want both
<Kamion> seeing as rsync runs at both client and server end
<thom> Kamion: did mdz tell you about the "fun" he was having trying to push kubuntu as a release?
<Kamion> medwards_: I'd prefer people to use the ssh-client and ssh-server virtual packages, unless they *really* need openssh in particular
<Kamion> thom: nope
<mjg59> fabbione: Can you add a patch to add ICH6 PCI ids to the intel8x0m driver?
<kiko> thom, what fun?
<Kamion> thom: I can imagine though - I generally end up hacking publish-release for nearly every release I do
<Kamion> thom: he said something worrying about md5sum mismatches?
<fabbione> mjg59: i think so...
<medwards_> point being, they all suggest the transitional package ssh.
<thom> Kamion: see query
<fabbione> mjg59: usual story.. send me the patch :-)
<fabbione> s/patch/Dpatch/
<medwards_> which depends on the openssh server+client.
<thom> and yeah, the amd64 preview iso in simple/.pool had changed a few hours before
<mjg59> Sent
<mjg59> How odd. Restarting slmodemd has fixed it.
<mjg59> So, uh, rock. Working modem.
<fabbione> mjg59: patch is ok..
<pitti> daniels: ping?
<medwards_> not exactly RC, I suppose.
<medwards_> And should I be compiling with g++ 3.3 or 3.4 when using cppunit and libboost?
<medwards_> hmm, nevermind ... those aren't in ubuntu.
<medwards_> But generally, are C++ libs in ubuntu compiled with one or the other or a mix?
<pitti> Kamion: time for an USN review?
<pitti> Kamion: s/^/do you have/
<Kamion> medwards_: ssh> yeah, I know
<Kamion> pitti: sure
<seb128> lamont: here ?
<medwards_> BTW, it's really nice to start dselect on a livecd and not have to undo 50 defaults before I can do anything useful.
<doko> medwards_: g++ 3.3, 3.4 has an incompatible ABI.
<seb128> lamont: if you are around just wondering about the gst-plugins0.8 build
<medwards_> doko: right.  I'm hoping that linking against shared libraries written in C doesn't create problems, and that hoary is systematically compiled with one or the other.
<Kamion> yes, we haven't switched C++ ABI in hoary or anything
<medwards_> g++ 3.4 is in for bootstrapping breezy?
<Kamion> Debian has g++ 3.4 too
<Kamion> as did warty
<Kamion>    g++-3.4 |    3.4.3-6 |       testing | i386, powerpc
<Kamion>    g++-3.4 |   3.4.3-12 |      unstable | i386, powerpc
<Kamion>    g++-3.4 | 3.4.2-2ubuntu1 |         warty | amd64, i386, powerpc
<Kamion>    g++-3.4 | 3.4.3-9ubuntu3 |         hoary | amd64, i386, powerpc
<trukulo> xfree86 4.5 released, just to inform (is not really important as we use xorg)
<medwards_> check.  b-d on g++ still gets 3.3 though, right?
<Kamion> yes
<Kamion> g++ defines the default
<Kamion> when we switch to 3.4/4.0/whatever we'll have to go around changing C++ library package names
<Kamion> Debian's done this before so the path is well-trodden, if long
<medwards_> So is there another c102-like agony in our near future?
<Kamion> at some point we'll have to have c103 I believe
<medwards_> any reason modutils isn't on the livecd?
<medwards_> 2.4 kernels only, I suppose.
<jdub> seb128: does red hat use krb5 or heimdal?
<crimsun> it's not needed for 2.6
<doko> medwards_: no, a c1003 agony ;)
<seb128> jdub: I've no idea, why ?
<medwards_> crimsun: just beat you to it.  :)
<Kamion> smurfix: kbd-chooser 1.09ubuntu9 has BitKeeper metadata in it again
<jdub> seb128: worth knowing considering our choice ;)
<Kamion> smurfix: reviewing debdiff between source packages before uploading is a good way to avoid that, I find
<seb128> jdub: <jpr> suse uses heimdal
<seb128> <jpr> evo should work with either
<seb128> <seb128> do you know for redhat ?
<seb128> <jpr> mit
<seb128> jdub: that's it
<jdub> "hmm" :)
<seb128> what ?
<seb128> we have the issue than kde/firefox/... use krb5, and openoffice.org2 use kde and evo and BOOM
<seb128> and according to jbailey krb5 is nice :)
<medwards_> doko: just for kicks, I'll try to massage cppunit to generate a c103 binary.
<thom> anyone see any reason not to remove powernowd from ia64 seeds? 
<medwards_> I see the hoary livecd contains perl but not python-2.3.  :-/
<jbailey> seb128: =)
<Kamion> medwards_: it'll have python2.4
<seb128> hey jbailey :)
<crimsun> medwards_: python2.4 please
<medwards_> optimists, are we?
<doko> optimists look for python 2.4.1 :)
<crimsun> 2.4.1a0. c'mon doko, you're slackin'! ;-P
<medwards_> I really ought to get around to cleaning up my multithreaded hotspot profiler hack and pitching it upstream.
<doko> crimsun: 2.4.1 release candidate 2
<medwards_> s/hotspot/hotshot/
<fabbione> thom: i am not completely sure that 7788 is kernel...
<medwards_> I was hoping to finish the thread-aware time sampling first (gettimeofday bites)
<pitti> Keybuk, Kamion: dpkg doesn't use debhelper, so it wasn't stripped. any objection against an upload which adds pkgstriptranslations to debian/rules?
<pitti> Kamion: same for coreutils (4.3 MB worth of translations), and sooner or later we have to fork the package anyway for pkgstriptranslations
<thom> fabbione: ah, no, it's not
<fabbione> thom: ok :-)
<Kamion> pitti: note that stripping dpkg means losing translations of stuff displayed to the user while doing the second stage install, since we don't have the ability to put a progress bar over the top of that yet
<Kamion> coreutils is probably ok
<pitti> Kamion: hmm, right
<pitti> Kamion: so we defer dpkg, but I can do coreutils?
<Kamion> I'd love to fix that but I just haven't quite managed to convince debconf's newt frontend into displaying progress bars yet
<Kamion> pitti: yeah, think so
<pitti> ok
<pitti> Kamion: oh, coreutils does use debhelper, so it's a no-change upload (-0ubuntu0)
<Kamion> ok
<pitti> Kamion: btw, I compiled a list of unstripped packages sorted by translation size here: http://people.ubuntu.com/~pitti/unstripped-hoary-main.txt
<pitti> Kamion: mdz agreed to do uploads for the biggest couple of packages which are shipped on CD
<Kamion> he agreed to do them, or he agreed to them being done? :)
<pitti> Kamion: the latter :-)
<pitti> "I think we could get a majority of the benefit by rebuilding these packages:"
<fabbione> yay for doko and ooo
<fabbione> doko: sparc hates you
<Kamion> pitti: I'd appreciate iso-codes staying unstripped please
<pitti> Kamion: of course
<Keybuk> pitti: for now, I'd keep the dpkg ones -- it's kinda a very core component; but then I guess we've stripped the apt ones?
<pitti> Kamion: this one should even be blacklisted
<Kamion> pitti: definitely
<pitti> Keybuk: yeah, we already agreed to defer this until we have nice progress bars on installation :-)
<Kamion> half the point of iso-codes is to provide those translations, and it appears in build-dependencies of packages that use the translations in their build processes
<medwards_> gnome-terminal line wrapping is b0rked.
<medwards_> (on array-7)
<medwards_> Most likely to be gnome-terminal, readline, or bash, I wonder?  Or maybe termtype?
<doko> fabbione: did ooo build on sparc/hoary before?
<fabbione> doko: yes. always
<fabbione> and it keeps building
<medwards_> OK, only happens when the previous cmd's stdout doesn't end in newline, resulting in misplaced prompt.  bash, probably.
<doko> hmm, powerpc failed :(
<fabbione> ask lamont to kick it back
<fabbione> ppc sometimes dies for no reasons
<doko> ok
<Kamion> uh, maybe check why it died first?
<fabbione> [   ]  openoffice.org-bin_1.1.3-2.3ubuntu9_sparc.deb 
<fabbione> Kamion: that too
<doko> Making: ../unxlngppc.pro/slb/set.lib
<doko> nm: 'Illegal': No such file
<doko> nm: 'instruction': No such file
<fabbione> but i was already doing it
<Kamion> right, sounds like the usual powerpc thing then
<fabbione> yup
<mjg59> Hrm. Is someone able to add a patch to i810switch?
<mjg59> (It's in universe)
<crimsun> sure, what does it need to do?
<dholbach> mjg59: i can apply the patch and upload it for you, but i 1) most likely won't understand, what it is about, 2) can't even test it with my amd64
<mjg59> http://www.codon.org.uk/~mjg59/tmp/i810switch.diff
<mjg59> It just adds an extra PCI ID
<medwards_> hmm.  mount did not auto-detect that /dev/hda4 contained an ext3 fs.
<dholbach> crimsun: shall i? do you want to?
<medwards_> mounted it as ext2.  wonder what I have to do to fix that.
<crimsun> dholbach: I'm kinda busy atm, so if you don't mind, you can take it
<dholbach> crimsun: right
<crimsun> thanks
<zul> mornin
<dholbach> hi zul
<zul> hey dholbach 
<pitti> Kamion: re m-thunderbird-locale-nb, I removed it from l-support-nb long ago, but this needs to be demoted to universe (or removed)
<pitti> Kamion: it's not seeded and nothing depends on it 
<Kamion> pitti: ok
<medwards_> oy.  apt-get build-dep wants to pull in build-essential, including g++ 3.3.  And cppunit wants libqt3-mt-dev and hence libqt3c102-mt.  Don't think I'll be charging on to c103 right now.
<Kamion> er, yeah, naturally current build-deps are c102ish
<Kamion> and you can't start a C++ transition with packages high up in the dependency graph; you need to start from the bottom
<medwards_> Kamion: yes, I've modified build-essential before to get the g++ I wanted in a pbuilder run.
<medwards_> Kamion: I didn't expect cppunit to build-depend on Qt.
<Kamion> http://lists.debian.org/debian-devel-announce/2003/01/msg00002.html
<medwards_> (I don't generally run the GUI front end, which winds up in a separate binary package)
<Kamion> anyway it's not like going through the transition buys you much
<Kamion> from your POV anyway
<medwards_> right, I was actually thinking of sneaking a g++ 3.4 build of this ugly bugger through the day job's QA system as a compiler test.  :-)
<medwards_> ("this ugly bugger" being a very thread-intensive network management client/server app)
<medwards_> Kamion: I will still do a c103 build, but I'm going to have to cut the Qt out of the cppunit build first, so it'll wait until the next cycle.
<ogra> amu, Riddell, haggai, just had a look at kubuntu, its marvelous, really rocking (no, i wont switch ;) )
<haggai> ogra: aw, switch switch switch :)
<jdub> ogra: where is your national pride? :)
<amu> ogra: hehehe
<ogra> *g*
<amu> we'll see :)
<medwards_> (cppunit is otherwise on the bottom of the graph, and boost is a template library)
<medwards_> OTOH, I might jump straight to g++-4.0, if it's even remotely stable.
<ogra> one thing btw, how am i supposed to unlock the screen after i lockaed it ?
<ogra> -a
<thom> oh, man. FUCK YOU VERY MUCH, FIREFOX
<Treenaks> thom: what happen?
<amu> ogra: the kubuntu one ? 
<ogra> yep
<thom> i can reproduce #7552 with my french test user, but not with my english main user
<ogra> amu, is there a password ? 
<amu> ogra: it could be a bug, nice testcase 
<thom> i do hope this is not a locales bug
<thom> if it is i shall cry
<amu> ogra: there's no pass, try ubuntu/ubuntu
<ogra> amu, tried, didnt work
<ogra> amu, but it might occur in the gnome version as well, just rsyncing my ubuntu live image
<amu> how you locked your screen? from menu?
<ogra> yep
<ogra> lock session
<pitti> ogra: now that you say it, I remember seeing this bug, too
<amu> ogra: could you add a bug
<ogra> pitti, ku- or ubuntu ?
<pitti> ogra: !k
<ogra> ok
<pitti> ogra: normal gnome ubuntu
<ogra> so it occurs in both 
<pitti> ogra: yeah, why not?
<pitti> ogra: the ubuntu user does not have a password
<ogra> dunno
<pitti> ogra: but screensaver does not accept an empty password
<ogra> but then screenlocking should be disabled completely....
<ogra> since it doesnt make much sense to lock yourself out completely ;) 
<ogra> hey, dholbach gets famous :) http://lwn.net/Articles/125666/
<amu> ogra: right but how you'll do it, till it's the same packagebase? 
<ogra> amu, disable screenlocking in the package for the live seed would be a guess.....
<ogra> s/seed/seeds
<jdub> dholbach: that's an awesome report, too :-)
<jdub> dholbach: that should totally go to ubuntu-news :)
<ogra> funny that lwn needed 17 days to put it up :)
<amu> ogra: apt-cache rdepends xscreensaver
<dholbach> jdub: i plan doing it every month, to let everyone FEEL the motu love :-)
<ogra> yeah
<ogra> amu, i see...
<amu> ogra: a userfriendly solution could be checking if we are on a liveCD, before locking the screen, than ask for a userpass
<ogra> yeah
<ogra> great idea
<amu> hmm dialog isnt install by default  
<zul> eww...dialog
<amu> zul: ok, kdialog :) 
<ogra> amu, #7843
<zul> oh thats better
<amu> ogra: could be, modify the desktop file and run a script which checks if we are on a livesys, if yes, (k)dialog ask user to set a password, if we are on a real sys nothing happens. Is there something wrong with it?   
<ogra> amu, sounds ok....
<amu> ignoring this by default, educate people to set a password, is another solution
<ogra> amu, you mean setting one before session ? (i.e. on bootup)
<amu> ogra: yep, this would be a saver, faster, cleaner, better way 
<Kamion> the password is disabled nowadays, AFAIK
<Kamion> so it's easier than that: just check whether the password is disabled, rather than having to check if you're on a live CD
<amu> Kamion: see orga's bug, it looks not. Oh yes, that would be easier.     
<doko> d3vic3: ping?
<ogra> Kamion, but setting one right before locking would be a pretty cool faeture, else you cant lock at all if you are on the live CD
<Kamion> ogra: sure, I don't see where I disagreed with that?
<Kamion> ogra: I was *agreeing* with you
<ogra> :)
<pitti> Keybuk: here?
<Keybuk> yup
<Kamion> do i386/amd64 installations with JFS / fail for anyone here?
<Kamion> (#7666, can't reproduce)
<thom> Kamion: yeah, it did for me with preview; i can try again now
<thom> well, nowish
<thom> seb128: about? 
<seb128> yep ?
<Kamion> thom: thanks
<Kamion> could be a race or something
<thom> seb128: help?! #7552 seems to be blowing up in gtkfilechooserdefault.c; but i dunno why
<seb128> is that the firefox download stuff ?
* seb128 opens bugzilla
<seb128> oh, no, a different one :)
<Kamion> hmm, interesting idea, time zero-question kickstart installations with each of the major filesystems
<seb128> thom: http://bugzilla.gnome.org/show_bug.cgi?id=170755 has the same bt
<thom> yeah, that looks identical
<seb128> iz gtk boog
<d3vic3> doko, pong 
<seb128> :(
<thom> hm, fun
<thom> seb128: care to add yourself to the cc list?
<pitti> jdub: it seems that I'm the moderator of ubuntu-hardened
<pitti> jdub: however, I never received a moderator password
<pitti> jdub: can you please gpg-mail it to me?
<seb128> thom: yep, I'll probably reassign to gtk
<thom> ok
<thom> i'll see if i can blame the download problem on gtk too :-)
<pitti> thom: which download problem?
<thom> pitti: 7711
<smurfix> Kamion: Bleh. Forgot. Again. :-( You may give me the evil eye in Sydney.
<jordi> morning
<jordi> well
<jordi> for me
<thom> jordi: even spain is usually not this slack!
<Kamion> smurfix: heh. :) was trying to track down that debian-installer/keymap thing by debdiff ...
<jordi> thom: shuddup, this hangover is not fun at all :)
<thom> jordi: over enthusiastic St Patrick's Day partying? :P
<medwards_> never seen this before:  "Package expat is not available, but is referred to by another package. ..."
<jordi> thom: I never drink rum, whisky or shit like that, but yesterday I had a bit
<jordi> + the usual beers and wine
<jordi> thom: nope, it was during the Alternative Falles celebration. We burnt our falla two days early. :)
<medwards_> expat seems to be in universe, but some package in main must refer to it in some way.  Probably libexpat1, which seems to be in main and built from the expat source.
<dholbach> ok... i'm off - see you later
<medwards_> I'm a little surprised to find debian packages in ubuntu main that don't seem to have been recompiled (libexpat1, for one).
<thom> they'll all have been recompiled; if they have debian version numbers it means we've not modified them
<jdub> medwards_: everything is rebuilt
<medwards_> jdub: without any indication in the changelog?
<jdub> medwards_: that's right
<jdub> medwards_: everything in every repository is rebuilt
<medwards_> jdub: that's certainly a good thing.  :)
<medwards_> jdub: but it makes it a little trickier for the debian maintainer if bug reports come in against a package that ubuntu rebuilt.  How does that interact with binary NMUs?
<Nafallo> is it just me or is cdimage.u.c slow as hell today?
<medwards_> hmm, looks like reportbug would send a report to ubuntu-users instead of the debian maintainer.
<Nafallo> medwards_: good then :-)
<medwards_> but I assume that's a feature of ubuntu's reportbug.  If debian users start adding ubuntu to their sources.list, some odd things may happen.
<Nafallo> medwards_: therefore that action isn't supported AFAIK :-).
<medwards_> I try to add a changelog entry even when just rebuilding locally, to avoid bug reports going to the wrong place.  I'm envisioning a situation where I have, say, ubuntu's libexpat1 but debian's expat, same version number, dep skew.  How will I even know?
<kiko> so
<kiko> doko?
<doko> doko: kiko!
<medwards_> Maybe reportbug should add the md5sum of the md5sums file for each package in the depends.  :-/
<kiko> doko@
<kiko> ack
<kiko> doko!
<doko> kiko?
<kiko> doko, we're getting reports on #lp-dev of SRE.py conflicting in the latest hoary apt-get update
<kiko> doko, I can get you a traceback if that's helpful -- has any important python module or package changed from yesterday to today?
<doko> not that I am aware of. which package is SRE.py in?
<kiko> it's part of standard python
<doko> ahh, sre.py ...
<kiko> and SRE is a module with symbols, IIRC
<kiko> I'll get you the traceback, or rather, carlos will in a minute
<doko> ok, I'll have a look then
<kiko> doko, http://www.rafb.net/paste/results/BlrELh33.html
<doko> hmm, interesting. maybe throwing away the compiled modules helps? 
<kiko> carlos, ping?
<carlos> kiko: pong
<carlos> doing it
<carlos> ohh, to remove compiled modules?
<carlos> doko: should I remove all .pyc?
<kiko> carlos, doko: can you guys coordinate the fix? I need to take a call
<jordi> kiko!
<kiko> hombre!
<jordi> hombre!
<jordi> qu pasa!
<kiko> qu, mucho trabajo carajo
* Nafallo would guess that cdimage.u.c doesn't feel very good atm ;-)
<doko> maybe first try to see, which pyc files are wrong: magic = string.join(["\\x%.2x" % ord(c) for c in imp.get_magic()] ,"")
<doko> these should be the first bytes in the .pyc file.
<jordi> kiko: dude I haven't been training at all.
<jordi> kiko: I've run 3 times since we last met.
<carlos> doko: sorry, I did the removal already ...
<carlos> doko: I'm too fast :-(
<kiko> jordi, I've run dozens of times, jesus, you need to get there
<kiko> doko, carlos: could it not be a pythonpath issue? I suggested running a -v
<lamont> morning
<pitti> Hi lamont
<jordi> kiko: I think my motivation is coming back more or less.
<Nafallo> lamont: hi there :-)
<jordi> I hope I'll be back soon.
<carlos> jordi: is Belen your motivation's name?
<doko> kiko: yes, I assume .pyc files mixed from 2.3 and 2.4 were found.
* carlos hides
<jordi> carlos: no
<carlos> doko: same problem after .pyc removal
<kiko> jordi, plan to run a marathon in this semester, and train for it
<jordi> carlos: team mates doing competitions and I only seeing the results in webpages mostly.
<kiko> agh
<jordi> kiko: nah, marathons are way too much. half, maybe.
<jordi> not a full one
<jordi> kiko: I want to prepare the olympic triathlons decently.
<carlos> bored people...
<carlos> :-)
<Kamion> medwards_: in practice that's not been a problem; we're building off the same base so we haven't experienced dep skew in anything that matters
<Kamion> medwards_: we warn VERY VERY CLEARLY not to mix the Debian and Ubuntu repositories; it confuses apt
<smurfix> Hoboy. Trying to burn the PowerPC hoary live-cd from OS X crashes Apple's Disk Utility program.
<medwards_> Kamion: OK, was just puzzled by libexpat1 in main and expat in universe.
<Kamion> medwards_: I imagine libexpat1 was needed by something in main and expat wasn't, then
<Kamion> smurfix: well-known bug in Apple's hdiutil
* smurfix grumbles
<Kamion> smurfix: I've had both a success report and a failure report with one recent version of Mac OS X, so it doesn't appear to be entirely consistent
<Kamion> but clearly a segfault on any input data must be a bug in the software, not the data :)
<smurfix> Kamion: Maybe it'd help not to have a slash in the volume name ..?
<Kamion> smurfix: does it help if you change that?
<pitti> meh, wrong key
<Kamion> smurfix: um - what slash?
<Kamion> Volume id: Ubuntu 5.04 ppc Bin-1
<smurfix> Kamion: I don't know yet, the ibook managed not to boot from the latest livecd I burned (may be CD drive problems)
<smurfix> Kamion: Mounting the current image says "Ubuntu/PowerPC_hoary" as the volume name
<Kamion> ah, the hfs-volid
<medwards_> Kamion: expat pkg consists of one program, xmlwf, 19K in size.  All of the bugs reported against it in debbugs are actually libexpat1 bugs, except one that is probably python.  :)
<Kamion> medwards_: nevertheless we only put stuff in main if we need it to be in main
<medwards_> Kamion: sure, I just found the results of inspecting the BTS amusing.
<Kamion> smurfix: would be surprising though; I'd've thought that : would be more of a problem than / on Macs
<Kamion> smurfix: there's only one occurrence of "Ubuntu/PowerPC_hoary" in the binary, though, so you could hex-edit it to something else and try :)
<Kamion> smurfix: hm, actually, no, there are quite a few towards the end. Want me to do you a CD with a different volume id?
<zul> mjg59: ping 
<medwards_> Last upload that fixed an expat bug was on 2003-03-17.  Might be worth at least touching up the BTS, and maybe actually updating to the might-be-expat-2.0 snapshot from January and looking over upstream's BTS.  Too late for hoary but perhaps not for sarge.
<lamont> jdub: did you care that flumotion is ftbfs?
<lamont> configure: error: No suitable version of python found
<lamont> but it valiantly tried 2.2 all the way down to 1.5 :-)
<lamont> and hoary-test gets it's _FIRST_WINNER_!!!!  and the winner iiiiiiissss.......
<lamont> graphviz
<seb128> lamont, fix gst-plugins0.8
<seb128> I want to give it some testing before hoary
<lamont> seb128: _I_ can't...
<seb128> need elmo ?
<lamont> elmo: seb needs the build-deps for gst-plugins0.8 promoted to main....
<lamont> seb128: yeah, is archive issue
<seb128> usually that works fine, somebody automatically handles such issues :)
<seb128> but right
<lamont> seb128: probably best thing to do is send elmo email, cc jdub/mdz requesting the promotion.  then jdub/mdz can ack it, and elmo has his history trail;
<seb128> right
* smurfix was off chasing his kids
<smurfix> Kamion: Please do
<smurfix> Kamion: Place it somewhere rsync'able if possible
<mdz> morning
<zul> morning mdz
<mvo> hey mdz 
<seb128> hey mdz 
<kiko> morning mdz 
<seb128> hey kiko
<kiko> hey seb128, how are you
<seb128> kiko: fine, and you ?
<Kamion> smurfix: I'm just doing a new daily install CD build, that's simplest
<sivang> kiko dude ! :)
<kiko> seb128, overworked but happy
<kiko> hey sivan!
<lamont> morning mdz
<mvo> Kamion: will that fix the keyboard issue?
<Kamion> mvo: not yet
<Kamion> mvo: this is to see if changing the volume label stops Disk Utility crashing
<mvo> Kamion: ok
<mvo> Kamion: just wanted to know if it's worth rsyncing it for testing :)
<smurfix> Dear Apple, please let my poor old ibook boot from usb, KTHXBYE
<pitti> smurfix: that's probably a matter of yaboot extension, isn't it?
<lamont> mdz: what severity do you want the hoary-test ftbfs's to go at?
<lamont> major or crit?
<smurfix> pitti: That's a matter of extending Apple's OpenFirmware
<mdz> lamont: critical at this stage
<pitti> Morning mdz
<thom> morning mdz
<mdz> seb128: my panel has been crashing every night while I am asleep
<mdz> seb128: the bt looks the same as the one I submitted to bugzilla
* thom had forgotten how long firefox takes to build with no ccache love
<mdz> there is an Error dialog which comes up at the same time, but no text is displayed in it as the process is stopped
<mdz> seb128: is there any information I can collect besides the bt?
<Kamion> smurfix: the instructions in the d-i manual don't help?
<seb128> good question ... I don't really have an idea on the crash and the backtrace is weird. I'll ping one of the gnome-panel upstream to know if he has some ideas and let you know
<haggai> guys how to undelete a wiki page?  Someone just deleted Kubuntu
<Kamion> still seems to be there?
<Kamion> oh, maybe not
<haggai> did someone just fix it?
<apokryphos> Perhaps deletions doesn't come up under the Recent Changes
<Kamion> history shows an all-caps rant about how Kubuntu shouldn't be a separate distribution
<haggai> Kamion: yup, followed by a delete
<Kamion> ok, bored of bugs about groff hyphens in UTF-8, I give up and will change that to render as ASCII 0x2D
<lamont> Kamion: that's using the old sledge hammer!
<seb128> somebody is using a ppp (RTC) internet access here ?
<lamont> seb128: I _could_ be, if you need me to
<lamont> RTC?
<seb128> mvo: you have a standard ppp or isdn ?
<seb128> lamont: hum, is that french ? a modem access like using the modem applet (or kppp), that's because of #7677 in fact
<lamont> ah, ok.
* lamont just uses pon - guess I could try using the gui to kick it.
<lamont> want I should grab the laptop?
<seb128> I know that mvo has worked on some modem stuff
<seb128> let's wait if he has an idea first
<lamont> ok
<seb128> I'll ping you if he doesn't, thanks
<lamont> np
<mvo> seb128: modem stuff? 
<seb128> mvo: #7677
<mvo> seb128: looking, thanks
* mvo grumbles about my slow net
<seb128> mvo: I don't know, you have looked on some applets/ppp bugs, haven't you ?
<seb128> or that's only for isdn ?
<mvo> seb128: yes, I did quite a bit of debugging in this area, modem/ppp too
* seb128 has a dsl modem, not easy for such bugs :p
<mvo> seb128: but it's horrible as all the backend stuff is written in perl
<seb128> :(
* mvo kicks his internet connection
<seb128> bah don't, that's useful :)
<thom> bah, firefox 1.1 renderer is *so* much better than 1.0
<thom> i wish they were on a release schedule useful to us
<mvo> seb128: I'll have a look
<seb128> mvo: thanks
<seb128> thom: what is the schedule for 1.1 ?
<thom> PR comes out about the same time hoary does
<seb128> they have 6 months between versions too ?
<smurfix> Number of screws to unscrew to replace an iBook hard disk: 35
<HiddenWolf> seb128: the way mozilla has been going, they have a roadmap they don't keep to. Too few developers.
<smurfix> Tune in next installment for anaccount of how many are left lying around afterwards
<wasabi_> you needa  p-p-p-powerbook
<smurfix> wasabi: it's an old one, and for some reason was slightly cheaper than a big chunk of titanium
<smurfix> The cutesy first-gen ibooks are *much* worse than that.
<wasabi_> I have an iBook2. One of the white ones.
<wasabi_> http://www.p-p-p-powerbook.com/
<lamont> smurfix: sounds like you need an extension cable for the hdd - then you could just keep it external. :-)
<mjg59> Are there instructions on building a lightly customised CD image?
<pitti> doko: regarding the OO.o bibliography bug on ppc, what shall I check?
<doko> pitti: if it crashes or not, as mentioned in the report
<pitti> doko: oh, it still crashes, as it does for ages now
<doko> which version?
<sivang> doko: have you uploaded the fixed oowrite version as per #7803 ?
<pitti> doko: just posted a bug followup
<pitti> doko: 1.1.3-2.3ubuntu9
<amu> mjg59: a livesys i guess? 
<doko> pitti: that's the old one
<pitti> doko: I don't have a newer one
<mjg59> amu: No, install
<pitti> doko: a new version from today?
<doko> pitti: yes, it needs building on powerpc ...
<pitti> oh :-)
<pitti> doko: no newer version on http://patches.ubuntu.com/~lamont/buildLogs/o/openoffice.org/ either
<doko> pitti: I know
<pitti> doko: okay, I check when it is available
<lamont> openoffice.org:         07:53:47 (6 entries, sigma 02:04:27)
<lamont> and we're 2.5 hours into the build
<amu> mjg59: saw some of them in d-i, probably the best if you ask Kamion
<lamont> "today" may be a bit overagressive, given your tz
<pitti> lamont: btw, is this sigma information available for other people than you? 
<pitti> lamont: it would be interesting for security builds
<Kamion> mjg59: not yet AFAIK, it's on my to-do list to write some
<lamont> pitti: it's not even shared between the buildd machines for a given architecture
<pitti> lamont: okay
<mjg59> Kamion: Ah, ok - I probably need to hack one up next week
<doko> sving: it's built, but maybe not yet in the archive
<mjg59> (A cd, that is, not the docs)
<doko> sivang: it's built, but maybe not yet in the archive
<sivang> doko: ok
<pitti> sivang: how far is your patch?
<pitti> sivang: I have a fixed g-c-m pending, but I would like to avoid uploading twice
<pitti> sivang: (I fixed another bug)
<sivang> pitti: I see, which bug? I'm actually preparing source packages and a debdiff for you to view
<sivang> pitti: (done with coding)
<pitti> sivang: #7842
<sivang> pitti: (and translations)
<Kamion> mjg59: I'll try; I just keep getting snowed under every time it nears the top of the pile :(
<pitti> sivang: it'd be nice to finish that today
<sivang> pitti: I'm done actually, just preparing stuff for your to review...
<pitti> sivang: I just need the debdiff
<sivang> pitti: k
<sivang> pitti: in about 5 minutes
<Mitario> hi everyone
<pitti> Hi Mitario 
<sivang> hey Mitario 
<pitti> sivang: I have to leave in half an hour; shall we do this at Monday?
<sivang> pitti: nrealy done, 1 minute :)
<pitti> ok :-)
<lamont> Kamion: what is a '10' from debconf again?
<sivang> pitti: debdiff online, same location
<lamont> mvo: you around?
<lamont> Setting up fontconfig (2.2.3-4ubuntu5) ...
<lamont> dpkg: error processing fontconfig (--configure):
<lamont>  subprocess post-installation script returned error exit status 10
<sivang> pitti: packages refreshed as well
<sivang> pitti: (on my /g-c-m/ folder in muse)
<pitti> sivang: already downloaded, inspecting now
<pitti> sivang: did you chagne any code?
<pitti> change, even
<pitti> sivang: I fixed the indentation, btw
<Kamion> lamont:         badparams => 10,
<sivang> pitti: ah ok, thanks , you edited the patch inline?
<Kamion> lamont: try DEBCONF_DEBUG=developer
<sivang> pitti: I didn't change any code
<lamont> that fits with things.
<pitti> sivang: yes
<lamont> Kamion: cool
<sivang> pitti: just hardcoded messages as you wanted for the sudo message
<sivang> pitti: (this were the only modifications I did for the code)
<lamont> Kamion: that gave me what I need for the bug.
<Kamion> good stuff
* lamont may even work on a fix
* netjoined: irc.freenode.net -> niven.freenode.net
<Kamion> lamont: don't get too radical, now
<sivang> pitti: let me know the verdict :-)
<pitti> sivang: oh, patch is nice, I'm adding the .de translations right now
<Mitario> mvo, ping?
<sivang> pitti: phew finally..:)
<doko> sivang: the OOo build is in the archives
<lamont> Kamion: all it needed was an || RET=false :-)
<sivang> doko: ok, I'm eager to test :)
<lamont> Mithrandir: you arouhd?
<lamont> dh_testdir
<lamont> /bin/bash: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory
* lamont stares at amd64
<sivang> doko: in incoming?
<sivang> doko: (I am using the .de mirror, hasn't hit it yet)
<lamont> mdz: I wonder if elmo is waiting for an ack on the sgml2x sync...
<seb128> Kamion: is there a place with the files to translate for the installer ? Some screen have no french version and I want to translate them
* lamont finds a defoma bug next
<seb128> pitti: here ?
<pitti> seb128: yeah
<seb128> I would like to get libshout in main (build requirement for gst-plugins0.8)
<seb128> according to mdz "Given a supportability review from Martin, yes."
<seb128> so if you can put that on your todolist ... :)
<pitti> seb128: I'm taking a look at it ASAP
<seb128> thanks
<seb128> atm gst-plugins0.8 ftbfs
<seb128> there is no real hurry but still good to fix the ftbfs
<pitti> seb128: it's ftbfs because of the missing lib in main?
<seb128> correct
* mvo is away to play some hockey
<mvo> bbl
<Kamion> seb128: http://people.ubuntu.com/~cjwatson/installer-po/ (may be missing some messages, I need to check it)
<pitti> seb128: this thing does not actually contain any mp3 codec stuff?
<seb128> pitti: I don't think it does the codec, rather the streaming part
<pitti> seb128: do you think #219027 will affect us?
<pitti> seb128: (not compiled thread-safe)
<seb128> pitti: not sure, I can check if you want
<pitti> seb128: otherwise, packaging, debs and bugs are fine for me
<seb128> nice, thanks
<pitti> seb128: it's a network-related app, so it is security sensitive somewhat
<pitti> seb128: I didn't do a source audit :-), but I did not audit KDE either :-)
<seb128> if you are not cumfortable with it I can drop this part of the gst-plugins0.8 build
<pitti> seb128: oh no, just go ahead
<seb128> thanks
<pitti> seb128: however, can you please check the thread bug?
<seb128> I'm looking the hoary build logs
<seb128> checking for the pthreads library -lpthreads... no
<seb128> checking whether pthreads work without any flags... no
<seb128> hum
* seb128 builds it
<seb128> Kamion: thanks for the po files
<pitti> bye folks, gotta go now
<Mitario> brb testing preview
<robertj> If you have refresh rates that work when the autoprobed rates don't, is there some place that info should go so it can be auto-detected for other people?
<dholbach> hello
<zul> hey dholbach 
<dholbach> hi zul 
<_d4vid> hi all
<medwards_> speaking of autoprobed graphics, any way to get 1920x1200 on this Dell M60?  (screen=1920x1200 works on knoppix)
* robertj prods ogra
<Treenaks> 1920x1200? is that 17" (I hope so)
* ogra falls over
<ogra> robertj, hey
<robertj> heya
<ogra> whatsup ?
<robertj> Is there a database for monitor refresh rates for stuff that can't be autoprobed?
<robertj> Or more particularly, i've got a monitor that seemed to probe fine but gave me a black screen until I googled up some better refresh rates
<ogra> heh, not yet, currently my inbox is the collection place
<robertj> hehe
<robertj> any plans on that front?
<ogra> yup
<robertj> Wiki page ?
<ogra> thats what hwdb is for, but the recieving part is not in place yet
<dholbach> php-site, hm? :-)
* robertj is a php guy
<robertj> (btw, check out http://l3ktr0n.homeip.net if you like muds and dhtml ;)
<ogra> robertj, first of all we will need the DB and the data recieving part in place, then we can build a website or something
<robertj> oh, I get you
<robertj> I totally forgot that the hardware utility had a mechanism for reporting back, or at least the beginnings of one
<ogra> but currently i focus on getting the data and converting it to something ueseful
<ogra> yup, it should hand you a token after the transfer, so you can look up your own data and point someon who wants to support you there
<robertj> I think its particularly nasty how this monitor responded to a probe it didn't support
<robertj> How do ADC monitors play well with others?
<dholbach> hey Micksa 
<dholbach> oops
<dholbach> hey Mitario  :-)
<Mitario> thanks, hi ;-)
<dholbach> how are you?
<Mitario> yeah fine :) you?
<dholbach> a bit tired, but a black tea will do the trick, i guess :-)
<dholbach> so fine myself, thanks
<Mitario> hehe ok, nice :-)
<medwards_> Treenaks: wide laptop screen.  (And sorry; that question probably belonged on #ubuntu.)
<Treenaks> medwards_: yes, but 17" I hope? I'm going to buy a 1680x1050 one and I think it has VERY tiny pixels already
* medwards_ measures: 15 1/2" or so
<medwards_> and yest, they are very tiny pixels.
<Treenaks> I'll stick to the 1680 one :)
<medwards_> I often use teeny-weeny-eyestrain-o-vision text anyway; so it makes for smoother eyestrain.
<Treenaks> medwards_: LOL
<Treenaks> I like the ultra-highres-ness of my Palm
<Treenaks> I have a few apps that use absolutely microscopic fonts
<medwards_> The M60 seems to get 1600x1200 in array-7 (black stripes left and right) and the default font is just about right.
<medwards_> However, it appears just to have locked up hard.  Bugger.
<Treenaks> hm, not too promising
<medwards_> and things were going so well ...
<mroth> medwards_: do you know what the video hardware is on it?
<medwards_> NVidia Go700, I think
<Treenaks> I'm looking at an OEM version of this one: http://www.uniwill.com/products/performance/259ia3/259ia.php?HL=1&P=1
<medwards_> Probably an OOM.  Totally wedged it, though.
<medwards_> (I was pushing my luck with apt-get and casper.)
<lamont> mdz: question of priorities...
<mdz> lamont: shoot
<lamont> there are 34 packages (main and universe - didn't do that breakdown) that will fail to remove if defoma happens to be removed before them (the Depend: defoma)...  The fix is a no-change NMU
<lamont> how much do we care at this point?
<lamont> (basically, all the font family of packages...)
<lamont> fontconfig needed it, will upload that in a second.
<lamont> actually, the fix is to bump the build-depends: defoma to the right version
<lamont> debian #300278
<medwards_> Love that startup sound.
<lamont> mdz: font-arhangai fontconfig grace grace6 lmodern msttcorefonts pango1.0 scalable-cyrfonts scigraphica tipa ttf-* vflib2 vflib3 x-ttcidfont-conf xfonts-baekmuk xfonts-scalable-nonfree xfonts-thai-ttf
<mdz> lamont: sounds like a good idea for main
<lamont> ok.  will do those after lunch
<mdz> lamont: for universe, let MOTU decide what to do
* lamont prepares to lunch
<dholbach> lamont: could you give me a list of the universe packages that will need the bumped defoma build-dependency?
<dholbach> lamont: of the entire list, i'll put it on the wiki and start working
<lamont> dholbach: yeah - I'll let you know once I do the split
<lamont> actually...
<dholbach> lamont: or give me the entire list... no problem
<Mitario> brb
<medwards_> I don't suppose mdz has looked at adding overlay on USB stick to casper.
<lamont> dholbach: sorry for the spewage in the other window...
<lamont> mdz: 8 packages in main, more in universe.
<dholbach> lamont: no problem
* lamont lunches
<lamont> (in town, back in a couple hours)
<dholbach> lamont: i'll start working
<lamont-away> dholbach: Build-Depends: defoma (>=0.8.11ubuntu2)
<mdz> medwards_: I'm already planning to implement it for Breezy
<medwards_> mdz: can device-mapper do flash-friendly load balancing?
<dholbach> lamont-away: thanks
<mdz> medwards_: that type of feature was one of the motivating factors for the choice of device-mapper as the basis
<lamont-away> mdz: can't you do it today with a correctly formatted disk and the right boot cmdline?
<mdz> medwards_: don't USB sticks do that internally?  CF devices do
<mdz> lamont-away: load one, yeah.  saving it is the tricky part
<mdz> well, almost
<mdz> you'd have to do it by hand because you'd need to arrange to mount the media
<mdz> it really needs work to make it into a usable feature
<medwards_> mdz: don't know whether USB sticks are that smart; I suppose I can do the naive thing and see how long it lasts.
<schweeb> medwards_: the biggest thing would be to mount with noatime
<medwards_> schweeb: good point.
<mdz> casper already does that
<schweeb> I'm pretty sure that USB sticks are intelligent... if not you need to use jffs2 or something for balancing
<doko> elmo: please could you install on davis/hoary: libreadline4-dev tk8.4-dev libgdbm-dev blt-dev libbluetooth1-dev
<medwards_> schweeb: yes, which is why I was thinking of trying a port to unionfs.
<medwards_> (immature though it is; I oopsed Knoppix 3.8 with "vi /etc/hosts")
<medwards_> not that device-mapper isn't a good solution, but for some purposes FS-level overlays fit better (e. g., ramdisk for volatile areas, jffs2 for most persistent bits, something else for mysql DB backing store)
<schweeb> can't seem to find any info about how it spreads writes across a usb stick
<medwards_> schweeb: unionfs doesn't, it's a sort of VFS loopback that can stack at FS rather than block device level.
<medwards_> Has other advantages too; for instance, the bottom layer can be a truly read-only FS such as squashfs.
<schweeb> yea, I've heard about unionfs
<elmo> doko: done
<doko> elmo: thanks
<medwards_> schweeb: http://lists.infradead.org/pipermail/linux-mtd/2004-December/011177.html
<medwards_> jdub (same jdub)? suggests just using ext3 (presumably noatime)
<schweeb> no
<schweeb> jdub = jeff waugh
<tritium> seb128, libgtk2.0-0 is compiled with threading, isn't it?
<seb128> no
<seb128> who needs threading ?
<medwards_> schweeb: also interesting: http://www.diskonkey.com/documents/Performance_reliability.pdf
* schweeb stabs firefox
<schweeb> stupid okay button is grayed out to open with xpdf grr
<medwards_> looks like ext3 noatime, possibly tuned for lazy sync, is the way to go.
<schweeb> yea
<medwards_> mount
<medwards_> ww
<medwards_> mdz: any particular reason for casper not to journalize the device-mapper block device (with a journal size appropriate to the ramdisk, not the whole FS) before mounting it?
<mdz> medwards_: the journal eats snapshot space, and doesn't really buy us anything unless the backing store is on persistent media
<mdz> that's why it's ext2
<dholbach> mdz: do you happen to know if the  Depends  on  defoma  has to be set to  (>=0.8.11ubuntu2)  as well?
<mdz> dholbach: no, I don't
<dholbach> mdz: ok, so i'll stop the action until lamont returns
<medwards_> mdz: understood, I was just wondering if there was a reason why it wouldn't be a one-liner.  Already seems to be mounted auto.
<herve> hi, motu trainee for the defoma version bump!
<dholbach> herve: lamont left, so we'll have to wait for him, because i don't know how to test if the newly built package is alright
<herve> ok, I get back to that good ol' python transition :-)
<dholbach> herve: hahaha, it's not _that_ "ol'" :-)
<dholbach> herve: we're just so fast :-)
<herve> it's one of the first, no? not to say the first
<tritium> seb128, I'm building python-matplotlib, and the interactive gui needs threading
<medwards_> Actually, I shouldn't even need to hack casper, except maybe to route the snapshot onto the USB stick; I should be able to create a new device-mapper device from a livecd shell (using whatever option starts by wiping the overlay), then add the journal, and it should Just Work.
<seb128> tritium: ...
<seb128> tritium: sure gtk is built with threading
<tritium> seb128, okay, just double checking
<tritium> seb128, based on these instructions: http://matplotlib.sourceforge.net/interactive.html
<herve> seb128, is there a reason a package built with glade and gnome2.8 from Sid won't compile on Hoary?
<herve> seb128, it fails on gtk/gnome calls
<herve> at compilation time I mean
<seb128> which one ?
<seb128> glade is an app, not a lib
<herve> gcompris :S
<seb128> you mean libglade ?
<herve> but the .c/.h generated by glade
<seb128> urg
<seb128> some apps do that ?
<herve> maybe the build log would be more obvious
<herve> the .c says "generated by GLADE"
<seb128> I'm downloading the sources
<herve> + "do not edit"
<herve> I think gcompris is too big for me anyway
<Mitario> hellohello
<herve> hi Mitario 
<seb128> hi
<seb128> herve: according to the build logs it's looking for -lvga
<herve> I added libsvag1-dev to build deps
<herve> now the compilation goes further but fails on gtk/gnome references
<seb128> k, so let me some min to download the deb-src
<zul> later
<dholbach> bye zul 
<mdz> thom: around?
<abelli> ciao everybody
<abelli> is sabdfl around?
<mdz> abelli: on holiday
<abelli> mdz: thank you
<abelli> when will he be back?
<mdz> he is away for another week I think
<abelli> right, thank you.
<abelli> does he read emails?
<medwards_> mdz: it looks like you already create the snapshot persistent in casper.
<medwards_> so 10snapshot just needs code to check, say, casper-udeb/snapshot/overlay-file and, if it's non-null, add a second line of stdin to the initial dmsetup create.
<medwards_> no, that's not quite right.  Perhaps it just needs to use dmsetup load instead of dmsetup create.  Experiment time.
<mdz> medwards_: it's in persistent mode, but it's stored on a ramdisk at the moment (where a journal would just take up more space)
<mdz> it's done persistent so that it could easily be dumped out to persistent storage
<Mitario> mvo, hey, around? :-)
<mvo> hey Mitario 
<mvo> yes
<dholbach> hi mvo
<mvo> hey  dholbach 
<Mitario> mvo, you got answer from the cvsadmins?
<dholbach> mvo: what about a beer in the middle of us? like bochum-langendreer? ;-)
<mvo> Mitario: no, you?
<mvo> dholbach: I'm _so_ tired :)
<Mitario> mvo, yes, they also didn't know the problem, they asked me if they wanted to import a tarball for us, so i'll just do that then
<mvo> Mitario: all right
<dholbach> mvo: even a nice and cold beer wouldnt get you outside? ;-)
<ogra> dholbach, mvo, what about a beer in the middle of us ? like cologne ;)
<dholbach> hahahah
<ogra> *g* kidding....
<dholbach> ogra: then we should stop calls for more people or we end in bavaria or something
<ogra> hehe
<herve> argh
<mvo> haha
<herve> I was about to suggesting Strasburg!
<dholbach> i read an article about belgian beer today
<ogra> india, if you invite jdub, or atlantis wrt mdz ;)
<dholbach> what about that?
<herve> dholbach, gaaa, belgian beer!
<Amaranth> seb128: Do you know where I can find documentation for python-xdg?
<herve> dholbach, I advise you to taste Leffe and Chimay
<seb128> there is some example in the package
<dholbach> herve: made a note :-)
<herve> maybe "Bire des ours" (bears beer) but I'm not sure it's Belgian
<Amaranth> I just need to get it to save. ;)
* doko seeks somebody to approve a python2.4 2.4.1 release candidate1 upload ...
<herve> doko, wasn't it RC2 today?
<doko> oops, typo, yes it's rc2
<herve> rock!
<dholbach> doko: hope we won't need wiki/UniversePython2.4rc2TransitionTODO :-)
* dholbach was only kidding :-)
<herve> glad I'm not cardiac!
<herve> :-)
* dholbach wished lamont was around
<herve> dholbach, as I've seen, it's just rebuilding those packages with the new dh_installdefoma postinst/prerm scripts
<dholbach> herve: i was wondering if we needed a Depends: on defoma (>= version) as well
<herve> I don't think for the binary depends, no defoma behaviour changed
<seb128> a danish guy is opening has a translation issue and is opening a bug on the differents apps :/
<medwards_> mdz: I'm almost there.  "enter preinstalled session" failed, apparently because mount neither correctly auto-detected ext3 nor succeeded in mounting it ext2 ("couldn't mount because of unsupported optional features (4)").
<mdz> medwards_: sounds like it should just need a "modprobe ext3"
<doko> seb128: the danish are strange, three different OOo reports as well ...
<medwards_> mdz: that seems to be right.  mount -t ext3 from a shell worked, presumably auto-probing the module, and then it all worked once I undid dmsetup and losetup steps.
<medwards_> well, "all" is a little strong; it seems to have gone into the install rather than the livecd, and then decided to use ati rather than nv, etc., etc. :-/
<medwards_> Perhaps you could add casper-udeb/snapshot/fstype defaulted to auto?
<medwards_> mdz: looks like persistent snapshot on USB stick is a wiki page away.  :)
<medwards_> I'll test with a fresh ext2 overlay -- unless there's already a probe-additional-modules debconf key?
<Mithrandir> lamont_r: pong
<lamont_r> yo
<lamont_r> Mithrandir: http://people.ubuntu.com/~lamont/buildLogs/Test/d/db3/......-amd64-fail
* lamont_r has nfc what's up with that...
<Mithrandir> lamont_r: db3 sucks, it uses LD_ASSUME_KERNEL=2.4.1 which blows up.
<Mithrandir> (on amd64)
<Mithrandir> glibc is compiled with minimum kernel version = 2.6.0
<Mithrandir> (it fails with problems loading libdl.so, right?
<Mithrandir> )
<lamont_r> yep
<lamont_r> so can we either fix it, or drop it from the archive?
<medwards_> It would be nice to integrate cryptoloop-aes into the chain, too.  Then I could throw away the old knoppix-mib CD that I've been using to do paranoid CD-booted GPG key management.
<lamont_r> hrm... dropping it isn't really a good option...
<Mithrandir> lamont_r: what needs it?
<lamont_r>  apt-cache showpkg libdb3| wc
<lamont_r>     177     354    5123
<lamont_r> what doesn't?
<Mithrandir> :P
<lamont_r> hrm.. that's with universe, I suspect
<lamont_r> exim4
<lamont_r> libgnomeprint
<Mithrandir> hm :/
<lamont_r> libsasl7
<lamont_r> bonobo
<lamont_r> I think it stays... :-)
<Mithrandir> yeah :/
<Mithrandir> I could try fixing it on amd64.
<lamont_r> pls fix.  kthxbye. :-)
<Mithrandir> beers_owned["lamont"] ++ :P
<lamont_r> lol
<Mithrandir> elmo: could you please sync db3?
<abelli> why if i try to install myspell-it it says it's not authenticated [gpg things] ?
<schweeb> abelli: likely the GPG key the package was signed by isn't in your keyring
<abelli> schweeb: huh? right... thank you.
<schweeb> try apt-get update again, and see if the update complains that it's missing keys
<abelli> ok
<herve> schweeb, shouldn't the package be refused if the key is unknown?
<schweeb> no, it asks if you want to use a untrusted package
<herve> I mean, when it's uploaded
<schweeb> herve: could be from a non-ubuntu archive
<herve> right
<lamont_r> herve: apt is checking the archive signature, not the individual package signature
<schweeb> or, I've had a couple of times where ubuntu archives will say that, then I update again, and it works again
<zul> hi
<marcin_ant> hi developers
<marcin_ant> I got a question - you'll propably send me to #ubuntu - but I'll try
<marcin_ant> Are there any plans to reduce size of upgrades? 
<marcin_ant> it's very nice that hoary is fresh and up to date
<marcin_ant> but it needs huge downloads
<wasabi_> That's because it's in development.
<dholbach> marcin_ant: you should be able to upgrade from a hoary CD
<marcin_ant> do we really need to replace whole packages to upgrade?
<wasabi_> Yes. We do. ;)
<marcin_ant> dholbach: I mean - daily upgrades
<mvo> marcin_ant: see http://www.ubuntulinux.org/wiki/APTPackageDeltas
<mvo> it's all in planing, no code yet
<dholbach> marcin_ant: no you don't need to upgrade daily
<wasabi_> i did an "implementation" of that a few months ago
<wasabi_> was pretty fun
<wasabi_> just distributed a diff of the new .deb to the old .deb though
<ogra> marcin_ant, if hoary is stable the amount of upgrades will drop, as long as its in development the current is the way to do it...
<wasabi_> oh yeah heh.
<wasabi_> this is exactly what I made
<marcin_ant> ogra: I don't want to reduce amount of upgrades
<ogra> marcin_ant, but we :)
<wasabi_> marcin_ant, read the page.
<marcin_ant> ogra: it's really nice that ubuntu/linux/gnome development is dynamic
<marcin_ant> ogra: but my question is generally about bandtwidh
<marcin_ant> we have tools like rsync
* wasabi_ sigh
<ogra> marcin_ant,  if its stable there are only security upgrades, which reduces them drastically
<marcin_ant> and I don't get why I need to download whole package in new version to upgrade
<wasabi_> because, read the page.
<dholbach> marcin_ant: momentarily there is no other way, we don't have half packages or something, you don't have to upgrade daily, this should save you bandwidth
<ogra> marcin_ant, feel free to add the missing code for http://www.ubuntulinux.org/wiki/APTPackageDeltas, i'm sure mvo will happily review and use it
<marcin_ant> dholbach: yes I know but I got apt in cron
<marcin_ant> dholbach: and sometimes I'm on broadband but sometimes on gprs (which is slooow)
<dholbach> it should only get the lists, unless you checked the checkbox in update-manager to get the packages as well
<marcin_ant> dholbach: and this is why I found this uncomfortable to download whole package 
<marcin_ant> anyway I got answer - I'll read about it
<medwards_> mdz: any idea how to clobber the magic on a dm snapshot so that dmsetup create will make an empty snapshot?
<mdz> medwards_: should work to zero it
<medwards_> mdz: zero the whole device? ouch.
<medwards_> mdz: let's try the undocumented "dmsetup clear".
<medwards_> not useful.
#ubuntu-devel 2005-03-30
<marcin_ant> ogra: btw what about this http://home.tiscali.cz:8080/~cz210552/aptrsync.html ?
<mvo> marcin_ant: for this particular problem (package list updates), please see http://bugs.debian.org/128818
<medwards_> mdz: device-mapper documentation is, er, sketchy.  :(
<mdz> medwards_: yeah.  I  know a few people who are helpful though
<medwards_> I RTFS to understand the "p" in snapshot create.
<mdz> medwards_: kevin corry of the EVMS project has answered many questions for me
<medwards_> argh, and argh some more.  I zeroed the entire /dev/sda1, and I still get "Invalid/corrupt snapshot".
<mirak> if I do a dd /dev/hda of a full 40G hard drive on a 120G hard drive, will I be able to resize the latest partition, or will the system believe it's still a 40G hard drive ?
<lifeless> you'll be able to resize it
<lifeless> but you'd be better off copying the partition with parted anyway
<medwards_> I swear to Murgatroyd, I had this working!
<Amaranth> seb128: are you sure gnome-menus will take an entry from ~/.locals/share/applications and show it over an entry with the same name from /usr/share/applications ?
<seb128> put a desktop file here and run the pyxdg example, you'll see
<Amaranth> I've got everything else working perfectly but you still have to run as root to edit root entries because it shows the root one over the user one in the menus
<seb128> hum
<Amaranth> i have testingthis.desktop in both places with a different Comment line and both my app (using python-xdg) and the gnome menus themselves show the root one
<seb128> oh, you have the same in both
<Amaranth> yeah, i thought you said that would work
<Amaranth> otherwise i'll still need root to edit root entries
<seb128> that does if you handle it right
<seb128> no
<seb128> read the spec
<seb128> a sec
<Amaranth> err
<Amaranth> what part of the spec tells how to make this work?
<seb128> http://standards.freedesktop.org/menu-spec/menu-spec-0.9.html
<seb128> D. Implementation notes
<seb128> Menu editing
<seb128> " To implement menu editing, the intent is that a per-user file is created. The per-user file should specify a <MergeFile> with the system wide file, so that system changes are inherited. When the user deletes a menu item, you add <Exclude><Filename>foo.desktop</Filename></Exclude>. If the user adds a menu item, you use <Include><Filename>foo.desktop</Filename></Include>"
<seb128> " If the user moves a folder, you might try to use <Move> elements to represent that, but it's tricky. (Move A/B/C to D/E/F, then move D/E to D/G, note that D/E/F still contains A/B/C while only the original D/E was moved to D/G.) In order to move a folder, you have to "fix up" all moves that move things into the folder being moved to instead move things into the folder's new location."
<seb128> 
<seb128> that
<Amaranth> oh, i need to create user versions applications files?
<seb128> right
<Amaranth> hrm
<seb128> you need to have the .menu files for your user
<seb128> that merge the system one
<seb128> and to use these ones
<seb128> so you can do the changes
<Amaranth> now to figure out how to generate .menu files...
<Amaranth> oh, Menu.addDeskEntry() might be it
<seb128> nice
<seb128> BTW thanks for the work on the menu editor, some users will be happy
<Amaranth> yeah, i've gotten some nice replies on the ubuntu forums
<seb128> some beeing an inderterminate number, but that's a frequent request on the mailing lists 
<thom> mdz: yo
<lamont_r> mdz: defoma cluster uploaded
<lamont_r> seb128: we have a menu editor!!!!!????!!? woo woo!!!
<seb128> lamont_r: somebody is working on a menu editor rather
<lamont_r> ah, ok
* lamont_r slumps back down in his seat, determined to be patient.
* Amaranth stabs the menu spec
<Amaranth> lamont_r: the old version works, it just doesn't quite follow the spec
<Amaranth> well, it does enough to work, just not enough to allow non-root editting of root entries
<Amaranth> i think Menu.addDeskEntry() is what i need to work with in python-xdg but when i give it my entry it tries to access entry.Name which doesn't exist
<Mitario> good night everyone
<thom> g'night folks
<Amaranth> night
<ogra> night thom 
<medwards_> blood.  y.  hell.
<medwards_> mdz: zeroing it worked.
<medwards_> mdz: left a gratuitous mkfs in between zeroing and dmsetup.
<doko> good night or good morning, as you like it ;)
<medwards_> Is there a boot parameter I can use to modprobe ext3 before casper runs?
<ogra> night doko
<mvo> night doko
* mvo -> bed too (was up way too long)
<dholbach> good night mvo
<ogra> night mvo
<mvo> ciao dholbach, ogra 
<medwards_> oh, boo.  "Failed to initialize HAL".
<medwards_> "hald timed out on ep0in"???
<medwards_> hmm, looks like I need to blacklist the USB stick from hotplug when casper's got hold of it.
<dholbach> i'm off to bed... good night to you all
<medwards_> thom: looks like you maintain hotplug for ubuntu; any thoughts on how to blacklist just the first USB stick from hotplug?
<medwards_> thom: sorry, looks like a hal problem, not hotplug.
<tsume> to explain why the newer nvidia module isn't in the archive?
<tsume> *can anyone explain
<Rocha> Good evening
<rvalles> hi
<Rocha> Will mono 1.1.4 be available for hoary?
<zul> tsume: because we are close to release we are concentrating on stabilization
<rvalles> I need to know how the gcc wrapper works in ubuntu
<tsume> zul: after that will there be normal updates again?
<rvalles> tried to find documentation on it, but no luck
<zul> tsume: should be
<rvalles> the thing is, I have gcc-3.4 installed
<tsume> zul: I like current software, I don't like using outdated "crap"
<rvalles> root@LeChuckK7:/ # kk
<rvalles> bash: kk: command not found
<rvalles> root@LeChuckK7:/ # gcc
<rvalles> bash: /usr/bin/gcc: No existe el fichero o el directorio
<medwards_> OK, it's fine as long as I wait until the isolinux prompt to insert the USB stick.
<tsume> zul: thanks to the near up-to-date kernel, I was able to use my intel 2200BG card in my laptop
<tsume> ipw2200 module :)
<rvalles> notice the difference
<Amaranth> Rocha: mono 1.1.x is unstable, it'll become 1.2 when it's ready for use
<rvalles> so a wrapper is definitivelly there for gcc
<rvalles> but... where is it?
<Rocha> Amaranth, on the website they say that people should use 1.1.4 instead of 1.0.6
<Amaranth> rvalles: gcc is a symlink
<Amaranth> Rocha: That's odd...
<Rocha> Amaranth, in the mono channel too
<Rocha> (in gimpnet)
<rvalles> Amaranth: where is that symlink?
<Amaranth> /usr/bin/gcc
<rvalles> Amaranth: /usr/bin/gcc doesn't exist.
<zul> rvalles: that is an #ubuntu question
<rvalles> Amaranth: yet, as you can see, the error I get by typing random crap (kk) is different
<rvalles> Amaranth: than the one I get typing "gcc"
<Amaranth> rvalles: have you installed the build-essential package?
<rvalles> Amaranth: yes.
<Rocha> do you use any graphical cvs tool to manage your files?
<rvalles> Amaranth: I removed gcc-3.3 to try~ to force gcc to be gcc-3.4, tho
<rvalles> Amaranth: also reinstalled gcc-3.4, no luck
<Amaranth> *facepalm*
<rvalles> zul: they pointed me here.
<Amaranth> rvalles: move this to #ubuntu
<Amaranth> it's definately not appropriate #ubuntu-devel discussion
<medwards_> mdz: snapshot on USB stick works.  What shall I do with the setup script?
<mdz> medwards_: nice, how many pieces is it in?
<mdz> and where do they fit?
<medwards_> All you have to do is run the script (hacked from 10snapshot) when booted from livecd/ramdisk and with USB stick inserted but not mounted.
<medwards_> Then reboot, and enter "live casper-udeb/snapshot/cow-device=/dev/sda1" at the isolinux prompt.
<medwards_> The freedesktop hal choked when my BIOS saw the stick during boot, so I just wait until the isolinux prompt to insert it.
<medwards_> that's all there is to it.
<medwards_> The script zeroes the first 10K of the partition, creates cow and snapshot devices, and runs e2fsck.  The tune2fs -j line is commented out pending a way to modprobe ext3 early enough.
<medwards_> mdz: got that?
<mdz> medwards_: reading now
<mdz> 05load-modules loads ext2; it could as easy load ext3
<tsume> questoin, are the development branches usually stable to use for a BSDer?
<mdz> tsume: that's a subjective question; you should be able to get plenty of opinions in #ubuntu about it
<mdz> medwards_: what was the root of the problem with hal/
<mdz> ?
<tsume> mdz: well does at least 75% work most of the time?
<tsume> mdz: compared to debian -unstable
<medwards_> BIOS probably does stupid things to enable USB mass storage boot.
<tsume> mdz: I need up to date software, not outdated software
<mdz> prior to freeze, we track Debian unstable closely
<tsume> mdz: but are there conflicts which debian -unstable have?
<mdz> medwards_: oh, you're booting from the stick and then also using it for COW?
<medwards_> tsume: I've had very good experiences with debian unstable, but YMMV.
<tsume> i.e. seems to take forever to be able to even download the software without missing deps with -unstable debian
<medwards_> mdz: nope, but if it's inserted, the BIOS tries to give me the option.
<tsume> YMMV?
<mdz> tsume: our focus is on getting a high-quality release out every 6 months.  this means we don't stay on the bleeding edge all the time, certainly not toward the end of our release cycle
<medwards_> tsume: your mileage may vary.
<tsume> there aren't any assholes like cafuego in the ubuntu community are there?
<zul> who?
<ogra> what ?
<tsume> zul: cafuego of #debian
<tsume> just a very rude person who doesn't like helping anyone
<zul> ah
<tsume> he suffers from big penis syndrome ;)
<medwards_> and for a stretch goal, how about AES encrypting the partition underneath the linear dm device, and asking the passphrase during 10snapshot.  :)
<medwards_> mdz: given appropriate access, I would be happy to put this stuff up on the wiki.
<ogra> tsume, ubuntu is known for its good helpful community that even tends to avoid such verbalisms like asshole...
<tsume> ogra: just what I wanted to hear :)
<mdz> medwards_: all you need for the wiki is to create an account; it's all open
<ogra> i.e. we have a code of conduct that forces you to be helpful and nice ;)
<tsume> ogra: debian lacks 'code of conduct'
<tsume> ogra: I guess its one of the major pros to go for in a project :)
<ogra> but has a "social contract" 
<ogra> yep
<tsume> there is a project for graphical linux boot, does anhyone know what it is?
<tsume> for a picture during kernel load, etc
<ogra> tsume, but we would also welcomecafuego if he would sign the CoC ;)
<ogra> usplash
<tsume> ogra: it would be difficult for people like cafuego to agree/act to such a contract
<tsume> orusplash?
<tsume> ogra: hmm I thought it was called bootsplash or something.
<tsume> *something else.
<lamont_r> bootsplash is something else
<lamont_r> that's a heavy kernel mod, etc.
<ogra> tsume, but if he would, and behave accordingly, he could even join :)
<lamont_r> usplash is ubuntu's all-user-space splash during boot
<lamont_r> that isn't in hoary
<tsume> ogra: that type of acceptance and behavior would be exciting to see.
<ogra> lamont_r, i think we'll have some proof of concept stuff in universe shortly after release, i talked to sladen at FOSDEM 
<lamont_r> ogra: right
<ogra> tsume, :)
<zul> okies usb storage device list has been updated
<ogra> tsume, ubuntu is always exciting ;)
<zul> oh you are around lamont_r
<lamont_r> doh. discovered.!
<zul> bwahaha
<tsume> are there any plans in getting bootsplash in the kernel?
<zul> no
<tsume> zul: any reason not to?
<zul> yes we are looking at usplash
<tsume> zul: can usplash show a progress bar?
<ogra> tsume, we have something better: http://www.ubuntulinux.org/wiki/USplash
<medwards_> mdz: under IdeaPool, or maybe BreezyGoalsThatTurnedOutToBeLowHangingFruit?
<srbaker> has anyone here played with apple's rendezvous on ubuntu? 
<srbaker> or any linux-based system, for that matter
<zenwhen> Does Canonical support Kubuntu finaially?
<ogra> tsume, usplash will support mng, you can animate what you want with it
<zenwhen> financially*
<tsume> almost firgor
<tsume> oops
<tsume> almost forgot, I've a small grub problem
<tsume> it says GRUB at boot, so I had to install lilo
<tsume> how can I load the CD and install grub the right way?
<ogra> ?
<tsume> GRUB
<tsume> thats it
<tsume> it freezes and the laptop doesn't boot.
<mdz> medwards_: it's on UbuntuDownUnderBofs right now, but I haven't fleshed it out yet (and probably won't do so in that wiki)
<srbaker> ogra, where do i find info on usplash?
<ogra>  http://www.ubuntulinux.org/wiki/USplash
<srbaker> thanks
<medwards_> mdz: will also be nice for poor-man's remastering, since an idle snapshot is a perfectly good cloop and can be rolled right up into a new ISO.
<zul> heh i was able to reproduce those ata_piix problems on array 6
<Amaranth> i give up, python-xdg hates me
<Amaranth> people can just edit menu entries by hand :/
<bluefoxicy> could somebody get me the source files for the users and groups applet?  I'm sure there's a mirror somewhere online, or I can apt-source it?
<medwards_> mdz: first draft at https://www.ubuntulinux.org/wiki/LiveCDPersistence
<medwards_> mdz: I know diddly about Plone markup, maybe someone could touch it up.
<mdz> medwards_: thanks, will look at it soon
<mdz> sometimes helpful souls trawl the wiki and fix up the markup ;-)
<medwards_> mdz: I'll try to get around to the AES cryptoloop support once I've succeeded with a remastering cycle.
<medwards_> mdz: is casper frozen, or can at least the ext3 modprobe go in?
<Amaranth> arg, seb left
<Amaranth> does anyone know anything about python-xdg?
<Amaranth> beyond listing menu entries and saving .desktop files themselves it looks entirely worthless
<jdub> mdz: permission to upload bugfix updates of libvorbis/libtheora that we probably should've had in warty (they're that old)?
<medwards_> mdz: I don't really see any reason why there should be livecds without at least AES persistent homedir support anymore.
<medwards_> mdz: thanks for casper, it's excellent.
<jdub> mdz: i've tested them locally, no problems (and FC3 had them).
<crimsun> Amaranth: and validation, which is just as important?
<Amaranth> meh, i need to figure out how to merge user menus with the main ones
<Amaranth> i would have thought they'd have a nice catchall setup for this
* Amaranth facepalms
<Amaranth> thank you redhat for the example file :)
<Amaranth> i give up
<Amaranth> this was intentionally made hard
<infinity> mdz : regarding #7857, how do I best handle that, since I can't build libapache-mod-php4 without a build-dep on apache-dev (from universe), but the php4 source package is main (with binaries split across main/universe)
<lamont> mdz about?
<lamont> any amd64 owners around?
* lamont needs someone to try a fix for him
* mjg59 boggles gently at http://www.microsoft.com/whdc/system/pnppwr/wmi/wmi-acpi.mspx
<zul> night folks
<mdz> jdub: if they're the new upstreams, then no, I'd rather not
<mdz> medwards_: I'm not touching casper at the moment except for bugfixes, but feel free to keep your changes in an arch branch for now
<mdz> medwards_: http://people.ubuntu.com/~mdz/archives/matt.zimmerman@canonical.com--2004/
<mdz> infinity: either we split the source, or we don't support apache 1.3
<infinity> mdz : Yeah, I just got advice from daniels to duplicate the source package, build all the main stuff from the main source, and the universe stuff from the universe source.  Ick.
<infinity> mdz : But it seems resonably sane, except for the maintaining of two branches.
<mdz> lamont: what do you need?
<fgx> do you think ubuntu will have its own boot/install floppy in the future?is it a goal?
<lamont> mdz: how does the fix suggested in #297543 sound?
<mdz> lamont: you would know better than i would; I assumed it was at 18 for a reason
<lamont> was 18 when I inherited it.
<lamont> module-tools-init is all that is at 20...
<lamont> I'll poke Md tomorrow and see what he thinks
<lamont> pb is that I lack an amd64 box to test on.
<jdub> mdz: they're well tested elsewhere, and will help with streaming stuff
<mjg59> Somebody really needs to write a driver for that WMI stuff
<jdub> http://distrowatch.com/stats.php?section=popularity
<schweeb> jdub: NICE
<jdub> pretty impressive
<mjg59> That's quite astoundingly good
<mjg59> What's the highest number they've managed before?
<jdub> hrm
<jdub> the historical high water mark forever?
<jdub> dunno
<jdub> might ask ladislav
* jdub mails
<infinity> mdz : So, do I have your okay to do that (re: duplicate main/universe source packages).  Does the archive deal with that sanely, or do I need to rename one to php4-universe or something?
<elmo> uh
<elmo> of course you can't duplicate the source with the same name
<elmo> main/universe are just components; you wouldn't try and put a package in main _and_ non-free in Debian, right?  same deal
<infinity> elmo : Check.  Wasn't sure how they were handled on the backend, as components of a dist, or as seperate dists, happening to release simultaneously.
<infinity> elmo : So, to duplicate the source, I need a php4-universe source package, then.  Can do.  (Did I say "ick" yet?)
<srbaker> hrm
<srbaker> for some reason knoppix makes my sound work every time, and it wont' work in ubuntu :(  i think it has omething to do with OSS
<schweeb> ubuntu uses ALSA... I believe knoppix does now too
<elmo> infinity: well - supporting apache 1.3 for 18 months would be even more icky
<sladen> medwards_: how much extra work would it be to have a loopback file on the USB/whatever device as the persisent home.  This strikes me that it'd work across USB/vfat/windows partitions much better
<sladen> medwards_: my (limited) knowledge of DM tells me it should be possible to take the existing memory-backed snapshot and write that to device/file retrospectively.  Avoiding the need to reboot and pass in a cow device
<infinity> Hrm.  If initscripts (which is priority: required) depends on lsb-base, is it really sane to change every package which provides an init script to ALSO depend on lsb-base?
<elmo> infinity: partial upgrades?
<infinity> From pre-warty?
<elmo> or Debian?
<infinity> initscripts has depended on lsb-base since before warty released.
<infinity> Meh.
<infinity> Fair nuff.
* infinity goes to add a bunch of deps.
<lamont> mdz: what severity do you want the hoary-test/ia64 build failures at?  normal? or critical?
<elmo> infinity: don't take that as authoritative, I'm just guessing
<infinity> elmo : Well, it makes sense.  I just wish it didn't. ;)
<bob2> I like how scrollkeeper hangs on install if you don't have network access
<froud> Mitario: ping
<Mithrandir> elmo: could you please sync db3?
<elmo> done
<Mithrandir> thanks a lot
<tritium> elmo, I sent requests to keyring and upload last Sunday.  Should I be all set?
<dholbach> goood morning!
<lunitik> Please can *someone* kick 'you' in #ubuntu?
<dholbach> daniels: thanks for dbus-mono - i'll take care of the uploads once it's in the archive
<daniels> dholbach: thanks a lot mate
<daniels> dholbach: afaict, it's just tomboy and muine that needed uploading
<dholbach> daniels: my pleasure...  have still to do quite a lot of uploads, and i already prepared them :-)
<daniels> dholbach: the c abi hasn't been touched, but because of the version bump, all the mono apps need to be rebuilt; apt-cache rdepends only showed those two
<daniels> dholbach: awesome
<daniels> dholbach: then do we get awesome beagle love? :)
<dholbach> daniels: to be honest, i'm just relying on your and tseng's word
<dholbach> i'm on amd64 :-)
<daniels> dholbach: afaict, 'it works'
<daniels> yeah, me too
<daniels> but I have an i386 laptop
<dholbach> ah... well i haven't :-)
<daniels> i can't imagine ever going back to an i386 desktop
<dholbach> no... it's only 3 months now, but i wouldnt switch back again
<dholbach> even with those amd64isms on http://wiki.ubuntu.com/UniverseUnmetDeps :-)
<elmo> daniels: you saw the REJECT right?
<daniels> elmo: for dbus in debian?  yeah, what's up with that?
<daniels> i saw it ... with no attached note
<elmo> err, no, in ubuntu
<daniels> elmo: er, no
<daniels> haven't checked my mail since I uploaded
<daniels> let me guess: targeted at unstable?
<elmo> REJECT
<elmo> Rejected: dbus_0.23.4-0ubuntu1.dsc refers to dbus_0.23.4.orig.tar.gz, but I can't find it in the queue or in the pool.
<daniels> ah, bong
<daniels> thanks
<daniels> i actually was careful to do -sa the first time around
<daniels> then, right before I uploaded, I did a tiny tweak, and forgot -sa
<daniels> cheers
<elmo> whee
<elmo> hoary-test's gone from 60% to 90% in like half an hour :>
* Mitario wakes up
<Mitario> hi everyone
<dholbach> hey Mitario 
<mvo> hey Mitario 
<dholbach> hey mvo 
<mvo> hey dholbach 
<tritium> lamont, ping
<Mitario> mvo, http://cvs.gnome.org/viewcvs/update-manager/ :-)
<Amaranth> i now know more about the fd.o menu spec then i ever wished to
<Amaranth> on the plus side, my menu editor works without running as root now :)
<Mitario> nice one :-)
<dholbach> Amaranth: cool
<Mitario> mvo, ping :-)
<Amaranth> hmm, it doesn't actually change the menu and if i reload the editor the change is reverted....
<mvo> Mitario: checking just now :)
<mvo> Mitario: ahhh nice :)
<mvo> Mitario: let's see if I can access it with my account :)
<Mitario> mvo, indeed :-)
<Mitario> mvo, i'll notify the translaters & contribers
<Amaranth> this is the buggiest thing i've ever seen
<Amaranth> sometimes it uses the .menu file, sometimes it doesn't, sometimes it uses part of it
<froud> Mitario: must I now work on gnome cvs for the docs?
<Amaranth> all i've managed to do consistently is blank my applications menu
<Amaranth> where is seb when you need him?
<Mitario> froud, yes, if you wish, do you have a cvs account there?
<mvo> Mitario: updating ... :)
<froud> Mithrandir: no
<Mitario> mvo, nice :)
<froud> sorry Mitario no
<Mitario> froud, ok, no problem, if you wish i can request one for you
<froud> Mitario:  I was about to update to add the "Add CD" button and once you have the Help Button Enable redo the captures
<froud> Mitario: It's a good idea
<mvo> Mitario: hm, we need to add a help button :)
<froud> mvo: snap
<Mitario> mvo, heh umm, i think we have to redo the UI a bit then :-)
<Mitario> mvo, otherwise it'll look cluttered :(
<mvo> Mitario: *nod*
<Mitario> froud, anyways, wait until you commit, or checkout the source from anonymous cvs.gnome.org and send us a patch
<froud> Mitario: *nod*
<Mitario> it'll only be for a short time
<froud> Mitario: OK
<Mitario> now, sorting my e-mail first..
<Mitario> will get to the stuff in a bit
<froud> Mitario: problem is to do that once screen changes are finished. no point documenting if the interface is changing
<dholbach> daniels: seems like i'm ready to go
<Mitario> froud, true
<Mitario> mvo, froud maybe we can do some kind of UI freeze one week before 5.4?
<Mitario> which is about today :p
<froud> Mitario: Um I dont see update-manager in :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome
<mvo> yes :) it's really a short time now
<Mitario> froud, huh.. hmm, maybe anoncvs.gnome.org is not synced yet
<froud> bummer
<froud> anyone know how long that takes
<Mitario> i don't know, sorry :-(
<Amaranth> anoncvs.gnome.org is on mirrors, isn't it?
<mvo> Mitario: I commited a "dirty" property for gnome-software-properties. it will know only ask for updating the packagelist if samething has changed in the sources.list. it would be nice if you could also give it a bit of testing :)
<Mitario> mvo, ok did you commit it in cvs.gnome.org? :-)
<Mitario> i'm going to grab some food, i'll brb in 10 minutes
<mvo> Mithrandir: yep
<mvo> Mithrandir: ups, nick-completion error :) have fun in .dk 
<dholbach> daniels: uploaded muine and tomboy
<mvo> dholbach: coooooollllll
<dholbach> mvo: well... i didn't do much on them :-)
<dholbach> mvo: tseng and daniels made sure you can tomboy around :-)
<mvo> *rock* tseng and daniels
<Mitario> i'm back
<mvo> Mitario: now I'm leaving for a bit
<torkel> froud, Mitario: at least one of the anoncvs.g.o mirrors was synced about an hour ago
<Mitario> ah ok, well, update-manager has been in cvs.g.o for 6 hours now
<torkel> Mitario: sometimes the mirrors are way out of sync, so I usually stick to farbror.acc.umu.se
<andred> Now that Ubuntu generates a whole bunch of english locales on install, Ubuntu's gdm suffers from http://bugzilla.gnome.org/show_bug.cgi?id=170706 . Check out the language list in gdm and you'll see the mess.
<froud> torkel: thanks
* Amaranth heads for bed
<deresh> hi 
<deresh> i have a question avout misdn in kernel version 2.6.10
<deresh> ANYONE??
<Treenaks> deresh: #ubuntu
<deresh> i tryed there but no one knows
<deresh> in kernel 2.6.8 there was a misd support
<Treenaks> this is not a support channel
<deresh> but when i upgraded to 2.6.10 support is missing
<deresh> do i think DEVELOPERS had removed mISDN support form kernel 
<deresh> so i think this is a right place to ask why?
<deresh> coz i dont want to manualy recompile kernel just for that
<dholbach> hey seb128 
<seb128> hi
<jdub> is it just me, or does firefox 1.0.1 *not* leak like a sieve?
<seb128> dunno I don't use firefox :p
<jdub> nen
<jdub> heh
<dholbach> jdub: seems to be better at my place too
<seb128> bah, everybody use that ? :p
<dholbach> seb128: if epiphany didnt have the problems with at-random-jumping-focus, i'd use it
<seb128> yeah, this one is annoying
<dholbach> (if you use tabs and reload pages, while working on others)
<seb128> the new galeon takles this issue, perhaps epiphany will follow :)
<dholbach> i love epiphany's tweakable bookmark-bar
<jdub> ah! dbus!
<jdub> daniels: thanks :-)
<dholbach> the MOTU crew completely fixed their first transition list :-)
<jdub> seb128: you got benm's mail about g-t/nautilus patches?
<jdub> dholbach: :-)
<dholbach> UniverseHowlRebuildTODO will be next, right seb128? :-)
<seb128> jdub: nop
<seb128> dholbach: yep
<jdub> seb128: what's your ubuntu.com address?
<seb128> seb128@ubuntu.com
* ogra wonders whats his ubuntu.com address, or dholbachs....
<dholbach> seb128: what about #7887? shall i just rebuild libgnomeuimm2.0?
<ogra> how is the status there
<seb128> dholbach: feel free
<seb128> I've to go for lunch
<dholbach> seb128: ok
<jdub> ogra: don't you have ubuntu addresses yet?
<dholbach> seb128: bon apptit
<seb128> bbl (~30 min)
<ogra> jdub, afaik not
<jdub> seb128: hrm, benm mailed you and cc'ed me
<jdub> seb128: i'll forward again
<ogra> jdub, thats why hwdb-client still says the users should send their data to hostmaster@grawert.net in the last step ;)
<jdub> heh
<ogra> got 35 submits so far :-D
<jdub> nice!
<dholbach> ogra: you should tell the people to gzip it, or do it yourself ;-)
<ogra> dholbach, my server can cope with 300k attachments :)
<dholbach> ogra: i thought it was only to polite to gzip it :-)
<dholbach> since xml compresses so fine
<ogra> and for release it will subimt to a ubuntu server so its only some weeks
<mdke> who's in charge of the mailing lists? mako? anyone else?
<ogra> mdke, jdub
<mdke> hi ogra 
<ogra> hi
<mdke> are either around do you know?
<dholbach> mdke: why don't you try a "jdub: ping" and see if he responds :-)
<ogra> :)
<mdke> hi dholbach, i got an email this morning confirming your worries about the wiki
<dholbach> mdke: confirming worries?
<ogra> mdke, you care for the new stuff there ?
<mdke> dholbach, because if they are here, they will have highlights already :)
<mdke> ogra, well sort of, everyone does really
<ogra> mdke, would be nice to have _any_ trace of MOTU on the frontpage
<mdke> ogra, stick it on.
<dholbach> mdke is the moin specialist giving me 30 wiki mails in half an hour :-)
<mdke> ogra, but really the ideal would be to cut down the frontpage making it simpler. maybe put a reference on the developer documents, and the "how to contribute" pages
<mdke> dholbach, i'll paste you the email in PM
<dholbach> ok
<dholbach> mdke: yes... seems to underline IdeasForNewFrontPageStructure
<mdke> also an italian user said the same thing this morning, that the wiki isn't accessible enough
<dholbach> it would be nice if the frontpage itself could manage encouraging and guiding towards "getting involved" in a nice way
<dholbach> so we don't loose willing contributors on the way
<mdke> totally
<dholbach> seb128: shouldnt libgnomeuimm2.0 then turn up in   apt-cache rdepends libhowl0   ?
<jdub> mdke: mail dude, mail.
<mdke> ok sorry
<mdke> jdub, ok done
<seb128> dholbach: why ?
<dholbach> seb128: shlibs:Depends should add it, or am i wrong?
<dholbach> seb128: grep howl /usr/lib/*.la is empty too
<seb128> dholbach: so what's the issue ?
<seb128> why do you want to make it depends on libhowl ?
<dholbach> i don't want it to
<dholbach> i thought it was
<seb128> on ia64
<seb128> according to the build log
<seb128> are you on an ia64 ?
<dholbach> oh... *reading again*
<dholbach> no... unfortunately not
<seb128> so wait for lamont's reply
<dholbach> sorry for the confusion
<seb128> np
<seb128> jdub: thanks for the fwd. I've received the mail according to the logs but plobably dropped it in the middle of the 20 spams around it
<jdub> heh
<seb128> hate hate spams
<psy_> er
<psy_> re
<psy_> :P
<daniels> jdub: BBBBBBBEEEEEEEEEAAAAAAAAGGGGGGGGGLLLLLLLLLEEEEEEEEEEEE
<trukulo> daniels, WHERE ???
<dholbach> wb daniels :-)
<psy_> BEAGLE?
<daniels> trukulo: dunno, but I want it in universe :)
<trukulo> daniels, me too, i'm trying to compile it
<trukulo> just now
<daniels> i can compile and use it just fine on my laptop :)
<trukulo> but i have problems compiling it
<daniels> it just needs an eager packager
<daniels> oh?
<daniels> i just followed HoaryBeagleInstallGuide
<trukulo> with one line: ./DBusisms.cs(67) error CS0117: `DBus.BusDriver' does not contain a definition for `NameOwnerChanged'
<ogra> daniels, quick, port it to amd64 :-P
<trukulo> i dont't compile any packages, just use everything from hoary
<trukulo> have to work, but it doesn't
<dholbach> yeah daniels: i will even say "please" :-)
<daniels> ogra: it works on amd64 just fine; just needs repackaging for 1.1
<daniels> trukulo: weird ... i think i was using latest cvs
<ogra> dholbach, wb
<trukulo> daniels, i'm using 0.0.7 from web
<dholbach> ogra: one ctrl-w too much :-)
<trukulo> not cvs, perhaps that's the problem
<daniels> trukulo: i'll just update and rebuild cvs and see if it works ok or if i was on crack :)
<trukulo> daniels, i'll use cvs too, then
<trukulo> thanks for info ;)
<trukulo> but tseng is working on package for universe
<daniels> awesome
<daniels> tseng: my hero
<trukulo> :)
<daniels> trukulo: 
<daniels> make[1] : Leaving directory `/home/daniels/src/beagle/beagle'
<daniels> make clean all  45.76s user 4.50s system 53% cpu 1:33.16 total
<daniels> daniels@catsby:~/src/beagle/beagle%
<trukulo> ok, daniel, i'm going to try it
<trukulo> You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
<trukulo> Running aclocal  ...
<trukulo> aclocal: configure.in: 113: macro `AM_CXXFLAGS' not found in library
<trukulo> aclocal: configure.in: 128: macro `AM_CXXFLAGS' not found in library
<trukulo> failing for me :P
<trukulo> i think i'll just wait for tseng package
<trukulo> i'm very bad at compiling things
<daniels> try this: sudo apt-get install automake- automake1.4- automake1.6- automake1.7
<trukulo> automake 1.7 not installed, could be this
<trukulo> seems to work now, thanks
<daniels> no worries :)
<daniels> automake is ... um ... annoying like that
<daniels> right now 1.7 seems to be the spot where everything works
<trukulo> i'll note that as important here
<trukulo> now seems to compile fine
<daniels> cool :)
<trukulo> System.DllNotFoundException: dbus-glib-1 in <0x00053> (wrapper managed-to-native)
<trukulo> compiled, but doesn't work well :) anyway, thanks, i'll look at it now
<daniels> trukulo: sudo apt-get install dbus-glib-1 :)
<trukulo> it's installed
<daniels> hmmmmm
<trukulo> DEBUG: Initializing D-BUS
<trukulo> FATAL: Could not initialize Beagle's bus connection.
<trukulo> FATAL: System.DllNotFoundException: dbus-glib-1
<trukulo> strange
<daniels> hmm
<daniels> OH!
<daniels> dbus-glib-1-dev
<daniels> it just tries to open the .so
<trukulo> that's it !
<trukulo> daniels, thanks, installed and working
<ogra> AAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHH
<ogra> http://backports.ubuntuforums.org/backports/dists/hoary-backports-staging/main/binary-i386/
<mjg59> daniels: Did you see my messages about i915?
<trukulo> WARN: Could not open /dev/inotify
<trukulo> :P too beutiful to be real
<daniels> mjg59: something about broken or seomthing
<daniels> trukulo: heh :) you need to boot with the 'inotify' option
<ogra> trukulo, enable it with the inotify bootopton
<trukulo> ah, thanks for info !
<trukulo> i love you ppl
<trukulo> rebooting then
<ogra> hmm, should we have told him hat it may lock up his system ?
<ogra> that even
<jordi> Kamion: did you have time to play with nano 1.3.5+cvs?
<torkel> shouldn't beagle work without inotify?
<torkel> it was just a warning...
<mjg59> daniels: By default, it's setting the video RAM too low to get working 3D. If I set the VideoRam parameter, nothing seems to change
<ogra> torkel, dunno, i dont even have mono on amd64 yet
<dholbach> bbl
<daniels> mjg59: bong
<daniels> mjg59: i've never played with real i915 hardware, but it may have a hostile bios
<daniels> mjg59: can you ramp up the allocation in the bios itself?
<trukulo> f*g hell , when i use inotify, my system halts when gnome is loading
<daniels> trukulo: yep :\ that's why it's not enabled by default
<mjg59> daniels: Nope
<torkel> trukulo: you should not have to use inotify with beagle
<daniels> trukulo: it works for some people, but breaks for other
<daniels> s
<daniels> mjg59: craaaack.
<mjg59> daniels: Indeed
<mjg59> What's irritating is that there's nothing in the logs about videoram
<mjg59> (other than Not enough to enable DRI
<mjg59> )
<torkel> they removed the inotify dependency i 0.0.7
<trukulo> torkel, i read about that, but beagle gives me a warn (dev/inotify not found) and haven't got any result in querys
<daniels> mjg59: ugh
<daniels> mjg59: it should bomb really loudly when it fails to up the amount
<daniels> should -> i think it does, not should -> it would be nice if
<mjg59> Hrm. Ok, I'll try debugging later on
<mjg59> (need to go to the pub now)
<trukulo> umm, no results for me in beagle, strange
<trukulo> Access to the path "/home/trukulo/.beagle/WebHistoryIndex/Index" is denied <- should be that
<trukulo> ERROR: Caught exception while instantiating Files backend
<trukulo> ERROR: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.IOException: Lock obtain timed out: Lock@/home/trukulo/.beagle/FileSystemIndex/Locks/lucene-673d9197cc718c7fe4242669f5ede4af-write.lock
<trukulo> more problems there , umm
<Treenaks> uh, remove .beagle & try again?
<trukulo> i did
<trukulo> sorry, don't want to disturb more here, forget it
<tsume> hmmmm
<tsume> so how does the ubuntu development differ from debian in the eyes of the developers?
<tseng> beagled needs xattr?
<tseng> wow
<tseng> daniels: beagle worksforme!!!
<tseng> http://tseng.ath.cx/beagle.png indexing away.
<tseng> hm it doesnt like our evo-sharp
<daniels> tseng: awesome!
<daniels> right now it's bedtime though
<daniels> g'luck with it :)
<tseng> thanks.
<_d4vid> ky all
<lamont> seb128: there's a reason I didn't mark that one critical...
<seb128> lamont: ?
<lamont> the ia64 bugs
<srbaker> tseng, what's the icon to th eleft of muine?
<tseng> update-manager
<tseng> system - admin in your menu
<srbaker> ahh
<srbaker> tseng, what theme is that?
<tseng> clearlooks
<srbaker> cool
<srbaker> nice.  that's my new theme
<tseng> yeah
<tseng> mine is actually -bluesky or whatever
<tseng> im off for the day
<tseng> have beagle working w/ e-d-s now also
<tseng> will hack tonight maybe
<lamont> morning mdz
<mdz> morning
<lamont> just tossed you a hoary-test update
<lamont> mdz: btw, what severity do you want on the ia64 failures?  Been using 'normal'
<lamont> although I would prefer to have nothing in the archive that we can't rebuild from source...
<herve> including universe?
<lamont> herve: if it doesn't build from source, it shouldn't be there.  The only way it got there is that _at_some_prior_point_in_time_ it did build
<herve> so you mean we used to recompile debian imports when the sync was automatic?
<lamont> all binaries in the archive have been built on data center buildd's.
<lamont> there are no binary syncs
<herve> good
<lamont> have to rebuild them against our libraries, etc.
<herve> but that doesn't explains how gcompris got in there :-)
<lamont> so the only keys that can upload binaries to the archive are the buildd keys.
<lamont> and they can't upload source.
<lamont> ??
<lamont> it built
<lamont> or it's not there
<herve> I had to add a build dep
<herve> it's problematic anyway
<herve> the motu is taking care of it
<lamont> http://people.ubuntu.com/~lamont/buildLogs/g/gcompris/6.1+6.3RC2-3/
<lamont> is the original build of it.
<herve> yes but the newest failed
<lamont> yes
<lamont> and you'll notice that the latest i386 binary in the archive is the prior revision.
<lamont> all nice an consistant
<lamont> ent even
<herve> good point
<herve> I think gcompris is turning me mad :S
<lamont> which is to say, gcompris is perfectly explainable. :-)
<lamont> well, at least why it's in the archive is...
<thom> ogra/jdub: mind if i NMU xscreensaver to removed the APPROVED crap?
<mdz> lamont: why does mplayer have an mplayer-custom binary in the archive? that shouldn't be
<zenwhen> it doesnt even install
<herve> by the way, there are still packages of gnome 1.4 in the archive :-)
<HiddenWolf> You're kidding me
<zenwhen> thats pretty funny
<herve> -dev packages mostly
<herve> check libgnome-dev
<herve> libgnomemm-dev
<herve> libgnomeprint-dev
<herve> some other but I won't list them all :-)
<mdz> fabbione: ping, re: mplayer
<fabbione> mdz: pong
<fabbione> ( i don't have heaps of time today )
<ogra> thom, i have my patch nearly ready
<mdz> fabbione: never mind, it looks like it is correct, only mplayer-custom remains in the Packages file for some reason
<fabbione> mdz: ok
<fabbione> there is one problem tho
<mdz> elmo: mplayer-custom has not been built by mplayer for a week or so; when will it fall out of Packages?
<fabbione> for one mistake the _ppc.deb did build empty once
<fabbione> whilt it should have been a FTBFS
<fabbione> mdz: are you sure none of the packages acutally provides it?
<ogra> thom, wanted to apply it tomorrow....but if you feel its urgent, go ahead
<mdz> mplayer-386 | 1:1.0-pre6-0.3ubuntu6 | hoary/multiverse | i386
<mdz> mplayer-custom | 1:1.0-pre5-0.6ubuntu1 | hoary/multiverse | i386
<mdz> the version in the archive is from an older version of the source package
<fabbione> ah ok
<thom> ogra: ok, if you're doing it tomorrow i'll wait :-)
<ogra> :)
<herve> you seem not to be in a hurry :-)
<ogra> just needs some small tweaks and i wanted to look at the ESC key thing
<sabmoc> who judges the artwork for the breazy badger logo?
<sabmoc> I would like to submit a few WIP's and get some feedback
<LBM> what steps is used to generate the initial ubuntu Xorg configuration?
<Dillweed> hello all.  I am currently using the nvidia drivers in hoary and get about 4550 FPS on my graphics card.  I also dual-boot with Gentoo and get about 6550 FPS.  Xorg.conf are the same.
<Treenaks> Dillweed: 
<Treenaks> FTP with what, and #ubuntu is the support channel, this is the development channel
<Dillweed> i understand that.  I'm using glxgears.  I was wondering if this was a bug or not.
<Dillweed> i mean a difference of 2000fps is huge.
<Treenaks> glxgears is not a benchmarking tool.
<Dillweed> i know.  but it was an informal test.  I would of not cared if it was 100fps difference.  I would of taken that as chance, but 2000 is huge and random
<Treenaks> Dillweed: what kind of CPU do you have?
<Dillweed> Treenaks, athlon-xp 2000+
<Treenaks> that shoudn't be much of a problem either
<Treenaks> don't have a clue. complain at nvidia
<Dillweed> i guessing that it is optimization problem?
<Treenaks> no
<Treenaks> very unlikely
<Dillweed> you think so?  that's basically the only difference between my systems though.
<Treenaks> nvidia driver version
<Dillweed> 6629
<Treenaks> you sure that's the same?
<Treenaks> on both?
<Dillweed> yes
<Treenaks> weird.. I have no clue, I'd blame nvidia
<Dillweed> I know my systems :)
<Treenaks> (them being the only uncontrollable factor in this)
<Dillweed> possibly, but i don't think so.  
<ogra> its _very_ likely (naerly sure) that nvidia is to blame
<Dillweed> the driver is the driver and interfaces with the kernel.  maybe I'm using a tweaked kernel in gentoo and not ubuntu
<Treenaks> Dillweed: are you using the -k7 kernel?
<Dillweed> yes
<Treenaks> then it's tweaked already
<herve> Dillweed, same xorg and kernel versions?
<ogra> btw, please move this to #ubuntu, this is not a support channel
<herve> apart from -k7
<Dillweed> i moved it to ubuntu but no help
<Dillweed> I'm wondering if it is a compiled problem.
<ogra> anyway, this is for ubuntu development...
<ogra> so please keep it over there
<Dillweed> I'm using hoary if that makes a difference
<Treenaks> Dillweed: #ubuntu -- the IRC channel
<Dillweed> i'm there.
<Treenaks> Dillweed: ask there, not here then
<Dillweed> geez not enough sleep.  thanks anyways.  I thought ubuntu was a helpful environment.
<herve> Dillweed, search and ask lists too
<ogra> Dillweed, its a nvidia problem, if nobody answers you it might e because only nvidia can help
<ogra> s/e/be
<Dillweed> ogra, i don't understand.
<ogra> Dillweed, we cant change the driver, only nvidia can
<ogra> and we dont know whats going on in the binary..
<Dillweed> understandable, i'll keep looking.  It doesn't look like I'll get help here.
<wasabi> I have a cyclic dependency I need to force. =(
<stuNNed> hi which package if any is gst decodebin in ?
<dholbach> stuNNed: apt-file search decodebin - this is more of a #ubuntu question
<stuNNed> dholbach: yes sorry, will do next time
<dholbach> stuNNed: np
<schweeb> packages.debian.org is a big help too
<schweeb> if you don't want to keep apt-file updated
<schweeb> dunno if there's a ubuntu equivalent to packages.d.o
<stuNNed> thanks guys /me keeps mouth shut :)
<dholbach> stuNNed: nobody told you to shut up :-)
<stuNNed> :D
<tsume> slirp/misc.o(.text+0x2a): In function `getouraddr':
<tsume> /home/tsume/qemu/slirp/misc.c:96: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
<tsume> how can I correct this?
<WebMaven> Hi folks. I think th lib.e Python included in Ubuntu is missing a part of the standard
<WebMaven> Ahem, I meant: I think the Python included in Ubuntu is missing a part of the standard lib.
<WebMaven> specifically, import profile fails.
<WebMaven> and it doesn't look like the profile module is installed anywhere.
<schweeb> chris@omglaptop:~$ apt-cache search python2.4 profile
<schweeb> python2.4-profiler - deterministic profiling of any Python programs
<schweeb> that what you're lookin for?
* tsume sighs
<tsume> erm
<tsume> why isn't wxWidgets packaged for hoary?
<ajmitch> tsume: it is
<ajmitch> it is in universe
<Amaranth> does wxwidgets finally use gtk 2.x?
<tsume> ajmitch: erm
<tsume> ajmitch: universe?
<tsume> ajmitch: I didnt see anything in dselect ;)
<ajmitch> tsume: yes, the universe component of hoary
<ajmitch> check your apt sources.list then :)
<Amaranth> tsume: you use dselect?
* Amaranth spits
<tsume> Amaranth: so? :)
<tsume> ajmitch: oh I see.
<tsume> ajmitch: so universe is user contrib?
<WebMaven> schweeb, no, it's not. I want to be able to do 'import profile'.
<WebMaven> http://docs.python.org/lib/profile.html
<ajmitch> tsume: mainly it's packages imported from debian unstable that aren't officially supported 
<tsume> ajmitch: oh.
<tsume> ajmitch: so I'd be breaking my system if I wasn't careful. Okay
<dholbach> tsume: http://www.ubuntulinux.org/wiki/UniversePackages/view?searchterm=universe
<ajmitch> 'not officially supported' doesn't mean they'll break your system :)
<tsume> ajmitch: debian packagers are pretty stupid, I've tried -unstable before
<ajmitch> tsume: many of the ubuntu developers are debian packagers, so I'd not say that..
<tsume> ajmitch: so they just create crap for debian and have it come out polished for ubuntu, cuute :) hah
<Kamion> er, no
<kylem> maybe you're just a moron.
<kylem> *plonk*
<dholbach> hey guys
<tsume> kylem: I don't think so, I tried -unstable debian _several_ times
<tsume> kylem: *plonk* to you as well ;)
<Amaranth> tsume: You're talking to a lot of debian developers here...
<Amaranth> tsume: Some of them may or may not have the power to ban you. :P
<Kamion> yes, most people here are pretty familiar with Debian unstable and its strengths and weaknesses; but discussion thereof is not on-topic here
<tsume> Amaranth: thats because all I see from debian are assholes who like thumping on people who are less fortunate to find manual material
<tsume> mainly cafuego is an example
<Amaranth> tsume: You can stop now.
<Kamion> Ubuntu is not intended as a Debian-bashing forum
<tsume> kylem: I know this.
<jbailey> tsume: Did you figure out your glibc stuff?
<Kamion> WebMaven: yes, that's in the python-profiler package. There are licensing issues with it, so it's separate.
<helix> tsume: cafuego is not a debian developer, fwiw
<Amaranth> the profiler license says it can only be used for python, right?
<tsume> jbailey: I did, it was a silly configure option. If you don't build qemu all the way with every target-list (i386, ppc, arm) then it will error
<tsume> the warning wasn't important
<Kamion> Amaranth: right
<ajmitch> Amaranth: it's quite annoying
<tsume> jbailey: there was actually more beneath the warning which was making it stop the build
<Amaranth> i bet
<jbailey> tsume: Cool.  Also in general, you can't static link an app that has anything to do with authentication, or database lookups (dns, etc...)
<tsume> helix: I know, but he is like dblack of the ruby community. He is suffering from big penis symdrome and has some power over the support and project people wise.
<dholbach> tseng: hey, will you please drop it
<tsume> jbailey: well :) heh I figured that out. 
<dholbach> oops
<dholbach> tsume: ^ 
<tsume> jbailey: I usually only use BSD, but the laptop is an exception :)
<dholbach> tseng: sorry for that :-)
<tsume> dholbach: I'd appreciate it if you didn't interrupt
<tsume> dholbach: I was answering a statement.
<Kamion> tsume: cafuego has no power over the Debian project people-wise, and again, this discussion doesn't belong here
<tsume> is there a 'multiverse' in hoary?
<dholbach> tsume: is that so? well, i think for most in here: this is a development channel and nobody really cares who you can't stand
<Kamion> tsume: yes
<dholbach> ...i think i speak...
<tsume> what does multiverse compose of?
<Kamion> non-free unsupported packages
<tsume> okay.. :) then what is the difference between multiverse, and universe?
<Kamion> universe => free unsupported packages
<tsume> ohh..
<zenwhen> and superverse is where the candy and drinks are kept
<Kamion> tsume: http://www.ubuntu.com/ubuntu/components
<tsume> hehe..
<dholbach> tsume: i referred to a link to the wiki a few minutes ago
<LinuxJones> guys there are a couple of idiots spamming #ubuntu can someone pop in and make them stop ?? NeWXeR and Groil
<tritium> can anyone point out a package that has a good watch file for sourceforge.net that I can learn by example from?
<WebMaven> Kamion, but isn't that part of the standard python library? Wouldn't that out it under the Python license?
<Kamion> WebMaven: it is part of the Python standard library, but it is not under the unmodified Python license
<Kamion> WebMaven: see http://www.python.org/doc/2.4/lib/node829.html
<Kamion> we've been discussing the issue with upstream
<Kamion> (not me personally though, so don't ask me for more detail than that :-))
* Amaranth bbl
<tsume> where can I request software for packaging?
<tsume> widestudio is an excellent toolkit, and stabple, but debian still have the 4 year old version
<tsume> *stable
<tsume> 4 years old is too long, the new release 3.90-1 has even java support :)
<mdz> tsume: www.ubuntu.com/wiki/MOTU
<mdz> these things go faster if you offer to help, rather than complaining about the current situation
<tsume> mdz: I can help! :)
<tsume> mdz: widestudio is important to me, and I use it on a daily basis. I know its stable
<tsume> mdz: heh.. masters of the universe.. hehe :)
<wasabi> widestudio (3.50-2-2) unstable; urgency=low
<wasabi>   * Orphaned this package.
<tsume> it needs to be deleted
<tsume> many debianers on a few MLs were getting confused at WideStudio because I told them about it, and they immediately went to the archive instead of the website
<mdz> it doesn't need to be deleted just because it's an old version
<tsume> mdz: and what about the bugs and exploits?
<mdz> tsume: there aren't any reported
<IamNEGATIVECREEP> hi
<IamNEGATIVECREEP> alguem fala portugues?
* ogra kicks "man strcmp"
<ogra> who writes such crap...
<stuNNed> good manpages *with* examples are key imho
<ogra> It returns an integer less than, equal to, or greater than zero if  s1  is  found
<ogra> so how do i know if the strings match ??? man, they should learn to explain it right...
<wasabi> So what's the process to get something moved from multiverse to universe?
* sabmoc is away: onBlur();
<thom> wasabi: prove to elmo that the license is Free
<wasabi> okay. this is odd then.
<wasabi> http://people.ubuntu.com/~lamont/buildLogs/Lists/hoary.all.i386
<wasabi> notice bcel. It's depwaiting on j2sdk1.4 isn't it?
<wasabi> (trying to interpret)
<wasabi> however, it doesn't actually depend on j2sdk1.4 anymore
<Amaranth> anyone here know how the fd.o menu spec works?
<Amaranth> i've got an applications.menu file in ~/.config/menus/ that merges user entries into the GNOME menu but it doesn't replace system ones with their user versions
<Amaranth> like if i have testingthis.desktop in the system menus and the user ones it uses the system one
<doko> LANGUAGE is a colon separated list of locale names, is there a reason why the encoding is not included in the locale names?
<doko> kamion: ^^^
<lamont> wasabi: you need something cleared?
* lamont applies a sledge hammer
<lamont> wasabi: I have informed the buildd that j2sdk1.4 is there.
<wasabi> It's not there. ;)
<lamont> mind you, that's a lie
<wasabi> k
<wasabi> Just to test, for future knowledge, I did a second upload.
<wasabi> I was just curious if it would bump it.
<lamont> but it's easier than taking the one package, and giving it back
<lamont> it won't
<wasabi> In case you get hit by a train someday.
<lamont> dep-waits are forever
<wasabi> oh.
<WebMaven> Kamion, thanks for the pointer.
<wasabi> Seems like depwaits should update if there is a new version available. ;0
<lamont> there are lamont-backups
<lamont> and there are times it seems they shouldn't.
<ogra> thom, a present for you....
<dholbach> lamont: tritium nearly cleared the whole defoma list, it's done now
<lamont> sometimes the depwait is not immediately obvious from looking at the package, etc.
<ogra> (hope it builds everywere)
<lamont> dholbach: woot
<dholbach> :-)
<WebMaven> The zope3 package depends on the presence of the profile module (at least for running the unit tests)
<wasabi> lamont, j2sdk1.3 also
<wasabi> for rhino
<wasabi> my other package in question. ;0
<thom> ogra: new screensaver? oooooh oooooh oooh
<ogra> :)
<ogra> didnt fix the ESC key thing yet, but designwise it should be k now
<doko> WebMaven: please could you file a but report
<lamont> wasabi: done
<wasabi> thanks!
* thom waves at mjg59
* lamont goes into town with the kids for a bit.
<dholbach> lamont: have fun :-)
<lamont> oh yeah.  loads.
<dholbach> good :-)
<ogra> lamont, what do they bite ?
<ogra> *g*
<Loevborg> thom, your nickname upsets me - each time I see it, I wonder if you might be the real thom. disappointment quickly ensues.
#ubuntu-devel 2005-03-31
<mjg59> thom: Hi
<ogra> Loevborg, he is the real thom
<mdke> thom yorke?
<Loevborg> mdke, *nod*
<mdke> whoa
* mdke mobs thom and gets his autograph
<thom> heh
<mjg59> thom: Ok, we got logs from the lolotop
<mjg59> It ran the powerbutton script immediately after the resume had finished
<thully> For several reasons (I don't enough time,  and I need something more stable as my primary OS) I will be unable to continue running/testing/reporting bugs in the development version of Ubuntu.  What should I do with my bug reports?  Is there a way to "release them" - that is, take my name off them?
<mjg59> Nope
<mdke> thully, i will watch the firefox one
<thom> Loevborg: it's not my nickname
<thom> *anyway*
<mjg59> thom: I /suspect/ that it's not actually handling the event until the previous event has exited, so we end up with the same problem
<Loevborg> thom, what does that mean metaphyiscally?
<thully> sorry - I just am at a time where I need to be able to depend on my laptop suspending, resuming, getting online etc.  Hoary does this most of the time, but I find that things go wrong at exactly the same time.
<thom> mjg59: meh
<thully> s/same/wrong
<thom> mjg59: acpid should clear the even if it's locked
<thom> event
<thom> Loevborg: it's my _name_
<mjg59> thom: I don't think acpid_handle_event returns until the script has exited, at which point the lock gets removed again
<thom> aaah, ew
<mjg59> thom: So I think our best bet is to have a helper script that sleeps and then removes the lock (which is horrible, but, well)
<thom> yeah, i think you're right. nod
<Loevborg> oh ok.
<thully> I think maybe I should just stick to the stable releases (of Ubuntu, another distro, or another OS altogether) for now - It's not a good sitution if you have trouble w/your internet connection and have something that needs to be done
<zul> hey
<thom> thully: sure; if you're not comfortable running unstable software, don't
<mjg59> Hmm. Right. I should go to bed soon, and then spend the day hacking acpi
<thully> I got started running Hoary when Warty didn't support suspend very well on my laptop (either 10% usage/hour or nothing - no swsusp even)
<dholbach> hey zul
<thully> If I had a test machine, I'd run it on that - but I currently only have one system (and I'm actually sending it for warranty work next week)
<mjg59> It's still the case that ACPI suspend is highly experimental under Linux, which is why it's disabled by default
<thully> to disk, to RAM, or both?
<Loevborg> thully, both.
<zul> oooh...what did i miss..
<mjg59> To disk is enabled by default, and works in most use cases
<thully> I would use APM (my system supports it) but apparently you can't do speedstepping in APM
<mjg59> You ought to be able to
<mjg59> You'll lose other aspects of CPU power management though
<mjg59> Kamion: Is man supposed to be attempting to use unicode hyphens on the Linux console?
<thully> Well, I'd like to avoid the OS That Can Not Be Named, but laptop support appears to still be a bit troublesome in Linux...
<mjg59> If you want laptop support equivilent to that offered by Windows, your choices are Windows or MacOS X
<zenwhen> works fine on my laptop
<mdke> lol
<thully> and I really can't fix it myself at this time
<mjg59> Linux laptop support has improved massively over the past year, but we still can't offer the same level of functionality
<thully> suspend and wireless are the big issues at this point - although I actually think I have one of the better supported laptops
<mdke> you have to buy the right laptop i guess
<thully> well, I think mine is about as good as it gets - suspend and wireless work fine, but are still a bit buggy
<zenwhen> The orinoco gold classic is the solution to linux wireless issues.
<thom> ipw* work fine
* thom radiates hate at cdbs
<helix> thom: why?
<ogra> :)
<thully> yes - most of my issues are wireless after resume from suspend, and switching internet connections (from wi-fi, to PPP, and back...)
<Loevborg> zenwhen, those are impossible to get a hold of at a decent price, at least here.
<thom> helix: obfuscation bad, mmmkay?
<jbailey> thom: You must hate debhelper and debuild then. =)
<helix> it's not that obfuscated
<thom> jbailey: i don't count debhelper as obfuscated, since it's utterly obvious from the rules file what the intent is :-)
<zenwhen> Loevborg, that is unfortunate. All i had to do was plug mine into my pcmcia slot, and it ifup'd as eth0
<jbailey> thom: I find the same with cdbs. =)
<helix> thom: you should use yada
<thom> helix: heh
<mjg59> Whee
<thom> jbailey: give me docs then, so i can decipher other people's cdbs
* mjg59 manages to almost solve the video out issues
<jbailey> thom: Working on it. =)
<mjg59> daniels: Argh. It can't change RAM size because AGP hasn't been loaded.
* mjg59 needs to add extra PCI IDs
<Kamion> mjg59: I uploaded a version of groff to Debian on Friday that turns that off; it's awaiting a sync to Ubuntu. (By the way, groff has no clue whether you're on the Linux console or not. Nor does man, for that matter.)
<mjg59> Ah
<Kamion> ogra: 'man strcmp' is pretty clear if you read the next line and know what the word "respectively" means. :-)
<thully> OK, then - I may regretfully end up installing that other OS... maybe I'll take a look at Hoary final first, and possibly SUSE (they have pretty good laptop+wireless support)
<ogra> Kamion, docbook was ore helpful ;)
<ogra> more even
<Kamion> It returns
<calc> cdbs isn't hard to understand :)
<Kamion>        an integer less than, equal to, or greater than zero if  s1  is  found,
<Kamion>        respectively, to be less than, to match, or be greater than s2.
<Kamion> ogra: i.e. "less than zero if s1 is found to be less than s2; equal to zero if s1 is found to match s2; greater than zero if s1 is found to be greater than s2"
* calc dislikes cdbs for other reasons, but understanding it isn't one of them
<Kamion> doko: no idea, I don't really understand LANGUAGE and I've never found a clear spec for its contents
<ogra> Kamion, after all it just should say it returns zero if the strings match :)
<Kamion> ogra: it DOES
<Kamion> if you know what the word "respectively" means (which is pretty standard in English developer documentation IME)
<ogra> Kamion, if you studied english ....
<Kamion> if you didn't, you should use a translation of the documentation :)
<ogra> heh, true
<thully> Bye everyone.  Thanks for all the ACPI work.
<ogra> Kamion, i was just a bit logically barred :) 
<mdke> man pages aren't supposed to be easy to understand ;)
<zul> heh..we got into this arguemnet at work yeserday
<mdke> lol
<ogra> mdke, if i have slept enough and didnt drink half a bottle of wine before reading them, i normally understand what they say :)
<mdke> ogra, if you finish the bottle, you'll understand em
<ogra> lol
<ogra> mdke, i'm near...
<Kamion>        Die Funktion strcmp() vergleicht die beiden Strings s1 und s2 miteinan
<Kamion>        der. Sie gibt eine ganze Zahl kleiner,  gleich  oder  grer  als  Null
<Kamion>        zurck,  wenn  s1 gefunden wurde und kleiner, gleich oder grer als s2
<Kamion>        ist.
<mdke> lol
<ogra> Kamion, yup, i already understood it ( xscreensaver is uploaded already) ;) but still the above i said would be an easier explanation
<ogra> even in german
<Kamion> I'm just resentful that people keep trying to blame unclear writing on the documentation format :P
<dholbach> add dates here: http://www.ubuntulinux.org/wiki/Calendar :-)
<zul> Kamion: heh then you dont want to work with the people i work with ;)
<thom> Kamion: heh
<ogra> Kamion, i know its my fault if i dont understand a man page in the firtst place, but one could make i easier for drunken people ;)
<jdub> gooooooood morning freedom lovers!
<dholbach> hey jdub 
<ogra> morning jdub 
<Kamion> writing documentation that's clear to drunken non-native speakers is, er, a challenge in general ;)
<Kamion> anyhow, gotta go
<zul> he jdub
<dholbach> bye Kamion 
<dholbach> jdub: may i point you to wiki/Calendar and invite you to the MOTU Meeting? :-)
<jdub> heh, that's not such a great time for me ;)
<jdub> but possibly
<ogra> jdub, we'd like to discuss some release manager related things there
* dholbach finds xscreensaver in the updates... :-)
<mdke> has anyone got a menu editing frontend in universe yet?
<ogra> jdub, btw, xscreensaver uploaded, objections go to my place...
<dholbach> mdke: ask Amaranth 
<jdub> ogra: ah cool, thanks
<Amaranth> I sort of do.
<mdke> dholbach, oooh that's already a partly positive answer
<mdke> Amaranth, yay#
<Amaranth> I need help with the menu spec before I can go any further with it.
<Amaranth> http://dev.realistanew.com/menu-editor/
<mdke> is that the one posted on the forum
<Amaranth> one of them
<Amaranth> check the screenshot in that dir
<mdke> yeah looks pretty cool
<mdke> is it systemwide or userwide?
<Amaranth> systemwide
<Amaranth> i'm working on user ones right now
<mdke> awesome
<mdke> thanks very much on behalf of us all
<Amaranth> i can make new entries show up just fine but i should be able to override system ones with user ones (so you can 'change' the users ones) but it isn't working
<mdke> Amaranth, maybe it is a limitation with gnome
<Amaranth> err, so you can 'change' the system ones
<Amaranth> i'm starting to think so
<mdke> is it packaged? i can't help you out but I can test if you like
<Amaranth> well, no, because it doesn't work in python-xdg either
<mdke> k
<Amaranth> no, no packages yet
<Amaranth> i want to get this fixed and allow deleting entries first
<mdke> k
<mdke> you seen that guide on the gnome site about how to do it manually?
<Amaranth> o_O
<Amaranth> I've been looking
<Amaranth> URL>
<Amaranth> ?
<mdke> erm
<mdke> i copied it onto our wiki
<mdke> GnomeMenuEditingHowTo
<mdke> someone posted it in bugzilla
<Amaranth> that's old
<mdke> oh
<Amaranth> that's vfolder junk
<mdke> doesn't work?
* mdke scraps wiki page
<zenwhen> Amaranth, your current menu editor has made my day
<zenwhen> :)
<Amaranth> hehe
<Amaranth> the new one will work without root and have a delete button :P
<zenwhen> my menus now contain a lot of things they should have
<Amaranth> if it ever gets released
<zenwhen> sounds nice
<srbaker> is anyone else here experiencing 'issues' with icons in gnome?
<srbaker> when i install software, the icons aren't recognized until after i log out and log in, often.
<srbaker> it's not really reproducable because it's not consistent
<Amaranth> srbaker: you mean on the menus?
<mdke> normal surely?
<mdke> killall gnome-panel will do it
<Amaranth> the menus are funny
<srbaker> Amaranth, yeah
<Amaranth> sometimes you need to kill the panel to make changes work, sometimes you don't
<srbaker> that's weird
<srbaker> what's the green dot that a lot of people seem to have in their panels?
<Amaranth> battery?
<Amaranth> do you have a screenshot?
<srbaker> http://www.oreillynet.com/network/2004/10/18/graphics/ifolder-icon.jpg
<srbaker> third from the left
<mdke> updates?
<srbaker> is that what that is?
<srbaker> update manager?
<Amaranth> no
<srbaker> i installed update-manager and update-notify but i can't seem to get the panel applet, either
<srbaker> but i haven't fucked around with that yet
<Amaranth> the notification icon only shows up when you have upgrades
<thom> srbaker: it's gossip
<srbaker> thom, what's gossip?
<srbaker> oh, the icon
<srbaker> cool
<srbaker> thanks
<jdub> srbaker: you do need to ensure that update-notifier is running in your session
<srbaker> jdub, i haven't logged out and logged in since i installed it
<jdub> so run it :)
<jdub> aha, good, kubuntu on slashdot
<jdub> ha ha ark linux
<zul> finally..
<Amaranth> isn't ark based on debian too?
<mdke> Amaranth, is it cool if I post your menu editor on that wiki page (have removed vfolder stuff)
<mdke> ?
<Amaranth> mdke: sure
<mdke> ty
<Amaranth> you put it on first, then asked for permission :P
<jdub> "Before people go like "Why doesn't Canonical make one cd with both KDE and Gnome?", let me put it this way: the same reason why they don't make one big DVD like Fedora."
<mdke> nope
<jdub> ^ ha ha
<mdke> Amaranth, i asked for permission, then saved the page
<Amaranth> oh
<Amaranth> i refreshed right away and i guess i got in right after your save
<mdke> :)
<Amaranth> jdub: someone said something about a DVD
<Amaranth> said they wanted more apps
<jdub> we're already building DVDs
<srbaker> jdub, isn't ubuntu with gnome only hard enough to fit on one cd?
<mdke> Amaranth, yeah i saw that
<mdz> daniels: me: "is this the same bug, or a different bug?" you: "yeah" -- which one?
<jdub> srbaker: not enormously hard, but it is getting harder.
<Amaranth> does anyone here know anything about the fd.o menu spec?
<srbaker> jdub, i am very impressed that ubuntu fit on one cd
<Amaranth> i swear they intentionally made it hard...
<azeem_> "it'll always be 1 CD" -- James Troup
<srbaker> hehehe
<jdub> azeem_: that's the intention, yes
<thom> mdz: popcon is waiting on me getting it cronned up and happy, then i'll announce it
<daniels> mdz: erk.  yeah -> same.
<mdz> daniels: cool, thanks
<mdz> thom: ETA?
<thom> mdz: monday
<mdz> stupendous
<ogra> so could someone tell me why my laptop just shot down unintentionally ?
<zul> gremlins?
<ogra> hrm
<ogra> i'm not amused, lost a lot of unsaved stuff....it happend out of the blue...
<dholbach> ogra: syslog?
* Amaranth rips into kmenuedit
<ogra> dholbach, nothing
<ogra> hmm...
<ogra> Mar 20 01:25:18 localhost kernel: psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
<ogra> Mar 20 01:25:18 localhost last message repeated 4 times
<ogra> Mar 20 01:25:18 localhost kernel: psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched.
<ogra> Mar 20 01:25:18 localhost kernel: psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4
<ogra> zul ideas ? looks like the kernel
<zul> weird
<ogra> in fact there seem to be a lot of these messages
<zul> when did it first start?
<dholbach> ogra: you flew out 1:17 of my time
<srbaker> hrm
<srbaker> update-notifier is running, but i don't seem to be getting a desktop icon for it
<srbaker> jdub, what's the "gnome way" of notifying other applications of something?
<ogra> dholbach, 1:37 here now...
<ogra> dholbach, does that match ?
<dholbach> ogra: yeah
<srbaker> jdub, i've been thinking about doinga Growl compatible client for Gnome (growl.info)
<ogra> k
<srbaker> it's for user notification
<ogra> ARGH
<ogra> ar 20 01:17:58 localhost kernel: ext3_orphan_cleanup: deleting unreferenced inode 734214
<ogra> Mar 20 01:17:58 localhost kernel: ext3_orphan_cleanup: deleting unreferenced inode 1322015
<ogra> Mar 20 01:17:58 localhost kernel: ext3_orphan_cleanup: deleting unreferenced inode 1321933
<dholbach> :-(
<Amaranth> heh, kmenuedit doesn't work either
<Amaranth> i'm calling this what i'm almost positive it is now: a gnome-menus bug
<ogra> WHAT ????
<ogra> Mar 20 01:16:31 localhost shutdown[21527] : shutting down for system halt
* ogra cant belive that
<jdub> srbaker: there's no blessed system yet
<srbaker> jdub, would something that's Growl compatible be appreciated, or are there more gnomeish ways to accomplish this?
<jdub> it's a huge discussion with no good answer for you
<srbaker> oh
<srbaker> so if i just ran out and wrote it, it might be a good idea
<jdub> could be
<srbaker> i kinda want a growl compatible system for other software i'm using anyways.
<lupusBE> jdub, how long does it take for packages to be in http://changelogs.ubuntu.com/changelogs/pool/main/g/ ?
<jdub> i'm not sure
<lupusBE> and why have a changelog file for every release? 
<thom> lupusBE: happens every 12 hours
<thom> um, howelse would you do it?
<lupusBE> yeah I'm testing update-manager and so I was wondering :)
<lupusBE> just the latest changelog and a regular expression to get the right changelog :)
<tseng> jdub: BEAGLE!!!!!!!!!!!!!!!!!!!!!
<lupusBE> I would only show the difference between the current installed one and the latest
<jdub> tseng: ssssshhhh
<tseng> :(
<thom> lupusBE: can't work (same changelog and regex) think about security point releases
<zul> tseng: are you running with inotify on or off?
<tseng> off.
<zul> ok just curious
<lupusBE> ic thom 
<lupusBE> the only really missing thing is that update-manager does not show the current installed version of the package
<lupusBE> but maybe that is just my personal taste :)
<thom> no reason why it should is there?
<lupusBE> a option to turn this info on would be kind of nice tho :)
<lupusBE> like I said :) personal taste :p
<lupusBE> so the only real bugger is that changes are placed on the server after 12 hours
<lupusBE> I mean every 12 hours :)
<lupusBE> can't be done when a packages is put in the repository?
<srbaker> anyone know fo a gnome app for writing docbook?
<zul> check google
<daniels> jdub: beagle!
<jdub> SHUT UP THE LOT OF YOU
<zul> jdub: pssst....ok
* ogra is realy frustrated and goes to bed now, lost more then half of his work because his laptop shot down out of the blue with no cognizable reason....
<ogra> night all :(
<exarkun> hey all.  I hope this is not an inappropriate forum for this question, but I was wondering about having Python's bsddb module linked against libdb4.3 instead of libdb4.2.  Anyone looked into this?
<exarkun> need to take off, but if anyone knows the answer my client will be logging, and I will appreciate it :)  ubuntu has been really awesome so far for me, by the way :)
<dholbach> good night everyone
<crimsun> night daniel
<dholbach> night daniel :-)
<Amaranth> i give up
<Amaranth> someone else can make a menu editor
<ajmitch> Amaranth: that bad, is it?
<zul> night
<ajmitch> Amaranth: I'd love to, if you can find me the spare time ;)
<Amaranth> ajmitch: It's horrible. Shitty docs, gnome-menus bugs, etc, etc, etc.
<ajmitch> that's all part of what makes programming fun
<Amaranth> The problem is I'm going that exact same thing kmenuedit is doing and gnome-menus ignores both of us. So I think gnome-menus doesn't even support what I need.
<srbaker> jdub, i suppose if i wrote said notification program in ruby, it's not as likely to get accepted, right?
<srbaker> jdub, python is probably the best choice if i want the "gnome community" to use it?
<jdub> srbaker: gnome and ubuntu, yeah
<srbaker> k
<srbaker> i'm working on it now
<srbaker> thanks
<srbaker> jdub, this is going to be less work than i thought.  there are Python, PHP, and Ruby implementations of the protocol for *notifying* to growl.
<srbaker> jdub, a growl server will be easy as pie
<Amaranth> anyone know if seb gets on IRC on the weekends?
<zenlol> why are the iso mirrors so slow
<crimsun> zenlol: can't use bittorrent?
<mdz> zenlol: because a lot of people are downloading kubuntu
<mdz> the torrents should be much faster
<daniels> isn't galago the notification stack of choice these days?
<wasabi> mdz, whoops. I woulda not sent you an email and just pung you here if i had seen ya. ;)
<zenlol> are there torrents for the daily installs
<mdz> wasabi: I'm hiding; I'm off-duty ;-)
<wasabi> ahh.
<mdz> zenlol: no, not yet
<zenlol> i am totally over here on abroadband connection just to get a new daily image and cant ;_;
<wasabi> then don't read your email!
<zenlol> at least kub is getting some exposure
<zenlol> :)
<jdub> hrm,
<jdub> lamont: around?
<jdub> how is the DVD image size going now that we've beefed up main so significantly?
<lamont> yeah
<zenlol> oh is there going to be a kde/gnome dvd now?
<tseng> zenlol: a dvd w/ all of main
<lamont> jdub: dunno
<jdub> zenlol: we've had DVD images throughout hoary
<zenlol> oh wow
<zenlol> how did I miss this?
<lamont> jdub: but they're all of supported, not all of main.  or something like that
<tseng> last weeks was ~3gb iirc
<lamont> zenlol: cdimage.ubuntu.com/cdimage/weekly-dvd/...
<zenlol> oh cool
<jdub> lamont: oh, so we're now distinguishing between "ubuntu supported seed" and "main, the combination of kubuntu and ubuntu seeds"?
<wasabi> poor folks. one of these days I'm going to unload Eclipse on you and blow your dvd out of the water. =/
<lamont> jdub: there's no boot foo to distinguish which you weant..
<lamont> want
<lamont> really a Kamion question though
<jdub> lamont: no, i just mean contents of CD, not what it chooses to install
<lamont> a dvd with either the union of {kubuntu,ubuntu}-supported, or with all of main, would be good.
<lamont> jdub: exactly
<lamont> the generation process is currently driven by the seeds, IIUC
<jdub> right, so it's not currently all of main?
<lamont> hence there's an ubuntu dvd and a kubuntu dvd
<lamont> that is my understanding.
<lamont> haven't actually looked though
<jdub> oh
<tseng> oh..
<lamont> ISTR Kamion telling me that when I was asking
<jdub> weird
<mdz> jdub: feel free to forward the google thing to sounder if you feel it's appropriate
<mdz> jdub: I don't like to be too competitive there ;-)
<tseng> wasabi: hah, like Eclipse will ever be in main
<mdz> tseng: it will
<tseng> ouch.
<jdub> mdz: woos ;)
<tseng> mdz: do we have a free java solution?
<wasabi> tseng, I am *so close*
<wasabi> Yeah.
<tseng> hm, neat
<wasabi> I have it running in GCJ right now.
<mdz> tseng: yes, several
<wasabi> Just a matter of knocking down packages in multiverse.
<wasabi> There are Eclipse packages on mentors.debian.net if you wnat to try them out.
<mdz> jdub: the DVD has always corresponded to supported via germinate; it's only recently that main and ubuntu-supported have diverged
<lamont> where does extra wind up?  universe?
<wasabi> http://mentors.debian.net/debian/pool/contrib/e/eclipse/
<Amaranth> is gcc 4.0 out?
<lamont> Amaranth: given the -0pre6ubuntu6 version in our archive, I'd say not unless it's been in the last day or 2
<Amaranth> heh
<Amaranth> think it'll make it in time for hoary+1?
<lamont> /usr/bin/ld: BFD 2.15 assertion fail ../../bfd/elflink.c:6081
<lamont> ew.
<lamont> well, the pre6 packages are in main in hoary...
<Amaranth> err, prerelease software is in main?
<mdz> lamont: extra winds up in universe, yes
<jdub> mdz: is ntpdate enabled on the livecd?
<mdz> jdub: yep
<jdub> hrm
<jdub> we should so get rid of desktop-base
<jdub> mdz: can push desktop-base from depends to recommends in gnome-session?
<calc> Amaranth: gcc 4.0 should be out relatively soon, fedora is based on it
<calc> Amaranth: so its likely to be out by may
<mdz> jdub: interesting; I didn't know about desktop-base
<mdz> jdub: should we use the same alternatives that it does for the artwork?
<mdz> (not for hoary, obviously)
<jdub> mdz: possibly, though i think our plan at mataro was more flexible
<Amaranth> *sigh*
<Amaranth> were is seb when you need him? :)
<Amaranth> he seems to do the only one i've talked to that has a clue as to how the new menus work
<calc> Amaranth: how fdo menus work, or what?
<Amaranth> Yeah.
<calc> i know :)
<calc> its a s3kr17
<Amaranth> translation? :P
<Amaranth> secrlt?
<jdub> have you read the spec?
<calc> Amaranth: secret
<Amaranth> many times
<daniels> jdub: some implementation details (particularly to do with merging) can be very hairy, to be fair
<calc> Amaranth: so what questions do you have
<Amaranth> daniels: _very_
<Amaranth> Ok, if I create new entries in ~/.local/share/applications it all works good and they show up in the menu
<jdub> daniels: good first question though :)
<Amaranth> However if I create testingthis.desktop in the user dir and the system dir it always uses the system one even though seb said it shouldn't.
<jdub> "you must be as smart as this stick to use the internet"
<jdub> "and/or smarter"
<Amaranth> I've tried toying with <MergeFile> and etc and I get nothing
<calc> Amaranth: is it in the same subdir?
<jdub> what's the order of inclusion of local dirs?
<lamont> jdub: "you must be this tall to use signals"
<calc> Amaranth: yea it should use the user one as an override
<Amaranth> I have testingthis.desktop in ~/.local/share/applications and /usr/share/applications
<Amaranth> the user one just has a different comment
<calc> hmm ok
* calc tests it
<Amaranth> Once I figure this out I can release 0.2 of my editor. :)
<Amaranth> kmenuedit sets things up the same way I do so I'm lost.
<jdub> yeah, i can reproduce that
<jdub> move the file to a different name, get the entry
<jdub> same name, it uses the system entry
<Amaranth> filename or Name?
<jdub> looks like a nice bug in gnome-menus
<jdub> filename
<jdub> i'm reproducing what you said :)
<calc> you should be able to use the same filename with hidden attribute to delete entries as well
<calc> not sure if you noticed that already Amaranth 
<Amaranth> so if i created my entries with a prefix they'd show up?
<jdub> hrm, i haven't put any information to override it though
<calc> Amaranth: in gnome as long as the filename isn't exactly the same it shows the one in ~/.local
<calc> it should be overriding it though with the same filename in ~/.local
<jdub> it should automagically override it, just because it has the same name?
<Amaranth> Yeah, the same Name
<calc> jdub: the same filename
<calc> not based on "Name: "
<Amaranth> err, it shouldn't do it based on Name?
<jdub> calc: mmm, that's what i meant. bad context. :)
<calc> np
<Amaranth> It should do it on filename and Name, iirc.
<calc> Amaranth: i'm not sure if its really even stated in the spec
<jdub> Name is too hard -> translation
<calc> but kde at least does it off the filename alone
<Amaranth> It does it based on Name now, doesn't it?
<Amaranth> Or does it produce a totally new entry?
* Amaranth tests
<calc> so if you had two things with the same "Name=" but filenames are different and they go in different parts of the menu then gnome squashes them?
<calc> Amaranth: doesn't seem to help having the same "Name= "
<Amaranth> yeah, this is screwed
<Amaranth> i think gnome-menus is doing the cascade backwards
<calc> so the next question is it screwed generally or something broken in just the ubuntu version
<Amaranth> all my testers have been hoary users :/
<daniels> Amaranth: there've been a few threads on xdg lately about merge order -- maybe it's worth hitting the archives
<daniels> http://lists.freedesktop.org/archives/xdg/2005-March/thread.html
<daniels> iirc
<Amaranth> i've been looking all over for something like that
<calc> http://lists.freedesktop.org/archives/xdg/2005-March/006227.html <- nice email
<calc> unrelated to what you are looking for though
<tseng> jdub: oh hey i forgot to mention this
<tseng> jdub: libgmime-cil seems to be missing dep on libgmime2.1, minor showstopper for beageld
<wasabi> that post makes me want to start mailing .desktops to people just to prove a point
<Amaranth> wasabi: hehe
<wasabi> Why can't we just have a .desktop file LINK
<wasabi> [Desktop File Thing] 
* Amaranth tries to figure out wtf is going on with gnome-menus
<wasabi> Link=/usr/share/applications/otherprogram.desktop
<jdub> tseng: bizaare
* jdub fixes
<tseng> jdub: rock on, dude.
<jdub> might check there's a new gmime too
<jdub> ooh, there is
<calc> i read through the list
<calc> Amaranth: http://lists.freedesktop.org/archives/xdg/2005-March/006278.html
<calc> that seems to be the post daniels was talking about
<calc> i didn't look at the gnome menu code but the email almost makes it sound like it does treat the home dir as lower priority than the global dir
<calc> which is backwards of what it should be
<Amaranth> err, shit
<Amaranth> yeah, that's what i'm reading too
<calc> so i guess you'll have to beat on the gnome menu maintainer/author
<Amaranth> i can't read enough C to figure out where that even happens in gnome-menus
<calc> what package is gnome-menus in?
<Amaranth> gnome-menus :P
<jdub> gnome-menus :)
<calc> heh
<Amaranth> maybe you could get a patch into hoary at least?
* calc sees if he can understand it
<wasabi> WOw this Exec thing frightens me.
<Amaranth> i don't speak glib either so most of it is nonsense to me without looking up something in the manual every other line
<wasabi> I swear, if I ever have to clean up a linux email virus at work, I will shoot somebody.
<crimsun> get your gun ready
<Amaranth> hmm
<Amaranth> the original infected source could wget from the evil guys box (probably still someone else's 0wned box) then when it spreads it it could have it's children wget from itself
<Amaranth> that'd be a bitch to track
* calc is confused
<wasabi> Amaranth, it'd be like every windows virus ever.
<calc> the only places where "XDG" is even mentioned in gnome-menus is comments
<Amaranth> wasabi: Yeah.
<calc> so how does it even check the env var?
<Amaranth> calc: I think the panel calls it with that stuff. :/
<calc> looks like you'll need to email Mark McLoughlin and Havoc
<calc> they are the two people listed in authors
* Amaranth pokes void desktop_entry_set_intersection (DesktopEntrySet *set, DesktopEntrySet *with)
<Amaranth> wow, that was nice
<Amaranth> i clicked the open button on the gedit toolbar and it crashed
<calc> i managed to make the kernel crash by trying to eject a cdrom from nautilus :)
<Amaranth> ouch
* Amaranth wonders why gnome-menus seems to have a framework for building an editor
<Amaranth> oh, nevermind
<Amaranth> nice, gnome-menus doesn't handle <MergeFile> recursion
<calc> so does it leave that to a higher level?
<calc> or just ignore it completely
<Amaranth> ignores it
<Amaranth> nice little FIXME comment
<Amaranth> mine if i paste it? it's 6 lines
<zenlol> looks like I wont be getting a new hoary image tonight
<Amaranth> FIXME * if someone does <MergeFile>A.menu</MergeFile> inside A.menu, or a more elaborate loop involving multiple files, we'll just get really hosed and eat all the RAM we can find
<calc> fun
<jdub> haha
<zenlol> i hate slashdot with the fire of a thousand suns
<zenlol> lol
<calc> Amaranth: ah i misread what you said as it doesn't handle mergefiles at all :)
<Amaranth> i wonder if i can do some XDG_DATA_DIRS trickery to make this work
<wasabi> Great. I just wrote my virus. =/
* wasabi contribues to conversation.
<calc> Amaranth: just use kubuntu ;)
<Amaranth> meh, i don't like kde
<Amaranth> i've managed to complete hose my menu, nice
<lamont> mdz: ppc has Total 345 package(s) in state Needs-Build, all others have no needs-build
<lamont> (hoary-test, that is)
<zenlol> Amaranth, so your tool in its current state is dangerous?
<Amaranth> zenlol: not the copy you have, no
<zenlol> oh ok 
<zenlol> i dont know how I am going to get caught up with hoary now
<zenlol> I suppose I will have to come up here again tomorrow
<lamont> thom?
<Amaranth> i can get one set of menus or the other, can't make it give me both
<Amaranth> ok, i've completely wiped my menus and i don't know how to get them back :P
<Amaranth> time to end this session
<calc> wasabi: distribute it to people now :)
<wasabi> calc, i have some pics of natalie portman for you!
<calc> heh
<wasabi> Actually, I have it working.
<fabbione> morning
<wasabi> I'm just now putting the finishing touches on it, making it grep ~/.evolution for email addresses. ;)
<calc> btw i think gnome in hoary doesn't update its desktop until you logout for some reason
<zul> hey fabbione 
<calc> is gamin broken?
<calc> hmm now it works
<calc> it wasn't working earlier :\
<Amaranth> calc: Sometimes it updates, sometimes it doesn't
<Amaranth> calc: Same with the menus
<calc> heh
<calc> sounds great :\
<Amaranth> heh
<Amaranth> it doesn't help that killing gnome-panel breaks gaim and rhythmbox
<Amaranth> omfgwtfhax
<Amaranth> my user override is working now
<calc> what did you do to it?
<Amaranth> restarted my session
<Amaranth> logged out and back in
<calc> thats fucked up
<Amaranth> very
<calc> it can see it if named something different, but not if its named the same?
<calc> until you log out i mean
<Amaranth> it must not even check the name, just the id
<calc> iirc kde did need its cache rebuilt for it to work
<calc> not sure if there is something similiar on gnome to run
<calc> running kbuildsycoca would fix it under kde
<Amaranth> heh, no wonder kmenuedit runs that so much
<Amaranth> woo, now i can release 0.2 tonight
<calc> so you just have to tell the user to log out to see the changes ;)
<Amaranth> yep
<tsume> thres something wrong :)
<tsume> sshd isn't listening on 127.1
<Amaranth> so i can set Hidden in .desktop file to remove it from the menu?
<Amaranth> If that works it's GNOME specific.
<calc> erm i am pretty sure that worked under KDE when i was building menu-xdg
<calc> does it not work anymore?
<Amaranth> Hidden=True?
<calc> yea or whatever the syntax is
<Amaranth> might be a KDE only thing
<calc> well it should work in both
<calc> since it should use the users file logically
<calc> and if the users file is marked as Hidden then it should not show anything
<Amaranth> damnit
<Amaranth> this is really screwed up
<Amaranth> testingthis.desktop is using the user version, gcalctool.desktop isn't
<calc> yea Hidden only exists specifically for the reason i mentioned above
<calc> "Hidden should have been called Deleted. It means the user deleted (at his level) something that was present (at an upper level, e.g. in the system dirs). It's strictly equivalent to the .desktop file not existing at all, as far as that user is concerned. This can also be used to "uninstall" existing files (e.g. due to a renaming) - by letting make install install a file with Hidden=true in it."
<calc> so if it doesn't work in both gnome/kde then its a bug in the desktop
<calc> erm menu parsing code (desktop is ambigious as to .desktop or DE)
<Amaranth> hey, it works
<Amaranth> where did you paste that from?
<calc> desktop entry spec
<calc> the section that lists the sections of a .desktop file
<Amaranth> woo, my delete button works now
<Amaranth> brb
<Amaranth> well, it more or less works :P
<Amaranth> buggy as hell, i blame gnome-menus
<Amaranth> nope, can't blame gnome-menus
<Amaranth> wtf is wrong with this thing. i've checked and python-xdg and it's cascading correctly (based on what paths it uses, anyway) but user overrides still don't work
<Amaranth> err, checked with python-xdg
<zul> right im off to bed...
<crimsun> l8r
<zenlol> o
<srbaker> can someone here recommend a good test runner script?
<srbaker> i like Ruby's default Rakefile that runs all of the tests under test/ 
<Amaranth> why oh why did i subscribe to ubuntu-users?
<crimsun> you like the deluge, eh?
<Amaranth> it's odd, gmail is applying ubuntu-devel and ubuntu-users labels to some mails
<Amaranth> i wonder if it got forwarded between the two
<mdz> lamont: that includes universe?
<crimsun> oh my, no wonder I haven't been able to set my-id
<sabmoc> Where do we submit art for the the Mascot Competition? 
<dholbach> goooood morning
<sabmoc> hello
* Amaranth needs guinea pigs
<Amaranth> http://ubuntuforums.org/showthread.php?t=21048
<jdub> sabmoc: it says in the announce email
<tritium> Amaranth, for what, your menu editor?
<Amaranth> tritium: yeah
<tritium> that's great that you did that :)
<Amaranth> try it :)
<tritium> Amaranth, I'll take a look at it.
<jdub> tseng: ha ha, libdbus-cil doesn't depend on dbus-1
<whiprush> hey jdub, was the work I did tonite even handy at all? Or did I miss the bus completely?
<jdub> whiprush: tseng said you had modified scherger's beagle packages, which were... not good. did any of the arslinux crew do gsf-sharp stuff, etc?
<sabmoc> zmog! sorry jdub, had only 4hours sleep today
<schweeb> whiprush: you finish them?  I'm back now
<whiprush> well, I did both. I did my own from scratch and did a set based on scherger's packages. scherger's were crack though.
<jdub> whiprush: (i've been maintaining beagle packages since 0.0.2 locally, they've just never been usefully releaseable.)
<whiprush> I'm sure between schweeb, metallikop, and myself that we could crank out the gsf one's pretty easily.
<schweeb> tomorrow morning (afternoon) I could help crank something out
<sabmoc> Are any Ubuntu-dev's Canadian?  
<whiprush> If you don't plan on doing them then we could do them tomorrow pretty easily I'm sure.
<schweeb> got a couple beers in me, so as soon as I pass out, I'll be out like a rock
<jdub> schweeb: jbailey is canadian
<jdub> whiprush: go for it :)
<schweeb> s/schweeb/sabmoc/
<jdub> atm
<jdub> we have
<whiprush> on it.
<jdub>         Evolution-Sharp?        yes
<jdub>         gsf-sharp?              no
<jdub>         gst-sharp?              no
<jdub>         Epiphany Extension?     no (missing dependencies)
<jdub>         Mozilla Extension?      yes
<jdub>         wv1?                    no
<jdub>         Enable Network          no
<jdub> 
<jdub> wv1 we won't do, because we only ship wv2
<sabmoc> jbailey, https://www.ubuntulinux.org/wiki/CanadianTeam
<jdub> (i don't get why they use 1, might be worth a poatch to support 2)
<dholbach> jdub: wv?
<jdub> it wants epiphany 1.2, not 1.6
<jdub> dholbach: wordview library
<jdub> dholbach: as in msword
<dholbach> ah i see
<jdub> so really, it's just gsf and gst
<dholbach> lucky they depend on a library and not openoffice.org-something-dev :-)
<whiprush> ok, we'll work on gsf. Should have something for you in less than 24 hours. It's sleepy time over here.
<jdub> sleep is for the week!
<jdub> :-)
<jdub> meanwhile, i'm going to upload beagle
<sabmoc> jdub, then I must be the strongest zombie on earth.
<jdub> hrm
<jdub> need an elmo
<whiprush> jdub: tseng had me work this up: http://www.ubuntulinux.org/wiki/HoaryBeagleRunningHowto
<jdub> elmo: around?
<jdub> oh man
<whiprush> it should cover what we need.
<jdub> another beagle page on the wiki? :)
<whiprush> well, I'm thinking, with an upload this should be the one page.
<jdub> yeah
<jdub> would be good to point to beagle wiki
<jdub> that gets a lot of eyeballs
<whiprush> I got that at the bottom
<whiprush> I could move it up though.
<jdub> Uploading via ftp beagle_0.0.7-0ubuntu1.dsc: done.
<jdub> Uploading via ftp beagle_0.0.7.orig.tar.gz: done.
<jdub> Uploading via ftp beagle_0.0.7-0ubuntu1.diff.gz: done.
<jdub> Uploading via ftp beagle_0.0.7-0ubuntu1_source.changes: done.
<jdub> Successfully uploaded packages.
<jdub> tseng: ^^^
<whiprush> woo.
<jdub> i'll put it up elsewhere too
<whiprush> also ... according to ifolder-dev, the gaim-workgroup plugin is mostly working. Although, it's probaly so post-hoary.
<whiprush> but I have a feeling it'll be demoed at brainshare this week.
<jdub> cool
<schweeb> whiprush: hah, you gotten ifolder running again, or you still unable to compile?
* jdub started some ifolder packages a while back, but ifolder was horrifically messy at the time. i think tberman's feedback sorted them out a bit.
<whiprush> it's all compilable and works and stuff. The problem is that it depends on a novell server. The interesting p2p stuff is still being worked on.
<schweeb> last time I checked it out of CVS it wouldn't compile
<whiprush> so it's still rather useless to people without an ifolder server.
<schweeb> heh
<whiprush> all indications seem to point towards the server portion being closed source. and the p2p stuff being Free.
<whiprush> though, according to nat, the p2p stuff should work behind NAT (the other kind of NAT, not the guy) and over local networks using some kind of zeroconf implementation.
<dholbach> jdub: what's your opinion on  https://bugzilla.ubuntu.com/show_bug.cgi?id=7888 ? should that kind of seed change be possible?
<jdub> dholbach: i don't think that's a problem
<jdub> dholbach: request a change to mdz/myself
<jdub> dholbach: hrm, and elmo
<dholbach> jdub: ok... i'll doublecheck and talk to you three again
<dholbach> looks like even libgtkmm2.0-1c102 could be removed from main
<sabmoc> Is Matthias Urlichs ever on IRC?
<sabmoc> dumb question, of course he is, but whats his nick?
<jdub> sabmoc: smurfix 
<sabmoc> ok
<smurfix> sabmoc: ?
<sabmoc> smurfix, https://www.ubuntulinux.org/wiki/CanadianTeam
<sabmoc> smurfix, I got your email this morning, read the info on LoCo and wrote a quick page.
<sabmoc> I dont really know if thats how the page should look
<smurfix> sabmoc: nice. Nicely verbose too ;-)
<smurfix> sabmoc: It's OK, every team has their own style, as long as the info is there I don't really care.
<dholbach> jdub, mdz, elmo: i'd like to request seed change, according to https://bugzilla.ubuntu.com/show_bug.cgi?id=7888
<jdub> dholbach: mail dude, mail :-)
<froud> jdub: did you get the Yelp stuff sorted for enrico and the docteam, so Ubuntu docs show in top level
<sabmoc> smurfix, cool, so now what? haha
<jdub> froud: no, one upstream change required
<jdub> froud: i also need packaging changes from docteam, but i'll mail about those
<froud> what is the change and who to speak to, perhaps I can press upstream for it
<smurfix> sabmoc: You know the answer to that question. ;-)
<froud> one less fo ryou to do :-)
<jdub> it's fine, i talk to shaunm every day
<sabmoc> smurfix, yes, now I go to bed
<sabmoc> cya
<froud> yeah, shaunm, but he needs kicking
<jdub> he's fine
<froud> not talk :-)
<froud> jdub: ok, leave it with you then
<jdub> smurfix: do you use de_DE.UTF8@euro on hoary?
<jdub> (with the utf-8 dash)
<smurfix> jdub: That depends (I use English strings but everything else German). Why?
<jdub> smurfix: just want to know the optimal german locale
<jdub> whether it's @euro or not
<ajmitch> evening
<smurfix> jdub: Probably yes
<dholbach> smurfix: what does  locale  say?
<dholbach> is elmo's mail adress @ubuntu.com ?
<jdub> dholbach: james.troup@
<dholbach> jdub: yeah... i wondered, if he was @canonical.com
<smurfix> dholbach: A weird mix of en_* and de_* -- the way my system is set up is not useful for most other people
<dholbach> jdub: thanks
<dholbach> smurfix: aren't the @euro locales obsolete by now?
<bob2> dholbach: everyone has both afaik
<smurfix> dholbach: Umm, let me check
<dholbach> bob2: hmmm: daniel@bert:~$ grep de_DE /etc/locale.gen
<dholbach> de_DE.UTF-8 UTF-8
<dholbach> daniel@bert:~$
<dholbach> jdub: mail sent
<doko> kamion: the thing I found is getlocale(3)
<doko> kamion: oops, gettext(3)
<smurfix> dholbach: you're right, they end up being identical.
<smurfix> jdub: so it seems you can drop the @euro. Check /usr/share/i18n/locales/*@euro whether they do anything special.
<smurfix> jdub: Might make sense to even exclude them from localegen, building two identical locales doesn't help anybody.
<jdub> mmm
<smurfix> I got thrown off by the date in the locale files, its date says 2000-06-24, which seems wrong, the switch was on 2002-01-01
<dholbach> smurfix: i recall them being in longer than 2002-01-01
<bob2> dholbach: oh, I mean @ubuntu.com, @canonical.com :-)
<dholbach> smurfix: for example: euro-support's initial version is from Sun, 28 Oct 2001
<dholbach> bob2: ah... ok ;-)
<smurfix> dholbach: Depends on whether you talk stock market, banking, or cash
<dholbach> smurfix: we're talking about packages and locales being generated ;-)
<smurfix> dholbach: (in real-world terms ;-)
<smurfix> dholbach: Anyway, somebody clearly modified the locale files without updating the timestamp in it.
* smurfix grumbles.
<dholbach> bob2: now if the MOTUs get @ubuntu.com mail adresses, the pattern will be out of order :-)
<bob2> dholbach: hehe, true
<ajmitch> dholbach: that may happen one day :)
* ajmitch thinks the release is more important than email addresses ;)
<dholbach> ajmitch: did i complain yet? :-)
<ajmitch> nope
<Kamion> jdub: run away screaming from .UTF-8@euro
<dholbach> Kamion: why not chuck them out? :-)
<Kamion> jdub: there's a bug open about dropping them; they're totally useless, the only reason it's hard to drop them is that we'd need to figure out how to transition users who are already using them
<Kamion> dholbach: ^-
<dholbach> i see
<Kamion> anyway the non-.UTF-8 @euro locales are still useful, but *.UTF-8 == *.UTF-8@euro
<Kamion> various things (like the upgrade handling in locales, and localechooser) are careful to avoid *.UTF-8@euro
<jdub> Kamion: eeruuugh
<schweeb> argh
* schweeb stabs gsf-sharp
<schweeb> jdub: guess you'll get your gsf-sharp tomorrow, it's 4:20am (5:20am?) here... I'm stuck on a fakeroot issue (I think), and I'm sure whippy's not much further
<jdub> schweeb: heh, go to sleep :)
<schweeb> ** (/usr/share/dotnet/bin/mcs/mcs.exe:10949): CRITICAL **: : shared file [/root/.wapi/shared_data-omglaptop-3-0]  open error: Permission denied
<schweeb> ^^^ that makes me sad
<jdub> schweeb: dude
<schweeb> think I should look at some reference mono pkgs, heh
<jdub> put the following in rules
<jdub> export MONO_SHARED_DIR=$(CURDIR)
<jdub> clean::
<jdub>         rm -rf $(MONO_SHARED_DIR)/.wapi
<schweeb> !!
<schweeb> jdub: first mono related pkg, heh
<schweeb> cdbs rules, btw... metallikop intro'd me to it the other day
<schweeb> omg <3 that worked
<schweeb> sleepy time, night
<sabmoc|zombie> I really need to sign up to the mailing lists
<schweeb> sabmoc|zombie: gmane is nice
<sabmoc|zombie> haven't heard of it
<schweeb> http://www.gmane.org/
<schweeb> mailing list -> NNTP gateway... they archive just about everything
<sabmoc|zombie> schweeb, do we have a build for it somewhere? I dont see it.
<schweeb> well
<schweeb> read harder :D
<schweeb> they archive for you
<sabmoc|zombie> oh, I havnet even looked at the url, i thought it was an app :)
<schweeb> http://www.gmane.org/
<schweeb> err
<schweeb> To read the mailing lists stored in Gmane, point your news reader to news.gmane.org
<sabmoc|zombie> ok :) thanks
<herve> gmane just rocks!
<schweeb> yep
* schweeb notes he chose the wrong mixture of caffeinated soda and beer... more soda than beer = wide awake schweeb at 5:30am
<sabmoc|zombie> schweeb, sounds like homebrew-redbull
<schweeb> well, I didn't actually mix them
<schweeb> but I interspersed them
<herve> as long as you realize caffeine is a threath to your health...
<schweeb> these days breathing is a threat to your health
<mirak> I have a question about sources kernel. When I install kernell tree, I got /usr/src/linux-source-2.6.10/  . Now the kernel is 2.6.10-5 . How can I know what version are the sources ? are the sources exactly the one of 2.6.10-5 ? I don't get how it works
<mirak> the best solution I have found is to us the headers instead of the kernel sources to be sure I will compile modules against the good sources
<mirak> I got no answer in the other chan, so I ask there, sorry
<schweeb> what are you trying to accomplish?  compiling a module, or compiling a kernel?  to compile a module, I think the general practice /is/ to compile against the headers for your running kernel
<mirak> I want to compile kqemu
<mirak> wich need to be linked I think
<mirak> ok thanks
<sabmoc|zombie> holy crap thats a lot of mail
<_d4vid> hi all
<sabmoc|zombie> hello _d4vid 
<pitti> Hi folks
<dholbach> hey pitti
<jdub> morning pitti 
<pitti> Hi dholbach, jdub, what's up?
<jdub> our distrowatch position
<jdub> but that happens every morning
<dholbach> pitti: working on the next motu report
<jdub> ;-)
<ogra> hi pitti
<jdub> dholbach: remember this email address... ubuntu-news@lists.ubuntu.com
<jdub> who here likes xfce?
<jdub> anyone on the motu team mention xfce?
<dholbach> jdub: crimsun does :-)
<Treenaks> jdub: I like it, but only on machines with <128M memory
<herve> jdub, don't tell me you trust distrowatch :-)
<jdub> dholbach: oh, of course!
<Treenaks> (of which I don't have any, atm)
<jdub> herve: i trust it, for the data it provides
<dholbach> jdub: can everyone post on ubuntu-news?
<jdub> it's moderated
<daniels> tseng: do we have beagle love yet?
<daniels> jdub: yeah, libdbus-cil needs to depend on dbus-glib-1-dev
<jdub> daniels: i uploaded it a little while ago
<daniels> jdub: you uploaded gmime, yeah, but did you upload dbus?
<daniels> er, dbus-mono
<jdub> ubuntu's highest ever hits on distrowatch was 2012
<jdub> er
<jdub> 3012
<ogra> boah
<ogra> more then 3000 ?? 
<Treenaks> jdub: wait for hoary final
<jdub> kubuntu's, with only two days of stats, was 3006
<jdub> day 1: 3006, day 2: 1508
<ogra> any statistics about the highest value ever on distrowatch ?
<daniels> jdub: scorchio!
<ogra> i would bet we passed it....
<jdub> ogra: one sec
<jdub> holy crap
<jdub> top five
<jdub> knoppix: 2921
<jdub> kubuntu: 3006
<jdub> ubuntu: 3012
<jdub> slackware: 3551
<jdub> fedora: 4201
<jdub> 
<ogra> wow
<daniels> slackware?
<daniels> i wouldn't think they would've gotten that high
<jdub> stats will be interesting at hoary release
<ogra> we'll pass 4000, i'm sure
* ogra bets five random bugfixes on that
<smurfix> jdub: Do these numbers have dates?
<jdub> smurfix: these numbers are "ever"
<jdub> i can probably put a date to a number
<dholbach> bbl
<smurfix> jdub: that's what I meant
<daniels> ogra: if those fixes are all to X, you're on
<ogra> daniels, word ;)
<daniels> or maybe 3 to xorg and 2 to mozilla-firefox
<daniels> i think thomarse needs a break
<ogra> i'm sure i wouldnt have to solve them :)
<daniels> heh
<ogra> since we will pass fedora by far
<jdub> 132 days ago
<jdub> FC3 release
<Burgundavia> FC4 looks to be more breakage
<Burgundavia> now that RHEL4 is out the door
<Burgundavia> the engineers at RH are going to play
<Goshawk> please can someone update this page ? --> http://www.ubuntulinux.org/wiki/USplash
<Goshawk> there is a link that is outdated
<jdub> Goshawk: the wiki is designed such that you can update the page
<Goshawk> jdub, i'm trying to do that
<Goshawk> can i use the same account of the ubuntu forum?
<jdub> no
<Goshawk> ok
<obe1> anyone ever use the iconv() functions of the GNU libc library?
<pitti> hm, my swsusp experiment was horrible...
<ogra> pitti, :(
<pitti> ogra: going to sleep worked pretty well, but the screen went black on resume
<pitti> ogra: does it work for you?
<ogra> nope not at all...
<ogra> only hibernate works here
<pitti> erm, isn't hibernate == swsusp?
<daniels> pitti: sounds like a gtk bug to me
<ogra> ut thats caused by the fact that i have no key sending events (acer laptops only send keycodes from the suspend button)
<pitti> daniels: of course :-)
<ogra> pitti, hibernate = suspend to disk.....
<pitti> yeah, that was my impression
<ogra> with a shutdown in the end
<pitti> ogra: you use the hibernate package?
<ogra> and resume on boot
<pitti> ogra: or does your gdm actually offer hibernate?
<ogra> yep
<pitti> I only ever got it offered on the live cd, which is kind of pointless :-)
<ogra> my gnome-session offers it on logout
<pitti> so I did "echo disk | sudo tee /sys/power/status"
<tseng> i only see it when pressing f10 in the username box
<tseng> in gdm.
<tseng> its not an icon.
<pitti> s/status/state/
<pitti> anyway, with init=/bin/bash, it doesn't even go to sleep
<pitti> and with a normal boot I get a black screen :-(
<pitti> well, at least suspend to ram works fine
* thom yawns idly
<ogra> morning thom 
<daniels> ogra: itym 'afternoon'
<ogra> heh
<mjg59> daniels: Around?
<daniels> mjg59: of course not
<daniels> mjg59: whattup?
<crimsun> uh oh, it's the daniels ghost
<mjg59> daniels: So, I have these laptops
<daniels> mjg59: are you going to send them to me?
<mjg59> Pressing the external video out key switches on the CRT output, but doesn't connect any pipes
<daniels> mjg59: hm
<daniels> mjg59: so i8xx
<mjg59> What magic do I need in xorg.conf to say Connect the CRT output to the pipe the LFP is using and get it so the LFP is the default output?
<daniels> mjg59: i assume the pipes would need to be configured in xorg.conf
<daniels> err
<mjg59> And do this without it noticing that I've told it there's a CRT there and so outputting 800x600 on the LFP because there's no DDC response?
<zenwhen> are there any estimates on how much traffic went through the cd image server last night because of slashdot?
<daniels> ah
<netdur> hey, I have two "silly" things, not sure if I should put in bugzilla (I just registred)
<daniels> mjg59: Option "MonitorLayout" "LFP+CRT,NONE"
<netdur> 1) KDE add it's apps into Gnome menu
<mjg59> daniels: Ok, let me give that a go
<daniels> mjg59: assuming your LFP is on pipe A, which holds true for most i815/i830; else, NONE,LFP+CRT
<daniels> mjg59: also, Option "DisplayPresence"
<netdur> 2) please add some empty documents (archive.tar, oo.o templates) to ~/Templates
<daniels> mjg59: er, Option "DevicePresence".  whatever.
<netdur> should I use bugzilla for them?
<daniels> netdur: for the Templates thing, sure
<thom> daniels: #7942, i'm tempted to fix it in firefox anyway
<herve> if we can vote for bugs, I would vote for that templates thing
<herve> even provide a patched package
<Kamion> patches are so much more useful than votes that they aren't even on the same scale of usefulness
<thom> voting on bugzilla is such a horrible idea
<herve> you would consider a revision from a not-even-motu member?
<mjg59> daniels: Ok, that /almost/ works
<Kamion> MOTU == upload privileges, nothing to do with whether patches would be accepted
<mjg59> daniels: However, the state is then either both displays on or CRT only on
<daniels> thom: disable back/forward per default?
<daniels> thom: iirc that will make the side buttons on mice scroll horizontally, which is confusing
<thom> daniels: make horizontal scrolling actually work correctly
<daniels> mjg59: hm
<herve> you talk about a patch, I talk about a n+1 package with templates
<herve> ready to upload
<daniels> thom: well, as I said, since it's just mapped to buttons, this will fuck up real mice
<daniels> thom: aiui
<daniels> herve: right, and you can put a diff somewhere so that one of the existing motu or core members can review and upload it
<herve> I'll take a look
<thom> daniels: i think you're misunderstanding, i just want to fix firefox so if people do enable it, it works
<netdur> buzilla form is not easy enough to use... what's "Assign To"?
<ogra> mjg59, my laptop recently started to shut down unintentionally.....could this be caused by any of the swsuspend patches ?
<mjg59> ogra: Under what circumstances? What hardware?
<daniels> thom: in what sense, 'fix'?  change the default horiz scroll behaviour to actually scrolling as opposed to back/forward, or?
<ogra> mjg59, acer 1520 amd64 
<thom> yes
<ogra> mjg59, circumstances: none...it just starts a clean shutdown out of the blue....
<daniels> thom: right.  the way horiz scroll is implemented, last I checked, was by extra buttons, not an axis.
<ogra> mjg59, nothing the "goiong down for shutdown now..." in the logs 
<daniels> thom: so the side buttons on mice with them will now be mapped to scroll left/scroll right, as opposed to back and forward
<daniels> thom: i think keeping those working is more valuable than fixing it for the synaptics people tbh
<mjg59> ogra: No real chance of it being swsusp
<mjg59> Could be acpi patches
<mjg59> What does /var/log/acpid say?
<herve> ogra, warmth trouble?
<ogra> mjg59, it happened several times during last week overnight and i suspected my cat sitting on the powerbutton, but yesterday it happened twice whille i was typing
<thom> meh meh meh
<thom> daniels: ok, understood
<helix> does celso providelo irc?
<daniels> thom: your call :)
<ogra> mjg59, may i PM you log excerpts...bwt /var/log/acpid isnt user accessible...
<mjg59> Sure - acpid isn't supposed to be use accessible
<daniels> fabbione: bah ... ogle is broken in the same way mplayer was
<mjg59> daniels: What's the easiest way to add extra options to the default xorg.conf?
<mjg59> (This can be a hardware specific package)
<daniels> playing DVDs over NFS (where you've just done dd if=/dev/hdd of=rza-germany.dvd bs=1M) ... kinda shit
<daniels> mjg59: you ... what?  er ... no
<daniels> mjg59: for breezy, there'll be a sweet infrastructure you can hook in to
<daniels> mjg59: hoary?  you're screwed
<Kamion> helix: "cprov", but I'm not sure he ever turns up here
<daniels> mjg59: just intelligently trash it with an awk script in postinst and then we'll leave it alone until the user explicitly runs dpkg-reconfigure xserver-xorg
<mjg59> daniels: It's, uh, somewhat necessary
<helix> Kamion: ok. (he signed my key but I never met him...)
<daniels> mjg59: ?!?
<Kamion> helix: heh. Brazilian Canonical employee
<ogra> helix, he signed your key ? how is that possible if you never met him...weird
<Kamion> ogra: some people are a bit careless at keysigning parties
<ogra> seems like
<helix> ogra: I was in matar
<ogra> helix, me too
<helix> but my key wasn't on the ksp sheet or anything
<helix> and I didn't meet him
<helix> so I'm really quite confused. :)
<ogra> heh
* ogra starts to doubt the trustabilty of the web of trust a bit....
<helix> Kamion: yeah, if I'd taken part in the ksp, that would be one thing...
<Kamion> helix: weird
<helix> quite
<Kamion> mail him?
<helix> yeah, just wanted to see if he was on irc first. thanks.
<jdub> helix: oh, hi.
<helix> hello, jdub :)
<mjg59> ogra: power.sh isn't the shutdown script
<mjg59> So, uh, acpid doesn't log the machine being shut down
<mjg59> Which leaves me confused about what might be doing it
<ogra> wierd...i'll talk to fabbionne tomorrow if it could be a kernel issue and if there is a possibility to track it...i tried the 2.6.11 bk snapshot for two weeks some time ago, there was no such behavior
<ogra> mjg59, thats why i suspected any of our patches being responsible
<mjg59> ogra: But it's a clean shutdown?
<ogra> yep
<mjg59> Crack
<mjg59> Any chance of setting up process accounting?
<ogra> mjg59, its the same as if i press the powerbutton during a desktop session
<ogra> mjg59, sure, if you explain me how to do that or pint me towards some docs 
<ogra> s/pint/point
<mjg59> apt-get install pacct
<mjg59> Sorry, that's not it
<ogra> cool
<ogra> oh
<mjg59> apt-get install acct
<mjg59> Then after it shuts down, run lastcomm and send me the last bit
<ogra> mjg59, ok, i'll have to wait until it does that again....hopefully not before tonight ;)
<mjg59> ogra: Heh. Thanks!
<ogra> thanks as well :)
<mjg59> Man, this machine is so much faster than my X49
<mjg59> (X40)
<daniels> mjg59: and four times the weight?
<ogra> heh
<daniels> i just want them to make an x40 with some sort of radeon
<daniels> i mean, having an r480 and an amd64 in there with that form factor
<daniels> and also running cool and silent
<daniels> with a 250gb disk
<daniels> but it's probably not going to happen
<bob2> haha
<bob2> they can have an all metal unobtanium case
<mjg59> Yeah, massively heavier and worse battery life
<mjg59> I want to have a 1600x1200 screen that's 10.4" big
<mjg59> And for it to be less than a kilo
<mjg59> And have 10 hours of battery life
<ogra> and very very good glasses to see something on this screen ;)
<daniels> ogra: large font sizes
<daniels> there's a lot to be said for a large dpi
<ogra> daniels, tell that to the webdesigners ;)
<mjg59> r300.sf.net is starting to look good
<mjg59> Working Quake3 and Tuxracer
<daniels> mjg59: yeah.  unfortunately someone who knows more about PCIE than me needs to get PCIE GART support going.
<jdub> mjg59: hmm. interesting.
<bob2> hm, my x40 screen has developed a few bright white blobs
<daniels> bob2: yours too?
<jdub> oh dudes
<jdub> scary stuff
<jdub> that's x40 chlamydia
<bob2> the dell's have a similar problem
<bob2> except it manifests itself by putting "dell" logos on top of the lid
<_BIJ_> hi @ all... 
<Mitario> hi everyone
<_BIJ_> first of all i got to say that you guys did a great job with the array 7 release of hoary... i've got a little proposal for the console... why not enable completion by default? for example if i write "apt-get install" and press TAB then it should list all possibilities... this can be done by editing the bash.bashrc in the /etc folder... i think this should be implemented by default... what do you guys think about this?
<_BIJ_> brb
<mjg59> Hrngh.
<mjg59> I /think/ I've tracked down all the i915GM PCI IDs now
<daniels> mjg59: feel free to send me a phat patch
<mjg59> daniels: It's all kernel stuff, X is fine
<daniels> mjg59: oh, woo
<zul> yeah woo for you
<mjg59> W00t. With that, I get working Xv and DRI
<lamont> mdz: main only - need to pull the other into the archive before it can build
<lamont> and when I said ppc 345, it had just grabbed oo.o and oo.o2 :-)  still at 345
<exarkun> hey all.  I hope this is not an inappropriate forum for this question, but I was wondering about having Python's bsddb module linked against libdb4.3 instead of libdb4.2.  Anyone looked into this?
<jbailey> sabmoc|zombie: Thanks.  You may want to subscribe to the page on the wiki so that it will email you changes to the page.
<_d4vid> ky all
<ogra> daniels, could you give me a hint on this ? https://bugzilla.ubuntu.com/show_bug.cgi?id=7658 i suspect i need to add xinerama support to the lock window
<ubuner_> hello, I am trying to customize the Ubuntu hoary livecd and I remove the original filesystem.cloop, and I use debootstrap to build a new ubuntu in /mnt/ubuntu, and now I want to compress /mnt/ubuntu  become  filesystem.cloop,  I use mkisofs -iso-level 4 -R -U -hide-rr-moved -cache-inodes -no-bak -pad /mnt/ubuntu | nice -5 create_compressed_fs - 65536 > filesystem.cloop
<ubuner_>  is that a correct way?
<daniels> ogra: damnit, I was going to report that tomorrow, if that's what I think it is :)
<daniels> ogra: and yeah, you need to add Xinerama support
<daniels> ogra: so rather than being at the centre of the display, you need to be at the centre of the primary screen for that display
<ogra> oki, i'll read the docs about that then :)
<daniels> ogra: i.e. centre on :0.0, not :0
<ogra> okay, thanks, thats what i wanted to know :)
<daniels> rad
<daniels> time for me to sleep now -- g'night :)
<ogra> night
<zenwhen> oh ok
<daniels> Quote:
<daniels> Friend: usblp0: on fire
<daniels> Jdong: Lol, buggy printer drivers
<daniels> Jdong: It's a humorous catch-all when the USB printer driver doesn't understand the printer
<daniels> Friend: No, you don't get it.
<daniels> Friend: It's actually _ON FIRE_
* ogra thinks its a hot summer down under
<zenwhen> daniels, isnt that a really old joke
<zenwhen> i kinda laughed because he thought his story was something new and he pretended it actually happened.
<doko> keybuk: status: resolved, solution: later look strange ...
<mjg59> Urgh. Crack.
* mjg59 tries to work out how this DRI reinit stuff is supposed to work
<ogra> mjg59, just had the crash again while i was out with the dog, seems the command that ran was spamc and the machine was very hot i think its a tempeature isse, will write a script ot monitor it
<ogra> s/ran/last ran
<mjg59> ogra: Ok - my suspicion would be that something in your hardware is triggering a shutdown for thermal reasons
<mjg59> daniels: If my current suspicions are confirmed, it's going to be really quite easy to sort DRM resume on i830+...
<ogra> jup, thats what i suspect too, since i dont run the nvidia driver this nightly shutdowns could be caused by some 3d screensaver
<ogra> i'll monitore the temp and will see if it raises shortly before shutdown...
* mjg59 waits for every PCI driver to rebuild
<jbailey> thom: ping?
<thom> jbailey: ack
<jbailey> thom: re: hdparm.  md pointed out to me that removing +x from a file in /etc/dev.d is a convenient way of disabling a script.  I notice that a few other bits in there are symlinks to elsewhere, though.  What do you think of the idea of moving that snippet to /usr/share/hdparm, using it for /etc/init.d as well, and just symlinking to it?
<thom> hrm, that's a good idea
<thom> be back in a couple of hours, getting a train home from cambridge
<dholbach> re
<smurfix> ogra: I had random shutdowns every few days with my old mainboard. I suspect the emergency power sensor on the mainboard returned spurious nonsense. :-/
<ogra> smurfix, in fact the machine is very hot, so the sensor may be right, the thermal situation of this laptop isnt the best overall...
<smurfix> ogra: Bah. No laptop CPU in there?
<ogra> smurfix, amd64 :)
<smurfix> ogra: OUCH
<mjg59> daniels: ARGH.
<smurfix> ogra: So how long does that thing's battery keep up with the demand, half an hour?  :-/
<ogra> smurfix, its very nice, but the fan grid is exactly the place where the thig sits on my right shank
* smurfix thinks laptops shoudn't even *have* a fan
<ogra> smurfix, about 1,25h but the thing is just about a month old....
<mjg59> daniels: Resume works fine with the kernel i915 driver, but the DRI code insists on a version number of at least 1.2
<smurfix> Hey sabdfl 
<ogra> yay sabdfl 
<sabdfl> hi all
<dholbach> sabdfl: hey! :-)
<mjg59> Hrngl.
<mjg59> Right. Everything works now except the massively awkward ACPI problem.
<sabdfl> mjg59: which laptop?
<mjg59> sabdfl: An HP
<mjg59> Working 3D over suspend/resume!
<sabdfl> nice! i thought dri killed swsusp?
<smurfix> mjg59: Cool. Can you do the same thing to mine please?  :-/
<mjg59> sabdfl: Nah, should be mostly fixed up now
<mjg59> smurfix: What sort of hardware
<mjg59> sabdfl: -29 kernel should make everything immensely happy
<smurfix> mjg59: Samsung P35. I'll have to retry with the latest kernel.
<sabdfl> mjg59: even the X40?
<mjg59> sabdfl: Yeah
<mjg59> smurfix: What sort of video hardware does that have?
<smurfix> mjg59: Radeon 9600
<mjg59> -29 isn't out yet - you'll have to wait until Tuesday or so
<mjg59> smurfix: Oh, right. No, you lose :)
<smurfix> mjg59: Bah
<mjg59> fglrx has effectively no suspend/resume support at the moment
<mjg59> Might be fixed for Breezy
<smurfix> mjg59: I can possibly try radeonfb or vesa
<mjg59> Nah. If you want 3D on Radeon 9500+, you probably don't get suspend/resume
<smurfix> mjg59: I can live without 3D more easily than I can live without suspend, to be honest.
<mjg59> Heh
<smurfix> The only program regularly exercising 3D support here is the screensaver
<mjg59> Just use the radeon driver rather than the fglrx one, then
<dholbach> Kamion: are you here?
<Mitario> hmm, can anyone succesfully checkout and build gnome-applets HEAD here (with ubuntu autoconf etc.)
<tsume> I'm trying to install vmware, and its not working
<srbaker> yaye
<tsume> any clue why it says...
<srbaker> so my growl compatibility is coming along well
<tsume> The directory of kernel headers (version 2.6.10) does not match your running 
<tsume> kernel (version 2.6.10-5-386).  Even if the module were to compile successfully,
<tsume> it would not load into the running kernel.
<tsume> srbaker: hmm
<tsume> srbaker: growl? have I heard of it?
<mjg59> tsume: Install linux-headers-2.6.10-5-386
<srbaker> tseng, growl.info
<tsume> mjg59: I thought I did, I'll see if its just me
<srbaker> growl is for apps to send non-intrusive notifications to the user
<srbaker> gnarl is the gnome implementation of growl
<tsume> mjg59: I'm not seeing the headers for my kernel
<tsume> mjg59: the kernel binary would be named what?
<mdke> tsume, sudo apt-get install linux-headers-2.6.10-5-386
<mdke> yw
<srbaker> anyone know of a good testrunner for python?
<srbaker> perhaps a script that will run all of the tests under "test/" named "test_*.py" ?
<mdz> srbaker: help(unittest)
<janc> srbaker : read the docs  :)
<srbaker> i *am* reading the doics, and i didn't find anything that would do what i want
<janc> http://docs.python.org/lib/misc.html
<tsume> mdke: thank you
<tsume> mdke: is there a search program on the web for the archives?
<mdke> tsume, which archives do you mean?
<tsume> mdke: a web search for any available packages
<tsume> description, name, etc
<mdke> i just use apt
<mdke> or synaptic
<tsume> apt can search description?
<mdke> tsume, see PM
<nasdaq7> @find visio
<mdke> O.O
<schweeb> nasdaq7: not a warez channel, thanks
<mdke> pmsl
<mdke> its an idea tho
<nasdaq7> :)
<nasdaq7> i was way away
<mdke> nasdaq7, this about as far off a warez channel that you can get
<nasdaq7> :)
<Amaranth> do you think having invalid desktop files still show up in the menus is a good thing?
<calc> Amaranth: invalid in what way?
<Amaranth> i just ran desktop-file-validate on all my menu desktop files and a lot of them are failing
<calc> ah well yea filing bugs on them would be a good idea
<mdke> heh
<calc> we don't need .desktop files becoming like html
<Amaranth> no, i think i made these entries :P
<Amaranth> /usr/share/applications/users.desktop: error: value of key "Categories" is a list of strings and must end with a semicolon
<Amaranth> i didn't make that one
<Amaranth> /usr/share/applications/screensaver-properties.desktop: error: required key "Encoding" not found
<zenwhen> you still blowin stuff up Amaranth 
<Amaranth> zenwhen: yeah
<zenwhen> lol
<mdke> lol
<Amaranth> i'm going to fix all these and see if it helps my editor any
<Amaranth> i wonder why i'm going to tell the people that used my editor when they find out i broke all the entries they editting
<zenwhen> your older safer editor is treating me well.
<Amaranth> I've been putting Terminal=True or Terminal=False instead of true and false
<mdke> Amaranth, tell em its testing
<Amaranth> zenwhen: it breaks things too
<zenwhen> oh
<zenwhen> it hasnt for me yet
<Amaranth> read up
<Amaranth> the terminal thing
<calc> Amaranth: Terminal isn't required in a .desktop file
<Amaranth> no but i put it in all the ones i edit
<calc> ok
<calc> and the True vs true doesn't seem to be mentioned in the spec so both should work i guess
<calc> well it somewhat says it should be "true" but doesn't say it in a really strong way
<calc> its mentioned in a previous paragraph before they mention that the text is case sensitive
<dholbach> bbl
<Amaranth> i give up again
<WebMaven> Still needing some ZCML help here, if anyone can assist.
<WebMaven> Still needing some ZCML help here, if anyone can assist.
<koke> Mitario: ping?
<thom> WebMaven: i suspect you're in the wrong channel
<Mitario> koke, pong
<shaya> the evince package claims to have a thumbnailer for nautilus.  I don't see any evidence of it
* schweeb points shaya to the "evince-thumbnailer" binary
<thom> Kamion: ta, resyncing now
<pitti> Hi folks
* pitti returned from a fantastic presentation about Iceland
<dholbach> hi pitti 
<pitti> jbailey: ping
<ogra> mdz ?
<ogra> hi pitti, how is the water situation in dresden ?
<pitti> ogra: pretty calm
<pitti> ogra: folks living in the vicinity of the Elbe might get wet cellars
<ogra> ah, sounds good, the news look worrying
<pitti> ogra: but nothing particularly unusual :-)
<ogra> heh
<pitti> ogra: I'm glad that I don't have a TV to be worried :-)
<ogra> i'm glad to hear its better then reported :)
<pitti> ogra: good reason for my parents to clean up their cellar for a change :-)
<ogra> Mithrandir, did you contact Ove ?
<ogra> heh
<Mithrandir> ogra: argh, forgot :/
<ogra> still two days until the meeting :)
<Mithrandir> yeah, what time is it again?
<dholbach> 16:00 utc
<Mithrandir> I'll do it straight away
<ogra> Mar 22nd 2005 at 1600 UTC
<dholbach> http://wiki.ubuntu.com/Calendar
<ogra> great, thanks :)
* pitti curses at the lying cdbs tutorial
<schweeb> pitti: where does it lie?
<pitti> schweeb: I try to gzip a few additional files before assembling the deb
<pitti> schweeb: the binary/foo:: example does something similar
<pitti> schweeb: i. e. the tutorial suggests that binary/foo is executed right before dh_builddeb
<pitti> schweeb: but in fact it's executed right _after_ dh_builddeb, which makes it kind of pointless
<pitti> schweeb: and install/foo: is too early for me
<schweeb> how about binary-install/foo::
<pitti> schweeb: (install sucks as well, it calls the commands right after dh_installdirs, when no files have actually been isntalled yet)
* schweeb just did similar in a package
<sabmoc> Would svg fonts be really cool or really lame?
<sabmoc> on a desktop, for example
<schweeb> isn't that essentially what TTF is?
<sabmoc> I have no idea. Ok
<dholbach> pitti: isn't there something like DEB_COMPRESS_EXCLUDE ? (only the other way round?)
<sabmoc> #ubuntu-docs
<mdz> ogra: ?
<ogra> mdz, i dont see wine on the CC agenda...
<pitti> can you be bribed to tell me how? :-)
<pitti> dholbach: no, unfortunately not
<pitti> dholbach: you can give additional files to dh_compress
<pitti> dholbach: but not per-package, only globally, and I have a multi-deb package
<dholbach> pitti: i try to understand whats going on in rules/debhelper.mk at $(patsubst %,binary-fixup/%,$(DEB_PACKAGES)) :: binary-fixup/%: binary-strip/% - but that must be the right stanza
<pitti> dholbach: and debian/package.compress is really lame, too :-(
<mdz> ogra: if you would like to discuss something which is not on the agenda, feel free to modify the agenda
<schweeb> sabmoc: yes, truetype fonts are scalable vector fonts
<ogra> mdz, the TB wanted to....i mailed scott (no confirmation yet) and Mithrandir just mailed Ove
<mdz> ogra: if they are not coming to the meeting, there is nothing to talk about
<pitti> dholbach: common-binary-predeb-arch could help :-)
<ogra> mdz, i'll put it there, even if we dont have confirmation yet
<mdz> ogra: so when you hear back from them, go ahead and change the agenda
<ogra> mdz, ok
<dholbach> pitti: what a charming name :-)
<ogra> mdz, thanks
<pitti> dholbach: but binary-predeb/package could work, too :-)
<mjg59> Oh.
<mjg59> I think I may have found out why the HP has strange lid switch behaviour.
* mjg59 hacks around it using setpci and is impressed to find that it works
<Keybuk> oh?
<pitti> dholbach, schweeb: yeah, binary-predeb does The Right Thing (tm) :-)
<schweeb> excellent
<mjg59> Keybuk: Hitting the lid switch sets a PCI configuration register. The only thing that clears that register is changing the display device using an ACPI call.
<schweeb> what's the correct thing to do while making a package from CVS?
<shaya> schweeb: yea, but I have 0 evidence that it hooks in with nautilus
<schweeb> run autogen.sh in the rules? or beforehand
<pitti> Dear jbailey, please rename binary to binary-postdeb and binary-predeb to binary. Love, pitti
<mjg59> Or, alternatively, clearing the register myself.
<mjg59> With setpci.
* mjg59 feels sick.
<schweeb> shaya: well, it works for me...
<shaya> you see mini pdfs in nautilus?
<schweeb> yes
<schweeb> tis a beautiful thing
<shaya> I dont, I just get the stock pdf icon
<shaya> hmph
* shaya feels left out
<dholbach> shaya: me too
<schweeb> I could take a screenshot, hehe
<schweeb> but I have Programming C# sitting in my home dir right now, and I see a thumb with the first page, with an acrobat symbol overlaid on it
<schweeb> bbiaf
<shaya> hmm
<shaya> weird
<shaya> it seems that evince-thumbnailer isn't in my gconf
<shaya> but I see a schemea for it in the package
<shaya> wonder if that's related
<dholbach> oh nice... nautilus uses 70% of mem
<shaya> I have no idea how evince-thumbnailer is supposed to hook in with nautilus
<mjg59> OH CHRISTING ARGH.
<zul> hmm?
<shaya> dholbach, 
<shaya> figured it out
<shaya> or not
<shaya> hmm
<mroth> schweeb: this Programming C# PDF you mention.. is that a Free book, or commercial?
* mjg59 hacks together ACPI video support
<schweeb> mroth: *cough* commercial
<schweeb> the O'Reilly book
<schweeb> I own the hardcopy, so it's all legal (I think) ;)
<mroth> schweeb: ahh.  we have an O'Reilly Safari subscription at work, but its all HTML, you cant get PDF versions of the books, so its kind of annoying.
<jbailey> pitti: Can't do it.  Debian Policy section 4.8 gives the behaviour required from the 'binary' target.  binary-predeb is a hack used for debhelper to work around various make suckages.  cdbs2 will have a post-debhelper hook for things that you want to run after debhelper is done its job, a debhelper hook to hook new debhelper rules into (for the gnome folks, and others), and a pre-debhelper hook to run things
<jbailey>  right before it.  Will that meet what you need?
<pitti> jbailey: Hi!
<pitti> jbailey: well, so far binary-predeb was exactly what I needed
<pitti> jbailey: binary/foo:: is too late, at that time the deb is already built
<pitti> jbailey: and binary/install:: is right after dh_installdirs, which is too early
<jbailey> pitti: Right.  It's a bit of a confusing mess in there.  Ar eyou generating something in the target package directories?
<jbailey> mroth: If you pay them money per chapter you can download the PDFs as well.
<jbailey> mroth: Not usually worth it.  THe discounts they offer on purchasing books makes it worth just buying the dead-tree edition if that's what you really want.
<doko> jdub: ping?
<pitti> jbailey: I want to gzip some additional files
<pitti> jbailey: dh_compress is not very extendable, so I do this with a find -exec gzip command in a rule
<Mithrandir> pitti: dh_compress filename?
<jbailey> pitti: Ah.  I probably would've used DEB_DH_COMPRESS_ARGS := $(shell find ...)
<jbailey> Err, no :=
<jbailey> =
<jbailey> Need lazy binding on that one.
<Mithrandir> ah
<jdub> doko: pong
<jdub> morning all
<pitti_laptop> Mithrandir: dh_compress is not per-package and I'd like to have wildcards
<pitti_laptop> Hi jdub 
<doko> jdub: could you send me a patch for #2702 or tell me the correct categories to place it in System/Administration?
<ogra> morning jdub 
<jbailey> pitti_laptop: Ugh.  YEah, that's one problem with this module is that not every variable has a perpass version of it.  *sigh*
<tseng> hi jdub.
<jbailey> wasabi: See?  Lots of things I hate about cdbsv1 which desperately need fixing. =)
<jdub> doko: i don't think it should be in System/Administration
<jdub> doko: you can open this dialogue from every OOo app, can't you?
<jdub> hrm, seems not
* schweeb tests his gsf-sharp pkg via a beagle build
<tseng> schweeb: package?
<doko> jdub: no, you can't, at least not from Draw
<tseng> is there a release?
<schweeb> jdub wanted it for beagle 
<tseng> yeah but, no tarball afaik
<schweeb> yea, I just SVN'd it
<tseng> gross.
<tseng> oh well
<schweeb> it's all I could find
<schweeb> I /looked/ for a release
<tseng> yeah there is none
<tseng> oh gsf
<tseng> im talking about gst.
<schweeb> same situation
<tseng> yeah.
<schweeb> heh
<schweeb> I think there's only even 2 pages of results for "gsf-sharp" on google
<schweeb> and most of them revolve around beagle
<thom> jbailey: as a simpler solution, we could just make sure that anyone upgrading from an old version of hdparm gets the dev.d script 755'd
<pitti> mdz: here?
<jbailey> thom: Yup, I had just been looking at it being an almost perfect copy of what's in the init.d anyway, and wanted to avoid code duplication.
<thom> mmm
* OddAbe19 is away: Gone... Like the French in a battle.
<Amaranth> OddAbe19: ...
<jbailey> OddAbe19: Umm.. Ouch?
<thom> OddAbe19: for the last time, please turn off public aways off, especially blatantly offensive ones
<ogra> OddAbe19, and please read and understand the CoC
<doko> jdub: what about the location of the OOo printer setup?
<jdub> doko: i'm trying to determine whether we really need a menu entry for it at all
<ogra> jdub, i dont think so
<doko> ok, just wanted to add it for the next upload
<schweeb> everything should be picked up via CUPS or configurable from the app itself, IME
<doko> schweeb: please send a patch
<jdub> and you can always run it from the command line
<jdub> doko: you can add add NoDisplay=true to the .desktop file
<doko> jdub: ok
<abelli> jdub: ciao
<abelli> jdub: im not ubuntu-it's moderator anymore.
<abelli> jdub: it has been so for about 3 weeks by now.
<jdub> abelli: so why did someone have to mail me about it, rather than you telling me?
<mdke> jdub, sorry that was me
<abelli> jdub: i actually mailed mako.
<abelli> and matthias.
<abelli> mmm.. i think that i explicitly talked about the ml only with mako.
<jdub> abelli: neither of whom admin the lists :)
<abelli> jdub: mako was one of the ex administrators, and i thought it was related with loco teams.
<jdub> abelli: so you agree that matthew.east@breathe.com and s.mestre@blueberrypie.it should be the new admins?
<abelli> mmm im not concerned actually.
<schweeb> jdub: is it beagle 0.0.7 that's goin in?
<jdub> schweeb: yes, already uploaded
<abelli> jdub: i can't say that sorry.
<jdub> we need an elmo to process it
<doko> jdub: should the printeradmin icon be hidden in KDE as well?
<jdub> doko: if you add NoDisplay=true, it shouldn't appear in either...
<Amaranth> Hidden=true?
<Amaranth> or does that do something different?
<jdub> abelli, mdke: so no one is listed on http://www.ubuntulinux.org/wiki/ItalianTeam
<abelli> jdub: i know.
<doko> jdub: ok, it does have another entry in /usr/share/applnk for KDE.
<jdub> abelli, mdke: can you guys mail matthias, mako and myself, to sort this out?
<mdke> gosh
<jdub> doko: ah, bong. you could get rid of that.
<jdub> doko: but, let's do that next release. :)
<Mithrandir> pitti: -p tells it what package to act on
<abelli> jdub: why me, if i can ask.
<jdub> abelli: because you were previously adminning the list, and ostensibly leading the locoteam.
<pitti> Mithrandir: I know, but cdbs doesn't have a rule to influence per-package invocation
<schweeb> wtf... beagle doesn't like my libdbus-cil :-/
<pitti> Mithrandir: anyway, I already found a solution :-)
<jdub> pitti: it does
<Mithrandir> pitti: binary-install/$package::\ndh_compress -p$(cdbs_curpkg) $file1 $file2 &c :)
<pitti> jdub: ?
<jdub> pitti: binary-install/<package-name>::
<jdub> (etc.)
* schweeb mentioned that earlier too
<pitti> Mithrandir: hmm, okay; this would call dh_compress again (which wouldn't hurt certainly)
<pitti> Mithrandir: however, I just did "find -name ... -exec gzip '{}' \; 
<pitti> Mithrandir, jdub: thanks, didn't know about binary-install; I used binary-predeb 
<Mithrandir> pitti: you just want to compress stuff < 4k though
<pitti> hmm, right
<pitti> so dh_compress $(find ...), I guess
<abelli> jdub: I have sent mako and matthias an email few hours ago.
<abelli> jdub:  I have already threated the question with mako last week.
<abelli> jdub: I wasn't very "happy" of mako's behaviour during all this problem.
<abelli> jdub: He handled the ubuntu-italia subject with a sort of detachment, and things are gone upside down.
<abelli> jdub: I strongly disagree with methods argued by this new group
<abelli> .
<jdub> abelli: meanwhile, i know nothing, and am loathe to change things without consensus.
<mdke> perhaps I might help
<mdke> is it necessary for moderators of a list to be team leaders?
<mdke> the issue for me is that we have no moderators on a list
<jdub> mdke: it's not necessary, no; the list has both admin and moderator access.
<jdub> mdke: however, that's the kind of thing i'd prefer to leave up to a locoteam leader. atm, there is none listed on the wiki page.
<mdke> jdub, there is no locoteam leader for the italian team
<abelli> jdub:  I don't know who is this sebastiano, but he didn't too much (almost nothing) for ubuntu-italia.
<jdub> so we have two problems :)
<mdke> lol
<mdke> can we change channel?
<jdub> so the best course of action would be to add this to the community council agenda
<jdub> so it can be sorted out there
<mdke> k you're the boss
<mdke> can you moderate my email through please?
<abelli> jdub: please do not consider myself as available anymore, and let mako explain you why.
<jdub> right
<jdub> mdke: i'm going to make you listadmin in the mean time.
<mdke> ok
<abelli> jdub: can i consider myself free to leave?
<jdub> abelli: you're always free to leave, it's just nice to let people know what's going on if you do.
<jdub> abelli: that's in our code of conduct even. :)
<abelli> jdub: mmm i mean now.
<abelli> jdub: i mailed mako cc: ing matthias...
<abelli> jdub: i was meaning: for this night.
<jdub> you don't need to ask permission from me
<abelli> jdub: i was talking with you, actually.
<abelli> i did what i thought was right, no one told me to do anything more.
<abelli> im sorry if i missed something.
<abelli> it wasnt in my mind.
<jdub> it's ok, it'll sort out
<abelli> jdub: if you need any other information, I can keep going on chatting, otherwise it will be a pleasure to meet you again.
<abelli> ahhh right.
* schweeb stabs beagle
<schweeb> jdub: well, looks like my gsf-sharp pkg works for the most part
<abelli> have good night/day everybody
<abelli> *a*
<abelli> ciao
<jdub> schweeb: "for the most part"? :)
<schweeb> I'm a packaging n00b
<schweeb> gotta tweak a bit... add copyright, etc...
<schweeb> oh shyte
<schweeb> is inotify on by default anymore?
<schweeb> might explain why best is dying on my lappy
<mdz> nope
<zul> hell no
<schweeb> what's the kernel option?  inotify?
<zul> yep
<schweeb> hehe, last time I tried beagle, it was on by default *shrug* I just recalled that it prolly wasn't on anymore like 2mins ago
<jdub> schweeb: hrm, that shouldn't matter
<jdub> *best* is dying, or beagled?
<schweeb> best
<jdub> start beagled with --fg --debug
* dredg has beagle working fine here...
<schweeb> ioctl(-1, INOTIFY_WATCH, {/home/chris/.gaim/blist.xml, 32776}) failedioctl: Bad file descriptor
<jdub> oh
<tseng> yeah schweeb 
<tseng> jdub fix0red that
<schweeb> then like 60 lines of output
<jdub> use my packages that haven't got through NEW yet
<schweeb> ahh
* jdub puts them up in his repo
<jdub> one sec
<schweeb> URL to get?  they're not in archive yet rightr?
<tseng> WOO!
<schweeb> oh goodie
<jdub> tseng: sorry, slept and forgot ;)
<tseng> np
<HrdwrBoB> no more sleeping!
<jdub> uploading now
<jdub> HrdwrBoB: yeah, now there's a valid solution
<jdub> i386 binary and source up at people.ubuntu.com/~jdub/hoary/
<tseng> damn right, beagle
<schweeb> I was pretty good at the no sleep thing last night
<tseng> jdub: apt-ftparchive :(O
<schweeb> although I was too tired to think or accomplish anything, I was too anxious to sleep
<schweeb> tseng: heh
<tseng> meh.
<jdub> tseng: kinda didn't want to make it apt-gettable because random crazy shit goes there
<schweeb> ahh
<schweeb> jdub: works <3
<schweeb> jdub: hey, for svn'ed packages, is it appropriate to run autogen.sh and have the generated files in the .orig tarball, or should it be run via debian/rules at compile time?
<dholbach> schweeb:   ./autogen.sh && make dist   should be fine
<schweeb> where at?  in the orig, or run at compile time?
<dholbach> orig
<schweeb> good, that makes things simpler
<dholbach> people will discourage you from having to build-depend on autotools
<jdub> oh man
<jdub> *another* new gaim
<ogra> heh
<ogra> they never stop
<dholbach> they should start killing dialogs :-)
<jdub> this is exactly the kind of wooly-headed release management that leads to foolish backporting
<mdke> night all
<jdub> we should stand outside the gaim developer's houses with pitchforks and flaming 42 gallon drums
<schweeb> haha
<schweeb> "adjust to our release management style now!"
<ogra> jdub, have you seen that backports already has a bunch of hoary packages (ff 1.0.1, nx etc)
<Keybuk> jdub: I prefer the idea of making Immendio make gossip do msn and friends w:p
<jdub> Keybuk: mmm
<jdub> ogra: maybe we should just do the pitchforks/burning-drums thing with the backports maintainers
<ogra> hmm
<dholbach> jdub: that sounds lovely
<dredg> gah. new gaim-encryption too
* dredg kills it in the face
<dholbach> dredg: you should rss-subscribe to its releases :-)
<dredg> dholbach: i've been away for the last few days. playing the catch-up-with-my-life game
<ogra> jdub, does the CoC comply to the treatment of external resources ?
#ubuntu-devel 2005-04-01
<schweeb> lol
<ogra> jdub, then i would suggest something less rdical...voodo puppets for example
<schweeb> ogra: or just find people who haven't signed the CoC yet
<schweeb> and "suggest" their course of action
<pitti> Mithrandir: bah, dh_compress does compress explicitly specified files even if they are < 4k...
* lamont rediscovers a hard drive with 2.0.35 on it.
<zul> oi vey
<lamont> zul: yeah, I screamed
<infinity> mdz : Regarding the FTBFS of mysqlclient10 on amd64... I suppose it's too late for me to suggest that I recompile 59 source packages to use mysqlclient12 (from mysql 4.0) and drop the old, broken lib entirely?
<zul> i still have have some slackware 2.0 cds around
<mdz> infinity: YES
<infinity> mdz : Just checking. :)
* infinity goes to figure out the failure, then.
<infinity> I may need access to an amd64 machine to poke at it.
<dilinger> hah
<dilinger> infinity, king of the last minute library transitions :)
<infinity> dilinger : Shh.  I just don't feel like fixing bugs in obsolete packages. :)
<infinity> Luckily, this bug isn't all that tough.
<infinity> Besides, all that talking with MySQL upstream has to be of some use..
<infinity> Other than me losing my sanity, that it.
<jdub> Riddell: around?
<jdub> amu: around?
<schweeb> jdub: alright, well, I uploaded what I did for gsf-sharp to http://www.schweeb.org/~chris/ubuntu/
<schweeb> passes lintian
<Robot101> thom: didn't notice slef had joined the channel, or didn't care? :)
<thom> yes
<Robot101> thom: both? :D
<thom> Robot101: mostly the former, but i now don't care eitehr
<jdub> schweeb: ahr!
<schweeb> jdub: huh?
<jdub> schweeb: a pirate says "ahr!"
<schweeb> ahh, hehe
<schweeb> I know a brit that says that, but only when angry ;)
<jdub> hrm
<jdub> automake symlinks in the tarball
<jdub> even though autogen.sh does automake -a
<schweeb> shouldn't have done that?
<jdub> oh
<schweeb> I just ran autogen.sh
<jdub> it needs -c too
<jdub> automake -a -c
* schweeb fixes
<jdub> schweeb: perhaps copy the tomboy/beagle build-depends for mono stuff
<jdub> schweeb: hrm, so
<jdub> schweeb: instead of running autogen.sh
<jdub> schweeb: run each command manually
<jdub> schweeb: using aclocal-1.6 and automake-1.6
<schweeb> in the rules file, or in the .orig source?
<jdub> when you're generating the dist tarball
<schweeb> k
<schweeb> 1.6 specifically?  I have 1.4 installed
* jdub tries make distcheck
<jdub> schweeb: yeah, use 1.6
<infinity> graphviz build-deps on itself unintentionally.  Cute.
<daniels> mjg59: bleh
<daniels> mjg59: if we have working suspend, just bump the version to 1.2
<schweeb> jdub: Build-Depends: cdbs, debhelper (>= 4.1.0), mono-mcs (>= 1.0) | c-sharp-compiler, mono-jit [i386 powerpc] , mono-mint [!i386 !powerpc] , libmono-dev, mono-utils (>= 0.96), mono-gac, libgsf-1-dev, libgsf-gnome-1-dev
<schweeb> jdub: those look better
<jdub> tops
<mjg59> daniels: Yeah, patch submitted
<mjg59> I was sitting there for ages looking at the code and thinking How does any of this stuff he added make any difference?
<mjg59> The answer is, of course, that it doesn't
<schweeb> jdub: and I'm guessing in the dist tarball, I shouldn't run configure, like autogen does?
<jdub> you do
<mjg59> daniels: I've also come up with a solution for X output that doesn't require changing the X config
<jdub> run the modified autogen commands (1.6 for aclocal and automake and use -a -c for automake)
<dholbach> good night everyone
<jdub> then do the maintainer-mode configure
<jdub> then make dist
<pitti> night dholbach 
<schweeb> ahh
<mjg59> Now, if I can just get the damn thing to reset...
<dholbach> bye pitti 
<schweeb> alright, that makes more sense to me now
<jdub> schweeb: oh, you need dh_makenetlibs too :)
<schweeb> alright
<schweeb> I wasn't sure what it did
<schweeb> and lintian bitched
<jdub> yeah, lintian doesn't know about it yet
<daniels> mjg59: oh?  just poking it all by hand from userspace?
<schweeb> what's it for? registering with the GAC or what?
<jdub> schweeb: it adds a little file that tells dependent packages how to depend on it
<schweeb> ahhhh
<mjg59> daniels: Yeah, I figured out how to get the video button to actually generate an acpi event
<mjg59> The ACPI spec is full of useful information
<daniels> heh
<dilinger> it's big enough, it should be :P
<jdub> mjg59: how boldly would you state the quality of our laptop/acpi power management in hoary?
<mjg59> jdub: It's massively better than anything else out there
<buga> jdub: i also can confirm that qca-tls is widely used
<buga> kopete developers said that using qca-tls is temporary, but removed "temporary" notice later
<infinity> lamont : Around?
<jdub> schweeb: also, why 'libgsf-cil' as the source package name? shouldn't it be 'gsf-sharp'?
<jdub> buga: aha
<schweeb> jdub: I was going by what all the rest of the package names for mono assemblies I've seen are
<jdub> schweeb: those are binary names tho, not source names
<schweeb> okay, so leave the binary name -cil, and set the source name to gsf-sharp?
<jdub> $ apt-cache showsrc libevolution-cil | grep ^Package
<jdub> Package: evolution-sharp
<jdub> yeah
<schweeb> kk
<jdub> that means the tarball name, etc., etc. too ;)
<schweeb> jdub: hey, I'm not doin too bad for bein green at packaging ;)
<jdub> not at all
<jdub> very tidy :-)
<schweeb> this is like the 2nd package I've done that isn't just a mod/upgrade of a prebuild
<schweeb> and the 1st haven't been released... Xen stuff
<mjg59> If I can figure out this reboot problem, we're all set
<schweeb> jdub: hrm... configure wasn't generated when I did aclocal-1.6 and automake-1.6
<mjg59> jdub: Are you still getting suspend love with latest Hoary kernels?
<jdub> mjg59: i did the other day
<jdub> mjg59: i was having problems earlier with suspend workign once then not again
<jdub> but i did it twice the other day
<daniels> jdub: except dbus is dbus-mono, not dbus-sharp :)
<jdub> schweeb: you should be running...
<jdub> aclocal-1.6
<jdub> libtoolize --force --copy
<jdub> automake-1.6 -a -c
<jdub> autoconf
<jdub> ./configure --enable-maintainer-mode
<jdub> make dist
<jdub> daniels: special case :-)
<schweeb> ah, okay, didn't do autoconf
<jdub> heh
<daniels> jdub: the exception that proves the rule!
<jdub> autoconf is the bit that generates configure ;)
<jdub> morning jlj
<mjg59> jdub: Probably down to mdnsresponder, if you had that running
<daniels> jdub: why not just autoreconf -v --install?
<schweeb> jdub: hehe, well their autogen script didn't run it!
<jdub> jlj: how's the response been to your release?
<jdub> mjg59: could've been polypaudio too, actually
<Amaranth> hey, jlj comes here too
<schweeb> I guess I was wrong on my versioning... they claim it's 0.3, but their NEWS claims 0.1.0, heh
<Amaranth> schweeb: you wrote http://bonehunter.rulez.org/~algernon/blog/2005/03/20/#pyMusique ?
<Amaranth> oh, nm
<schweeb> nope
<Amaranth> you're talking about something else :P
<schweeb> yep
<Amaranth> i fell off my chair when i read what they wrote about us
<schweeb> gsf-sharp, heh
<Amaranth> my name is python, or something
<calc> Amaranth: hehehe
<pitti> night everybody
<lamont> infinity: not really
<daniels> infinity: If you need SSH access to an amd64, I can hook you up.
<infinity> daniels : Too late, but I may bug you later.
<daniels> infinity: OK
<infinity> lamont : Can I bug you about an FTBFS bug of yours anyway
<infinity> lamont : ?
<infinity> lamont : 7846 ... libtool is generating a different linker line on i386 than on the other 3 arches (which is why it's only failing on i386).. Any chance it was cosmic rays, or a goofy chroot?
<infinity> daniels : Do we have a house yet? :)
<daniels> infinity: just called and harassed Simon, incidentally
<daniels> infinity: 34 Barkly St is coming up soon ...
<infinity> daniels : A lot of stuff is.  Then again, it may all suck as badly as everything we've already seen. :)
<daniels> Heh.
<infinity> daniels : If we don't settle soon, Zofia might actually cause me bodily harm.  And I'l pass on the favour.
<infinity> daniels : Not to mention, until we move, I don't have my amd64 system up and running.
<lamont> infinity: shouldn't be...
<daniels> infinity: Right.
<lamont> infinity: and libtool shouldn't be in the chroot, so the log should show what version was installed.
<mjg59> Hm. ndiswrapper is depressingly easy to set up
<infinity> lamont : If you look at the build logs, it looks pretty suspect, that's all.
<infinity> lamont : On the other hand, the packages doesn't relibtoolise during build either, so it's all a bit weird.
<infinity> lamont : IOW, I can't come up with a solid explanation for the different logs, other than "something was confused that day".  But I'll dig deeper.
<infinity> lamont : Could you retry it anyway for kicks?
<lamont> which package?
<infinity> lamont : graphviz/i386
<infinity> lamont : Note that it IS in the archive already, it just failed during your rebuildability testing...
<lamont> ah, from the hoary-test rebuild?
<lamont> right
<infinity> Right.
<infinity> But the other 3 arches succeeded.
<lamont> given back
<lamont> mind you, if it succeeds, I'll be annoyed
<infinity> Not as annoyed as I will if it fails. :)
<lamont> oh, if it still works, I expect that there's still a bug... if it succeeds, I'll build it 3-5 more times to take a vote.
<jdub> mjg59: http://live.gnome.org/ProjectUtopia_2fPowerManagement_2fgnome_2dpower_2dmanager
<lamont> intermittant failures are far worse than solid ones.
<infinity> lamont : Agreed, though I don't look forward to trying to find the bug in question.  The previous i386 build (the one in the archive) got the correct libtool linker line, and so did the other 6 builds (previous and current builds of the other 3 arches)
<infinity> lamont : So, one broken build out of 8 looks pretty weird, when the breakage is in an arch-indep bit.
<lamont> yeah
* infinity goes back to reproducible bugs for a while.
<mjg59> jdub: Yeah, it's lovely
<Robot101> *drool*
<mjg59> jdub: It doesn't do all that much of use yet, though :)
<mjg59> I'm doing a GUADEC BOF on this stuff
<schweeb> jdub: alright, uploaded changes... would have done so a long time ago, but my parents disconnected the cable modem... I wasn't a very happy camper
<schweeb> jdub: http://schweeb.org/~chris/ubuntu
<mjg59> thom: I've also got code for ndiswrapper over suspend/resume
<mjg59> (argh)
<jdub> schweeb: d'oh!
<jdub> schweeb: thanks :)
<schweeb> np
<schweeb> always lookin to contribute, now was as good a time as any
<jdub> ahar!
<lamont> infinity: T&*)%_+_)&%*^_(+_*&%^_)&*^_%)(+*^%^(
<infinity> lamont : Is that line-noise for "it built fine this time"?
<lamont> document that however you want.
<lamont> the latter
<lamont> must run for a while
<infinity> lamont : alright... I'll document another successful build, but leave the bug open for now.
<infinity> lamont : I'm still betting on cosmic rays.
<jdub> schweeb: ok, i'm running a big fat index now :-)
<schweeb> jdub: cool, tell me how it goes... I'm too impatient to sit there and let my stuff index... too many gigs of it
<schweeb> jdub: what about gst-sharp?  that gonna be wanted too, or are there probs with it?
<jdub> dunno really
<jdub> haven't tried it
<janc> it seems like several packages have no /usr/share/applications/*.desktop files (yet) ?
<crimsun> several being "a ton", yes
<janc> I just filed a bug for fontforge
<janc> the other ones I found were in universal
<schweeb> jdub: ah, gst-sharp ain't happenin... requires a newer ver of libgtk2.0-cil...
<jdub> schweeb: aha, ok
<srbaker> so i started update-notifier (and it's running in my session) and i never get the icon in my panel
<jdub> you will when you apt-get update and there are updates available
<srbaker> hrm
<cc> ok, if i've already rolled a LiveCD, and i want to make further changes, i should use the LiveCDCustomizationHowTo and only pay attention to the customizations part (i.e. preparing the chroot) right?
<jdub> should do
<cc> great, time to make the LiveCD more customised then. does anyone know how to specify the firefox startpage properly? in my last roll pref("browser.startup.homepage", "...") didn't work so well
<jdub> perhaps check our firefox diff
<schweeb> cc: I think the user's preference overrides in that situation... so you'd have to specifically set it in the user's prefs.js... otherwise, there's also a way to lockdown ffox settings, but I don't have a link
<cc> schweeb: hmm, thanks. i'll have to take a look
<cc> (and get faster cdrws)
<schweeb> I've done it at work before
<cc> or alternatively, use Epiphany, which uses gconf settings iirc
<schweeb> crap, I thought I blogged about when I did the firefox lockdown :-/
<schweeb> guess you're out of luck
<schweeb> it's on mozillazine somewhere
<zul> later
<srbaker> whoa.  i have a big hate on for evolution.  i think i'm going to have an i hate evolution party
<schweeb> srbaker: the enlightened use thunderbird or mutt
<srbaker> schweeb, i was using thunderbird, i'm switching back to balsa
<srbaker> all mail clients suck
<schweeb> yea, pretty much
<srbaker> actually, i don't mind evo for mail
<srbaker> it's all of the other horseshit they throw in there
* Keybuk adds "nda" to the list of silly tool names :p
<fabbione> morning
<janc> schweeb : thunderbird has one big faw: it has no useable plain text editor  :-(
<schweeb> hrm?  I make plain text messages just fine...?
<janc> you don't see how they look at the receiver's end?  ;)
<schweeb> plaintext is just that - plaintext... no formatting... I still dunno what you're talking about
<sabmoc> hi schweeb 
<schweeb> hello sabmoc
<janc> quoting is completely broken in the plain text editor
<sabmoc> schweeb, hows it going?
<schweeb> fine fine
<schweeb> trying to mock up some mono 1.1.4 packages for myself
<janc> at least up to TB 1.0
<calc> mutt is a good mail client :)
* infinity scratches his head.
<schweeb> janc: odd, it's worked fine for me.  I have my whole company (150 users) running on tbird
<sabmoc> schweeb, hmm.. Im not much of a programmer so Im not too interested in mono, only the slick mono apps like tomboy.
<schweeb> hehe
<infinity> Is festival_client supposed to vomit all over stderr when you run it?
<schweeb> sabmoc: hah, I'm in the middle... I know enough that I can build the stuff and be interested in it, but I'm by no means a programmer
<schweeb> as soon as I hit GUI design I give up
<schweeb> hopefully Stetic makes things better
<janc> schweed : it works, the messages just look stupid when the receiver has a decent mail client  :P
<sabmoc> schweeb, yeah me too sort of, I went though a little the learning to build mono process, then I went though all the msdn tutorials on mono (very good btw) then made a calculator in gtk# and gave up :D
<janc> schweeb*
<sabmoc> I think I would like to learn xul now.
<sabmoc> err.. correction, I went though the msdn tutorials on c#, they dont have any tutorials on mono yet. ;)
<sabmoc> gtk# really impressed me, I didnt give up because I didnt like it. GTK# makes GTK+ look like an evil joke. No offense :D
<schweeb> yea, I've seen GTK+ too, bleh
<Amaranth> sabmoc: PyGTK makes GTK# look like a joke. :P
<sabmoc> Amaranth, but I have no interestin in py, I picked up a book on it but keep falling asleep, anything that easy is just no fun.
<schweeb> bleh, py doesn't rub me right for some reason
<Amaranth> sabmoc: You like pain? :)
<sabmoc> me2
<Amaranth> If you do it correctly it reads like psuedo-code, it's so awesome.
<sabmoc> Amaranth, no, just kidding you a bit, but py just didnt really interest me. Its just personal preference I guess.
<Amaranth> GTK# is good too. Anything is better than GTK+. :)
<sabmoc> Amaranth, I know, but maybe thats the problem, my brain needs at least a small level of abstraction from psudocode to code, writing psudocode is no fun.
<Amaranth> I'm lazy so easy is fun. :)
<sabmoc> but its possible im crazy
<sabmoc> Amaranth, hehe
<schweeb> I like perl for quick admin stuff, C# for other stuff
<sabmoc> schweeb, ever looked at xul?
<schweeb> xul is mozilla's stuff, isn't it?  if so, yes
<sabmoc> yes
<schweeb> hrm
<sabmoc> when I have time Im starting to poke into xul a little bit. So far it seems more complecated that I had hoped, but Im still interested.
<schweeb> it seems really complicated
<sabmoc> yes
<sabmoc> its basically just xml, css and javascript, thats pretty neat
<schweeb> I don't like webapps that much, heh... if I so desired, I could do PHP all day at work
<sabmoc> But even for a simple app they make you jump though a lot of hoops
<sabmoc> through*
<schweeb> hrm
<sabmoc> schweeb, where do you work?
<schweeb> I work in the finance industry... for a credit card processor in MI
<sabmoc> wow cool
<schweeb> eh, not really... rich bosses suck
<sabmoc> haha
<sabmoc> want to trade jobs?
<schweeb> probably not
<sabmoc> indeed
<jbailey> Financial industry's not that bad.
<jbailey> That's usually my sector.
<sabmoc> hey jbailey 
<schweeb> we're a bit... understaffed
<schweeb> and mismanaged
<jbailey> schweeb: understaffed usually isn't the problem I've seen.  Committee meetings with 30 people, none of whom have a clue or are really interested in the problem are.
<schweeb> heh
<jbailey> But each of them have to sign off on it because it touches something they might once have thought about.
<sabmoc> damn bureaucracy
<schweeb> well, we're a rather small company... ~150... 5 person IT dept, 2 of us are co-ops (interns)
* sabmoc gets back to work.. *grumble grumble*
<jbailey> sabmoc: Usually, bad trust model more than anything else.  You can't trust that people will review the things they're supposed to so you drag them into a meeting to force them to do it.
<sabmoc> jbailey, hmm.. ic
<sabmoc> jbailey, I've never had to deal with that, closest I have ever come to going corporate was working in the mailroom for midlandwalwyn but they got bought out by merril lynch sortly before I left (I still blame myself)
<schweeb> odd
<sabmoc> oops, I mean shortly after I left.. 
<schweeb> I think I ran into a problem compiling mono 1.1.4 with mono 1.1.4
* schweeb uninstalls
<sabmoc> schweeb, I havent compiled mono since around .40 or so, whats the problem?
<schweeb> it's cleared from my scrollback already
<sabmoc> heh
* sabmoc reaches over and adds another zero to schweebs scrollback
<schweeb> but I built mono alone earlier, and installed to /usr/local... but when building for a package, it bombed on compile every time
<schweeb> (fresh source tree)
<sabmoc> ah, well I dont know a thing about packaging 
<sabmoc> ok, time to work
<schweeb> time to sleep
* sabmoc is away: why cant I just make art for a living?
<jbailey> sabmoc: Midland Walwyn had an awesome trading floor. =)  I got a tour of their facility in BCE in 96 or 97.  
<sabmoc> jbailey, cool, I would have been the guy pushing the mailcart around, and picking up the courier to be delivered.
<sabmoc> jbailey, that was back when I lived in TO of course, Im in BC now.
<sabmoc> that was such a fun job :) 
<jbailey> I was working for Phillips Hager & North in Vancouver at the time and was out here to do some server maintenance.
<jbailey> I moved to TO 'bout 4 years ago, moving to Montral this summer.
<sabmoc> cool
<infinity> And in another 3 years, he'll be in Newfoundland.
<jdub> noofie!
<jbailey> infinity: I'm vegan, I don't think I could cope with being screached in.
<daniels> jbailey: You too could be a Noofie.
<daniels> jbailey: Ooh, but I hear the screach is awesome!
<infinity> jbailey : Pfft.  Convert.
<jbailey> Okay, and why do the Auzzies know about neufies?
<jdub> we know noofies smell
<daniels> jbailey: And their screach.
<schweeb> feel the love! ;)
<jbailey> jdub: Newfie's don't smell, that's just what living in a seaport smells like in general.
* jbailey misses living near real water.
<jbailey> Not this thing that used to be a fresh water lake that's beside me.
<infinity> Port, schmort.
<infinity> A year next to the ocean in Cairns cured me of any such urges.
<infinity> Thankfully, Melbourne smells enough like "big city" to avoid smelling like ocean.
<jbailey> infinity: Are you in Melbourne now?
<infinity> Aye.
<jbailey> Shit dude, pick a city and stay there for a week or two.
<daniels> Well, as much as you can call Altona a part of Melbourne.
<infinity> I'm staying, I promise.
<infinity> Unless they kick me out of the ocuntry.
<infinity> daniels : Pfft, it's closer than your current residence.
<infinity> (barely)
<infinity> Also, I get to hear folk from Footscray on the train every day talking JUST LIKE Dave Hughes.  And that's always good for a laugh.
* infinity gives wget a sideways glance.
<sabmoc> Wow, is everyone here Australian Noofies except me? Whats going on?
<daniels> sabmoc: Australian Noofies?
<daniels> That's a little bit of a contradiction in terms.
<infinity> Evidently, wget segfaults iff the first connection times out, but the second attempt connects.
<schweeb> I'm a resident of the US of A
<infinity> That seems... Different.
<daniels> Except for infinity, because he comes from Noofieland, and now lives in .au.
<infinity> I come from Noofieland?
<daniels> infinity: Yes.
<infinity> WOuld you like me to tell people that you come from Darwin?
<daniels> Well, that's demonstrably untrue.
<sabmoc> yes, tell us he comes from Darwin
<sabmoc> then tell us who Darwin is
<infinity> daniels : As is the bit about me and Newfoundland. :)
<infinity> daniels : Since I'm from the other side of the country.
<daniels> sabmoc: darwin is a horrible city in Australia
* infinity goes to argue with wget instead, which is starting to seem like more fun.
<sabmoc> infinity, noofies are the best people
* sabmoc has never met a noofie he didnt like.
<jbailey> sabmoc: While australia is a rock they exile people to, it's a bit too big to be mistaken for the Province of Newfoundland and Labrador.
<jbailey> sabmoc: Even my geography isn't that bad (and I can assure you, my geography is horrible)
<infinity> It's probably the lack of meat that makes your sense of proportion and direction go all whacky.  <nods knowingly>
<sabmoc> jbailey, how can you have bad geography? I thought you were Canadian.
<sabmoc> oh wait, should have said "of course you have bad geography, your Canadian."
<daniels> s/your/you're/
<sabmoc> gah
* sabmoc things grama is for whimps
<jbailey> sabmoc: Right.  If it's flat it's the praries.  If there's a mountain it's BC.  If there's a big lake, it's Toronto.  If people are talking around me and I can understand them all, it's Quebec, and if it smells like Vancouver but is either hotter or colder than it should be, it's Halfax.
<sabmoc> HAHA
<jbailey> sabmoc: But notwithstanding that, I tend to think that Africa and India look awfully similar on maps.
<daniels> jbailey: And if it's flat, dull, and invaded by masses of hackers once a year, it's Ontario.
<jbailey> You're thinking about ottawa.  It's not perfectly flat.  There's one hill there, and they decided to put the parliament buildings there.  There's a hurd of wild cats there, which I think is terribly cool.
<jdub> oh man
<daniels> Is a hurd like a herd? :)
<jdub> jbailey: you're SICK
<jdub> ^ exactly
<dilinger> daniels: they're daemon cats
<daniels> jbailey: and I thought Ottawa was in Ontario?
<jdub> daniels: we'll fix him in sydney
<jbailey> Err.
<Keybuk> a hurd of cats sounds cruel ... poor things must keep dying every few hours :(
* OddAbe19 is back (gone 07:44:24)
<jbailey> daniels: There are allegidely mountains in Ontario somewhere.  I haven't seen any sign of them, but this provice is somewhere around a million square kilometers.
<daniels> jbailey: Ahr.
<sabmoc> jbailey, what is the weather doing over there right now, have your igloos melted yet?
<jbailey> The province I'm moving to is apparently larger: 1,450,680 square kilometres.
<Keybuk> ouch; we have 1,511 sources in main.  and 1,026 sources we've changed from Debian
<jbailey> sabmoc: Mostly.  There's still a bit of snow on the ground my rain and sun over the last 3 days are wearing them down.
<infinity> The igloos never melt.  If they did, where would we keep our pet polar bears?
<Keybuk> (though some of that latter number are universe ones)
<daniels> Keybuk: I blame lsb init.
<Keybuk> daniels: I suspect python2.4 is more worthy of your blame
<jbailey> Keybuk: A question that came to mind earlier, if we eventually merge everything to where the changelog is the only difference, do we eventually go back to just merging?
<Keybuk> if the changelog is the only difference, get elmo to sync it from Debian
<daniels> highly unscientific:
<daniels> daniels@catsby:~xap/debian/patches% COLUMNS=1200 dpkg -l | COLUMNS=1200 egrep '^ii' > foo
<Keybuk> it drops our changelogs, but that's ok because they should be at least mentioned in the Debian one
<daniels> daniels@catsby:~xap/debian/patches% wc -l foo
<daniels> daniels@catsby:~xap/debian/patches% awk '{ print $3; }' < foo | grep ubuntu | wc -l
<daniels> 1656 foo
<daniels> 864
<jbailey> Keybuk: Ah, good.
* sabmoc wears shorts and tshirts year round.
<Keybuk> daniels: aptitude install dpkg/experimental
<Keybuk> daniels: dpkg -l | egrep ...
<daniels> Keybuk: ooo, shiny.
<mkedwards> wasabi_: wrt ant packaging, which domino needs to fall next?  Can I help?
<fabbione> elmo: i think there is an inconsistency in the Sources.gz. kdesdk is in main as source and a couple of libs, but the Sources.gz still reports it as in universe
<jdub> jbailey: what are your thoughts on new versions of nptl?
<sabmoc> wow tomboy rocks
<jdub> http://boudicca.tux.org/hypermail/jackit-devel/2005-Mar/0104.html
<jdub> jbailey: ^
<sabmoc> schweeb, I have a couple questions about LoCo.
<sabmoc> schweeb, knock knock
<mkedwards> mdz: word to the wise: "There is no way of recovering an invalid snapshot" (per dm-exception-store.c).
<mkedwards> mdz: So don't jog your USB stick when it's your device-mapper COW device.  :(
<elmo> what's up with mono being uninstallable?
<elmo> jdub: ^-- ; it stops me from test-building beagle
<fabbione> elmo: did you read above?
<fabbione> elmo: and the Build-Deps for kdesdk will pull in more craft from universe
<elmo>     kdesdk | 4:3.4.0-0ubuntu1 | hoary/universe | source
<elmo> I don't know what makes you think it's in main?
<fabbione> yes... but kdeaddons Build-Dep on libcvsservice-dev (provided by kdesdk)
<fabbione> in the pool/ is in main
<elmo> katie@jackass:~ $ zgrep kdesdk dists/hoary/main/source/Sources.gz 
<elmo> katie@jackass:~ $ 
<elmo> fabbione: that's seed inconsistency - it happens all the time
<fabbione> ah ok
<fabbione> in main there is an older version tho
<elmo> things aren't pulled in automatically so we have some control over what gets into main
<fabbione> hmmm
<fabbione> meh not kdeaddons..kdewebdev
<fabbione> kdewebdev is the one that Build-Dep on something provided by kdesdk
<fabbione> and kdewebdev is in main afaics
<elmo> yes, I know, it's an ongoing thing
<fabbione> ah ok :-)
<elmo> we're discussing it with the kubuntu folks
<fabbione> fine for me than
<fabbione> i tought it went in unchecked
<fabbione> (tbh these are the last 2 packages for main, the sparc buildd is bitching about :-))
<jdub> elmo: how's it borked?
<elmo>   mono-mint: Depends: mono-assemblies-base-0.96 but it is not installable
<elmo>              Depends: mono-common (= 0.96-1) but 1.0.5-1 is to be installed
<elmo> up-to-date i386 hoary chroot
<jdub> ergh
<jdub> elmo: one for tseng / motu
<pitti> Morning
<elmo> jdub: k
<sabmoc> Is anyone organizing ubuntu-love days?
<aj> hrm, so what goes on at these Ubuntu conferences?
* aj ponders visiting sydney for a couple of days at least
<Keybuk> the main plan for the sydney one is planning for breezy, I think
<aj> ym bendy?
<Treenaks> aj: no, breezy :)
<Treenaks> aj: http://lists.ubuntu.com/archives/ubuntu-announce/2005-March/000020.html
<aj> sabdfl's been gagged and left tied up in the back of his jet or something? :)
* Treenaks points at Keybuk 
<dholbach> goood morning
<Keybuk> Treenaks: whyfor point?
<dholbach> Keybuk: cool, thanks for the /patches/ :-)
<Treenaks> Keybuk: something about suggesting badgers :)
<Keybuk> only because I couldn't remember the names of the other dwarves
<smurfix> Keybuk: Some of them are not quite suitable for release names anyway.
<dholbach> morning elmo, could you please sync  lineakd  from sid at some stage of caffeination? :-)
<elmo> dholbach: just lineakd?
<elmo> it has a bunch of dependent children source packages
<dholbach> elmo: i'll investigate
<dholbach> elmo: thanks
<elmo> dholbach: (I mean lineak-.*plugin, FWIW)
<dholbach> elmo: i only had a complaint about lineakd itself and it seems to work with the new debian version
<dholbach> elmo: then it'd be  lineakd, lineak-kdeplugins, lineak-xosdplugin, lineak-defaultplugin
<dholbach> elmo: because they enforce lineakd versions
<dholbach> elmo: did you plan to attend tomorrow's CC meeting?
<elmo> dholbach: sure
<dholbach> elmo: because right after it, the MOTU crew wanted to discuss the proceedings of universe in the release schedule and mdz already pointed out, that we'd need your input
<dholbach> elmo: (  http://www.ubuntulinux.org/wiki/MOTUMeeting  )
<elmo> dholbach: ah.  hmm.  I have to travel to London at some point - how long is the second meeting likely to be?
<dholbach> elmo: we have it as first point on the agenda
<dholbach> elmo: and if you don't make it, you could just tell us, how you feel towards it in advance
<elmo> you guys want to change universe _after_ release??
* elmo whines quietly
<dholbach> i guess most of us don't *WANT* to
<dholbach> elmo: http://www.ubuntulinux.org/wiki/UniverseUnmetDeps will give you an idea
<dholbach> and that's not even the "doesn't build anymore"-list
<dholbach> we just need the input if it's possible or not, because i'd feel a bit safer if it was 
<elmo> not being funny, but trying to fix hoary universe now seems like fighting in quicksand.  it's been version frozen for several months now and you guys have come to the party very late (not at all your fault).  have you considered concentrating your efforts on breezy instead?
<elmo> oh tehcnically it's possible, just a small amount of work - it's just messing with something after it's been released - even universe - just gives me all the wrong kinds of chills
<dholbach> of course... we'll focus on each an every release
<elmo> apart from anything else, breezy will probably fix most of these issues, just through auto-sync
<dholbach> but i just feel bad for having a fucked-up universe
<Treenaks> dholbach: "fucked-up" or "slightly broken"
<dholbach> Treenaks: my judgement depends on the DoesntBuildAnymore-list
<elmo> dholbach: anymore meaning since warty or?
<dholbach> elmo: i don't quite understand
<elmo> well anymore implies they did build once?
<dholbach> elmo: i heard someone mumbling about test-rebuilding the universe some time ago and never heard of it again... i'm always dreading such a list NonBuildables, but i'm sure we could tackle a lot of dumb stuff with it
<elmo> I'm actually importing universe right now into the test-rebuild archive
<elmo> main just finished this weekend
<dholbach> oh cool
<dholbach> where could we check for build-errors?
<pitti> jdub: here?
<dholbach> hi pitti 
<pitti> Hi dholbach 
<jdub> pitti: yo
<elmo> dholbach: I'm not sure - lamont will know
<daniels> bleh
<dholbach> elmo: i'll ask him then
<daniels> elmo: mirnyy needs more connections ;)
<elmo> daniels: use a mirror, you tramp
<daniels> elmo: we have rsync mirrors?
<elmo> boggle
<elmo> tons
<daniels> yeah, just waiting for /wiki/Archive to load
<daniels> i blame you for telling me to use mirnyy instead of auckland
<elmo> us.archive.ubuntu.com is guaranteed to be up-to-date too
<elmo> god, don't use mirnyy for the archvie
<dholbach> elmo: thanks a lot
<elmo> archive.u.c is fine atm, cdimage (i.e. mirnyy) is still suffering horribly
<daniels> elmo: ah, ok
<daniels> it seemed absolutely fucked
<daniels> 5KB/sec and always dropping out
<daniels> i suppose you can't speak as to whether mirror.isp.net.au is a decent mirror
<elmo> yeah, apache's err, not performing well.  I'm not "fixing" it, 'cos I want something to beat thom around the head with when he gets up
<daniels> i like your motivations :)
<elmo> daniels: I don't know - I'm still look for an australian who can give me a useful answer on who'd be best for au.archive.u.c
<daniels> elmo: planetmirror
<daniels> absolutely no doubt there
<jdub> planetmirror
<daniels> they have stupidly fast links to the entirety of the country, a fair few people peer with them, and they mirror the entire, well, planet
<daniels> and are very reliable
<daniels> hell, they were going to mirror fd.o
<daniels> (we didn't get around to setting up a proper mirror infrastructure)
<daniels> the only downside to planetmirror is that they don't seem to do an rsync mirror
<elmo> yeah, but that's not a requirement for $cc.archive.u.c
<doko> morning all
<dholbach> morning doko!
<pitti> Hi doko
<pitti> Morning sabdfl 
<sabdfl> hey pitti et al
<daniels> sabdfl: 'morning
<fabbione> morning sabdfl 
* Amaranth heads for bed
<sabmoc> night guys
<dholbach> elmo: thanks again! :-)
<elmo> dholbach: no prob
<janc> Amaranth : good idea, it's about 9h35 here  :-/   ;-)
<dholbach> elmo: could you please sync   libgnome2-wnck-perl   from sid, when you do the next bunch?
<bob2> is it possible to edit the applications menu in hoary atm?
<dholbach> bob2: ask Amaranth, he's writing code to make it happen
<dholbach> bob2: but he said "<Amaranth> now, don't say my name anymore it beeps and wakes me up :P"
<Amaranth> grr
<Amaranth> bob2: You can edit /etc/xdg/menus/applications.menu to change the actual structure of the menus and /usr/share/applications contains the desktop files that go into the menu (they're ini files)
<pitti> Hi carlos
<Amaranth> http://dev.realistanew.com/menu-editor/ is what i have so far
* Amaranth turns off the beepiness
<carlos> morning
<bob2> so there's no GUI in hoary for this atm?
<dholbach> erm... how can a package have two different source packages? (apt-cache showsrc schoolbell)
<dholbach> ah... maybe re-packaged
<dholbach> that explains, why schoolbell-ssl isnt installable any more
<drspin> anyone awake this evening?
<sabmoc> who do we talk to about setting up a mailing list for LoCoTeam-CA? or registering the domain www.ubuntu-ca.org?
<dholbach> hey mvo
<mvo> hey dholbach 
<mvo> morning all
<dholbach> good morning, seb128 
<sabmoc> meh, im going to bed
<sabdfl> sabmoc: smurfix is the LoCo team coordinator, he'll be able to help you out
<drspin> what script is run when I insert my USB drive?
<seb128> hi
<sabmoc> sabdfl, thank you
<drspin> or better yet -- would it be possible to get RO support for NTFS added?
<seb128> ajmitch: have you tried python-nautilus before uploading it ?
<sabdfl> drspin: check out gnome-volume-manager, and hal, and pmount
<pitti> Hi seb128 
<mkedwards> drspin: ntfs support (ro) works fine on livecd
<pitti> drspin: what do you mean by "added"?
<pitti> drspin: you should already be able to use NTFS removable devices
<mkedwards> drspin: it'll let you mount it rw too, but I wouldn't advise it.  <g>
<drspin> mkedwards: yes :) :) but the automount scripts for a USB drive doesn't check for NTFS -- therefore my drive doesn't mount when I plug it in and it's a pain in the a$$ to use it (root only)
<pitti> drspin: and you can add NTFS partitions to /etc/fstab
<seb128> hey pitti 
<drspin> in other words I have to manuall mount my USB drive with the NTFS filesystem and only root can use it then
<seb128> pitti: you broke gnomevfs :p
<pitti> seb128: ??
<pitti> seb128: I only added a segfault patch recently :-)
<pitti> seb128: you mean #7933? indeed, very odd
<mkedwards> drspin: mount -o ro,umask=000
<pitti> drspin: no, it should be mounted automatically
<mkedwards> (via sudo)
<seb128> pitti: yeah, this one :)
<pitti> drspin: if not -> http://wiki.ubuntulinux.org/DebuggingRemovableDevices
<pitti> drspin: and please _dont_ use mount
<pitti> drspin: use pmount /dev/yourdevice as normal user
<seb128> pitti: this crash is due to some distro changes ? Just to know if it should be closed upstream
<mkedwards> drspin: pitti's right; I use mount with HD partitions
<pitti> seb128: I didn't deal with it yet, will do ASAP
<seb128> k, thanks
<drspin> pitti: WOW!! 15 or so people have helped me with this and you are the first one to be helpful... followed closely by onkarshinde in #ubuntu... thanks
<drspin> sorry to annoy the -devel chan
<mkedwards> drspin: I only point out umask= to say that mount doesn't imply root-only
<seb128> pitti: I would like to get your opinion on the da_DK breakages for this guy. I've Cc you on the bug, I wonder why it opens en_GB after da_DK
<dholbach> morning dredg 
<seb128> pitti: the guys has opened a bunch of bugs for differents apps
<pitti> drspin: as it happens, I'm the pmount maintainer and caretaker of hotplug stuff :-)
<drspin> mkedwards: I use it in my fstab but not sure how to set those on the cli
<drspin> pitti: well thanks for the help :) :)
<mkedwards> pitti: interesting hal weirdness: hald wedges during startup if a USB stick was present during power-up (probably BIOS brain damage)
<elmo> tseng: ?
<drspin> pitti: can I annoy you for another moment?
<mkedwards> pitti: see comment in http://ubuntulinux.org/wiki/LiveCDPersistence
<pitti> drspin: sure
<drspin> pitti: pmount /dev/sda1
<drspin> mount: wrong fs type, bad option, bad superblock on /dev/sda...
<pitti> drspin: pmount -d /dev/sda1
<pitti> drspin: (and /msg please)
<sabmoc> Is there any chance I could get some free webspace for hosting some files if they are related to ubuntu?
<janc> sabmoc : that depends largely on what you want to host...
<janc> (I can't host, but there are several solutions...)
<pitti> dholbach: you should ask elmo to sync rxvt-unicode, it brings a security fix
<dholbach> pitti: why me? :-)
<dholbach> pitti: i'll test it and ask him... thanks 
<pitti> dholbach: or any other MOTU
<dholbach> <- dogwalk
<pitti> dholbach: universe syncs are the responsibility of MOTU, so I don't want to interfere with freezes
<ace2001ac> anyone try compiling gcc 3.4.3 on amd64?
<dholbach> pitti: thanks for telling me
<maswan> ftp-deb@churchill:~> rsync --delete --delete-after -av rsync://releases.ubuntu.com/ubuntu /export/ftp/mirror/ubuntu
<maswan> rsync: read error: Connection reset by peer
<maswan> rsync error: error in rsync protocol data stream (code 12) at io.c(162)
* maswan prods ftpadmins
<kagou> hi
<doko> mdz: still awake?
<dholbach> elmo: could you please sync rxvt-unicode from sid?
<madduck> daniels: ping?
<daniels> madduck: pong
<madduck> i just installed hoary's xserver-xorg and had some comments...
<madduck> specifically:
<madduck> (a) i was asked by debconf 4 times to configure the xserver (apt-get install x-window-system-core)
<madduck> i have a de_DE system, and 'nodeadkeys' was the default for the question where i enter ctrl:nocaps usually
<madduck> (that was (b)
<madduck> )
<madduck> the variant question was empty, however.
<madduck> and for (a): each time, debconf asked me more questions than before...
<madduck> [other than that, it works like a charm] \
<daniels> madduck: a) is known
<madduck> ok
<daniels> for b), i assume nodeadkeys needs to be the variant, not the option
<madduck> exactly.
<daniels> ber
<madduck> dict ber?
<seb128> carlos: here ?
<trulux> pitti: ping
<pitti> trulux: pong
<carlos> seb128: yes
<pitti> trulux: btw, are you admin of the -hardened ML?
<seb128> carlos: rosetta question
<trulux> pitti: hey pitti, how are you doing?
<trulux> pitti: yeah
<pitti> trulux: fine, thanks
<pitti> trulux: I got a moderation request email, but I don't have a moderation password
<carlos> seb128: rosetta answer
<trulux> pitti: lemme take a look
<pitti> carlos: rosetta done?
<seb128> carlos: how have you planned to handle po files with ubuntu changes. Ie: gnome-panel.po ... if upstream want to use rosetta, they need to have 2 pot files ? One for the stock upstream and one for the package ?
<carlos> pitti: not yet
<pitti> carlos: just bitching :-)
<pitti> seb128: btw, the guy on the ML who complains about a slow gstreamer totem is right. it really sucks :-(
<carlos> seb128: yeah, that's the idea. It will be improved in the future but for now, it's going to be done that way
<carlos> pitti: I know ;-)
<seb128> carlos: merging the common parts ?
<carlos> seb128: yes, upstream and ubuntu translations will have a way to share the translations
<seb128> nice, thanks
<seb128> and when have you planned to push rosetta po files in the language packs ?
<seb128> because managing the translations with this bugzilla bug, is *urg*
<carlos> seb128: This week people should be able to start translating ubuntu with Rosetta
<seb128> \o/
<carlos> and next week I hope they will land automatically into language packs
<pitti> \o/ . o O { YAY }
<jbailey> Do we keep an archive snapshot of the array CDs at all so that the jigdo's can actually work?
<jbailey> I'm getting 404's (no surprising) on every package that's been updated since.
<seb128> carlos, pitti: any of you mind to comment on #7370  about the langue-packs ?
<Kamion> jbailey: no, I've been asking for it for ages
<seb128> there is some question about the updates, etc
<m0rphx> hi guys. I couldn't file a bug to python-nautilus, so I filed it under nautilus.
<seb128> RAAAHHHH
<jbailey> Kamion: 'kay thanks.
<seb128> m0rphx: this in an universe stuff
<seb128> and broken
<seb128> simply don't use it
<m0rphx> oh, ok
* seb128 grrrr
<dholbach> seb128: should it be on MorgueCandidates?
<m0rphx> it "works" after applying a simple patch
<seb128> dholbach: no
<seb128> it should be fixed
<dholbach> seb128: ok
<seb128> ajmitch has uploaded a broken version without testing it
<carlos> pitti: could you look into it?
<seb128> it crashes nautilus
<seb128> upstream have got 4-5 dups this WE
<seb128> and people start complaining here
<pitti> seb128, carlos: looked at #7370, what should I comment?
<m0rphx> seb128: I made a patch for that crash, works for me
<seb128> dholbach: do you know who is he ?
<pitti> seb128, carlos: nevermind, saw it
<seb128> pitti: the current comment, language packs updates for new version and outdated stuff
<dholbach> seb128: who?
<seb128> dholbach: <seb128> ajmitch has uploaded a broken version without testing it
<Kamion> wow, rsync really kills my laptop's I/O bandwidth when it gets going
<dholbach> seb128: oh yes... he's one of our MOTUs
<seb128> dholbach: ie, new python-nautilus rebuilt for python2.4 breaks nautilus and that's flooding upstream with crashes
<seb128> dholbach: I'm not happy with that
<seb128> dholbach: guys, install a package before putting it in the archive and break nautilus
<seb128> dholbach: don't get it for you, you are doing some great job :)
<pitti> seb128: done
<seb128> pitti: thanks
<dholbach> seb128: thanks a lot... :-)
<seb128> pitti: sorry for the comment conflict :)
<dholbach> seb128: i guess ajmitch will talk to you in some minutes, he was there ... 10 minutes ago
<seb128> dholbach: I've pinged him 2h30 ago, he has not replied :p
<dholbach> seb128: guess he was working
<seb128> np, don't worry
<crimsun> daniels: ping
<ajmitch> seb128: sorry, I didn't logout before testing nautilus with nautilus-python, so it didn't pickup the new lib
<seb128> ajmitch: np. that's no luck that it makes nautilus crashing for everybody that has it installed
<seb128> ajmitch: I'll fix it now
<ajmitch> ok, sorry about the hassle
<dholbach> seb128: woohoo:  	[gnome-db]  libgda/libgnomedb 1.3.1 released   ? can we now fix mergeant? :-p
<seb128> dholbach: I've looked on libgda/libgnomedb, that's a mess
<seb128> I think we will keep them in this way for hoary
<dholbach> alright
<crimsun> lamont: ping
<dholbach> hi jinty
<jinty> hoi dholbach
<dholbach> jinty: i was brooding over  apt-cache showsrc schoolbell
* jinty goes to brood quickley
<dholbach> jinty: what shall we do about  schoolbell-ssl  and  libschoolbell ?
<dholbach> jinty: at least schoolbell-ssl is not installable anymore
<jinty> no it is going to die.
<jinty> there is a new schoolbell 1.0 source package which only has schoolbell/libschoolbell
<dholbach> so putting  schoolbell-ssl  on  wiki/MorgueCandidates  is the right thing to do?
<jinty> it's already in unstable, and i've asked doko to bring it in to universe
<doko> jinty: eh, it should be ...
<jinty> won't schoolbell-ssl just dissappear automatically when the new schoolbell comes along?
<dholbach> jinty: it's because of 2 different source packages
<jinty> doko: is this the wrong place to check: ftp://ftp.ubuntulinux.org/ubuntu/pool/universe/s/schoolbell/
<jinty> thats the point, the new package is a school"bell" source
<jinty> so, from now on there will be 2 source packages again
<tseng> elmo: jdub mono-mint has been broken all along afaik, x86 and ppc dont use it, and its too slow to for anyone from other arches to have bothered
<doko> jinty: oops, sorry, I didn't ... wait a minute
<elmo> tseng: beagle b-d's on it tho?
<tseng> for !x86 !ppc
<tseng> or thats how it should be.
* tseng looks
<elmo> ah, ok
<elmo> does mono really not support amd64 yet?
<tseng> it does via mono-mint, sortof kindof, but its slow as crap
<tseng> and no one has bothered to fix whatever it in hoary
<tseng> mono 1.1 has native support.
<tseng> mono-mint [!i386 !powerpc]  .. that looks correct per debian policy
<elmo> yeah, I ran dpkg-buildcheckdeps in the amd64 chroot first
<elmo> and cut'n'paste the missing packages into the i386 chroot
<elmo> how come we don't have 1.1 yet, btw - just 'cos debian doesn't, or is it not released?
<tseng> because debian doesnt
<tseng> a) its a new build system, and b) a new packaging policy
<elmo> ok
<tseng> upstream was very unhappy w/ the old packaging
<tseng> (non)progress is tracked here: http://wiki.debian.net/?MonoDebianPlan
<tseng> there is some app breakage from 1.1 also
<tseng> tomboy doesnt compile, blam needs a patch, muine crashes on close
<tseng> fun :)
<dholbach> enrico: ping
<thom> (also, 1.1 is the unstable branch leading to 1.2, so maybe better waiting for that)
<tseng> according to upstream 1.1 is leaps and bounds better than 1.0
<tseng> but there are still regressions in external apps
<Kamion> upstreams always say that sort of thing :)
<thom> tseng: sure, i'm just nervous of getting bit by a last minute change that goes into 1.2 and we have to support both 1.1 and 1.2 cos we have a release with 1.1 in ;-)
<Kamion> "IT'S LOADS BETTER. (oh, some shit breaks.)"
<tseng> oh, im definately not planning on it for hoary
<fabbione> hey Kamion 
<Kamion> afternoon
<tseng> my plan is wait for debian to post a new policy and core packages, and go to fixing any incompatibilities in other apps
<fabbione> Kamion: is the debian-cd source updated on archive.u.c ?
<Kamion> where on archive.u.c?
<fabbione> Kamion: and is actually the one you are using.. right?
<fabbione> Kamion: rsync a.u.c:<somewhere>
<Kamion> please don't use archive.u.c/cdimage/ if that's what you mean, use cdimage.u.c
<daniels> crimsun: pong
<fabbione> there is only one entry with code/debian-cd.tar.bz2
<crimsun> daniels: hi.
<daniels> sup?
<Kamion> http://cdimage.ubuntu.com/code/debian-cd.tar.bz2 is updated every time a CD build happens
<fabbione> ah ok
<fabbione> thanks
<enrico> dholbach: hello there
<crimsun> daniels: I had a question regarding the "disappearance" of libXinerama_pic.a, but I think I've nailed the real problem (hotkeys ftbfs on ia64)
<fabbione> i am going to try to build sparc iso's sometime during this week
<daniels> crimsun: s/-lXinerama_pic/-lXinerama/, s/xlibs-static-{pic,dev}/libxinerama-dev/
<dholbach> enrico: you're not an "uploader" for ubuntu?
<enrico> dholbach: I should be
<dholbach> enrico: ah, just because of debtags and debtags-edit
<dholbach> enrico: they should be rebuilt against new libapt
<crimsun> daniels: right, the problem seems to be an outdated ./configure for hotkeys on ia64 that incorrectly detects the presence of libXinerama_pic.a
<enrico> dholbach: There's a new libdebtags in Debian: a very minor change (removed some debugging fprintfs).  Can't you re-pull that one?
<enrico> I feel sincerely weird in downloading libdebtags and debtags-edit from hoary and then reuploading them again
<daniels> crimsun: right, that'd be a Debian patch, so you'll need to remove that patch and re-run autoreconf -v --install
<enrico> And it's not really something that needs me to do it
<mkedwards> The actual root cause of the Xinerama_pic thing would be easier to determine given the config.log from the ia64 build.  It thought it saw XineramaQueryExtension in Xinerama_pic.
<daniels> mkedwards: er, libXinerama_pic doesn't actually exist
<daniels> mkedwards: do you mean in Xinerama.h?
<mkedwards> I know it doesn't exist; see http://people.ubuntu.com/~lamont/buildLogs/x/xosd/2.2.14-1/xosd_2.2.14-1_20041119-0352-ia64-successful
<dholbach> enrico: i thought it was common politeness to ask the maintainer before uploading (even in a case of a simple rebuild)
<daniels> mkedwards: right: Unpacking xlibs-static-pic (from .../xlibs-static-pic_4.3.0.dfsg.1-6ubuntu25_ia64.deb) ...
<enrico> dholbach: ah, ok, thanks.  But I don't maintain it for Ubuntu anyway.  Anyway, please go on
<mkedwards> It doesn't get any symbols out of it (verified with ldd), but it still puts -lXinerama_pic in xosd-config output.
<dholbach> enrico: we have the newest versions already :-)
<enrico> dholbach: is that automatic?
<daniels> mkedwards: err, it won't be there in ldd; libXinerama_pic is a static-only library, so it'll get linked in regardless
<dholbach> enrico: semi-automatic :-)
<enrico> cool!
<mkedwards> So dh_shlibs doesn't put a dependency on xlibs-static-pic into the libxosd output.
<daniels> mkedwards: what needs to be done is that s/Xinerama_pic/Xinerama/ needs to be beaten out of the package, and the Build-Deps updated
<enrico> (or, semi-cool :)
<daniels> mkedwards: it doesn't need one; it's a static library
<dholbach> haha
<mkedwards> sorry, typed that before you answered.
<mkedwards> OK, so all that needs to happen is that xosd-config needs to drop the -lXinerama_pic.
<crimsun> hmm, ok, so we'll need to touch xosd as well
<trulux> jezz
<trulux> Stefan Esser fscking with "my FUD on hardened-php"
<trulux> (the email regarding hardened-php posted to ubuntu-devel)
<trulux> what a jerk
<mkedwards> (hmm.  Suppose xlibs-static-pic is static?  /me kicks self)
<daniels> mkedwards: you need to change -lXinerama_pic to -lXinerama (which will be a Debian patch: just back it out and run autoreconf -v --install), and change the xlibs-static-pic build-dep to libxinerama-dev
<mkedwards> OK.  Then we get xosd-config and the linker agreeing on -lXinerama.
<mkedwards> crimsun: got that?
<crimsun> yep, thanks
<mkedwards> dholbach: that'll fix lineak too
<mkedwards> pretty much need to rebuild everything that b-d on libxosd-dev afterwards.
<dholbach> mkedwards: thank you very much for investigating... i was busy - will catch up on it
<mkedwards> dholbach: no worries.
<mkedwards> dholbach: small wild goose chase.  wild gosling, maybe.  ;)
<dholbach> mkedwards: good work nevertheless :-)
<mkedwards> thx
<dholbach> elmo: do you know what happened to  scribus  upload 3 hours ago?
<daniels> elmo: according to broonie (the debian zlib maintainer), zlib should be synced from debian
<pitti> jbailey: ping
<elmo> dholbach: who uploaded it?
<elmo> daniels: nothing to sync?
<daniels> elmo: hmm?
<jbailey> pitti: Here
<pitti> jbailey: I need another libc upload soon
<jbailey> pitti: 'kay.  Soon like today, or soon like maybe tomorrow?
<pitti> jbailey: we should coordinate to put out changes into one uploa
<pitti> d
<pitti> jbailey: tomorrow would be better 
<jbailey> pitti: For me too.
<pitti> jbailey: :-)
<elmo> daniels: version in debian == version in ubuntu
<daniels> elmo: oh.  my laptop must be out of date, then?
<dholbach> elmo: erm... i uploaded for herve
<daniels> elmo: actually, no.
<elmo> dholbach: it's in main
<daniels> elmo: http://archive.ubuntu.com/ubuntu/pool/main/z/zlib/
<jbailey> pitti: I have... 3 code patches and one packaging patch, and I'd like to beat the crap out of them.
<daniels> elmo: unless some cock uploaded 1.1.2-4ubuntu1 to debian ;)
<dholbach> elmo: *ARG*
<dholbach> elmo: i'll tell herve
<elmo> daniels: 1.1.2-4ubuntu1 is >> 1.1.2-4, I can't sync a _down_grade
<daniels> elmo: hrm, ok
<pitti> jbailey: okay, can we merge our stuff tomorrow? I only need to update one patch (ubuntu-altlocaledir.dpatch)
<elmo> (1.2.2, same diff)
<pitti> jbailey: so it might be the easiest thing if I just sent you the patch and the changelog entry
<jbailey> pitti: Yeah, sounds good.
<dholbach> elmo: thanks
<jbailey> pitti: And I'll aim for an end-of-my-day tomorrow upload.
<pitti> jbailey: okay, please prod me if you want to upload and I didn't mail you yet
<seb128> pitti: debian/patches/14_null_volume_crash.patch, is that something to send upstream or specific to hoary ?
<pitti> seb128: I asked the bug submitter to test it; if it works, I'll send it to the upstream bug
<seb128> k, thanks
<pitti> seb128: I can't test it, I can't reproduce
<ogra> seb128, my little evonotify just stopped working due to the timestap change in wnck/metacity. i dont think its worth to fix it but since i want a working mail notification i'd like to know if there is already something in plce that can handle the evo generated d-bus message (else i will have a look how to write such a thing)
<seb128> nop
<seb128> how does it break your stuff ?
<ogra> if i klick the tryicon evo should pop up...but it doesnt. and in .xsesion errors i see  Usage: Gnome2::Wnck::Window::unminimize(window, timestamp)
<dholbach> ogra: i synced a new libgnome2-wnck-perl today... does it work with that one?
<ogra> seb128, but i dont think its even worth the 10mins to fix it :)
<dholbach> or isnt evonotify perl-gtk2?
<ogra> dholbach, already in the arch ? 
<ogra> yup
<dholbach> was like 4 hours ago
<ogra> the it might be caused by it
<dholbach> libwnck4 -> libwnck16 transition
<ogra> dholbach, but i tink the d-bus way is the preferred one....so a little python script recieving the message and showing the tryicon would b cooler
<Kamion> daniels: looks like xserver-xorg doesn't honour preseeding of xserver-xorg/config/display/modes
<daniels> Kamion: no, it won't
<Kamion> daniels: can that be fixed? it breaks kickstart
<daniels> Kamion: uhm
<dholbach> ogra: i won't stop you :-P
<ogra> heh
<daniels> it's within the realm of probability, but I'm willing to bet it breaks lots of other stuff
<daniels> that part of the code is particularly fragile
<Kamion> I know, but I have to mark a big whack of kickstart as unsupported otherwise
<Kamion> like it won't always be able to do unattended installs, which kind of defeats the purpose :)
<Kamion> I only realised it was broken today, because up until now kickseed was preseeding the wrong question - but I fixed that and then ran into this
<daniels> Kamion: right
<daniels> Kamion: i'll look at it, but no promises
<Kamion> ok, please
<Kamion> thanks
<daniels> Kamion: patches welcome also, of course ;)
<Kamion> daniels: presumably the correct logic is "don't set /display/modes if it's seen and we aren't reconfiguring"
<ogra> seb128, i got a user here who deleted his /etc/gconf dir..... (crazy KDE users)
<Kamion> except I wonder what the live CD should do there
<daniels> Kamion: the live CD is a reconfiguration scenario
<ogra> seb128, any iway to get that back ?
<seb128> no
<Kamion> yeah, but the live CD is also a potential target for preseeding
<daniels> Kamion: it handles things differently based on two cases: a) upgrading, b) everything else
<daniels> Kamion: initial installs fall into 'everything else'
<Kamion> maybe not in hoary, but in the future
<ogra> seb128, yup, thats what i thought
<dholbach> ogra: apt-get install --reinstall <.........................................................................................>  :-(
<Kamion> apt-get install --reinstall doesn't do that
<daniels> Kamion: so we'd basically have to either get everything seeded from kickstart and special-case it into the 'upgrading' scenario (everything filled in), or yeah
<daniels> Kamion: actually, I have a passable idea of how to attack this
<ogra> dholbach, but what ?
<Kamion> you need to pass the --force-confmiss option to dpkg
<Kamion> daniels: by that point you can't tell kickstart did it - all you have is that the value is set and that the question is fset seen
<daniels> Kamion: huzzah!
<daniels> Kamion: the modes thing is a bit of a bugger, though, because you realistically can't just preseed modes
<Kamion> why not?
<dholbach> ogra: no "but"
<daniels> Kamion: config/monitor/use_sync_ranges is an important thing to know
<ogra> dholbach, i thought probably removing libgtk and then reinstalling ubuntu-desktop, but i have not the slightest idea if it works or what else breakss then
<Kamion> kickstart can provide h/v sync
<dholbach> ogra: he can't break it any further
<Kamion> but kickstart is very much a "you asked for it, you got it" kind of thing anyway
<daniels> Kamion: if it can provide use_sync_ranges, that'll do
<daniels> Kamion: we can calculate our own sync ranges
<ogra> dholbach, i know :)
<ogra> dholbach, but what meatn "what package" a simple apt-get install --reinstall cant solve that
<Kamion> daniels: it will already provide sync ranges if you use xconfig --hsync=<blah> --vsync=<blah>
<daniels> Kamion: even better
<Kamion> daniels: so what should use_sync_ranges be set to and when?
<daniels> Kamion: let me think about it and hack a bit, but you totally get the wrath of mdz if it's all fucked ;)
<Kamion> daniels: mdz gets to resolve competing breakage of primary hoary goals :P
<Kamion> daniels: I'll upload kickseed 0.15 so that you can test it once it gets into d-i initrds and stuff
<Kamion> daniels: boot with ks=http://riva.ucam.org/~cjwatson/tmp/daniels.ks
<Kamion> daniels: ... on a scratch machine though, since that'll wipe the disk
<daniels> Kamion: awesome, ta
<Mitario> hi everyone
<daniels> Kamion: oh, er
<daniels> Kamion: interesting concept, this 'scratch machine'
* daniels looks around for an empty disk.
<Kamion> daniels: delete all the partitioning stuff from that file, then
<daniels> oh, ugh
<Kamion> daniels: probably want to grab it to somewhere HTTP-accessible and customise it; I've deleted the partitioning/bootloader bits
<Kamion> daniels: it should let you do partitioning manually now
<daniels> Kamion: could you please change 'XWindows' to 'X.Org', 'X', or 'X Window System'?
<daniels> Kamion: X Windows -> world of trademark pain
<Kamion> that's really upstream RH stuff, but done
<daniels> thanks
<Kamion> (though not in that file, can't be bothered :))
<daniels> heh
<daniels> i can vim that myself
<ogra> hi \sh
<\sh> hoi ogra
<Treenaks> c:\bin\sh?
<ogra> heh
<\sh> joke is old ;) 
<zul> hey
<dholbach> hey zul
<Mirv> anyone know which nick Michiel Sikkes uses?
<dholbach> mitario
<thom> Mirv: mitario
<Mirv> ok, thanks :)
* pitti shudders at the version number 1.0lang20041216+ubuntu1-0ubuntu1
<daniels> pitti: ... dude
<daniels> thom: i hate to say it, but you've just been outdone :(
<pitti> daniels: I have to add the Xhosa XPI to moz-ffox-locale-all
<pitti> daniels: and I don't want to mess with uuencode crap, since the package build is largely automatic
* thom applauds pitti
<pitti> ?
<pitti> longest upstream version number ever?
<daniels> s/upstream //
<daniels> even worse than 0.9.3+1.0rc1+reverted-to-0.9.3-0ubuntu1
<daniels> or whatever it was
<pitti> odd, I had expected that the new m-ffox-locale-all package gets stuck in NEW...
<trulux> pitti: got the moderator access?
<pitti> trulux: didn't try yet
<trulux> pitti: ok, lemme know if there's any problem
<trulux> pitti: btw, do you have time for toolchain work these days?
<pitti> not really
<pitti> the time before RC and final release we have to concentrate on bug squashing
<zul> bbl
<dholbach> elmo: could you please sync  xli   and   openscenegraph   from sid?
<pitti> mvo: here?
<dholbach> see you later
<trulux> pitti: ok, just for gcc-hardened/-ssp finishing
<dholbach> bye
<seb128> a rsync on the dvd image is supposed to work ?
<schweeb> seb128: that's how everyone I know updates theirs
<seb128> rsync: connection unexpectedly closed (0 bytes received so far) [receiver] 
<seb128> rsync error: error in rsync protocol data stream (code 12) at io.c(359)
<seb128> 
<seb128> I keep getting this
<schweeb> :-/
<Treenaks> seb128: how are you rsyncing?
<seb128> rsync -azvP rsync://cdimage.ubuntu.com/cdimage/dvd/20050315/hoary-dvd-i386.iso hoary-dvd-i386.iso
<mvo> pitti: pong
<thom> seb128: prolly too many connections
<Kamion> cdimage is overloaded :(
<pitti> mvo: is there any reason why php4 4:4.3.8-3ubuntu7.5 doesn't appear in your changelogs tree?
<jbailey> Kamion: A download that I started earlier this morning (11h00 GMT or so) claimed 10 hours to complete
<lamont> elmo: http://people.ubuntu.com/~lamont/buildLogs/Test/... is a clone of it's parent, but for the test distro
<lamont> crimsun: sup?
<seb128> thom: is there any other location to get that ? :)
<mvo> pitti: when did you uploaded it?
<pitti> mvo: last friday
* seb128 wants a DVD image
<Treenaks> seb128: http://images.google.com/images?q=dvd&hl=en&btnG=Google+Search </annoying mode>
<mvo> pitti: hrm, let me check
* lamont plaintively wishes we'd started with just the universe packages _currently_ in hoaary
<jbailey> pitti: *pounce*
<pitti> jbailey: ?
<jbailey> pitti: 7987 just came in, it looks like it might be caused by the stat reduction you did.  Would you mind looking at it?
<pitti> jbailey: handled, dup of #7835
<jbailey> pitti: Thanks.
* fabbione mumbles
<fabbione> anybody with UML experience around?
<pitti> Unified Modelling Language? or User Mode Linux? :-)
<fabbione> the latter
<carlos> fabbione: I'm using it, but moving to Xen now...
* elmo randomly fanboys xen to fabbione just to be unhelpful and annoying
<fabbione> heh
<fabbione> carlos: i get errors trying to rootstrap a fs
<fabbione> elmo: i need to look into it too, but i need something that is more packaged that xen :-)
<fabbione> carlos: basically rootstrap barfs becuase 'linux' cant open the init script
<carlos> fabbione: there are Debian packages for xen in experimental
<fabbione> carlos: do you recall this problem?
<fabbione> Kernel panic: No init found.  Try passing init= option to kernel.
<fabbione> but there is an init defined there
<carlos> fabbione: hmm, don't remember that problem
<carlos> fabbione: are you using an initrd kernel?
<fabbione> carlos: do you remember how to rootstrap a fs? perhpas it's just me doing something really stupid
<fabbione> i am using the default...
<carlos> fabbione: from debian??
<fabbione> plain deb installed
<fabbione> ubuntu
<fabbione> modified /etc/rootstrap/rootstrap.conf to point to my mirror and bring up the network
<fabbione> that's all the customization i did
<schweeb> fabbione: I'm working on packaging xen actually
<carlos> fabbione: sorry, I did it about 6 months ago, and since then, I decided to use debottstrap and do it by hand
<schweeb> but I use UML as well
<carlos> fabbione: I think mdz wrote that script (not completely sure)
<fabbione> carlos: hmmm ok.. even doing it manually is fine for me.. mdz wrote rootstrap (the one i am trying to use ;))
<fabbione> schweeb 
<fabbione> ok.. do you know how to solve that problem?
<schweeb> I don't, however, use rootstrap
<schweeb> :-/
<carlos> schweeb: I'm using xen on Ubuntu and have the Debian package modified to work with Ubuntu, the only change I don't have is the kernel patch
<fabbione> ok.. how do i create the image manually..
<fabbione> i don't care to use rootstrap..
<carlos> fabbione: I was talking about rootstrap, not debootstrap
<fabbione> something that works is FINE.
<carlos> fabbione: create a file for your filesystem
<schweeb> fabbione: you know how to make a sparse file?
<carlos> mount it with the loop option
<schweeb> make a sparse file how big you want the fs to be, mkfs it, mount loop, then use debootstrap on it
<carlos> and do a normal debootstrap installation inside that mount point
<fabbione> carlos: ok.. gotcha.. install the um kernel...
<fabbione> carlos: and so on, right?
<carlos> but really, you should look into xen. my uml machine gets blocked every month or so and I need to ask my ISP to reboot it
<schweeb> carlos: hah, mine's been up for like 9 months straight
<carlos> fabbione: weel, the kernel is in the host machine, and then, you need to copy the modules into the  /lib/modules of the loop file
<dredg> mine's been up for ~100 days.. but then i run the servers that they live on, so my UML gets nice treatment :)
<fabbione> carlos: ok.. works for me... thanks
* fabbione just needs some kind of [UML|xen]  to test kernels without having to reboot the world
<schweeb> carlos: I looked at doogie's packages, then decided to scrap and start over... his are overly complicated... patches in a couple places where no patches need to be added, etc...
<schweeb> manually mv'ing files
<carlos> fabbione: http://www-128.ibm.com/developerworks/linux/library/l-xen/
<schweeb> etc...
<schweeb> felt like too much of a hack job
<carlos> schweeb: are you talking about 2.x packages or 1.x?
<schweeb> the 2.x
<schweeb> plus, I used cdbs
<schweeb> but, I haven't figured the best way to do the kernel patch yet
<carlos> schweeb: hmmm, do you have them in any apt friendly place?
<schweeb> nope, they're still in my private stash... I'll release something on my website in the next week or 2
<carlos> I don't care about the kernel, I'm creating them without using .deb packages
<carlos> schweeb: ok
<schweeb> carlos: if you feel like sharing your experiences, I made a wiki page for Xen too
<carlos> schweeb: URL?
* fabbione sighs
<fabbione> this is all so damn complicated....
<schweeb> carlos: http://www.ubuntulinux.org/wiki/XenVirtualMachine
<fabbione> i want my e10k back!
<carlos> schweeb: ok, thanks
<carlos> schweeb: I had no problems booting an Ubuntu rootfs with Xen
<schweeb> did you enable DEVFS, or use an initrd?
<carlos> schweeb: no I was not able to use it with initrd
<carlos> but didn't try it too hard
<schweeb> my machine was also a bit odd... it's on an Asus A7V... and my boot drive was on my secondary Promise IDE controller
<carlos> schweeb: I'm using my main server with Xen atm, with SATA hard drives
<schweeb> I couldn't get it to mount my root, my guess was it was missing a dev entry
<carlos> and it's on production atm
<schweeb> carlos: I also haven't really tried even booting it since I started packaging the stuff... haven't had time really
<Kamion> hooray, nis kickstart support
<Kamion> well, more or less
<Kamion> not sure I've got it quite right, it's ages since I did any of that nsswitch.conf mangling
<carlos> schweeb: count with me as betatester
<Mithrandir> fabbione: did I forget my fleece neck in your car last night?
<fabbione> Mithrandir: i need to check... let me ask Ulla.. shw just come back
<schweeb> carlos: alright, maybe I'll work on them tonight... they don't come close to passing lintian atm
<Mithrandir> fabbione: sure, no worries
<fabbione> nope.. it's not in the car
<carlos> ok
<mdz> doko: here now
<mdz> morning
<thom> hey matt
<pitti> Hi mdz
<pitti> mdz: sorry for breaking libc :-(
<doko> hi, just wanted to get the python 2.4.1 rc2 into hoary. the final release will be next week after PyCon
<mjg59> If I want to produce an ISO with some extra packages from universe, what's the best way to do it?
<mdz> pitti: you broke libc?
<fabbione> hey mdz
<simira> hi fabbione 
<pitti> mdz: #7835, the stat() caching stuff breaks for applications that have multiple domains 
<mdz> mjg59: extra packages just on the CD, or installed per default?
<mjg59> mdz: Installed per default
<pitti> mdz: jbailey has to upload libc tomorrow anyway
<pitti> mdz: if I don't find a good solution by tomorrow, I will revert the patch to the old one
<mdz> mjg59: that involves hacking Task: in Packages; not as convenient as it might be
<mdz> I think Kamion has notes on the process
<mjg59> mdz: Ah, right
<mdz> pitti: one day I will learn to trust my instincts ;-)
<mjg59> Also, what do people feel about putting small hardware-specific packages in universe?
<seb128> hi mdz 
<pitti> mdz: one day I will learn not to touch basic packages close to a release 
<mjg59> Something that would pull in packages used for that hardware and set up default configuration
<mdz> metapackages?
<fabbione> hi simira 
<mvo> morning mdz 
<mjg59> mdz: Possibly with a small amount of scriptage
<mdz> mjg59: can you give an example?
<mjg59> mdz: Say "thinkpad-x40" which would depend on tpb and provide a video switch script for acpi
<Kamion> morning mdz
<mdz> mjg59: I have this idea that is on the list to discuss in sydney, to tie hardware detection to package management
<mjg59> mdz: Ok, cool
<mdz> mjg59: so that if, e.g., you plug in a particular USB device which requires additional software (say, hpoj), update-notifier would tell you about it
<mdz> this sounds like it might tie nicely into that
<Kamion> ogra: should hwdb-client get a .desktop file?
<mdz> possibly
<zyga> mdz: That's cool as long as it's updated
<ogra> Kamion, mdz, dont you think the button in h-d-m is enough ? 
<zyga> mdz: It's like shared folders telling you to install sharing stuff ;] 
<mdz> ogra: not for KDE ;-)
<zyga> (too bad there is no install-them-I'm-newbie button)
<ogra> hmm...didnt think of KDE
<mdz> ogra: Kubuntu doesn't currently use hal-device-manager
<ogra> yup, i saw it ...
<mdz> they do want hwdb-client, but I don't think we can do it for hoary
<mdz> they prefer not to have all the GNOME libs in the default install
<mdz> for breezy we can perhaps split the package
<Kamion> ogra: oh, I didn't know it was there
<ogra> hmm, having hwdb-client itself involves a lot of gnome libs (canvas, pygtk etc...)
<schweeb> heh, hwdb-client doesn't like doing the video test over remote X it seems ;)
<Kamion> ogra: might be a good idea to write "Ubuntu" rather than "ubuntu" everywhere
<ogra> schweeb, could you file a bug ? i'll see if its solvable
<schweeb> sure
<ogra> Kamion, lol ( have changed it three times now, from small to big and back)
<ogra> Kamion, see #6934
<ogra> Kamion, mdz, so whats the corporate identity, the logo shows it all in small letters, elsewhere in the system its written non capitalized, a final decision would be appreciated :)
<mdz> ogra: the name within a body of text should be capitalized
<ogra> mdz, ok :)
<mdz> doko: are you here?
<doko> yes
<pitti> sjoerd: ping
<seb128> <CIA-1> mvogt * update-manager/src/aptsources.py.in: 
<seb128> <CIA-1> * src/aptsources.py.in:
<seb128> <CIA-1> - made "Binary" and "Source" translatable
<seb128> mvo: oh, GNOME CVS, nice :)
<mvo> seb128: jesus, you have your eyes _everywhere_ :)
<mdz> doko: if packaging a zope thing from scratch, should zope-debhelper be used?
<seb128> mvo: :p
<doko> mdz: yes, it should.
<sjoerd> pitti: pong
<pitti> sjoerd: have you ever heard of cameras not recognized by hal-hotplug-map?
<sjoerd> yeah
<pitti> sjoerd: I just found a bug that's so stupid that I wonder why we didn't recognize it more early
<sjoerd> their id's aren't in the hotplug map thingy..
<sjoerd> oh, nice :)
<pitti> hal_hotplug_map: Checking usermaps for USB device vid=0x04a9 pid=0x30ba
<pitti> -> hex numbers
<pitti> sjoerd: however, h-h-m uses atoi() to convert these vendor/product id strings to integers
<pitti> sjoerd: which results in 0 
<zyga> seb128: actually I've sent the same patch as you did ;] 
<pitti> sjoerd: now I changed it to strtol(string,NULL,16) and it works perfectly
<seb128> zyga: about what ?
<zyga> update-manager Binary / Source 
<seb128> oh, I've just noticed the CVS commit
<pitti> sjoerd: or are the numbers converted to decimal in the environment vars?
<seb128> I've not sent any patch
<doko> mdz: if people have questions, send them to me
<sjoerd> pitti: hal passes them in env vars iirc
<pitti> sjoerd: hmm, probably it converts it to integer then
<pitti> sjoerd: yeah, otherwise almost no camera would work. Okay, please forget the noise, I debug further
<sjoerd> pitti: in the cases were i had people whose camera's weren't detected it was just a question of adding them..
<sjoerd> pitti: np :)
<pitti> sjoerd: in my case the camera is present, but it isn't picked up
<pitti> sjoerd: https://bugzilla.ubuntu.com/show_bug.cgi?id=7387
<Kamion> ogra: please file bugs on any other places in the system (other than the logo, or places like filenames) that use "ubuntu" in lower case
<schweeb> ogra: you want it assigned directly to you?
<ogra> yup
<ogra> Kamion, ok
<sjoerd> pitti: i'll have a look later on if you haven't fixed it yet by then :p
<pitti> sjoerd: right now I do an extra-verbose hal-hotplug-map and ask for executing it
<sjoerd> k
<mdz> jbailey: 5204 looks like ECLOSEDWRONGBUG, confirm?
<schweeb> ogra: okay, submitted
<ogra> schweeb, thanks :)
<jbailey> mdz: It's two bugs in one, and we dont' have a clone feature.  The hdparm part is finished, hdparm now sets the drives when udev notices them (I uploaded that this morning), and hotplug needing to start earlier is nothoary (per comment 3 and our conversations), so I've marked it as remind for post hoary to make sure that hotplug in initramfs in fact does solve this bug.
<dholbach> elmo: was there a problem regarding the syncs of  xli  and  openscenegraph  from sid?
<mdz> jbailey: ok, let's keep it open, though, because we get a steady stream of duplicates about it
<mdz> milestone is set to 5.10
<jbailey> 'kay.  Should I use milestones then?
<mdz> in general, yes. if the bug is not fixed, and we do intend to address it in the future, it should stay open
<jbailey> 'kay.  I'll tweak my default bugzilla view to only show 5.04 targets, then.
<jbailey> I'd been using 'remind' and 'later' for those.
<mdz> 5.04 or "---", of course
<jbailey> Right. =)
<mdz> Kamion: have you had a chance to test the DVD dependency fixes?
<dholbach> lamont: elmo told me there was some universe-rebuild-action going on and you probably new, where i could find the logs... can you give me a clue?
<lamont> http://people.ubuntu.com/~lamont/buildLogs/Test/byDate
<dholbach> ahhhhh, ok... thanks lamont 
<lamont> np
<mdz> thom: ping, re: #4679, #7711, general firefox 1.0.1 readiness
<Kamion> mdz: not yet
<mdz> Kamion: is there a new image available which contains the changes?
<Kamion> mdz: they're pretty much the same as were done to a few packages post-sarge to avoid stuff being installed from the network
<mdz> if the kubuntu bandwidth curtain has been lifted, I'll pull one down
<Kamion> mdz: Saturday's should
<mdz> Kamion: isn't one built mid-week now?
<Kamion> mdz: yes
<Kamion> 17 12 * * 2,6   /srv/cdimage.no-name-yet.com/bin/cron.dvd
<Kamion> => Tuesday and Saturday
<mdz> but tuesday's won't have the fixes?
<mdz> I should add the DVD to awty
<thom> mdz: 4679 is fixed in hoary, 7711 is top on my list for the rest of the week; otherwise i think we're pretty good for hoary
<seb128> Kamion: do you know why the "Set up users and passwords" screen is not in http://people.ubuntu.com/~cjwatson/installer-po/ file ?
<mdz> thom: last word in 7711 is that it seems like a gtk problem; should seb128 be aware of it?
<Kamion> seb128: hmm, probably 'cos base-config isn't part of that file, it should be
<thom> mdz: he's on the cc list already, yes
<mdz> ah, ok
<seb128> Kamion: can you fix it ? I would like to have a full french translation for the basic installation :)
<mdz> amu: what is the plan for #7298 (kmail segfault)?
<seb128> mdz: seems to be a fileselector crash yep
<Kamion> seb128: yes, working on it since I said "it should be" ;)
<seb128> thanks
<seb128> please let me know when you update it
<Kamion> mdz: last Tuesday's won't, no, seeing as I did the work on Friday
<mdz> Kamion: oh, you meant this past saturday, not this coming saturday
<Kamion> mdz: yes
<Kamion> sorry, unclear
<lamont> dholbach: I assume that I'm only going to actually look at the ones that are in the archive, but fail on rebuild.  If you see some that aren't in the archive, but now succeed, please feel free to holler.
<mdz> ETA 11 hours
<Kamion> mdz: starting from install+live?
<mdz> Kamion: starting from scratch
<mdz> I didn't even attempt rsync
<mdz> I'll try it
<mvo> same here, ETA: 9h 
<mdz> rsync: read error: Connection reset by peer (104)
<mdz> oh, that's due to my nightly rsync from like 3 days ago still running
<elmo> use a bleeding mirror
<mdz> who mirrors the dvds?
<elmo> us.archive.u.c
<mdz> oh, nice
<mdz> rsync, even
<elmo> via syncproxy too, so he always mirrors. something insane like every 3 hours too, I think
<ogra> elmo, whats the state of my ubuntu.com mailadress, i'd like to use something nicer then hostmaster@grawert.net in hwdb-client to not confuse the user
<ogra> elmo, (sending the data by mail is the fallback actio of hwdb-client)
<ogra> action even
<mdz> elmo: not their cdimage mirror, apparently
<mdz> lrwxrwxrwx           8 2005/03/15 06:37:38 current -> 20050315
<mdz> i.e., useless to me
<mdz> it looks like their last update was 20050318
<elmo> hmm, okay, I guess he updates cdimage less ofte
<mdz> so back to why cdimage.u.c is resetting my connection
<jani> is mail-transport-agent an obsolete metapackage?
<jani> I see darcs depends on it but nobody provides it
<elmo> jani: err?
<elmo> postfix, exim4 et al. all provide it
<mdz> jani: it's not obsolete, and several packages provide it
<mdz> apt-cache showpkg mail-transport-agent
<lamont> dholbach: alogg, clanlib, dia-newcanvas, gmime2, jakarta-log4j1.2 all seem to love you.
<jani> hmm why then darcs removes postifx and installx exim ?
<seb128> mdz: I get this on cdimage while trying to rsync a dvd image:
<seb128> rsync: read error: Connection reset by peer (104)
<seb128> rsync error: error in rsync protocol data stream (code 12) at io.c(515)
<mdz> seb128: yes, the same
<lamont> dholbach: where would you like your failures sent as I find them?
<jani> elmo, apt-get build-dep darcs wants to remove postfix
<jani> does it not take that metapackage itno account?
<lamont> jani: I bet build-dep takes the real package over the virtual package
<lamont> and exim conflicts: postfix
<schweeb> exim | mail-transport-agent <-- build-dep
<elmo> err, does apt-get really do that?
<jani> lamont, so build-dep does not look if I already have postfix then?
<elmo> that'd be horribly horribly broken 
<lamont> jani: apt-cache show postfix 
<lamont> Provides: mail-transport-agent
<herzi> what do i need to do to make synaptic show the progress dialog instead of vte when updating packages?
<mvo> herzi: uncheck "Settings/Preferences/Show changes in terminal window"
<lamont> elmo: my vote is for horribly-broken
<schweeb> lamont: mine does it too, the build dep is exim | mail-transport-agent... perhaps it'd work if the order was changed
<lamont> schweeb: no.
<lamont> s/exim/postfix/
<schweeb> or that
<lamont> policy says Depend/Build-Dep on real | virtual
<lamont> plan for main is to s/exim*/postfix/ for such *Depends
<lamont> in breezy
<schweeb> gotcha
<lamont> unless mdz tells me I may today...
<lamont> hrm.. I think part of the reason I was stalling was hoping for breezy to be lunchpad-happy.. easier life then
<schweeb> is the problem that apt-get build-dep is stupid and only goes for the real package?
<schweeb> (even though the virtual pkg is installed)
<herzi> mvo: thanks
<Kamion> seb128: installer-po updated
<seb128> Kamion: thanks
<mdz> lamont: test-build of main is complete and all bugs are filed, right?
<mdz> mvo: ping?
<mvo> mdz: pong
<mdz> mvo: please fix #7399 at your earliest opportunity
<lamont> mdz: yes
<mdz> mvo: it should be very simple and safe, and adds missing hardware support for a number of cards
<lamont> there are about 3 ppc failures that are dups of the others that are not reflected in wb, will do that momentarily
<mvo> mdz: will do, sorry for the delay
<mdz> lamont: the failure of workrave is expected; elmo will need to migrate a few packages to main and retry it
<lamont> mdz: cool
<mdz> lamont: (the workrave just uploaded)
<ogra> has scribus always been in main ?
<ogra> it somehow found its way to the MOTU python transition page....
<mdz> ogra: it came into main with Kubuntu
<ogra> ahh, that explains it...
<zul> re
<dholbach> *wave*
<Kamion> argh, mail is just coming in faster and faster
<mdz> yep
<Kamion> oh ye screaming gods
<Kamion> #7961 is in fact a really nasty debconf/cdebconf passthrough interaction
<mdz> "Today I installed Kubuntu (the full monty)"
<mdz> what a great subtitle for a release
<mdz> Ubuntu 5.04: the full monty!
<mdz> jbailey: re: #1440, which CD image do you need?  us.archive.ubuntu.com has images which are only a few days old, and should be much faster
<Kamion> mdz: whenever you run debconf in a chroot, you need to first do something like this:
<Kamion> db_get debconf/priority
<Kamion> TARGETPRIO="$RET"
<Kamion> mdz: and then add DEBIAN_PRIORITY="$TARGETPRIO" to the 'env' around the call to debconf
<mdz> ugh
<mdz> I shouldn't need to worry about that when faking debconf-copydb, though, right?
<Kamion> I'll add something in di-utils to wrap all this, post-hoary
<doko> Mithrandir: ping
<Kamion> mdz: no, not in that case - only stuff that uses INPUT or GO
<mdz> most of casper's stuff uses casper-reconfigure, which doesn't chroot
<mdz> does this apply there, or no?
<Kamion> you still need to figure out the correct priority
<jon1012> hi everybody ^^
<Kamion> when using debconf as opposed to cdebconf
<Kamion> the passthrough frontend doesn't get it from cdebconf automatically
<Kamion> hm, maybe it should; but that's a hairier change
<Kamion> I'm less comfortable with doing that than I am with just hacking the four or five things that use debconf that way, right nw
<Kamion> now
<Kamion> for extra bonus points, debconf uses DEBIAN_PRIORITY while cdebconf uses DEBCONF_PRIORITY, yum
<Kamion> mdz: if you want to put this TARGETPRIO thing on your list of "awful hacks that should go away" for UDU, feel free
<mdz> Kamion: will do
<crimsun> lamont: sorry, was in class.  I had what I thought was an ia64-specific question, but it has been resolved.  Thanks anyhow!
<mdz> mvo: I think we definitely need a minimum age in the apt cache cleanup code
<mdz> mvo: otherwise there will always be a race (e.g., release upgrades, which will always put the cache over the limit)
<mvo> mdz: do you mean only a minimum age as default (not a minimalAge and a minimalSize)? 
<seb128> rahhh
<mdz> mvo: currently you have maximum size and maximum age, but we need minimum age as well
<srbaker> seb128, someone was looking for you saturday.  asked if you irc on the weekends
<mdz> mvo: so that we will not remove things which are over maxsize, until they have aged
<seb128> locales refuse to generate a locale if you don't have the language-pack for it ?
<maswan> Ok, I'm heading off to sleep. Please include my nick in reports about releases.u.c doing something weird, so I'll see them.
<seb128> srbaker: depending, I tend to not irc now the WE because as soon as I start it I've 10 people pinging me for something
<mdz> seb128: no?
<seb128> mdz: I've removed language-pack-fr and language-pack-fr-base because they are outdated and I want to try to new translations
<Kamion> maswan: hey, cool, didn't realise releases.u.c had been moved
<seb128> now I get
<seb128> perl: warning: Please check that your locale settings:
<seb128>         LANGUAGE = (unset),
<seb128>         LC_ALL = (unset),
<seb128>         LANG = "fr_FR.UTF-8"
<ogra> lamont, any idea why workrave doesnt find libgnomeuimm-2.6-dev in the chroot ?
<mdz> seb128: the language packs remove the locales when they are removed
<mdz> seb128: but you can put them back
<seb128> and dpkg-reconfigure refuse to generate fr_FR.UTF-8 even with the locale selected as default
<mdz> what happens when you try?
<seb128>   en_US.UTF-8... done
<seb128>   fr_FR.ISO-8859-15@euro... done
<seb128>   nl_NL.ISO-8859-1... done
<seb128> 
<seb128> it skips it
<mvo> mdz: right. I'll add this. do you think 2 days is a reasonable default?
<mdz> how strange
<mdz> seb128: I guess file a bug for pitti
<mdz> mvo: yes
<herve> seb128, locale removed from locale.gen too?
<maswan> Kamion: temporary, to get the load down on mirnyy
<mdz> mvo: I am starting to get very concerned about the complexity, though
<maswan> Kamion: or at least try. we'll see how it does overnight, hopefully it will be mostly working as usual.
<seb128> herve: sure, the locales generated are the one listed here
<Kamion> maswan: *nod*
<mkedwards> crimsun: did un-hacking xosd work?
<seb128> mdz: http://rafb.net/paste/results/yosLmM52.html
<mvo> mdz: yes, adding complexity is not good so close to the release. I'll check it and send a debdiff and try to be as carefull as possible
<mdz> mvo: perhaps do it as a single for loop, using stat(1) to get the values and compare
<mdz> seb128: and no fr_FR.UTF-8 in /etc/locale.gen?
<seb128> mdz: no
<seb128> and it's selected in the dpkg-reconfigure locales list
<seb128> and even picked as the default
<seb128> I open a bug for pitti
<mvo> mdz: thanks for this idea
<ogra> mkedwards, he made it ready, i havent come around to upload it yet
<ogra> wb dholbach 
<dholbach> ok, now i'm really back :-)
<ogra> dholbach, workrave failed with a strange error...(Couldn't find package libgnomeuimm-2.6-dev)
* mvo -> dinner
<seb128> #8000 
<seb128> ah ah
<dholbach> bye mvo 
<seb128> Is there a prize for the bug #8000 ? :)
<lamont> ogra: no clue
<lamont> want me to look?
<dholbach> ogra: i know, it's because of a yet-to-happen change of packages going universe->main and main->universe
<ogra> lamont, ^^^
<ogra> lamont, thanks
<lamont> ogra: yeah, taht'd do it
<mkedwards> ogra: packages that b-d on libxosd-dev will need to be rebuilt after the xosd fix is in.
<ogra> mkedwards, ok
<dholbach> mkedwards: http://www.ubuntulinux.org/wiki/UniverseXosdRebuildTODO :-)
<ogra> :)
<ogra> mkedwards, dholbach is to fast ;)
<Kamion> hmm, I think I should start adding the 'installer' keyword to installer bugs
<mkedwards> Oh nice.  vlc will work now, maybe?
<ogra> mkedwards, not yet...
<Kamion> that would make it easier to give people a Bugzilla query to start from if they want to help with installer bugs
* ogra hands a medal with a big 8000 to seb128
* ogra hands a medal with a big 8000 to seb128
<Kamion> mdz: do you have access to add Bugzilla keywords?
<thom> Kamion: i can
<thom> d'you just want an "installer" keyword?
<mxpxpod> seb128: could you recompile libmpeg2 on ppc with gcc3.4 so dvd's with gstreamer will work?
<Kamion> thom: yes, description something like "Problem is relevant to the installer, and should be dealt with by the installer team"
<Kamion> I have a big "change multiple bugs at once" queued up :)
<thom> hrm, actually i can't. sorry; thought i had admin rights
<thom> Kamion: sorry dude
<Kamion> ok
<mxpxpod> seb128: rather, mpeg2dec
<thom> (i have no wish to do this via mysql direct, for obvious reasons) ;-)
<mdz> Kamion: yes
<Kamion> mdz: see above :)
<mdz> Kamion: already done
<Kamion> cheers dude
<mdz> thom: do you  know how the "Live CD" entry on enter_bug.cgi works?
<mdz> thom: we need to add one just like it for kubuntu
<haggai> +1 for that please
<mdz> I've added a kubuntu keyword for it
<schweeb> who's in charge of the openoffice packages?
<haggai> mdz: btw forgot to tell you, klaus knopper (of knoppix) was asking me how you did the livecd based on the deb installer
<haggai> at cebit last week
<mdz> haggai: did you point him to the casper package?
<haggai> mdz: no
<mdz> there's also an arch archive for it now
<elmo> haggai: good work; we don't want our trade secrets getting out
<haggai> hehe
<mdz> Kamion: that also means that if you need to change casper again in the future, you can make my life easier by putting your changes in a branch
<mdz> Kamion: http://people.ubuntu.com/~mdz/archives/matt.zimmerman@canonical.com--2004/
<mdz> seb128: my panel did *not* crash last night
<Kamion> mdz: ta, will do
<Kamion> unable to access URL: /~mdz/archives/matt.zimmerman@canonical.com--2004/.listing
<mdz> seb128: it had been crashing overnight recently
<Kamion> webdav error: 404 Not Found
<Kamion> mdz: care to make-archive -l that mirror?
<mdz> wha?
<Kamion> you can't access HTTP mirrors with baz unless you created the mirror with make-archive -l/--listing
<Kamion> (likewise with tla)
<mdz> odd, the person who was nagging me to publish it didn't complain
<mdz> do I have to recreate it from scratch?
<Kamion> AFAIK yeah
<mdz> sweet
<Kamion> but presumably it's a mirror, not the master archive?
<mdz> yes
<mdz> I might as well take advantage of this opportunity to convert it to signed
<mdz> huh
<mdz> the gnuarch wiki says there is a change-archive to make this not suck so much
<mdz> but it doesn't seem to be in baz?
<lamont> mdz: all you have to do is mirror it to a new archive (and type your passphrase a few million times), nuke the old archive, rename the new one in place, and remove the meta file that says it's a mirror.
<lamont> but don't tell lifeless I told you how... :-)
<mdz> lamont: I know
<mdz> those are the instructions which _used_ to be in the wiki
<mdz> and now it tells you to use this unreleased feature instead
<lamont> yes, because none of us would be running what's in hoary any more... :-(
* lamont remembers to be good and shuts up
<mdz> I forget the trick to carrying over the signature stuff
<mdz> without signing the entire mirror separately
<mdz> or doee that work properly by default now?
<Kamion> mdz: one sec
<mdz> all of the useful information has been purged from the gnuarch wiki in favour of this unreleased crack
<lamont> signed archives mirror just fine
<mdz> lamont: with or without make-archive --signed?
<Kamion> mdz: echo 'matt.zimmerman@canonical.com--2004' > ~/.arch-params/signing/matt.zimmerman@canonical.com--2004-MIRROR
<Kamion> you need make-archive --signed
<mdz> right, and that extra magic you gave me in order to prevent it from trying to re-sign the mirror
<Kamion> but that rune (or similar, depending on what the mirror's name is) will copy the signatures rather than making you re-sign
<lamont> make archive --signed, yeah.
<Kamion> lamont: you too, you don't need to type your passphrase a few million times :)
<Kamion> lamont: why remove the meta file?
<mdz> Kamion: well, in this case my master wasn't signed yet
<mkedwards> mdz: I wasn't nagging about casper, was I?
<mdz> mkedwards: no
<lamont> Kamion: the one that says 'i'm a mirror'
<Kamion> mdz: no idea how to change that
<Kamion> lamont: that's evil; that means you can accidentally commit to the mirror
<lamont> mdz: when I did that conversion recently...
<lamont> Kamion: note the step prior, in which you nuke the master
<mdz> mkedwards: that was mantiena
<Kamion> lamont: oh, I see :)
<lamont> yeah
<Kamion> fun
<mdz> who accused me of being impossible to work with because my code was in the source package rather than in revision control
* lamont writes commands he used...
<mdz> then I put it into arch and published a mirror
<mdz> and he said he was happy then
<mdz> but apparently he didn't even try to use it, because it was broken
<mkedwards> mdz: your code's not in revision control, it's in arch.  :)
<mdz> Kamion: non-broken mirror syncing now
<lamont> baz make-archive --signed (--listing) lamont@ubuntu.com--2005-COPY
<mdz> mkedwards: ssshh, there are arch developers all around us
<lamont> doh
<ogra> hehe
<lamont> baz make-archive --signed (--listing) -m lamont@ubuntu.com--2005 lamont@ubuntu.com--2005-COPY
<lamont> baz archive-mirror lamont@ubuntu.com--2005
<lamont> <lots of signing>
<lamont> cd /var/lib/arch
<mkedwards> gnashing their pointy teeth and gibbering
<lamont> rm -rf lamont@ubuntu.com--2005
<lamont> mv lamont@ubuntu.com--2005-COPY lamont@ubuntu.com--2005
<lamont> (ok, I actually just moved it out of the way until I was sure it worked...)
<Kamion> lamont: that would never have occurred to me - fun trick
<lamont> rm lamont@ubuntu.com--2005/=meta-info/mirror
<mdz> Kamion: those are the steps that used to be in the gnuarch wiki
<lamont> then really really really make sure you nuke the original master, because it's really really really bad to have two masters...  and lifeless will beat you up.
<mdz> I suppose I should be happy they're updating the docs, but it would be nice to keep the old docs around until they actually "release"
<ogra> could someone tell me what i did wrong with xosd before i disturb our ftp master ? crimsun changed it, i checked the packaging (which seems ok), signed and uploaded it....am i supposed to put myself in the Changed By field to get it accepted for main ?
<Kamion> this is the problem with using a wiki simultaneously as design discussion forum and user documentation
<lamont> mdz: I fear that the gnuarch crowd is assuming that everyone is running crack-o-the-day.  Why would you want something older, anyway?
<Kamion> ogra: you certainly shouldn't change Changed-By:
<tseng> ogra: im not in keyring@ and i get stuff uploaded Changed By me
<mdz> lamont: omg ur code is 2 weeks old it's WORTHLESS
<lamont> mdz: zactly
<ogra> tseng, it simply disappeared
<Burgundavia> mdz: incorrect descriptions in packages? Should I fire the email off to you? (It just got sent to ubuntu-doc)
<mdz> Burgundavia: bugzilla
<tseng> ogra: its not NEW?
<Burgundavia> mdz: will open bug
<mdz> Burgundavia: or if it's a universe package, MOTU
<ogra> Kamion, i thought so, so i'm wondering why it silently disappeared
<ogra> tseng, nope
<Burgundavia> mdz: checked, its main
<lamont> Kamion: and that discussion led to a wonderful semantics discussion on whether or a mirror of the archive is the same archive, or a different archive.  (it's the same archive, they tell me.  Even though it's on a different machine in a different location and all that...)
<ogra> tseng,  apt-cache showsrc libxosd2
<ogra> i uploaded 2.2.14-1ubuntu1 for crimsun
<ogra> 2.2.14-1 is in the archive
<mkedwards> mdz: xosd change fixes FTBFS for all xosd-using packages
<mkedwards> (FTBFS on ia64, anyway)
<ogra> mkedwards, ia64 is not release critical afaik
<elmo> Kamion: I think we need /releases/ to not be on cdimage.u.c
<mdz> you'd think everyone who wanted kubuntu would have it by now
<mdz> at least the first big wave
<Kamion> elmo: can I leave snapshots like arrays there?
<Kamion> elmo: Mark didn't want them on releases
<elmo> Kamion: sorry, what I mean is, we need to not duplicate stuff on releases.u.c and cdimage.u.c
<Kamion> but sure, I can unpublish the preview from there
<mkedwards> ogra: neither are xosd-using packages, which are in universe.  :)  But the Xinerama_pic stuff will bite.
<kagou> hi
<ogra> elmo, sorry to bother you with that, but could you look what happend to my xosd upload
<elmo> xosd_2.2.14-1ubuntu1_source.changes
<elmo> ACCEPT
<elmo> that?
<Kamion> urr
<Kamion> RSA host key for syncproxy.ubuntu.com has changed and you have requested strict checking.
<elmo> urr?
<elmo> oh, _crap_
<elmo> sorry
<ogra> elmo, yep, no trace on hoary-chages ?
<ogra> changes even
<Kamion> elmo: now claims to be 6b:cf:da:50:e0:21:28:20:55:73:5c:76:52:87:e1:89
<Kamion> although I guess it's safe to ignore that, I don't exactly need to trust those machines
<elmo> Kamion: yes, that's right
<ogra> elmo, but thanks, that becalms me :)
<mdz> kubuntu/amd64 seems to be incredibly popular
<Kamion> elmo: (did you purge/reinstall openssh-server or something?)
<elmo> From: crimsun@fungus.sh.nu (Daniel T. Chen (new))
<ogra> yup
<elmo> possibly that broke mailmn
<elmo> kamion: yes, to get the DSA version
<ogra> ah, ok
<Kamion> ah, right
<mdz> elmo: possibly that broke postfix; that's against RFC2822
<Kamion> er, no it's not?
<Kamion>    Strings of characters enclosed in parentheses are considered comments
<Kamion>    so long as they do not appear within a "quoted-string", as defined in
<Kamion>    section 3.2.5.  Comments may nest.
<elmo> Daniel T. Chen (new) <crimsun@fungus.sh.nu>
<elmo> now _THAT'S_ against RFC2822
<elmo> katie turned it into the valid form
<ogra> elmo, i see, i'll ask him wher the (new) coes from
<ogra> comes even
<elmo> ogra: his GPG key I'd imagine
<Kamion> ogra: it's not the (new) that's against RFC2822 there, it's the unquoted "."
<ogra> oh
<ogra> ok
<Kamion> "Daniel T. Chen (new)" <crimsun@fungus.sh.nu>
<Kamion> or
<Kamion> "Daniel T. Chen" (new) <crimsun@fungus.sh.nu>
<Kamion> either of those would be valid
<ogra> blind me 
* ogra blushes
<haggai> mdz: why did you assign kubuntu bugs to amu and not to kubuntu-devel?
<mdz> haggai: assigning bugs to a mailing list isn't generally productive
<mdz> kubuntu-devel is the QA contact so that the traffic is CC'd
<Amaranth> seb128: PING?
<seb128> sort of pong
<Amaranth> heh
<Amaranth> seb128: you're the only one that seemed to have any idea how this menu spec works
<seb128> what about reading it, so you have an idea too ? :)
<Amaranth> i've read it completely a couple times now
<mdz> haggai: are you officially devoting much of your day to kubuntu now?  if so, some of those should go to you
<Amaranth> i'm down to one last thing that i think might be a gnome-menus bug
<haggai> mdz: yes I am
<Amaranth> i have testingthis.desktop in the user and system locations and the menus are choosing the system one. new user entries show up just fine though
<elmo> Kamion: lemme know when it's unpublished - no rush, just so I know
<Amaranth> this is the non-root editting of root menus holy grail
<ogra> elmo, thanks for the time btw :)
<elmo> ogra: no prob
<seb128> Amaranth: you use your user .menu files ?
<seb128> not the /etc/xdg/menu ones
<Amaranth> i don't know how gnome-menus does it, i have python-xdg reading ~/.config/menus/applications.menu
<Kamion> elmo: I've TODOed it, because I want to update the publish-release script at the same time
<Kamion> elmo: not putting it off though, will do it tonight or tomorrow
<elmo> Kamion: cool, thanks
<seb128> Amaranth: I don't think that's ~/.config
<Amaranth> seb128: http://ubuntuforums.org/showpost.php?p=100619&postcount=10 <--thats what the applications.menu looks like
<Amaranth> seb128: that's where kmenuedit puts it's stuff
<Amaranth> seb128: it puts .desktop entries in ~/.local/share/applications and .menu files in ~/.config/menus
<seb128> Amaranth: http://bugzilla.gnome.org/show_bug.cgi?id=170702
<seb128> MENU_VERBOSE=1 gnome-menu-spec-test
<seb128> Amaranth: the bug has an example
<Amaranth> yikes
<Amaranth> i think i want to pipe the output of that to a file
<elmo> argh
<Amaranth> seb128: yeah, that shows my desktop file loading from the system menus instead of the user ones
* lamont must go yell at the gas people over lunch... back in a while
* lamont does a couple more things before leaving
<Amaranth> seb128: hell, that doesn't show anything loading from user menus, which is obviously wrong because i'm looking at an entry loading from user menus right now
<seb128> Amaranth: MENU_VERBOSE=1 gnome-menu-spec-test
<Amaranth> that's what i did
<seb128> and what does it say about your local .menu ?
<buxy> Kamion: where can I find the scripts used to generate ubuntu CD images / live CD ?
<Amaranth> nada
<seb128> Amaranth: 
<seb128> Loading menu layout from "/etc/xdg/menus/applications.menu"
<seb128> Loading "/etc/xdg/menus/applications.menu" from disk
<seb128> Set basedir "/etc/xdg/menus"
<seb128> Set menu name "applications"
<seb128> 
<seb128> etc here
<mdz> ogra,seb128: can you think of any simple way to address bug #7150 for Hoary?
<mdz> (xscreensaver locking on the live CD)
<Amaranth> seb128: that doesn't even seem to show up in here
<seb128> mdz: hum, out of turning xscreensaver off, nop
<seb128> Amaranth: where is your .menu file ?
* Amaranth wonders why this spits most of it's stuff out on stderr
<buxy> mdz: I asked that to Kamion first, but maybe you can also help me: where can I find the scripts used to generate ubuntu CD images / live CD ?
<Amaranth> seb128: ~/.config/menus/applications.menu
<mdz> buxy: we use debian-cd
<seb128> Amaranth: apparently I don't have access to your homedirectory 
<mdz> with some modifications that Kamion made
<seb128> Amaranth: so that's not really useful
<Amaranth> seb128: Oh, I gave you a link, let me get it again.
<seb128> Amaranth: ie: is the content somewhere ?
<Amaranth> http://ubuntuforums.org/showpost.php?p=100619&postcount=10
<Amaranth> what he has is what i have
<buxy> mdz: and for the live CD ? I doubt it's also debian-cd... :-)
<mdz> buxy: yes, it is
<seb128> Amaranth: 
<seb128> Set basedir "/home/gnome/.config/menus"
<seb128> Set menu name "applications"
<seb128> File loaded OK
<seb128> Resolving files in: <Root>
<seb128> Resolving files in: <!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN"
<seb128> etc
<seb128> on the top of the log
<buxy> mdz: duh, must be "many" modifications then, okay I'll wait input from Kamion then
<ogra> mdz, what seb128 said, except the LiveCD releases at least a week later, then i could try to hack something together, but currenty i'm full with tasks
<mdz> ogra: how could we implement what seb128 said?  is there a configuration file which can disable the locking functionality entirely?
<Amaranth> ah, now that shows up
<ogra> mdz, dunno, i'll lookinto it
<seb128> Amaranth: ??
<mdz> at the least, we would need to a) remove the menu entry, and b) adjust acpi-support configuration to avoid its explicit locking
<Amaranth> seb128: i dunno, i couldn't find that part in my log before
<seb128> Amaranth: grep is nice :p
<ogra> mdz, it has a configuration dialog, so there must be a config file anywhere....
<Amaranth> i had it in gedit and search for Loading menu layout
<Amaranth> nothing showed up, i think it was because of the was i was logging it
<Amaranth> anyway, it just says it's loading my menu then moves on to the system one and starts loading desktop entries
<Amaranth> Resolving files in: <MergeFile>/etc/xdg/menus/applications.menu</MergeFile>
<Amaranth> Merging file "/etc/xdg/menus/applications.menu"
<ogra> mdz, i'll find it and tell you what we can do....but i dunno anything about the kde dialog
<seb128> Amaranth: from the spec
<seb128> "If the user adds a menu item, you use <Include><Filename>foo.desktop</Filename></Include>."
<seb128> Amaranth: works fine here, you just need to add an include in ~/.config/menus/applications.menu
<svenl> Kamion: 
<svenl> Kamion: would you consider enabling -chrp dailies of the netboot stuff ? 
<svenl> Kamion: now that the kernels have mkvmlinuz support ? 
<Amaranth> seb128: that should make the user entry show up over the system one?
<elmo> Kamion: do you have any array deadlines/cdimage creating sessions coming up?
<Amaranth> seb128: that doesn't do anything :/
<seb128> Amaranth: yep
<seb128> have you even tried ?
<Amaranth> yes
<seb128> what is in the log ?
<seb128> is in the menu ?
<seb128> s/is/is it/
<seb128> how have you added it ?
<Amaranth> <Menu><Name>Accessories</Name><Include><Filename>gcalctool.desktop</Filename></Include></Menu>
<Amaranth> i put that in my applications.menu below the MergeFile line
<seb128> and it's not in the menu ?
<Amaranth> it is, but it always was
<Amaranth> i need the user version
<seb128> the use one ?
<Amaranth> no, it's still the system one
<seb128> is the user version in the menu ?
<Amaranth> no
<Amaranth> gnome-menu-spec-test shows my version and the system version being merged
<Amaranth> but it looks like it's picking the system version
<Amaranth> Union of 0x80c4178 and 0x80c7d70
<Amaranth>  Adding to set 0x80c4178 entry gcalctool.desktop
<Amaranth> my version is loaded as 0x80c7d70
<seb128> Amaranth: I think that you need to make totem-user.desktop
<seb128> Include it
<seb128> and Mask totem.desktop
<Amaranth> mask?
<seb128> <Exclude>totem.desktop</Exclude>
<Amaranth> oh
<shaya> seb128: you here?
<seb128> sort of
<shaya> does evince thumbnailer work for you in nautilus?
<shaya> it doesn't do anything for me and othres
<Amaranth> arg!
<shaya> while for a few it seems to work fine
<shaya> any ideas?
<seb128> shaya: works fine
<seb128> try to run it from the command line
<seb128> Amaranth: what ?
<shaya> it runs and can create a png when run manually
<Amaranth> still nothing
<seb128> Amaranth: no way that doesn't work
<Amaranth> maybe killing gnome-panel isn't enough to make it update, let me look in my editor
<seb128> Amaranth: Including a menu item works, Excluding too
<seb128> no need to kill it
<seb128> gamin follows the changes
<Amaranth> ok, it's just gnome-panel and/or gnome-menus
<Amaranth> then there it a bug
<Amaranth> err, is
<seb128> works fine here (tm)
<seb128> shaya: /desktop/gnome/thumbnailers/application@pdf/command gconf key ?
<Amaranth> yeah, sometimes it does
<Amaranth> other times it doesn't
<seb128> gamin is 0.0.26 ?
<shaya> evince-thumbnailer -s %s %u %o
<Amaranth> seems totally random and i haven't been able to reproduce it working or not working in certain situations
<Mithrandir> doko: pong
<shaya> and "enable" is checked
<Amaranth> 0.0.26, yeah
<seb128> shaya: so no idea, do you have some thumbnails for other stuff ?
<shaya> yes
<shaya> movies
<shaya> pictures
<seb128> no sense
<shaya> anyway to debug this
<shaya> i.e. have nautilus output a log
<seb128> no
<shaya> bah
<shaya> stupid nautilus
<seb128> the gconf key is set, the command works
<seb128> are you sure it doesn't thumbnail it ?
<seb128> have you "touch file.pdf" ?
<shaya> its not displaying the thumbnauls
<shaya> hold on
<shaya> let me try that while viewing it
<shaya> ah
<shaya> that did it
<seb128> so that works
<shaya> but only for that pdf
<shaya> not for the old ones in the dir
<seb128> touch *.pdf
<shaya> yea, but why do I have to do that?
<seb128> because you have screwed the preview somewhat
<seb128> and it doesn't update if the file doesn't change
<seb128> you need to update the timestamp to force a refresh
<Amaranth> seb128: You're my hero. ;)
<seb128> ie: perhaps you had a broken thumbnailer
<Amaranth> I don't know why I didn't think of that....
<seb128> it has masked the file has thumbnailed
<seb128> and it doesn't try to update
<seb128> Amaranth: np :)
<shaya> hmm
<seb128> s/masked/marked/
<seb128> shaya: you can rm -rf ~/.thumbnails/fail/
<seb128> and restart nautilus
<seb128> should do the trick
<shaya> only problem with these thumbials is that they screw up the spacing
<shaya> hmm
<shaya> anyways, thanks
<seb128> np
<jbailey> mdz: Ah thanks, that's worth knowing.  I'm getting Jordi to pull down array 6 and the current nightly.  It's probably finished by now (but he's certainly gone home for the day).  I'll keep that in mind for next time, though.
<seb128> do we have a server actually working to rsync a dvd image ?
<mvo> hey Mitario 
<Mitario> mvo, heya
<zul> later guys
<Mitario> mvo, i have some kind of radical thought here :)
<mvo> Mitario: two week before the release :)
<Mitario> mvo, oh, that's noproblem my idea can be implemented in 10 minutes coding ;-)
<mvo> Mitario: tell me about it then 
<Mitario> ok, let's say a /security/-update will never remove any packages from the system, agree with that?
<mdz> seb128: not anonymously
<Mitario> mvo, anyways not noticable for the user - as in, some front-end app is removed
<mvo> Mitario: right, u-m will never remove or add packages
<Mitario> mvo, ok, why don't we drop the 'select/unselect' update column, and let the 'install' button perform a dist-upgrade always
<Mitario> mvo, i mean, most users just want to know there are updates and install them, no matter what happens
<mvo> Mitario: we never do a dist-upgrade :) only upgrades. but I think it might be nice to have the checkboxes because a user might decide to not-install some packages (because e.g. it's too big right now)
<Mitario> hmm, yeah true.. but won't a user which already knows he doesn't want to install that package but does want to install the others use synaptic?
<Mitario> mvo, and security updates will probably only change 1 - 3 packages
<Mitario> i've never seen security updates with > 10 packages
<luis> FWIW, some kde security updates for suse and redhat have required updating all kde packages
<luis> which is >> 10
<Riddell> luis: any idea which ones?
<luis> I don't recall
<luis> just offering it as an edge case where security updates could have more than 10 packages
<luis> I presume you could see the same thing with gnome, though to the best of my knowledge it has never happened
<thom> mdz: i know how it works, yes
<mdz> thom: can you work the magic for kubuntu?
<thom> mdz: i'll get the kubuntu stuff done after dinner - haggia; is that mail from the other day still valid
<thom> haggai, even
<mdz> thom: it would save both me and the kubuntu team a lot of time moving bug saround
<thom> sure
<thom> be about 45 minutes?
<Riddell> mdz: what is thom's magic for kubuntu?
<thom> mdz: can you have a quick look over popcon.ubuntu.com and see if it looks ok?
<azeem_> *big magic*
<mdz> Riddell: having a 'kubuntu' pseudo-product in Bugzilla to get bugs automagically copied to kubuntu-devel and assigned to someone reasonable
<Riddell> ooh yes please thom 
<mdz> thom: ia64 seems to be very nearly white-on-white
<mdz> in the legend
<mdz> er, amd64
<thom> mdz: amd64, yes
<mdz> and the scale is a bit crowded :-)
<thom> heh
<thom> i wanna look at the debian code and see if they have a fix for that
<mdz> there's certainly a lot which could be done to prettify it, but I think it's certainly ready to publish
<thom> i really want to rewrite the whole thing to use templates for the html and so on, but that's way down on the priority list
<thom> righto
<haggai> thom: the mail is still valid, but a new Product would be even better than the description change I asked for
<Kamion> buxy: http://cdimage.ubuntu.com/debian-cd/code.tar.bz2 (no diff though, it's a tarball of modifications to somewhat-out-of-date CVS ...); it's basically a horrible nasty hack because I haven't been able to convince anyone to import debian-cd into arch so that I can maintain local changes sanely
<ogra> seb128, seen that ? https://launchpad.ubuntu.com/malone/bugs/239
<Kamion> svenl: sure, although the kernel upload that adds mkvmlinuz stuff hasn't actually happened yet - I'm waiting for that first
<Kamion> elmo: nope, nothing in the next week or so that I know of
<Kamion> elmo: hoary release candidate is the next thing on my list (30th)
* Kamion goes away again
<Kamion> buxy: (the casper source package is the thing to look at for how the live CD works)
<seb128> ogra: any example ?
<ogra> seb128, nope, i'm just discovering malone and if that would be real, it would be worrying
<ogra> seb128, no idea if thats an actual bug, but ccording to bradb it could be legit...
<bradb> ogra: as in, i'm unaware of anyone having used prod lp just for testing purposes.
<ogra> ok
<mdz> thom: hmm, the popularity-contest dialog still says debian, even though it's not the debian popularity contest
<mdz> thom: since we install it by default disabled, debconf isn't very interesting; perhaps we should just ship a command-line tool to turn it on
<thom> yeah; i wasn't sure how to change it without blowing away the translations
<thom> hrm, should be trivial to write; will do
<mvo> is linux-restricted-modules installed by default for new installs?
<Mithrandir> iirc, yes
<mdz> mvo: yes
<mdz> has been since Warty
<mdz> thom: or maybe update the template, and wrap it in debconf-with-gnome-frontend-love
<mdz> thom: then we could add a .desktop for it too
<mdz> though that might be too in-your-face
<mdz> I do want to find a way to encourage participation
<mdz> but I agree that we shouldn't ask during the install
<mvo> mdz, Mithrandir: thanks. I'll add the pcmcia driver for avm pcmcia-fritz then too to the pcmcia-cs package
<haggai> is rsync://cdimage.ubuntu.com turned off or something?
<haggai> rsync: connection unexpectedly closed (0 bytes received so far) [receiver] 
<mdz> mvo: yes, I think it's easiest to add everything to pcmcia-cs, since the modules can come from different packages
<mdz> haggai: it's apparently broken
<mdz> I asked elmo about it, and he berated me for not using a mirror
<mdz> which I assume means he knows it's broken
<haggai> mdz: hmm thanks I'll look for an rsyncable mirror then
<dholbach> kamion, mdz: what am i supposed to do with #7888 (workrave) and new g*mm dependencies? am i required to find someone to upload new versions, that get rebuilt?
<infinity> dholbach : I was about to tackle mdz about that (since the bug has been assigned to me)...
<jdub> Kamion: around?
<infinity> dholbach : To use your proposed change, seeds need to change, right?
<dholbach> infinity: i can forward you the mail conversation
<infinity> dholbach : Which doesn't seem unreasonable, but requires intervention from people who are Not Me.
<dholbach> infinity: i already mailed kamion, jdub and mdz about it - but i'm not sure if my input/action is required
<infinity> dholbach : If one of them said "yup, we'll fix the seeds", then that should about do it.  I can upload a fixed source package once the libs have moved around appropriately.
<dholbach> infinity: you can upload to main? good to know... :-)
<mdz> dholbach: I mentioned in the bug that i already uploaded the package
<mdz> dholbach: and then i passed the bug to elmo for the archive resync bits
<infinity> Oh, see?... I guess I need to wake up and check my mail.
<dholbach> mdz: so no further input required from me?
<mdz> dholbach: nope, thanks
<dholbach> thank you, mdz 
<thom> where should kubuntu bugs go? kubuntu-devel@lists?
<mdz> thom: bugzilla, QA contact; kubuntu-devel
<thom> ok
<mdz> thom: unless they want a kubuntu-bugs list, like kernel-bugs
<mdz> haggai,amu?
<Riddell> mdz: yes please
<jdub> Riddell: you want kubuntu-bugs?
<thom> mdz: can one not assign a default QA contact to the component? i don't know if i can set QA in the way the livecd hack sets owner
<jdub> thom: you can set default QA contact
<Riddell> jdub: well I'm happy with using kubuntu-devel but mdz seems not to like that, either is good
<jdub> Riddell: it's pretty anti-social ;)
<jdub> mdz: http://gnomedesktop.org/node/2199
<mdz> thom: a default qa contact can be set on a component, yes
<mdz> but I have no convenient way to maintain the list of components
<mdz> and editing components when you have thousands of them is painful in the web UI
<mdz> jdub: it is not based on ubuntu :-(
<thom> right. unf
<mdz> thom: one day I will add stuff to bugzilla.py to do it via SQL
<mdz> but not today
<jdub> mdz: but after the breezy livecd enhancements... :-)
<mdz> thom: if the same hack used for livecd can be used, that would be ideal, but somehow I doubt it (since qa contact isn't on the enter_bug form I don't think)
<mdz> jdub: what's missing from the hoary infrastructure?
<thom> mdz: that's exactly the problem :/
<mdz> it sounds like a flavour
<jdub> mdz: it could be, but there are still reasons to play with other systems before using casper
<mdz> jdub: it sounds like it's based on the new knoppix with unionfs
<jdub> just thinking attractiveness over technical requirements
<jdub> yeah
<jdub> we should have a casper site
<jdub> http://planet.livecd.net/
<jdub> ^ lame, but it exists
<azeem> bah, onlx Linux Live CDs
<thom> azeem: what, you mean it doesn't cater to the huge and GROWING hurd live-cd market?
<azeem> dude, even Eugenia loves us
<jdub> yeah, now there's a growth market and a half
<luis> man, I need to get on that planet
<luis> I'm feeling so left out
<jdub> mandrake goes yearly: http://lwn.net/Articles/128451/
<mdz> thom: from zero, there's nowhere to go but up
<thom> mdz: *g*
<thom> mdz: right, i don't think i can bludgeon this in quite the necessary way :(
<jdub> ah, eugenia likes arch now
<jdub> which keeps her out of our bugzilla :)
<thom> jdub: arch linux? she always did
<azeem> I wonder whether she likes the new XFCE file manager
<jdub> now she's publically liking it
<maswan> mdz: the rsync problem is just that mrinyy has a couple of magnitudes too high load to support it at the momen
<jdub> in an osnews kind of way
<mdz> Kamion: amd64 dvd install in progress
<jdub> haha
<jdub> "Saying Ubuntu was 2004 is a bit wrong though, I've never seen such sustained hype over a distro as we've seen with Ubuntu, and Ubuntu looks set to take 2005 by storm as well."
<jdub> released in *september* and people think it was "the distro of 2004"
<mdz> october ;-)
<Burgundavia> jdub: s/people/Eugenia
<smurfix> jdub: What's "hype"ish about simply being good? That guy needs to work on his terminology.
<jdub> Burgundavia: other than eugenia
<azeem> smurfix: EGENDER
<jdub> mdz: public knowledge, etc.
<smurfix> azeem: OK, OK, s/his/her/g
<jdub> smurfix: there's been a lot of hype, user articles, etc.
#ubuntu-devel 2005-04-02
<smurfix> jdub: All a matter of your PoV. ;-)
* smurfix seems to have forgotten the simley up there
<smurfix> smiley
<seb128> oh, mdk change for one version/year now 
<jdub> seb128: main result: fcrozat will be on irc more often now ;)
<seb128> ah ah
<thom> mdz: i've mailed justdave to find out if he knows a way to do it
<jdub> haha: "first of all during install you can compile your own kernel (what most sane people do)"
<infinity> Anyone currently have any automounter processes running on their machine?
<mdz> thom: meanwhile, we have a kubuntu product which acts just like ubuntu?
<Burgundavia> jdub: that one cracked me up as well
<HiddenWolf> jdub: piont whoever said that to gentoo. :P
<mdz> Kamion: around?
<thom> i'm gonna add a link in a similar style to livecd, so at least you get the kubuntu keyword set
<thom> mdz/amu/haggai/Riddell: sample text for the kubuntu product?
<ogra> fabbione, if you read this tomorrow, could you please add #ubuntu-motu to your weblogger asap ?
<Riddell> thom: Beasties specific to the KDE based Ubuntu derived distribution
<thom> Riddell: done
<Riddell> cool :)
<haggai> thanks thom
<jdub> thom: so we can't really do qa contact stuff yet, right?
<thom> jdub: we can't set it on keywords from the bug entry page, is all i'm talking about
<mdz> jdub: not at the product level
<mdz> thom,Riddell: "beasties"?
* justdave checks his mail
<mdz> please reconsider
<jdub> so we're using the same livecd hack
<haggai> s/Beasties/Bugs/ ?
<thom> justdave: so, if you remember the hack in place to ensure that bugs filed on the livecd get a keyword and the owner set, the desire is to do similar but set the qa contact
<thom> is that possible/plausible?
<mdz> haggai: that would be better, yes ;-)
<jdub> isn't that just another url component?
<justdave> hmm, plausible, but I don't think qacontact is in the enter_bug form
<thom> justdave: no, it's not
<justdave> you'd have to add a hidden field to the enter_bug template to hold it
<justdave> I *think* post_bug will accept it if it's in the form
* justdave double-checks
<justdave> you're still running 2.19.1+, right?
<thom> yeah
<justdave> yes, post_bug does accept it if it's in the form
<justdave> so adding it to the template should be all that's needed
<justdave> even as a hidden field which is set when the livecd "product" is chosen
<thom> ok
<mjg59> Hmm. 200 for conference registration and a room at LCA.
<mjg59> That's less than I paid for fewer nights of accommodation at Guadec in Dublin.
<Riddell> mjg59: but more than fosdem
<justdave> roundabouts line 262 in template/en/default/bug/create/create.html.tmpl
<Riddell> (or indeed akademy which I just announced on kde dot news)
<Mithrandir> mjg59: where are you staying for LCA?
<mjg59> Riddell: This is for a week
<mjg59> Mithrandir: The student rooms
<Mithrandir> mjg59: ok, they're all booked out now, so I'm kinda searching for something.
<Mithrandir> I tried mailing the hostel stuff but they never responded
<Mithrandir> I should try to call the,m
<Mithrandir> s/,//
<justdave> [% IF keywords == "livecd" %] 
<justdave>   <input type="hidden" name="qa_contact" value="nametouse">
<justdave> [% END %] 
<mjg59> Mithrandir: Ah - an email was sent out offering more rooms
<Mithrandir> mjg59: oh, it was?  could you bounce it to me?
<Mithrandir> (or are they all taken now?)
<jdub>   ubuntu-announce:3280
<jdub>   ubuntu-users:1626
<jdub>   ubuntu-security-announce:1029
<jdub>   ubuntu-news:1237
<mjg59> Mithrandir: Dunno, I got bounced it by keybuk...
<jdub>   kubuntu-devel:56
<jdub>   kubuntu-users:136
<jdub>   ubuntu-devel:737
<mjg59> They said they'd open it up to people who hadn't booked yet in April
<Mithrandir> mjg59: if you could bounce it to me, I'd appreciate.
<mdz> speaking of ubuntu-news, I haven't seen Ubuntu Traffic in a while...mako? ;-)
<Mithrandir> mjg59: tfheen@err.no ; thanks :)
<jdub> and ladies and gentlemen
<thom> justdave: thanks a bunch
<jdub> the top five ubuntu loco lists
<jdub>   ubuntu-es:555
<jdub>   ubuntu-fr:433
<jdub>   ubuntu-de:306
<jdub>   ubuntu-it:230
<jdub>   ubuntu-ru:122
<jdub> 
<justdave> thom: np
<ogra> Mithrandir, any answer from Ove ?
* thom tests
<Mithrandir> ogra: no, none
<ogra> Scott didnt confirm to be there tomorrow either, hrm
<mako> mdz: yeah.. its been a little bit.. me pouring water into my laptop week didn't really help the situation
<mdz> mako: through your nose, I hope
<mako> i spilled water onto *two* computers in under 30 seconds
<mako> it would have been funny if it didn't also make me unable to work for 4 days
<ogra> mako, did you talk to guiness ?
<mako> ogra: ?
<ogra> mako, its proably worth a entry in their book ;)
<thom> justdave: hrm; the enter_bug page correctly has:
<thom>    <input type="hidden" name="qa_contact"
<thom>    	  value="kubuntu-bugs@lists.ubuntu.com">
<mako> not only that, but it was *while* my talk was being introduced.. 
<thom> but when i go to the bug (#8021) there's not QA contact filled in
<mako> so i'm there, standing front of 1500 people about to talk having just poured water into two computers.. one of which was running the presentation
<ogra> argh
<mako> frickin' horrible :)
<mjg59> Mithrandir: Sent
<mako> the laptop seems to be fine.. although the keyboard is not.. i've already ordred a new one :)
<Mithrandir> mjg59: thanks
<ogra> mako, but a good practice for improvisation....
<mjg59> My name is Mako, and I have a drinking problem...
<ogra> lol
<mako> mjg59: perhaps, but that is unrelated :)
<mako> "i don't have a drinking problem, 'cept when i can't get a drink"
<ogra> heh
<Mithrandir> mako: new laptop or new keyboard?
<justdave> thom: grrr.   post_bug.cgi line 149
<mako> Mithrandir: new laptop keyboard
<justdave> currently has         $::FORM{'qa_contact'} = $qa_contact;
<Mithrandir> mako: I'm amazed your latop hasn't fallen totally apart yet.
<mako> Mithrandir: it's a kb/mouse deal.. found a refurbished one for ~60USD + shipping
<mako> Mithrandir: yeah.. me too :)
<mako> Mithrandir: it's teetering on the edge
<justdave> change that to    defined($::FORM{'qa_contact'}) || $::FORM{'qa_contact'} = $qa_contact;
<mako> i thought the water thing was the end of it.. but i think i might have another 6 months out of this one..
<Kamion> jdub: yes?
<Mithrandir> heh
<Kamion> mdz: yes?
<seb128> hum,  gaim 1.2.0 
<thom> Can't modify logical or (||) in scalar assignment at post_bug.cgi line 150, near "$qa_contact;"
<thom> Execution of post_bug.cgi aborted due to compilation errors.
<dholbach> hey zul
<zul> hey
<thom> justdave: ^^
<Kamion> thom: "||" => "or"
<justdave> what Kamion said :)
<justdave> or add another set of parens on the right-hand-side would work, too
<thom> justdave: still no joy
<justdave> still errors, or still doesn't work?
<mdz> Kamion: hmm, I forget
<thom> just no QA contact set
<mdz> Kamion: fwiw, DVD install on amd64 from Saturday's ISO did not ask for the disc, seems to be fixed
<zul> is launchpad active now or something?
<justdave> ok, let's do it the long spelled out and easy to read way :)
<Kamion> mdz: bonus, thanks for testing
<justdave> if (!defined($::FORM{'qa_contact'})) { $::FORM{'qa_contact'} = $qa_contact }
<jdub> Kamion: started testing kickstart with my toilet seat
<mdz> Kamion: we need to do something about the long pause after the passwd questions
<Kamion> jdub: never tried it on powerpc :)
<jdub> :-)
<Kamion> mdz: yeah, need an extra progress bar in apt-setup-udeb, easy to do
<jdub> that makes it more fun
<Kamion> jdub: there's no bootloader support for powerpc in kickseed
<mdz> Kamion: is it on your list, or would you like a bug?
<Kamion> nor upstream for that matter
<Kamion> mdz: bug'd be good
<Kamion> jdub: it may be a matter of defining more syntax, which makes it scary
<jdub> Kamion: atm, netcfg/choose_interface=eth0 doesn't seem to be working
<thom> justdave: is there actually a QA contact set by default? (I assume not, since the field is blank) if not, we won't ever hit that code, will we?
<Kamion> jdub: would need /var/log/* to diagnose
<jdub> Kamion: by default, it attempts to use my wifi (eth1)
<justdave> thom: the param it's loading is whether the QA contact field is visible at all on show_bug
<justdave> if you can see it on the show_bug page then that's on and that code runs.
<Kamion> jdub: like I say ...
<justdave> that's populating it with the default from the database if it's on.
<thom> ah, right
<jdub> Kamion: also, i'm netbooting
<justdave> thom: doh, you're right....
<jdub> anyway, trying again atm
<justdave> ok, put the original code back...
<justdave>     if (defined $qa_contact && $qa_contact != 0) {
<justdave>         $::FORM{'qa_contact'} = $qa_contact;
<justdave>         push(@bug_fields, "qa_contact");
<justdave>     }
<Kamion> jdub: where's your kickstart file
<Kamion> jdub: ?
<justdave> except move the push line outside the last brace
<justdave> that's the problem. :)
<justdave> the push is conditional on whether there's a qa defined for that component
<justdave> we need it to check that field whether there's a default or not
<justdave> @bug_fields is the list of fields it looks for later when reading the form
<jdub> Kamion: on a local http machine
<Kamion> jdub: oh, I see your problem
<Kamion> jdub: in order to get that kickstart file, kickseed forces netcfg/choose_interface=auto in an attempt to bring the network up with *some* interface noninteractively
<thom> justdave: with that modification, still no joy
<jdub> Kamion: aha
<Kamion> jdub: I hadn't considered that people might be setting that on the kernel command line
<Kamion> jdub: willfix
<justdave> thom, looks like this, right?
<justdave>     if (defined $qa_contact && $qa_contact != 0) {
<justdave>         $::FORM{'qa_contact'} = $qa_contact;
<justdave>     }
<justdave>     push(@bug_fields, "qa_contact");
<jdub> Kamion: so, does autoconfiguration attempt to use wifi first?
<Kamion> jdub: first interface it thinks it can use
<thom> justdave: yeah; shouldn't that push be $::FORM{'qa_contact'} ?
<justdave> oh, but that overrides only if there wasn't one defined for that component
<Kamion> jdub: maybe mii/ethtool doesn't work on your eth0
<jdub> aha
<jdub> no, it doesn't
<Kamion> jdub: /var/log/* would say
<justdave> no, the checking of the value in $::FORM{'qa_contact'} should happen later
<justdave> the hash key needs to be in @bug_fields before then though.
<thom> ok
<justdave> it uses @bug_fields to know which fields to read.
<thom> right
<jdub> yeah, syslog just shows that it thinks it's disconnected
<justdave> that if block needs to also not fire if $::FORM{'qa_contact'} already contains something.
<Kamion> *dis*connected? it shouldn't be trying to use it then
<justdave> so maybe we need that line we did earlier in there anyway
<jdub> it's not
<jdub> that's the problem :)
<justdave> if (!defined($::FORM{'qa_contact'})) { $::FORM{'qa_contact'} = $qa_contact }
<Kamion> oh. "it thinks it's disconnected" => what does the second "it" refer to?
<jdub> eth0
<justdave> as well as having the push outside the if() block
* thom tries
<thom> right
<jdub> it skips eth0 (wired), goes on to eth1 (wifi)
<Kamion> jdub: so is that not what you want? from what you said earlier I thought you wanted eth1
<jdub> no, i expected eth0 (wired) to work
<thom> justdave: still no joy
<Kamion> jdub: oh right, I misremembered
<dholbach> good night everyone
<Kamion> jdub: fun example of MII/ethtool being plain wrong, then
<Kamion> since people keep claiming at me that it's infallible and why don't we just believe it ;)
<jdub> heh
<jdub> perhaps it should do something different if mii/ethtool isn't supported by the defice?
<jdub> device
<jdub> bring up the interface and detect traffic ;)
<Kamion> jdub: your device is claiming it supports it
<Kamion> jdub: if it didn't claim to support it, ethtool-lite would log "couldn't determine MII ioctl to use for <iface>" and return UNKNOWN
<Kamion> I think hardware that plain lies deserves to lose :P
<jdub> the toilet seat never lies!
<mdz> Kamion: oh, I remember what I was pinging about
<mdz> Kamion: UDU planning
<Kamion> oh, CRAP, the LCA reg thing
<mdz> Kamion: trying to break down / group the installer stuff into BOFs
<mdz> Kamion: oh, that too
<Kamion> MUST DO THAT TOMORROW
<Kamion> mdz: now not a great time for that, was about to go to bed ... can you mail or something?
<thom> justdave: any further thoughts?
<jdub> Kamion: hrm, where are the mii/ethtool binaries during install?
<mdz> Kamion: will do, about both
<mkedwards> amu: is there something hard about building boost?  IWFM
<amu> mkedwards: nope everything was fine, boost as a depends
<Kamion> jdub: it's a function in netcfg, not a separate binary
<jdub> oh
<mkedwards> amu: per MOTUTodo, boost needs to move to main, right?
<jdub> Kamion: can i make the installer use eth0 mid way through?
<seb128> jdub, mdz: opinion on gaim 1.2.0 ?
* mdz shrieks and runs away
<seb128> :)
<ogra> *g*
* seb128 doesn't really care
* seb128 likes gossip
<jdub> seb128: from what i hear it's not significantly different to 1.1.4, it's essentially a few fixes and blessed
<mdz> gaim scares me in general
<mdz> gaim updates close to release scare me more
<amu> mkedwards: so it is
<Kamion> jdub: setup/net brokenness fixed in kickseed 0.17
<zul> mdz: oh its not that bad :)
<mdz> zul: I use it every day, but I never take my eyes off it
<mdz> I don't turn my back on it
<Kamion> jdub: 'network --device=eth0' in kickstart should do that?
<zul> heh
<jdub> i currently have
<jdub> network --bootproto=dhcp --device=eth0
<seb128> the evil gaim crashes mdz's panel every night when he's not looking
<jdub> man, gaim still dies for me when i kill my panel
<seb128> me too
<Kamion> jdub: that *should* do it, if it doesn't let me know
<ogra> for me too
<seb128> gossip doesn't :)
* Benoni resolves to add gnome-panel to his Cooperative Bug Isolation Project instrumented application suite.
<seb128> dudes, you don't kill a panel
<seb128> you need to be nice with it and use gnome-session-remove :)
<seb128> gaim is happy in this case
<Benoni> In Russia, gnome-panel kills *you*!
* jdub spanks seb128 
<Benoni> Ha ha ha.
<Benoni> Thank you, thank you.  I'll be here all week.  Remember to tip your waitress.
<mdz> Kamion: hoary-dvd-amd64 desktop install looks good, testing live now
<jdub> Kamion: it really wants to keep using eth1 :-)
<justdave> thom:  found it.
<mdz> Kamion: we should add a bit about 'live' to the isolinux text on the dvd
<justdave> thom: it's expecting a user ID and not a username
<maswan> anyone has a mirror and can test updating to rsync://releases.ubuntu.com/ubuntu ? I'm seeing failures in the logfiles, but they all come form just one host
<ogra> jdub, whats wrong with that ? swap your cards :-P
<thom> justdave: unf. how do i work round this?
<jdub> ogra: laptop.
<justdave> thom: hang on a sec, still trying to figure out the least instrusive way to work around that
<jdub> though i could take out the airport.
<ogra> heh
<Kamion> jdub: wonder how many times I have to keep mentioning /var/log/* ... ;)
<Kamion> mdz: yes, we should. it's a bit fiddly
<Kamion> mdz: is #8015 a kernel bug?
<mdz> Kamion: it's a sort of fuzzy make-the-kernel-smarter-or-work-around-it-in-userspace thing
<jdub> Kamion: i've mentioned what's in there earlier, but i can't get anything to you beyond what i can type
<Kamion> jdub: you have nc
<zul> Kamion, i dont like the words kernel and bug in the same sentence :)
<jdub> ok, without the wifi card there to confuse everything, it's already into base installation
<jdub> it seems to have created the partitions and formatted :)
<jdub> Kamion: have you tried loading a cfg file with s-c-k?
<thom> mdz/jdub: can you add kubuntu-bugs@lists as a valid bugzilla user, please? (i assume that's how this works)
<mdz> Kamion: I was thinking today that a casper-style overlay could reduce d-i's memory requirements (keeping much of the initrd on the CD rather than in memory)
<mdz> it'd be slower, though
<jdub> thom: sure
<infinity> Whast sort of hours does pitti keep?
<jdub> thom: done
<jdub> thom: will create list in a minute too
<thom> infinity: gmt+1 9am-> late seems about right
<infinity> So, I proabbly just missed him, then?  Achwell.
<thom> justdave: thanks heaps, that's working
<thom> mdz,Riddell,haggai,etc: you have kubuntu love
<justdave> thom: coolness :)
<justdave> thom: took long enough :)
<thom> justdave: oh well :-) no pain no gain ;-)
<mdz> thom: thanks
* thom -> sleep
<Kamion> jdub: yeah; did it break?
* mvo -> bed
<Kamion> mdz: that would be interesting ...
* Kamion -> bed
<jdub> kubuntu-bugs is alive
<jdub> needs a small bit of love from haggai/Riddell 
* Benoni waves to jdub.
<ogra> mdz, look at ~/.xscreensaver, line 7 :)
<mdz> ogra: that is disabled by default, isn't it?
<mdz> ogra: the problem is with, e.g. the "Lock Screen" menu item, and acpi-support's locking
<mdz> which do xscreensaver-command -lock
<jdub> http://tml-blog.blogspot.com/2005/03/stop-that-music-or-vmware-is.html
<jdub> heh
<jdub> yo Benoni 
<thom> ogra, mdz: hrm, what's the problem?
<ogra> thom https://bugzilla.ubuntu.com/show_bug.cgi?id=7150
<mdz> thom: on the live CD, the logged-in user has a locked password
<ogra> thom, xss allows locking even if there is no PW
<thom> ow
<amu> jdub: please file a bug
<ogra> mdz, is ti possible to have a different xscreensaver package for the live CD (patched) ?
<mdz> ogra: no
<ogra> *sigh*
<mdz> casper can change the acpi-support config easily enough
<mdz> I'm not so sure about how to remove the menu item
<ogra> hmm, the entry in ~/.xscreensaver doesnt even affect the behavior, odd
<jdub> amu: hmm?
<daniels> Benoni: quiche?
<mako> ogra: around?
<crimsun> mako: he went to bed ~40 mins ago
<mako> ah well
<Amaranth> arg
<Amaranth> i go from a menu spec issue to a python xml issue
<daniels> Amaranth: builds character
<Amaranth> daniels: finds bugs, i think
<Amaranth> nothing in my dom tree from the root on down has an ownerDocument attribute
<sabmoc> oooo.. he is such a cute badger!!
<sabmoc> looks like a bunny with claws
<Amaranth> yea for making none of my menus show up!
<sabmoc> yay!
<sabmoc> oh wait, you're being sarcastic Amaranth ?
<Amaranth> heh
<sabmoc> fear the badger!
<Benoni> Hey, daniels.  Long time no see.
* daniels stares.
<daniels> 111     Mar 22 Mona            (   0) Wikipedia knows the shit
<daniels> strangest spam I've yet received
* Benoni waves to jdub again, this time paying attention in case jdub waves back.
<daniels> whoever uploaded toursst: you just uploaded it to Debian, dude
* Benoni decides xchat-gnome is not quite stable enough for day-to-day use.
<Benoni> So daniels, how have you been?
<daniels> not too bad, thanks; you?
<Benoni> Good, good.  Life has changed quite a bit since last we talked.
<daniels> indeed
<Benoni> I'm now *Dr.* Benoni.  (W00t!)
<Benoni> Speaking of which, jdub, are you still around?
<adamh> How can I install ant on Ubuntu?
* adamh grabs the Debian package. Never mind me... :)
<mdz> interesting, Debian hit 300k bugs at around the same time Ubuntu hit 8k bugs
<wasabi_> mdz, who do I need to coordinate with on the upload of a new Ant package? It's merging two Debian merged packages into one, and moving that one to universe.
<mjg59> mdz: And around the time we hit 111111111 seconds since the epoch. Conspiracy?
<mdz> wasabi_: you already have privileges to upload to universe, right?
<wasabi_> Yes.
<mdz> wasabi_: if you need packages synced in from Debian, mail James and CC me; if you just need to upload stuff directly, go ahead
<mdz> wasabi_: once it's in the archive, we can promote it from multiverse to universe as appropriate
<wasabi_> Not exactly. I need a package in universe removed.
<wasabi_> And then this package uploaded to multiverse (for now)
<mdz> before you can upload?
<wasabi_> Err, wait, that's not going to work yet. ;)
<wasabi_> But, in the future!
<wasabi_> Do you know the Ant situation?
<mdz> I talked to jbailey about it briefly in the context of oo.o2
<wasabi_> two source packages: libant1.6-java and ant
<wasabi_> libant1.6-java produces libant1.6-java
<wasabi_> ant produces ant
<wasabi_> libant1.6-java is in universe, ant is in multiverse.
<wasabi_> new package: ant. produces both ant and libant1.6-java (superset of old libant1.6-java)
<wasabi_> And removes non-free pieces that forced 'ant' to be in multiverse previously.
<mdz> as long as the new package follows the existing version line, that's no problem
<mdz> upload ant 1.6.2-2ubuntu1 or similar; the binary packages it builds will supersede both ant and libant1.6-java since it's a newer version
<mdz> then once the dust settles, you can request removal of libant1.6-java
<wasabi_> ahh.
<wasabi_> Now to just figure out how to get this thing properly universe-compatible.
<mdz> well, at least, that's how it would work if they were in the same component
<mdz> I'm not entirely sure how this type of superseding works across components
<mdz> probably best to check with elmo
<mdz> hopefully it still works as I described, but check before uploading
<wasabi_> that makes sense. thx
<wasabi_> mdz, can you perhaps move libbcel-java to universe?
<wasabi_> if not i'll wait for elmo tomorrow.
<wasabi_> just, I have a log of 3 packages to upload waiting on it that I want to get going. ;)
<wasabi_> and im totally impatiant
<mdz> wasabi_: will libbcel-java build if it's in universe?
<mdz> it looks like its build-depends are satisfied in universe, but please confirm
<wasabi_> The source package is in universe.
<wasabi_> the binaries are in multiverse.
<wasabi_> So yeah, I confirm. ;)
<mdz> wasabi_: should be in the next pulse
<wasabi_> awesome, thanks.
<wasabi_> mdz, oh, libbcel-java-doc too if ya didn't notice it. ;)
<mdz> I did
<wasabi_> k thanks once again
* infinity thinks more people should learn how to use start-stop-daemon effectively..
<infinity> mdz : Given that you seem to have opinions on how 7847 (shouldn't be) fixed, want to glance at my diff before I upload?
<mdz> sure
<infinity> http://lucifer.0c3.net/~adconrad/cupsys.diff
<infinity> (But, hey, what's wrong with 'sleep 20 ; pray'?)
<mkedwards> mdz: device-mapper snapshots don't survive crashes very well.  :(
<mdz> infinity: how does that address the issue of a failed restart aborting the upgrade?
<infinity> Oh, wait.  Do I need to read those lsb functions?... When you "log_end_msg 1", does it exit 1 as well?
<infinity> Oh, it does too...  Feh.  Well, it half fixes it, since the stop is less likely to fail.
<infinity> I'm not so sure one can have their cake and eat it too in rgards to init scripts having correct output and never exiting with a failure, so I guess anything that's restarting it in postinst will also need a ||true
<sabmoc> when setting up pan to browse gmain, do you need to add anything except the new servers name?
<sabmoc> news* servers name
<sabmoc> I set mine up last night and it works fine, but I am trying to help someone else and it is asking them for a group and doesnt seem to be working. :/
<infinity> mdz : Yeah, I guess the second half of the fix is a ||true in cupsys-driver-gimpprint's postinst.  Easy enough.
* infinity wonders how many packages reload cupsys...
<mdz> mkedwards: hmm, I'd expect them to hold up as well as the filesystem above them allows
<mdz> sabmoc: please use #ubuntu for questions about using Ubuntu; this channel is for development-related discussion
<mkedwards> mdz: filling a cow device is a bad scene
<mdz> mkedwards: yes, yes it is
<mdz> mkedwards: in the casper source package is the beginning of a simple applet to display a meter, to try to avoid that happening
<mdz> mkedwards: I also changed casper at one point to use a device-mapper target as the snapshot store, rather than the ramdisk directly, so that it can be trivially extended
<mkedwards> mdz: jogging the USB stick is also a bad scene.
<mkedwards> mdz: pstore valid flag set to zero, snapshot unrecoverable.
<mkedwards> mdz: dm-exception-store.c code is scary 
<mkedwards> "hmm, didn't expect an error code here ... better mark it invalid, from which we can't recover."
<kain> hi there, anyone knows here why eclipse isn't in current multiverse/devel repos on hoary?
<wasabi_> Heh.
<wasabi_> Because I haven't uploaded it yet.
<kain> that's ok, thanks ;)
<wasabi_> I have 3.0 packages on mentors
<wasabi_> which you are welcome to attempt to build.
<kain> today I can give it a try
<sabmoc> will there eventually be a http://planet.ubunut.org ?
<wasabi_> isn't there  already?
<sabmoc> we'll I hope not :)
<sabmoc> well*
<mdz> there has been, for many months now
<wasabi_> http://planet.ubuntu.com/
<mdz> planet.ubuntu.com and planet.ubuntulinux.org
<sabmoc> ah, but no planet.ubunut.org
<sabmoc> ubuntu* gah
<mdz> kain: because it doesn't build yet
<kain> I see
<mdz> sabmoc: ubuntu.org is a different organization
<sabmoc> mdz not affiliated with canonical?
<fabbione> morning
<mdz> sabmoc: correct
<sabmoc> ahic
<mdz> nor affiliated with Ubuntu the open source project
<wasabi_> I guess I could almost upload Eclipse 3.0 to multiverse.
<wasabi_> hmm. maybe maybe not.
<kain> mm
<wasabi_> nope, still missing tomcat
<fabbione> mdz: do you still play around with uml?
<mdz> fabbione: I have no time for it
<fabbione> mdz: i just have one problem with rootstrap that complains it can't find the init= script... perhaps you knew...
<wasabi_> mdz, how long is the next "pulse"?
<wasabi_> thought that was a 30 minute deal
<crimsun> wasabi_: at :03 and :33
<wasabi_> hmm or will it not change until I upload a new version?
<crimsun> there is something odd afoot with the buildds
* crimsun checks scrollback
<Amaranth> woohoo, non-root menu editting!
* Amaranth points to http://ubuntuforums.org/showthread.php?t=21390
<sabmoc> Amaranth, really?
<Amaranth> sabmoc: yeah
* lamont decides that his typing is becoming bad enough to warrant sleep
<Kaloz> good (ugt) morning
<sabmoc> Amaranth, cool
<Amaranth> sabmoc: it has bugs :P
<sabmoc> Amaranth, are you packaging a new version of fixing the old one?
<infinity> mdz : Shall I prepare a fixed php4 for warty?.. I found the bug.
<sabmoc> s/of/or/;
<sabmoc> I cant type at all tonight
<infinity> mdz : I'm assuming I don't have the access required to actually push it through, of course.
<Amaranth> sabmoc: still trying to fix it
<sabmoc> Amaranth, well, good job :) ..i'll go back to my doodle drawings now
<sabmoc> Amaranth, I know a lot of people would really like that fixed
<fabbione> schweeb: ping?
<schweeb> fabbione: about to sleep, but yea?
<fabbione> schweeb: is it you packaging xen, right?
<schweeb> for personal use, yes
<schweeb> want me to upload what I've got so far?
<fabbione> schweeb: did you manage to get xend to start?
<fabbione> i am more interested in making it working first :-)
<schweeb> heh
<fabbione> i did compile it from sources without any problem
<fabbione> but xend refuses to start
<schweeb> umm, xend started in sarge, yes
<fabbione> i am on an ubuntu machine....
<schweeb> are you in a domain 0?
<fabbione> yes
<fabbione> i already booted with the Xen kernel
<fabbione> and now it is supposed to start xend
<schweeb> did it error at all?
<fabbione> nope....
<fabbione> did you move the tls libs out of the way?
<schweeb> yes
<fabbione> so did i
<schweeb> it'll bitch a lot otherwise
<schweeb> umm, hrm
<schweeb> you're using 2.0.5?
<schweeb> stable, testing, or unstable?
<schweeb> fabbione: even manually executing 'xend start' does nothing?
<schweeb> then try 'xend status'
<fabbione> nope
<schweeb> urgh :-/
<fabbione> i am using 2.0.5
<fabbione> i did a strace and i can see it fails to open a lot of files
<fabbione> specially some .so in /usr/lib/python/xen/xend/
<svenl> Kamion: ok.
<schweeb> fabbione: hrm, I'm assuming you have python twisted and python logging installed?
<fabbione> schweeb: what's the standard output of a xend status?
<fabbione> twisted yes... not sure about logging
<Amaranth> ffs why do you have to make this so hard
<Amaranth> err, they
<schweeb> logging is included in the dist tarball... it shoul dget installed on compile
<Amaranth> not any of you, i don't think :P
<Amaranth> stupid fd.o menu spec
<fabbione> schweeb: is there a deb package for it?
<fabbione> (for logging i mean)
<schweeb> I'm not sure
<fabbione> ok
<fabbione> i will just build it
<schweeb> I thought it was part of the base python distro
<schweeb> but I know jack about python
<schweeb> fabbione: which .so is it missing?
<fabbione> no luck
<infinity> Can/does anyone other than pitti do security uploads?
<fabbione> open("/usr/lib/python/xen/xend/server/domainmodule.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
<fabbione> schweeb: just one of them that is missing....
<fabbione> infinity: nope...
<fabbione> infinity: btw.. i have a bug report for you...
<fabbione> infinity: what email can i forward to?
* Amaranth beats random things with a stick
<Amaranth> This is so _stupid_.
<schweeb> fabbione: odd, I don't have a domainmodule.so compiled... maybe it's a dynamically generated python thing or something
<schweeb> I have domain.py and domain.pyc in that path...
<fabbione> schweeb: ok.. at least that excludes the possibility that i did miscompile
<fabbione> schweeb: so do i
<infinity> fabbione : Ubuntu or Debian?
<fabbione> infinity: Ubuntu...
<infinity> fabbione : Ubuntu bug reports, you can assign to adconrad@0c3.net in bugzilla.
<schweeb> infinity: it's a xen specific thing
<schweeb> unsupported
<fabbione> infinity: i will forward the mail. somehow bugzilla barfed
<schweeb> oh
<schweeb> whoops, mixing up convos
<schweeb> hehe
<infinity> bugzilla, barf?... Never... That's crazy talk.
<fabbione> infinity: aahha
* infinity holds bugzilla in the highest regard... No... Really.
<fabbione> schweeb: are you running 2.0.5 btw?
<fabbione> or unstable? or bk snapshot?
<fabbione> i really don't care to upgrade or something
<schweeb> running is a relative term ;)
<schweeb> more, I have the userspace packaged, and still have to make a kernel
<schweeb> but yes, 2.0.5 stable
<fabbione> schweeb: well.. but did you test xen at all, before starting the packaging part?
<schweeb> yep
<fabbione> ok
<schweeb> xen 2.0.4 though
<schweeb> 2.0.5 just came out like last week
<fabbione> schweeb: ah ok.. so it might actually be buggy
<mdz> infinity: yes, coordinate with pitti
<schweeb> fabbione: bwell, I'm  uploading what I've got on the packages right now, if you at least want to try them, see if it helps... http://schweeb.org/~chris/ubuntu/ ... I'm uploading now, so wait at least a half hour or so...  they don't by any means pass lintian
<schweeb> but, bedtime, later
<fabbione> schweeb: don't worry.. no need to trash your bw
<fabbione> schweeb: i just need to get it working.. and have a good night :-)
<schweeb> thx... I should have gone to bed 2 hrs ago, I'm gonna pay for this
<schweeb> hehe
<schweeb> night
<infinity> fabbione : That bug did finally get submitted to bugzilla.  And I'm fixing it right now.  I need pitti to upload it, though. :)
<fabbione> ah ok
<mdz> Keybuk: would it be easy to filter the changelog diffs into a separate patch in MOM?
<bob2> bah
<bob2> slay in ubuntu is fascist
<Keybuk> mdz: in the ongoing-merge output or patches output?
<mdz> slay is a silly single-purpose tool which duplicates functionality in more standard tools
<mdz> Keybuk: in the patches output
<Keybuk> they are already?
<mdz> they weren't the last time I looked...
<mdz> did you change that within the past month or so?
<Keybuk> nope
<Keybuk> ah, changelog + control get lumped together
<mdz> and called most descriptively "misc"
<Keybuk> heh
<Keybuk> sure, can change that
<mdz> thanks
<Keybuk> seb128's filed a bug about that libtool bug I mentioned the other week
<fabbione> mdz: #7939, if we can't get a fix in the kernel i will upload hotplug to blacklist the alsa module and load the oss one. would that be ok for you?
<fabbione> (also because i have no other solution)
<mdz> Keybuk: yes, I noticed
<infinity> mdz : Alright, fix tested, rolled, and signed for pitti to have a look at.  I've pinged him via mail with a pointer to the sources, so the ball is in his court.
<mdz> fabbione: alsa-base rather than hotplug, but yes
<fabbione> mdz: ok
<mdz> infinity: he'll be awake soon enough
<fabbione> you talk about the devil...
<pitti> Good morning
<infinity> Speak of the devil..
<infinity> Also, I'm redundant.  Yay.
<infinity> pitti : Check your mail, svp. :)
<pitti> infinity: I'm about it :-)
<pitti> mdz: still here?
<mdz> pitti: yes
<pitti> mdz: remember that we removed raidtools support from heartbeat?
<pitti> mdz: the Debian maintainer did this as well and cleaned this up further a bit
<mdz> pitti: yes, and Debian is discussing the same thing now
<pitti> mdz: it's in version -8 in incoming
<pitti> mdz: between -3 (that we have) and -8 are only bugfixes, can we merge this?
<mdz> pitti: do you have a specific reason to change it so close to release?
<pitti> mdz: no, not a particular one
<mdz> pitti: at this late stage I prefer not to change things unless we have a good reason
<pitti> mdz: okay, fine for me :-)
<Play_> http://www.playzero.com
<Play_> http://www.playzero.com
<dilinger> pitti: hey, what is this vfs-f-maxcount patch that was added to warty's kernel in 16.11?
* sabmoc wonders when the really slick desktop rendering is finally going to be ready.
* infinity -> home.
<mdz> Keybuk: you sound like an arch developer -- that version is *weeks* old, it's worthless!
<Keybuk> mdz: version?
<mdz> Keybuk: 7995
<Keybuk> heh; no, I just said what you said, we opted not to take the patch
<Keybuk> afaik, of every libtool-using source in existance, it only affects gnome-vfs2 at the moment
<Keybuk> so if we're not re-libtoolizing that, it's not worth taking
<mdz> night all
<pitti> night mdz
<pitti> sleep well
<pitti> doko: ooo 1.1.3-8ubuntu1 bibliography db still crashes on ppc
* jdub wonders how horrific an rsync against the linux magazine dvd would be ;)
<dholbach> gooood morning
<jdub> pants off dholbach 
<pitti> Hi dholbach 
* ogra yawns
<Treenaks> good morning all
<dholbach> jdub: they are off! wooohoooo! spring is in the air!
<ogra> morning
<dholbach> hey ogra
<pitti> Moin ogra
<jdub> heh
<jdub> raining here :)
<Treenaks> nice, sunny spring weather here :)
<dholbach> morning jani
* dholbach hands Treenaks, ogra, jdub, jani and pitti a mug of coffee
* pitti hates coffee
<ogra> thanks dholbach 
<jani> morning, dholbach
* Treenaks sells te coffee and buys tea for the money he gets
* jani takes a swig froma bottle of plain water
* ogra trades the tea he has around against all the orphaned coffee
* dholbach sighs deeply
<jani> dholbach, I faxed the notary stuff to mako this morning
<jani> I might get to do an upload before hoary :)
<dholbach> jani: wow... that's sooooo coool :-)
<Seveas> mjg59, ping?
<ogra> fabbione, ping
<fabbione> ogra: pong
<jani> elmo ping
* fabbione waits for ogra.....
<Mithrandir> fabbione: did you find my fleece neck?
<fabbione> Mithrandir: there was nothing in the car :(
<Mithrandir> fabbione: it's probably lying around here somewhere, then. :/
<Mithrandir> I'll see if I can find it
<fabbione> Mithrandir: i will check again, but i doubt it's there
<Mithrandir> it's not a big deal, it's just a fleece neck
<fabbione> still annoying
<jani> ?
<ogra> ahh, the world gets into shape again
<zyga> not really :/
<pitti> welcome back, world
<zyga> just the ngettext part
<ogra> hey pitti :)
<Amaranth> stupid netsplits
<Amaranth> I was all alone! :/
<Burgundavia> BBC says --> Rise of the zombies threatens UK 
<zyga> what's stat64 needed for?
<zyga> to check for .mo files?
<pitti> zyga: we have to stat the files in locale and locale-langpack to compare timestamps
<pitti> zyga: if a file is present in both dirs, we want to take the newer one
* ogra comforts Amaranth 
<Amaranth> ogra: I don't need comfort, I need a PyXDG hacker. :)
<zyga> hmm
<ogra> heh
<siddharthk> what is PyXDG 
<zyga> pitti: when do you have to do that?
<Amaranth> siddharthk: python module that implements various freedesktop.org specifications
<ogra> siddharthk, xdg is the new menu spec for .desktop files
<zyga> pitti: once a mo file is open does it stay open or is it rechecked on every gettext call?
<pitti> zyga: up to the prelast libc version we had done it for every string lookup
<jdub> it's a hassle when you have a bunch of people and no way to work together
<pitti> zyga: it is rechecked
<sabmoc> jdub, yes
<zyga> pitti: what about some fam thing?
<pitti> zyga: not for libc
<sabmoc> jdub, Im pretty sure they have ideas and we just need a way to talk
<zyga> pitti: rechecking this is really bad idea :/
<Amaranth> I posted a reply to a macrumors thread defending PyMusique, I suspect I'll be torn to shreds.
<pitti> zyga: this is what the original libc6 does, but it uses cachign
<pitti> caching, even
<sabmoc> jdub, Im pretty happy about how well it is working
<pitti> zyga: I added caching in the latest version as well, but it is flawed
<zyga> hmm
<siddharthk> what kind of development is being done in pyXDG ?
<mkedwards> Amaranth: I possess a modest amount of python-fu; what needs doing?
<siddharthk> i have some python exposure.
<zyga> pitti: and libc got broken by caching only one domain?
<pitti> zyga: yeah, sort of
<zyga> cache = open mo && read all ?
<pitti> zyga: cache == store the result from a previous timestamp comparison
<zyga> ah
<pitti> zyga: btw, my current version looks promising
<zyga> btw: is this really needed - checking if mo has changed on every lookup?
<siddharthk> i just now downloaded pyXDG from http://freedesktop.org/Software/pyxdg
<zyga> it's not that those things change all the time
<pitti> zyga: it isn't done
<pitti> zyga: it's implemented as lazy initialization
<Amaranth> mkedwards: So do I, I just don't possess enough menu-spec-fu to know how to fix this. :P
<Amaranth> mkedwards: https://bugs.freedesktop.org/show_bug.cgi?id=2784
<zyga> 10:22 < pitti> zyga: I added caching in the latest version as well, but it is flawed
<zyga> hmm
<zyga> pitti: okay I need more insight into how that works exactly
<siddharthk> the README says, implementation of XDG-Base-Directory, XDG-Desktop, XDG-Menu, XDG-Icon-Theme standards. But http://www.freedesktop.org/standards/basedir-spec is not accessible.
<pitti> zyga: the mo lookup has had caching since ages
<pitti> zyga: my caching refers to the timestamp comparison
<Amaranth> siddharthk: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
<zyga> pitti: can I see your tree somehow?
<pitti> zyga: download glibc sources, debian/patches/ubuntu-altlocaledir.dpatch
<pitti> zyga: I prepare a new dpatch soon, when I finished testing the new libc
<zyga> pitti: how is that different from apt-get source glibc ?
<pitti> zyga: that's what I meant
<zyga> :-)
<zyga> excelent :>
<zyga> I come from slackware background
<dholbach> hey mvo
<zyga> and apt-get is really nice ;] 
<pitti> zyga: oh, indeed :-)
<pitti> zyga: I came to Debian from SuSE in 1997, and I loved it
<zyga> I tried fedora for a while but it was sooo broken on amd64 that I decided to try debian again :)
<pitti> zyga: btw, the version you are currently downloading is the broken one
<zyga> ok just a simple question - all of the patches from debian/patches are already applied, right?
<pitti> zyga: it works great for single-domain apps (most console tools), but it breaks for gnome stuff
<pitti> zyga: no, they are applied at build-time
<pitti> zyga: debian/rules patch
<pitti> zyga: call that to generate the build tree and apply the patches
<zyga> pitti: hmm I think I need more help with the debian way... this will take some time 
<siddharthk> and how this pyXDG is used ? is it something like applying user desktop settings once he logs in ?
<pitti> zyga: glibc has a particularly difficult source packaging 
<pitti> zyga: almost all packages are way easier
<zyga> pitti: ./debian/rules made some stuff but I'm puzzled what exactly
<zyga> pitti: I don't see any ./configure or anything similar
<pitti> zyga: if you called it with patch, then it should have generated build-tree/glibc-2.3.2
<zyga> ah so that's how it works
<zyga> ./debian/rules ./debian/patches/foo.dpatch ?
<pitti> zyga: nope
<pitti> zyga: debian/rules patch
<pitti> zyga: glibc has a lot of homebrew build magic, I don't fully analyzed it myself
<jbailey> pitti: It's not that the packaging is difficult, it's that we've taken every hack that people usually think of for packaging and wound up using it in one package.
<pitti> jbailey: sure :-) I mean I had to actually look into rules.d/* to find out how to rebuild without cleaning, and unpack sources, etc.
<zyga> pitti: doesnt work (probably my fault)
<pitti> jbailey: btw, my new patch looks promising
<zyga> let's try it one more time...
<zyga> getting clean glibc sources...
<pitti> jbailey: another 30 minutes, and I shall have it ready
<pitti> zyga: "debclean"
<zyga> on my link apt-get source is faster ;] 
<pitti> zyga: okay, debian/rules patch might not work
<pitti> zyga: rm -r glibc-*
<pitti> zyga: dpkg-source -x glibc*.dsc
<jbailey> pitti: Nice!  I'll wind up hackign my glibc stuff a little later into the day than I tihnk I had planned for.  After I'm done looking at 1440 with Jordi, I think I need to go back to bed. =)
<jdub> sabmoc: cool
<sabmoc> :D
<sabmoc> needs some more work, but I like it
<zyga> pitti: extracting now... seems to work this time
<zyga> pitti: ok, still the same situation - glibc is packed and debian is full of flurry stuff that I don't know about
<zyga> trying README now
<pitti> zyga: maybe jbailey can tell you how to unpack and patch the sources without building it
<pitti> jbailey: what's the glibc way to do "debian/rules patch" (or apply-patches)?
<jbailey> pitti: "debian/rules patch" =)
<zyga> jbailey: from what pwd?
<pitti> jbailey: hmm, that seems to fail for zyga
<pitti> zyga: the source directory
<zyga> jbailey: I've tried that but it didn't to anything usefull
<jbailey> zyga: top of the source tree.
<jbailey> zyga: Paste me the output in a /msg?
<Burgundavia> amd64 users here?
<zyga> rechecking...
<zyga> ok
<zyga> Burgundavia: me
<Burgundavia> zyga: can confirm that you have libparted1.6-dev?
<pitti> Burgundavia: ogra, thom
<ogra> yup
<Burgundavia> pitti: thanks
<Burgundavia> hmm
<Burgundavia> damn qtparted bug
<siddharthk> amaranth, after browsing through the code, i see that, this module is acting as interface to .desktop files. am i right ?
<ogra> Burgundavia, dholbach too
<Amaranth> siddharthk: More or less.
<Burgundavia> ogra: he is walking dog currently
<zyga> Burgundavia: in a second
<jbailey> zyga: Oh, I see.  No I meant literally 'debian/rules patch'
<ogra> Burgundavia, ok
<jbailey> zyga: You can't apply only one patch, it needs to be listed in debian/patches/00list
<jbailey> zyga: The assumption is that all patches have to be done in the right order before files are patches multiple times.
<jbailey> s/before/because/
<zyga> jbailey: I see, so literally what do I need to do?
<Amaranth> hey seb128, think you could help me with another python-xdg issue? :)
<pitti> zyga: debian/rules patch
<zyga> ah
<zyga> :>
<pitti> zyga: as I said :-)
<zyga> hehe
<zyga> that was confusing ;] 
<zyga> ok this time it works great
<zyga> thanks alot
<zyga> Burgundavia: checking now
<siddharthk> Amaranth, may i know the issue ?
<zyga> Burgundavia: no I don't have it
<zyga> Burgundavia: can install though
<jdub> whiprush: i like the new hackergotchi spot on planet arslinux ;)
<Amaranth> siddharthk: https://bugs.freedesktop.org/show_bug.cgi?id=2784
<Burgundavia> zyga: ok, just checking
<Amaranth> siddharthk: you can see the bug in action at http://img166.exs.cx/img166/8287/16nq.jpg
<Burgundavia> zyga: can I provide with you a .dsc/.diff.gz to build and test install?
<zyga> Burgundavia: hmm as I'm really unexperienced regarding debian build you might need to help me a bit along the way, buy yes
<siddharthk> amaranth, ok let me see
<Burgundavia> zyga: lets move to #ubuntu-motu
<zyga> ok
<pitti> infinity: ping
* pitti heartily curses at the glibc upstreams...
<zyga> pitti: I'm with you -- reading intl sources now ;] 
<jdub> jbailey: still around?
<pitti> zyga: no, I'm currently discussing this issue with them, and they are very unfriendly
<pitti> zyga: they don't even read and understand the problem, they just say "you want to do this modification? you don't know about packaging and it's nonsense"
<siddharthk_> amaranth, i see some testcases in test dir,  we can add testcases validating against such bugs ?
<jbailey> jdub: Yup
<zyga> pitti: hey I didn't know about packaging but you managed to help me out ;-)
<mkedwards> Amaranth: OK, I've reproduced the bug ... python-fu going into action.
<Amaranth> mkedwards: hehe
<Amaranth> siddharthk_: Well, you could try...
<Amaranth> mkedwards: Do you have my menu editor?
<mkedwards> Amaranth: reproduced it using test-menu.py
<Amaranth> yeah, that works too :)
<siddharthk_> let me see
<seb128> Amaranth: ?
<Amaranth> seb128: https://bugs.freedesktop.org/show_bug.cgi?id=2784
* zyga is amazed by intl on not-so-popular-endian-cpus
<zyga> BTW: glibc could use some doxygen syntax :/
<seb128> Amaranth: do you have the issue with gnome-menu-spec-test too ?
<Amaranth> seb128: It doesn't show up in the menus, let me check with that.
<jbailey> zyga: I think glibc is pretty much intended to be unfriendly.  There's alot of magic in there and the upstream maintainers are not known for being kind to new people.
<zyga> pbuilder create --distribution hoary
<pitti> jbailey: hah, I'm just experiencing this
<zyga> hmm... sorry
<pitti> jbailey: I asked them about this issue, and I was only insulted and threatened
<Amaranth> seb128: Not that I can see.
<Amaranth> seb128: Removing from 0x80c2c40 entry gnome-btdownload.desktop
<jbailey> pitti: Yeah, it's pretty standard.  You need asbestos underwear to hang out on the libc mailing lists.
<Amaranth> seb128: That's close to the last thing that happens, like I would expect.
<jdub> jbailey: so, what do you think about moving to newer versions of NPTL in breezy?
<pitti> jbailey: I won't followup any more, that makes no sense
<pitti> jbailey: I rather ask Denis Barbier, he seems to be very nice and actually understand the gettext code
<jbailey> jdub: mdz's already agreed to it. =)
<jdub> aha, great :)
<jbailey> jdub: I want to sync up with gotom on my idea of making the NPTL stuff a hard default, rather than relying on the tls hwcap.  Applications that are still broken and can't cope will need a solution to use LinuxThreads, though.
<jbailey> jdub: But it would be really nice to actually use the NPTL header files.
<doko> jbailey: nptl on powerpc is broken, isn't it?
<seb128> pitti: WTF with g-c-m ? :) debian/patches/ui_browse_ctl.patch 865K ... ?
<pitti> seb128: that's the result of update-po
<seb128> but why doing that ?
<pitti> seb128: sivang said that he did exactly like you suggested
<jbailey> doko: Do you mean upstream?  I thought I'd seen a number of success reports.
<seb128> and why in is patch and not in a translation patch ?
<pitti> seb128: because he had to add some strings
<seb128> pitti: no way
<jbailey> doko: But tht that type of thing could be tweaked per-arch if it really needed to be.
<seb128> and ?
<Kamion> jbailey: sounds strange; what's the value in making it a hard default?
<jbailey> doko: It's nice like we're consistant now.
<pitti> seb128: the Hebrew/German translations are in separate patches
<seb128> I said "diff -u po/nn.po.orig po/nn.po >> debian/patches/translations"
<Kamion> jbailey: oh, the header files, I see
<seb128> yeah, I know
<seb128> and this patch is enough, isn't it ?
<jbailey> Kamion: Upstream doesn't like the code that allows the linker to support switching between both.  They're of the opinion that you should use only the ld.so that was built with the matching thread library.  It shows up subtle problems from time to time.
<seb128> what's the point to include 800k of po changes in a ui patch ?
<jbailey> Kamion: But yeah, that and the header files that are actually getting development, etc...
<seb128> pitti: I'm dropping that if you don't mind, the po changes are enough
<pitti> seb128: I don't know, I relied on the fact that sivang and you discussed how to do it
<Kamion> jbailey: sounds like the sort of thing we ought to be coordinating with Fedora etc. ...
<pitti> seb128: sure, go ahead
<seb128> thanks
<pitti> seb128: but at least the POT changes should be somewhere
<Kamion> so people don't go insane switching from distro to distro trying to figure out what's going on with their threaded applications :)
<pitti> seb128: so that Rosetta users see the new strings
<seb128> pitti: no need to include 800K of po to include the new .pot :)
<pitti> seb128: sure :-) thanks for cleaning this up
<jbailey> Kamion: Right.  I'm more actively worried about someone doing a backport of some sort on an Ubuntu system and having a non-working deb get handed to someone on Debian.
<seb128> np
* pitti reboots, brb
<Kamion> jbailey: yeah, binary incompatibility there would be Badness
<jbailey> Kamion: In practice it shouldn't be a problem when everyone actually drops 2.4 support.  Breezy might be a release too soon.  After that I'm pretty sure every distro will have dropped it.
<zyga> pitti: cscope helps alot with glibc mess
* smurfix sends some curses in the general direction of his public utility company
<smurfix> Just after I replaced my mainboard because of its random power failures, I get random power failures from outside
<zyga> smurfix: get a random ups
<smurfix> zyga: My computer room already has one
<zyga> they're cheeper than random mobos
<smurfix> zyga: time to string a power cable to the office :-/
<zyga> smurfix: I've got one small ups for every home pc
<zyga> call me crazy...
<seb128> pitti: about the .pot files/rosetta, do we need to include them in the packages ? g-c-m has no .pot and it's not generated during the build
<Amaranth> seb128, mkedwards, siddharthk_: any ideas? :)
* zyga wonders why in glibc instead of 'foo' we get #define foo __foo; weak_alias (__foo, __real_foo_you_didn't_know_about);
<mkedwards> Amaranth: the author of pyxdg should be shot.
<mkedwards> Amaranth: actually, shooting is too good for him.
<mkedwards> he should be strangled, drowned, diced, and then shot.
<jbailey> zyga: Symbol versioning tricks.
<pitti> seb128: they should at least be generated during the package build
<pitti> seb128: without a pot, the Rosetta guys can't import the pacakge
<zyga> jbailey: hmm?
<Amaranth> mkedwards: heh heh heh
<jbailey> zyga: It also allows you to override the symbols in glibc with local versions.
<mkedwards> This code is unworthy of a Visual Basic programmer.
<seb128> pitti: we can upload the .pot by hand, right ?
<zyga> jbailey: tricky - almost smart really ;-)
<pitti> seb128: yes, but this gets tedious
<pitti> seb128: generating the pot file is not possible at build time?
<seb128> Amaranth: I've some other stuff to do than replying to 100 questions/days about how edit a menu
<Amaranth> seb128: sorry :/
<seb128> pitti: need to hack, I don't like that
<Amaranth> seb128: you seemed to be the only person that had any clue how this actually worked
<seb128> Amaranth: no need to be sorry but I'm busy
<seb128> Amaranth: I've read the spec ...
<seb128> that's all
<Amaranth> didn't seem to help me much :P
<zyga> #define FOO __foo
<seb128> read it again ? :)
<zyga> I guess they like indirection alot
<zyga> hmmm and k&r style too?
<Seveas> pitti, i saw your mails on libc-alpha, good luck trying to convince bone-headed drepper to be nice, i've been reading that list for some time noe and those guys simply cannot be polite. Too bad that such an important part of GNU/Linux is in the hands of these idiots
<zyga> pitti: ping?
<pitti> Seveas: I don't really mind the impoliteness, I rather mind that they don't even read 
<pitti> Seveas: somehow he insists that this is a packaging problem, but I already explained three times that this has got nothing to do with packaging
<pitti> zyga: pong :)
<Seveas> pitti, they're known not to read things, I have seen that behaviour very often, they seem to think they are gods
<zyga> pitti: did you grok the dcigettext madness?
<Seveas> especially that drepper guy, the others are definitely nicer people to talk to
<pitti> zyga: only as far as I am required to actually change it for our needs
<zyga> pitti: I'm wondering why they choose trees instead of hash lookups?
<pitti> zyga: hashes would be great, but doing them in C is somewhat clumsy
<zyga> pitti: strange, did them for ages and they're fine
<pitti> zyga: actually the whole thing should be rewritten in a clean way (with supporting several directories :-) ), but this is not something for me
<zyga> pitti: I guess I could (and would be willing to) do that but what are the chances this gets accepted?
<maswan> hey guys, is cdimage doing better today?
<pitti> zyga: upstream? Might become tricky :-)
<zyga> only one problem really -- i386 && amd64 are my only test platforms
<pitti> zyga: Debian/Ubuntu would certainly accept it if it's sane
<zyga> I just imagine this bearded guy with alpha telling me it's wrong ;] 
<pitti> zyga: in Debian and Ubuntu we have two handfuls more
<pitti> zyga: however, this shouldn't be overly platform dependent
* zyga found langpack changes
<zyga> well all those file locks and other mess seems ... not so neccesary
<zyga> unless we are racing with ever updating mo file ;] 
<pitti> zyga: well, the whole code is just a mess..
<zyga> (I understand the need for correctnes)
<zyga> how could I test this without changing my working libc?
<zyga> (alias magic experts please)
<pitti> zyga: use LD_LIBRARY_PATH
<zyga> hmm i thought about LD_PRELOAD 
<ogra> zyga, dont move it over ;)
<pitti> zyga: LD_LIBRARY_PATH=/home/foo/my-glibc my-program
<pitti> zyga: I think PRELOAD is wrong
<zyga> so there is no way to test gettext without rebuilding glibc every time?
<pitti> zyga: maybe it works, but LD_LIBRARY_PATH is better
<zyga> I'm used to LD_PRELOAD gettext trick
<zyga> and use it all the time
<pitti> zyga: oh, if it works, so much the better :-)
<zyga> libintl_preload
<pitti> zyga: if you can compile libintl separately, this is certainly much easier
<zyga> .so-mething like that
<jani> elmo ping
<mkedwards> Amaranth: the behavior of pyxdg is correct.
<mkedwards> Amaranth: that "Other" menu is getting exactly what it should.
* zyga loves .y files 
<Amaranth> mkedwards: ...
<Amaranth> mkedwards: Then GNOME and KDE are wrong.
<zyga> that is the biggest mess of them all :/
<mkedwards> Amaranth: When an application is excluded from the only set to which it otherwise belongs, the <Unallocated/> in the definition of Other picks it up.
<Amaranth> mkedwards: Entries in the user's application.menu should come after Other has picked up what it is supposed to.
<mkedwards> Amaranth: KDE, at least, has deliberately deviated from spec.  http://lists.freedesktop.org/archives/xdg/2004-December/005541.html
<zyga> (since /me didnt ever rebuild glibc and actually used it afterwards)
<zyga> should I add linuxthreads or not?
<jbailey> zyga: Just make sure that anything you do, you do it in a chroot.
<Amaranth> mkedwards: Well, at least I have a solution now. :)
<mjg59> Seveas: Hi
<Treenaks> jbailey: Real Men hack libc outside chroots :)
<sabmoc|zombie> heh
<zyga> ok
<jbailey> Treenaks: Right, and the ones install the hacks inside them. ;)
<jbailey> sane ones, that is.
* zyga rips gettext out of glibc
<zyga> I'll let others hack it back in if it's worthy anything
<mkedwards> Amaranth: clarified in spec:  http://lists.freedesktop.org/archives/xdg/2004-December/005593.html
<pitti> zyga: this is not for hoary, but if you can get this ready and sane for early breezy (the tree will open in about two weeks), that'd rock :-)
<zyga> pitti: I'm not counting on getting it into hoary really 
<Amaranth> mkedwards: Doesn't that mean PyXDG is wrong?
<zyga> If 2 people test this I'd be more than happy
<Seveas> mjg59, hi, I have an HP Compaq nc6000 laptop that works great with warty except that kacpid sometimes takes 100%cpu and the machine won't reboot (it stops at "disabling acpi"). I have been told that you were the guy to talkt to about this
<Seveas> mjg59, the odd thing is that there are no entries in dmesg or any other log
<Treenaks> Seveas: don't forget the /proc/acpi stuff hanging
<pitti> zyga: maybe you can write it in a way that it doesn't do the search and iteration process all over again for each message
<mkedwards> Amaranth: no, it means it's right.  In the gnome-btdownload example, it's included by the Internet rule in /etc/xdg/menus/applications.menu and then excluded in .config, so it's Unallocated.
<Seveas> and it happens when power.sh is run and tries to grep -q 'off-line' from the /proc/acpi/apdapter files
<ogra> Seveas, look in /var/log/acpid for traces, rather then in dmesg 
<Seveas> ogra, no traces there too
<Seveas> simply nothing
<mkedwards> Amaranth: the Other rule picks up applications that are Unallocated.
<Amaranth> and that last link says Excluded entries are still considered allocated
<jbailey> pitti: Hey, looking at your "Fixing USB after ppc resume" thread.  Would be be suitable to just do an /etc/init.d/hotplug reload on resume?  That way all you have to do is make sure that all the drivers for the usb subsystem are unloaded.
<mkedwards> Amaranth: spelled out in http://lists.freedesktop.org/archives/xdg/2004-December/005545.html
<Amaranth> Note that an entry that is included in a menu but excluded again by a later <Exclude> is still considered allocated
<jbailey> pitti: I suspect it's safer than memorising them and reloading them, since it's reasonable that a person might suspend, and then unplug their usb printer.
<pitti> jbailey: I think hotplug reload will last considerably longer
<pitti> jbailey: why "memorise"
<pitti> ?
<mkedwards> Amaranth: duh. You're right.
<pitti> jbailey: I both unload and load the USB host drivers after resuming
<jbailey> pitti: Is that enough?  Don't you have to unload all the modules that depend on those host drivers?
<pitti> jbailey: this should eventually look like "rmmod usb_uhci && modprobe usb_uhci"
<mkedwards> Amaranth: I was still thinking in terms of PyXDG's NotOnlyAllocated weirdness.
<pitti> jbailey: obviously nothing really depends on the host controller interface driver
<zyga> pitti: right now I'd like to make minimal reimplementation
<zyga> pitti: I'm reading mo format info
<zyga> pitti: then I'll ask you what should be needed 
<zyga> and well see
<pitti> zyga: the mo parsing can certainly be taken from the current code
<zyga> pitti: I'll probably do that as soon as I'm sure I understand everything in there
<jbailey> pitti: I do not find the Linux driver model to be incredibly obvious in many, many way.s =)
<pitti> jbailey: I didn't bother with this; it works for me, it works for other people, let's do it :-)
<zyga> pitti: pcc is other-endian, right?
<jbailey> pitti: But if usbcore doesn't flip out, then that's cool.
<pitti> zyga: other=big, yes
<pitti> jbailey: no, usbcore is fine
<zyga> pitti: I never remember which really - ok thanx
<pitti> jbailey: probably the E/O/UHCI driver just fleshes out the core
<mkedwards> Amaranth: change the else branch in Rule.do() to:
<mkedwards> elif entry.Add:
<mkedwards>     entry.Allocated = True
<mkedwards>     entry.Add = False
<mkedwards> Amaranth: that WFM
<Amaranth> mkedwards: Can you make a patch? :)
<mjg59> Seveas: Ok, that's not /too/ unusual. Any chance you could test it with Hoary?
<mjg59> There's been a huge amount of ACPI code fixed
<mkedwards> Amaranth: kind of a pain to get it to you, since I'm booted into livecd.
<Amaranth> ok
<Seveas> mjg59, thanks for the answer, I will try out hoary 
<mkedwards> Amaranth: xdg/Menu.py line 378.
<Amaranth> i'll finish the bug i'll working on in my menu editor then try it
<mkedwards> Amaranth: make sure to get the whitespace right.  :)
<siddharthk_> Amaranth:i can give you the patch file with the changes suggested by mkedwards
<Amaranth> siddharthk_: ok
<mkedwards> mjg59: who judges whether a two-line fix to https://bugs.freedesktop.org/show_bug.cgi?id=2784 goes into hoary's pyxdg?
<mjg59> mkedwards: No idea
<mkedwards> Amaranth: is there an Ubuntu bug for this?
<dholbach> mkedwards: upstream changes are the safest method
<Amaranth> mkedwards: nope, just a PyXDG one
<Amaranth> dholbach: No guarantee this will get patched upstream in time for hoary, which I was hoping for.
<dholbach> ah
<mkedwards> No debian bug either, no upload since October.
<mkedwards> Ubuntu has patched it, Matt Klose is the Ubuntu uploader.
<mkedwards> (patched the python-xdg package, not this particular bug)
<siddharthk_> Amaranth: how should i give you the patch file ? 
<mkedwards> Amaranth: I would probably open an Ubuntu bug, include the patch, let Matt decide whether to try to push it into hoary.
<Amaranth> siddharthk_: alleykat@gmail.com
<Amaranth> mkedwards: That's the plan. :)
<mkedwards> Amaranth: don't forget to file it with Debian as well, tag +patch, point to upstream's bug URL
<Amaranth> will do
* Amaranth beats things with a stick
<Amaranth> my brain doesn't want to figure out this category_map tuple anymore
<mkedwards> Amaranth: or maybe just attach the patch to upstream's bugzilla, point Ubuntu and Debian bugs both to it.  :)
<mkedwards> and include the URL for the fd.o exegesis (the clarification to the spec)
<siddharthk_> Amaranth: ok, i have sent the patch, please let me know if i have made some mistakes. This is my first time ... 
<mkedwards> siddharthk_: diff -naur, right?
<siddharthk_> mkedwards: not actually ... let me send that once again.  :(
<mkedwards> -ur is fine
<mkedwards> conventional thing is to cp -a the clean unpacked source tree to foo-0.0-orig, modify foo-0.9, then diff -Naur them
<mkedwards> resulting patch applies cleanly with patch -Np1
<siddharthk_> mkedwards: ok, got it. I am resending ...  Thanks.
<mkedwards> or you could svn import, modify, svn diff -- but that's overkill for a two-line patch.  :)
<siddharthk_> mkedwards: i am using -Naurw .. is it fine ?
<mkedwards> siddharthk_: you don't want -w as a general rule, especially with python.
<mkedwards> You don't really want to ignore re-indentation in a language where whitespace is significant.  :)
<siddharthk_> mkedwards: ok, i understand
<mkedwards> The -a, on the other hand, shouldn't matter (dpkg barfs on binary content in diff.gz)
<mkedwards> but it bypasses diff's "is it text" heuristic, which can sometimes be fooled by UTF-8
<Amaranth> siddharthk_: ok, i'm ready :)
<Amaranth> siddharthk_: did you send the new version? :)
<siddharthk_> Amaranth: yes, just now.
<siddharthk_> Amaranth: it is using -Naru
<siddharthk_> Amaranth: if you see that diff file, the last 'else' clause is not showing up with proper indent, though it is correctly indented in the .py file i modified.
<ogra> fabbione, did you get my answer before the netsplit ?
<fabbione> ogra: i didn't even get the question...
<siddharthk_> mkedwards: should i use spaces or tabs ?
<mkedwards> siddharthk_: I tend to just copy the adjacent line so that I get the exact same mix of spaces and tabs.
<mkedwards> Or edit it in IDLE or python-mode.
<thom> seb128: is the "imap4rev1" account type in evo actually ready to use? it seems hugely broken here
<seb128> no
<seb128> they have switched back the default to imap for a reason :p
<torkel> thom: I'm using it and it works most of the time, but the other one is the preferred one...
* zyga wonders how many languages are there
<zyga> ok here's the idea:
<zyga> strip as much as possible from intl :-)
<thom> seb128: it's totally non obvious from the new account setup - i have an imap4 account, i choose imap4
<zyga> biggest mess to go is plural form stuff
<zyga> if the equations could be pre-calculated (cough, because they don't change really, cough)
<zyga> stuff would be faster
<zyga> no parsing - no mess
<ogra> fabbione, sec. phone...
<siddharthk_> mkedwards: ok thanks, i have already sent the modified file to Amaranth
<mkedwards> siddharthk_: thanks!
<pitti> seb128: can I give you #7999?
<Amaranth> siddharthk_: i fixed the patch you sent me
<pitti> seb128: ("nautilus wants to execute all files on a vfat flash drive"
<siddharthk_> Amaranth: ohh .. what was missing ?
<zyga> first step could be to get all the expressions from info gettext "Plural forms"
<Amaranth> spacing was wrong
<seb128> pitti: sure
<seb128> pitti: that's probably a gnomevfs issue, for sure not a pmount one
<zyga> then perhaps set up ugly parsing and fall back when unknown expression is there 
<pitti> seb128: reassigned, thanks
<seb128> pitti: hum. Should the lsb-base depends be versionned ? Just looking on hal as an example you have versionned it
<zyga> what do you guys think?
<pitti> seb128: yes, earlier versions didn't support all the script functions we are using
<thom> seb128: yeah
<seb128> k, thanks
<siddharthk_> Amaranth: yes, i realised that, and sent you the 3rd file. Thanks for bearing with me ...
<Amaranth> siddharthk_: oh, sorry
<Amaranth> i editted it right away then went to get breakfest going
<Amaranth> err, breakfast
<Amaranth> works great!
<siddharthk_> Amaranth, mkedwards: This was my *first* direct interaction with people from ubuntu community. This was great .. the whole bug solving thing. I am happy .. :)
<mkedwards> siddharthk_: kinda fun, innit?  :)
<Amaranth> Now the hard part. :)
<siddharthk_> mkedwards: yes .. true
<siddharthk_> Amaranth: whats that ?
<Amaranth> getting it into debian and ubuntu :P
<mkedwards> Amaranth: and upstream, of course.  :)
<Amaranth> https://bugs.freedesktop.org/show_bug.cgi?id=2784
<Amaranth> done there
<siddharthk_> mkedwards, Amaranth: when we will start with next bug ?  :)
<pitti> elmo: please remove the following source packages from the archive: mozilla-firefox-locale-{de,es-ar,es-es,pl,pt-br}
<Amaranth> siddharthk_: I'm done patching bugs for now. :P
<Amaranth> siddharthk_: Have fun hitting up bugzilla though. :)
<mkedwards> Amaranth or siddharthk_ : please reference http://lists.freedesktop.org/archives/xdg/2004-December/005571.html in a comment to the upstream bug.
<dholbach> elmo: could you please sync  openscenegraph  xli  phpbb2  from sid?
<mkedwards> Makes it clear to upstream where we got the interpretation that led us to change pyxdg's behavior.
<pitti> elmo: (they are obsoleted by the new version of m-firefox-locale-all=
<pitti> elmo: s/=/)/
<Amaranth> mkedwards: Not relevant...
<dholbach> did i miss something? when did CC meeting get re-scheduled?
<Amaranth> mkedwards: I think you meant http://lists.freedesktop.org/archives/xdg/2004-December/005593.html
<dholbach> 16 -> 22 utc
<mkedwards> Amaranth: yes, that's better.
<siddharthk_> Amaranth: yes.
<dholbach> ah ... i see "as decided 14 days ago."
<Amaranth> https://bugzilla.ubuntu.com/show_bug.cgi?id=8055
* Amaranth spams this bug around a bit
<siddharthk_> Amaranth: can i open a bugzilla account ? is it needed ?
<Amaranth> I think seb128 is listed as the package maintainer.
<Amaranth> siddharthk: You can. You'll need to do post to bugzilla.
<Amaranth> to post comments, attachments, new bugs, etc
<siddharthk> Amaranth: ok
<seb128> Amaranth: you should describe what the patch does and why
<Amaranth> oh, i did upstream
<Amaranth> i'll do it in ubuntu too
<seb128> no you didn't
<seb128> I've read both bug
<Amaranth> i guess it is a little vague :P
<seb128> totally
<seb128> "This patch makes <Exclude>ed entries that were included earlier stay allocated
<seb128> as the spec says."
<seb128> you should add a comment about how you determine that and what you change
<seb128> and point to the spec
<Amaranth> mkedwards: You wanna fill that in for me? :)
* thom really hopes he's fixed the ia64 firefox crasher, because it takes *forever* to build
<Amaranth> mkedwards: ?
<Amaranth> seb128: Actually, I just know what I've been told it does. :/
<Amaranth> seb128: I ran it through a couple tests.
<mkedwards> seb128, Amaranth : really must go to bed now, but http://lists.freedesktop.org/archives/xdg/2004-December/005545.html explains why this test case should not be matched by the <Unallocated/> rule that creates the "Other" menu in /etc/xdg/application.menus.
<Amaranth> yes, but what does the patch _do_?
<Amaranth> and why?
<mkedwards> If a previous <Include> pattern matched the menu entry, then it set entry.Add to True.  So the correct behavior for <Exclude>, if it finds entry.Add to be True, is to set it to False but to remember that it was allocated along the way.
* Amaranth pastes that into the bug
<mkedwards> Previously, the only way Allocated could get set was on insertion of the entry into a menu.  This adds a second code path by which Allocated gets set: Include followed by Exclude.
<Amaranth> seb128: https://bugs.freedesktop.org/show_bug.cgi?id=2784 <--updated
<seb128> Amaranth: k, thanks
<Amaranth> shit, wait!
<Amaranth> that one is broken :P
<mkedwards> seb128: recommend you exercise the bug reporter's test case using /usr/share/doc/python-xdg/examples/test-menu.py
<seb128> ?
<Amaranth> siddharthk: i should have stayed with mine, your latest is borked
<seb128> mkedwards: k, thanks
<siddharthk> Amaranth: oops ... :(
<mkedwards> you'll see that the Other menu goes away when the patch is applied.
<Amaranth> seb128: ok, the original patch the one to use
<mkedwards> Truly unmatched items will still go in Unallocated.
* Amaranth will remember to test patches from siddharthk next time :P
<mjg59> thom: Sorry to keep nagging, but had a chance to take a look at the gdm-signal stuff? (It's getting a bit urgent)
<seb128> mkedwards: right, I've understood, thanks for the explanations
<mkedwards> Amaranth: not easy to keep the spaces straight if you're not experienced with python and patch.
<mkedwards> g'night, all.  Try to make it clear to the Debian maintainer too.  :)
<Amaranth> seb128: the first patch is the one i tested
<Amaranth> i thought siddharthk tested the one he gave me :P
<seb128> pitti: known about /usr/share/gnome-volume-manager/gnome-volume-manager-gthumb.sh (#7725) ?
<siddharthk> Amaranth: ohh ... really sorry for that .. but is it related to spaces and tabs ?
<Amaranth> yeah
<Amaranth> fuck, found a regression, i think
<seb128> I'll wait before using the patch I think 
<thom> pitti: is there a CAN for 6319
<Amaranth> the original authors of this junk mixed tabs and spaces
<Amaranth> so i have to compensate
<Amaranth> not mkedwards and siddharthk, the authors of pyxdg
<mkedwards> seb128: replaces one line with two.  Just have to get the indentation right.
<thom> mjg59: noted, sorry i've not done it yet
<mjg59> seb128: Have you done anything with #7583?
<mjg59> thom: Ok, no problem
<mjg59> I'd just prefer to be able to build ISOs without needing my own hacked packages :)
<zyga> pitti: ping
<seb128> mjg59: nop, waiting to get gdm-signal in the archive
<mjg59> seb128: Would it be possible to do it preemptively? :)
<seb128> sure, I'll update
<mjg59> At the moment, the shortcut does nothing (apm will return 0, so it won't move onto the next option, but running apm with no options results in it just printing the battery status to stdout)
<seb128> k
<mjg59> Thanks!
<seb128> np
<Amaranth> seb128: Ok, I've done a half-dozen different little tests, PyXDG now matches GNOME and the spec in this area.
<Amaranth> making a new patch
<ogra> fabbione, re, the question was...please add #ubuntu-motu to your weblogger :)
<fabbione> ogra: ok.. just in a sec
<siddharthk> hmm. i am waiting to see that.
<ogra> fabbione, wow, great :)
<fabbione> ogra: done... logs on the web will start to appear in 30/60 minutes
<ogra> fabbione, great, thanks, thats perfect timing ( in an hour we start the malone test that should get logged)
<fabbione> ogra: remeber that it is still an IRC network
<ogra> fabbione, oops, sorry 2h
<ogra> fabbione, sure ;)
<fabbione> ogra: so if there is a netsplit the client can be anywhere
<fabbione> ogra: ok.. just a reminder :)
<ogra> yep, i know....
<ogra> :)
<fabbione> you do.. somebody did complain about incomplete logs..
<fabbione> have fun
<ogra> fabbione, surely it wasnt me who complained..... (i wouldnt argue with the master of pain) ;)
<dholbach> elmo: could you please sync  xplc  from sid as well?
<fabbione> ogra: ehehhe
<Amaranth> seb128: Ok, lots of testing on this one. Seems to work fine. https://bugs.freedesktop.org/show_bug.cgi?id=2784
<seb128> k
<thom> seb128: for gdm-signal, you'll need to dep on powermanagement-interface version 0.3
<seb128> thom: I've uploaded a patched version 
<seb128> thom: I'll change that in the next upload
<Amaranth> perfect
<Amaranth> :P
<Amaranth> seb128: I have an excuse for not understanding the spec now. The implementations are all different! :D
<seb128> Amaranth: are you sure than your patch is not reversed ?
<seb128> grrrr, it is
<Amaranth> oh jeez
<Amaranth> *facepalm*
<Amaranth> sorry
<seb128> np
<seb128> upstream will start wondering why you flood them
<Amaranth> I haven't made patches in like 18 months. :P
<seb128> you should work, try the patch, etc before sending a new version every 5 min
<Amaranth> yeah
<zul> hey
<dholbach> hey zul 
<Amaranth> didn't go to bed last night, wanted to get this fixed first
<seb128> hi
<Amaranth> i blame that :P
<zul> hey dholbach 
<dholbach> zul: what about the kernel-non-installable-packages? :-)
<zul> dholbach: whoops..totally forgot about it
<zul> ill have a look at it today
<Amaranth> seb128: I promise to get a clue first next time. ;)
<dholbach> zul: that'd be cool because we want to discuss the proceedings of the packages on  wiki/MorgueCandidates  tonight
<dholbach> (after the CC meeting)
<zul> k
<dholbach> zul: but don't worry
<seb128> Amaranth: don't worry :)
<seb128> Amaranth: there for upstream, some of them don't like to be mail flooded 
<zul> dholbach: i think we might need to keep most of them because if something doesnt work with them 2.6.10 they can always fall back to 2.6.8
<Amaranth> yeah, i can understand that
<Amaranth> i've been flooding myself too :/
<dholbach> zul: that's completely fine with me, the packages should just be installable
<zul> dholbach: k
<zul> i guess i can see why they arent installable ;)
<dholbach> zul: gooooood :-)
<dholbach> seb128: could it be  libmrproject  was superseded by  planner  and now is completely useless and doesn't deserve to be fixed?
<jdub> dholbach: yes
<jdub> dholbach: 100% correct
<seb128> dholbach: correct
<jdub> dholbach: it should be purged
<seb128> damned jdub 
<seb128> too quick :p
<dholbach> woohoo! Clean! UNIVERSE! today!
<ogra> hehe
<seb128> hey jdub :)
<tseng> dholbach: <3
<dholbach> tseng: could you please elaborate on "<3"? :-)
<jdub> morning slow128 ;)
* seb128 slaps jdub 
<haggai> how is network configuration supposed to be done on the live CD?  I inserted a wlan card but the interface didn't come up
<thom> mjg59: Uploading via ftp powermanagement-interface_0.3_source.changes: done. enjoy
<dholbach> what's wrong with the powerpc-buildd? its last build was  workrave_1.6.2-1ubuntu1_20050322-1106-powerpc-failed 
<ogra> dholbach, the same as yesterday ?
<jani> ping elmo
<haggai> jdub: am I right in thinking that you get storage media eg USB stick icons to pop up on the desktop on gnome?
<ogra> dholbach, main<->universe transition of some build dependencys ?
<zyga> hmm
<zyga> gettext should be thread safe, right/
<haggai> jdub: its turned off in KDE by default and I'm wondering if it is better to turn on too.
<mjg59> thom: Rocking
<jdub> haggai: yeah, we do
<haggai> jdub: so what was your reasoning to do those but nothing else on the desktop?
<dholbach> ogra: but it should continue building :-)
<jdub> haggai: atm, we have removeable drives and network drives on the desktop
<dholbach> ogra: even if one package fails :-)
<jdub> haggai: we didn't have a good, obvious interface for unmounting, etc.
<jdub> haggai: now we have a modified drivemount applet, but it's not idea
<jdub> l
<ogra> dholbach, might take some time....
<haggai> jdub: hmm, we have the media:/ view where you can unmount, but you reach it via konqueror -> removable storage.  Is that too many clicks away?
<jdub> haggai: your call, dude :-)
<jdub> haggai: for reference, we have the Computer view, too
<jdub> haggai: felt it was better to have something obvious
<jdub> i hate storage and filesystems
<jdub> messy stupid crap
<haggai> jdub: bah :)  I wanted a sound reason that I could just use :)
<jdub> BURN IT ALL!
<jdub> haggai: well, you've pretty much given the reason for why we did it ;)
<haggai> jdub: ok, I'll take it back to the others then
<haggai> jdub: while we're talking desktop stuff: OOo print admin tool.  I see you advocated removing the icon completely
<Kamion> looks like today is the day I upload the ENTIRE INSTALLER
<jdub> you should *so* not use me as a reference for kde usability dude
<jdub> haggai: yeah
<haggai> jdub: heh
<jdub> haggai: what's your call on that?
<jdub> haggai: i realised immediately afterward that we really need to work together on those calls
<haggai> jdub: so you consider command line stuff to be ok now?  That's the only way to access additional printer/fax filtering stuff
<jdub> haggai: we have gnome-cups-manager
<jdub> which doesn't necessarily cover the weird OOo things
<haggai> jdub: right, but oopadmin doesn't duplicate that anyway (add a printer is disabled on CUPS systems)
<ogra> hmm, funny, my alt-tab recently only shows the two panels and the desktop....
<haggai> jdub: so, you have: font replacement per printer, add a pdf converter and fax device.  Are those already covered elsewhere?
<jdub> ogra: that's usually ctrl-alt-tab
<ogra> ah, switching to tty1 logging in and switching back solves it....weird
<dholbach> jdub: wow... didnt know that one
<ogra> jdub, i have a lot of porbs with this laptop wrt keyboard stuff....
<jdub> haggai: how important is "add a pdf converter"?
<jdub> dholbach: a11y feature :)
<dholbach> wooooooooow :-)
<haggai> jdub: its important if you need very high quality stuff that OOo's PDF output isn't good enough for
<ogra> jdub, so my laptop is more accessible then wanted :-P
<jdub> haggai: ok, niche use case.
<jdub> haggai: font replacement per printer seems niche.
<haggai> jdub: about those icons, I wondered about adding the generic OOo icon (from which you can do new document or open any OOo doctype), and bin the less used doc type icons (drawing, math, writer/web)
<wasabi_> morning
<haggai> jdub: so a niche use = command line?
<ogra> jdub, have such problems twice a week....seems like my meta key is stuck, or ctrl or something else...changes everytime a bit...
<jdub> haggai: fax is interesting, but requires input of command line, etc. we should integrate that with cups better. in the mean time, don't mind losing the weird feature.
<haggai> jdub: can we not collect nice cases in a gui point somewhere?
<ogra> jdub, (its a new keyboard, so i doubt its a HW issue)
<haggai> uh niche caches not nice
<jdub> haggai: niche use case doesn't immediately relegate it to command line, but looking at this particular case, i think we can do without
<jdub> haggai: the good thing is, you can still get to it if you have specific needs
<haggai> jdub: righty.  And the doc type reduction?
<jdub> yeah, i agree
<jdub> that's a good solution
<jdub> so we'd have
<wasabi_> so yesterday i had mdz move a binary package from multiverse to universe. he said it would be moved in the next pulse. Am I guessing right that I need to reupload?
<wasabi_> (since it is not yet moved)
<jdub> presentation, word processor, spreadsheet, 'new document'
<jdub> ?
<haggai> jdub: s/'new document'/openoffice.org/
<haggai> jdub: since you have to choose File->New
<jdub> isn't there some 'new document' window you can open up?
<jdub> there used to be an icon for it
<jdub> i'm sure
<jdub> oh
<jdub> from template one
<jdub> yeah
* haggai looks at that
<jdub> we could rename that to "New OpenOffice.org Document"
<pitti> infinity: ping
<haggai> checking it allows all functionality
<jdub> business cards!
<jdub> labels!
<jdub> templates!
<zyga> pitti: gettext should be thread safe?
<jdub> this is exciting!
<haggai> heh yeah even more stuff OOo didn't even make menu entries for
<dholbach> thanks elmo 
<pitti> zyga: erm, isn't this read-only?
<jdub> doesn't do gnome-vfs though
<pitti> zyga: or you mean internal data structures?
<haggai> there's a bug somewhere in the packaging
<zyga> pitti: yup but internal goo is not
<pitti> zyga: I think so
<zyga> pitti: well since it probably has too...
<jdub> whoa
<jdub> haggai: why is -gnomevfs in universe?
<haggai> jdub: it doesn't work atm
<jdub> oh
<haggai> jdub: yeah new document looks good
<jdub> so we lose drawing and math
<ogra> ****** ok guys, everybody who wants to attend the malone test, please join #ubuntu-motu we start at 14:00 UTC ******
<jdub> ****** woohoo! *******
<haggai> jdub: and printer admin, and writer/web
<jdub> yeah
<jdub> though printer admin was already lost in another menu
<ogra> **** malone test starts NOW in #ubuntu-motu ****
<Loevborg> (btw: writer/web should be renamed to "web editor" or something)
<doko> jdub, haggai: are you sure that you want to rename OOo menu items that short before the release? what about the translations needed for other languages?
<doko> jdub: openoffice.org-evolution and openoffice.org-kde should go back to main/desktop
<haggai> doko: hmm, ok.  We can still remove the extras though
<mako> jani: got it dude :)
<mantiena> Kamion, hi
<Kamion> mantiena: hi
<jani> mako cool
<dholbach> is anyone aware of the powerpc-buildd hanging somehow?
<mantiena> Kamion, in casper udeb TODO I found this info: "- Mount hard disk partitions - os-prober"
<mantiena> Kamion, who will do this job ? you or mdz ?
<Kamion> mantiena: I have no idea
<mantiena> ;)
<mantiena> Kamion, you aren't os-prober maintainer ?
<fabbione> pitti: are you around?
<pitti> fabbione: yeah
<Kamion> mantiena: one of them, upstream
<fabbione> pitti: any ETA for #8020?
<Kamion> mantiena: I'm not sure how that's especially relevant though; os-prober shouldn't need any changes for that TODO item
<pitti> fabbione: as soon as I reach infinity
<fabbione> ok
<pitti> fabbione: I can also upload it on my own, but I'd like to talk to him first
<pitti> fabbione: probably he is asleep, though
<fabbione> ok thanks
<mantiena> Kamion, os-prober can write partitions, available on user's system, into /etc/fstab ?
<Kamion> mantiena: no; please read the os-prober documentation
<mantiena> Kamion, I've read already
<Kamion> mantiena: then I do not understand why you asked the question above
<mantiena> Kamion, because you told, that os-prober shouldn't need any changes for that TODO item ;)
<Kamion> mantiena: that statement holds
<Kamion> mantiena: other components are supposed to *use* os-prober to do things like messing with /etc/fstab
<Kamion> mantiena: os-prober simply produces output
<Kamion> mantiena: this should be quite clear from its documentation
<mantiena> Kamion, ok, I understand this
<Kamion> mantiena: have a look at the way os-prober is used throughout the installer; yaboot-installer/debian/postinst is a reasonable example
<mantiena> Kamion, ok, it seems in os-prober's output there are missing partitions without os, for example fat32 partition with pictures, right ?
<Kamion> that's true
<Kamion> I'm not sure whether that would be better off in os-prober or in casper
<Kamion> or somewhere else
<Kamion> I suspect not os-prober; that's not really its task
<mantiena> Kamion, I think ubuntu installer should also do this job somewhere
<Kamion> sure
<mantiena> because if user installs ubuntu on system, which already has some partition[s] , then user would very happy if he can access these partitions from newly installed ubuntu system ;)
<Kamion> yes, I've read the bug reports about that
<Kamion> you don't need to persuade me of its usefulness
<mantiena> ;)
<Kamion> I dunno, maybe some component a bit like os-prober that output something in a similar format about data partitions
<mantiena> Kamion, it seems there are no filesystem type in os-prober output, right ?
<Kamion> nope
<Kamion> I wasn't the one who wrote that TODO item :) os-prober is probably just something to look to for ideas, not the Right Thing To Use
<mantiena> it seems so
<mantiena> in any case it's not casper's job, because ubuntu-installer (and debian-installer too) needs same thing
<Kamion> it is extremely difficult to get casper to use bits of partman, and I don't think that would be very sensible
<Kamion> I don't really mind there being a bit of code duplication here, as long as the bulk of it is common
<mantiena> Kamion, partman already does this job ?
<Kamion> casper will still have to be responsible for starting it off
<Kamion> mantiena: no, but whatever would do this in the installer would have to be called from partman
<mantiena> Kamion, maybe new d-i module, named for example partition-finder should be created for this ?
<Kamion> mantiena: it would be sanest to have something that spits out easy-to-parse output in a similar way to os-prober, and have casper and partman both use it to add to /etc/fstab as needed
<Kamion> the file format of /etc/fstab is probably not suitable in itself, because casper would want to mount filesystems immediately while partman probably wouldn't
<mantiena> Kamion, I think it both cases (partman and casper) found partitions should be writen to /etc/fstab, casper could just run "mount -a" after fstab is filled with found partitions
<mantiena> s/it/in
<Kamion> mantiena: the way partman works, that probably wouldn't be appropriate
<Kamion> mantiena: you would want the partitions to be selected to be mounted in particular places by default, but the user must be able to override that when doing manual partitioning
<Kamion> you can't just dump them into /etc/fstab and say "ha, screw you hippy, I don't care if you didn't want those mounted" :)
<mantiena> Kamion, I understand this
<Kamion> so fstab output format wouldn't be appropriate
<pitti> who can add tags in bugzilla?
* pitti wants to have "security" and "utopia"
<mantiena> Kamion, maybe you know if automatic finding partitions is planned in hoary or it will be done in hoary+1 ?
<Kamion> mantiena: seems unlikely that new features like that will make hoary
<Kamion> mantiena: it is ONE WEEK until our release candidate :)
<dholbach> pitti: add easytofix as well, for ubuntu-love--days
<Kamion> pitti: mdz or jdub, I think
<pitti> Kamion: okay, thx
<mantiena> Kamion, so, it seems I need to write this component by myself, because I need it this month ;)
<Kamion> mantiena: you're certainly the person pushing for it most
<mantiena> it's not a problem to write this component for me, I just don't want do duplicate my work if someone other from ubuntu developers is coding the same thing ;)
<fabbione> pitti: ping?
<Kamion> elmo: please sync partman-partitioning 33 from Debian; translation fixes only
<Kamion> mantiena: as far as I know nobody is currently working on it
<pitti> fabbione: pong
<mantiena> Kamion, I can start to write this component today and it would be nice if ubuntu developers would accept my work ;)
<DarthFrog_> What IRC channel is the Community Council meeting in?
<zul> #ubuntu-meeting
<DarthFrog_> Tnx
<zul> no probs
<mantiena> Kamion, what things (consultation, documentation) I should do if I want to make component, which will be ok for ubuntu ?
<thom> weee, just worked out #7711; now to work out why it's happening and how to fix it
<mantiena> Kamion, should I write specifications of partition-finder into ubuntu wiki ?
<Kamion> mantiena: sure, anything but IRC
<Kamion> mail, whatever
<Kamion> I'm not convinced about the name "partition-finder", it doesn't really say what it does
<Kamion> but whatever
<Kamion> mantiena: since it's post-hoary there's plenty of time
<mantiena> Kamion, it's plenty of time for you, but not for my project this component should work in 5 days ;)
<Kamion> mantiena: sure, so you don't have to make it be the final design; but we have plenty of time to make it non-hackish
<Mitario> brb, trying kubuntu
<Kamion> 5 days? don't see why you're even talking to us in that case, rather than getting coding :)
<mantiena> Kamion, because I wanna write good software, not evil hack :)
<Kamion> yeah, but we're all ultra-busy with bug fixing for release
<Kamion> so right now we aren't the best people to come to for design discussions :)
* Kamion has done 37 uploads today, if that's any guide
* fabbione has done that will root all your boxes
<mantiena> Kamion, ok, it seems you alredy told be main design ideas, I just write these to ubuntu wiki and show them to mdz (if he will be not too busy to see these ;)
<mantiena> s/be/me
<Kamion> mantiena: ok
<Kamion> elmo: please sync floppy-retriever 1.05 from Debian; translation fixes only
<dholbach> see you later
<mdz> wasabi_: no, you do not need to upload
<pitti> Hi mdz 
<mdz> mantiena: I am already planning to write it, but in any case it will not go into Hoary (only Breezy)
<ogra> mako pong
<pitti> mdz: can you add bugzilla tags? ("security" and "utopia" would be nice)
<ogra> hi mdz
<mako> ogra: hey ddue :)
<ogra> :)
<mdz> pitti: keywords?
<pitti> mdz: erm, yes
<pitti> mdz: they correspond to debbugs tags somehow
<fabbione> hey mdz
<mdz> pitti: what would be the description for utopia?
<pitti> mdz: "Bugs that affect the automatic handling of removeable media"
<pitti> mdz: i. e. g-v-m, hal, gnome-vfs, maybe inotify, etc.
<pitti> mdz: we can also call it "hotplug"
<pitti> mdz: but that's somewhat overloaded
<mantiena> mdz, maybe you already has the specifications ?
<seb128> mdz: a "translations" would be nice too
<mdz> mantiena: no, I will write the specification in Sydney in April
<seb128> or i18n
<pitti> seb128: l10n, rather
<seb128> right
<mdz> security and translation added
<seb128> thanks
<wasabi> mdz, how long is it supposed to take then?
<jani> elmo ping
<mantiena> mdz, I can write specifications today for you if you aren't agains this ;)
<mdz> wasabi: it already took effect, I can see it on archive.ubuntu.com
<mdz> mantiena: I think there is some discussion to be had in order to finalize the requirements; what do you think?
<mdz> where should they be mounted, how will this interact with Nautilus, how to interface with os-prober
<jdub> Kamion: ooof!
<Kamion> jdub: hmm?
<jdub> hoary-changes "love" ;)
<Kamion> good, isn't it
<Kamion> semi-automated ;)
<Kamion> would be so much easier in revision control
* Kamion wants an arch config laid out exactly the same way as d-i svn
<Kamion> then I can use the same translation-exporting scripts
<Kamion> elmo: how often does the mirror on rookery get updated?
<mantiena> mdz, I should go, will talk with you later
<jordi> Kamion, mvo: nano 1.3.6 has been released. It appears to work quite well here.
<jdub> french gypsy.
<mdz> Kamion: thanks for the clarification on d-d
<Kamion> elmo: ok, cdimage.u.c/releases/hoary/preview/ is gone now; the preview's only on releases.u.c/
<Kamion> elmo: and I've updated the script so that in future releases will only go on one of releases/cdimage, not both
<thom> Kamion: any joy with simple torrent pool?
<elmo> Kamion: thanks a lot
<Kamion> mdz: you have no idea how many times I redrafted that message ;)
<Kamion> thom: oh, crap. will look now
<mdz> Kamion: yes I do :-)
* thom arrgghs at whoever thought writing UI in javascript was a good idea
<mdz> Kamion: I had to ABORT ABORT ABORT the thomas bushnell subthread and didn't have a good place to try to start over; I think you've done that, though, thanks
<Kamion> mdz: np
* thom zooms off to the pub to see another batch of yankee friends
<Kamion> joeyh's response on seeing the patches repository was something like "holy crap, there's a lot of stuff in there"
<Kamion> he noted that we hadn't fed back a lot of discover1-data patches, I assume because they were all last-minute warty release things and we forgot about them
<mdz> pitti: what is the outlook for the glibc locales problem? do we need to revert?
<jbailey> mdz: He sent me a patch this morning to incorporate.
<jbailey> mdz: It basically doesn't check files that we already know for certain don't exist, but it doesn't try to cache much beyond that.
<mdz> Kamion: also, LCA registration
<pitti> mdz: the new patch is essentially like the old one without caching, but avoids at least some stats()
<pitti> mdz: it is nontrivial to make it more efficient, so this is what Hoary should ship
<pitti> mdz: I'm currently discussing this with upstream, BTW (however, they are not exactly cooperative)
<mvo> jdub: any news from the update-notifier icon :) ?
<jbailey> pitti: What are you having is not a discussion, it's a beating.  =)
<pitti> mdz: for breezy we should change the patch to drop timestamp comparison and instead prefer files in /usr/share/locale if they exist
<pitti> mdz: i. e. we need a search path lists
<Kamion> mdz: should I be registering as professional or hobbyist? I assume professional
<pitti> jbailey: btw, what's the upload ETA?
<mdz> Kamion: I think hobbyist
<Kamion> ok
<pitti> jbailey: I have another bug in the install-language-locales script which I would like to fix as well
<jbailey> pitti: Evening sometime or tomorrow morning.
<mdz> Kamion: it is a hobbyist registration which I have to transfer
<pitti> jbailey: do I have another hour then?
<Kamion> ah, right
<pitti> jbailey: bug #8000 (thanks seb128 :-) )
<jbailey> pitti: Many, it's only just stopped being morning here.
<seb128> pitti: you're welcome :)
<Kamion> in that case I shall use my @debian.org address to register ;)
<pitti> jbailey: oh, nice :-)
<seb128> pitti: you get it too ?
<pitti> seb128: I never tried this :-)
<pitti> seb128: I think remove-language-locales should not remove the locale that is selected in /etc/environment
<pitti> seb128: if you manually add your default locale to /etc/locale.gen, it should work again, right?
<dholbach> re
<pitti> Hi dholbach 
<seb128> pitti: probably, I can try if you want :)
<pitti> seb128: however, it only affects perl applications
<pitti> seb128: other apps just use C
<seb128> which I don't want
<pitti> seb128: but the locale should probably be available even if translations aren't
<pitti> yeah
<seb128> I've removed the language-pack to try some uptodate translations :p
<pitti> seb128: this bug will be fixed as soon as jbailey uploads the new glibc
<seb128> nice
<pitti> seb128: i. e. then you can install debs with translations and they will be used
<pitti> seb128: however, if I do dpkg-reconfigure locales after purging l-p-de-base, de_DE.UTF_8 gets regenerated...
<seb128> bah, perhaps that's a local issue
<seb128> removing or purging ?
* pitti purged
<seb128> does that make a difference ?
<pitti> seb128: however, I just fix remove-language-locales to keep the default locale
<seb128> nice, thanks
<elmo> pitti: can you please seed the new language-pack?
<elmo> err, if you haven't
<pitti> elmo: oh, I didn't, thanks for notification
<pitti> will do now
<pitti> elmo: -rm, right?
<elmo> yeah
<elmo> fabbione: ?
<pitti> elmo, Kamion: actually all the -base packages don't need to be in the seeds since the l-p-foo packages depend on them. Right?
<pitti> elmo: seeded l-p-rm and l-support-rm
<fabbione> elmo: ?
<Kamion> pitti: correct
<zyga> pitti: what's the rationale behind multiple .mo directories?
<elmo> fabbione: is sparc buildd ok?
<fabbione> elmo: yes, why?
<pitti> zyga: 1) support /usr/local/share/locale
<elmo> haven't seen an upload in 24 hours
<pitti> zyga: (for ubuntu) 2) support /usr/share/locale-langpack/
<elmo> and I kinda need workrave updated 
<fabbione> elmo: ooo1.3 that was already out of ccache :( but thanks for pinging me :)
<elmo> ok
<zyga> pitti: and the newer one has precedense, right?
<fabbione> it finished last hour.. next upload batch will start at 03 of the next hour...
<pitti> zyga: right now, yes
<fabbione> elmo: btw.. i got a timeout from ftpd recently...
<elmo> fabbione: uh, really?
<pitti> zyga: however, starting from breezy we don't need timestamp comparison any more
<pitti> zyga: the first found one (in the path list) wins
<zyga> pitti: I'm thinking about supporting multiple locations
<elmo> I managed a 6 hour or so upload at 2k/s without timing out - are you sure it was the ftpd?
<pitti> zyga: that'd be great :-)
<fabbione> elmo: yes. i had almost no outgoing bw... and ftpd kicked me out uploading ooo :-)
<fabbione> but there was traffic going
<pitti> zyga: same like $PATH specs
<zyga> pitti: and some config stuff like /etc/gettextrc $HOME/.gettextrc
<pitti> zyga: /etc/gettextrc would rock :_)
<fabbione> elmo: thanks a lot dude :-) i need to go again 
* fabbione &
<pitti> zyga: it could contain SEARCH_PATH=/usr/local/share/locale:/usr/share/locale:/usr/share/locale-langpack for Ubuntu
<pitti> zyga: /usr/local/share/locale:/usr/share/locale should be the hardcoded default 
<zyga> pitti: that could be in environment...
<zyga> anyway that's easy as soon as I get .mo file support compleate
<zyga> still want to add lazy transcoding 
<zyga> (transcoding really suxx IMHO)
<pitti> zyga: so environment beats ~/.gettextrc beats /etc/gettextrc beats hardcoded default?
<jani> elmo ping
<zyga> pitti: that's reasonable - but second priority
<zyga> I'll still have a lot of work to do
<pitti> zyga: I meant wrt <zyga> pitti: that could be in environment...
<zyga> pitti: but I fully agree on that it's very good idea :)
<salgado> hey guys, I wanted to build ion2 from hoary to warty, but it's telling me that I have to build it with fakeroot, even when I try to build it with fakeroot
<zyga> I'm still puzzled about thread safty though...
<pitti> zyga: you will do a lazy initialisation of file lookup? I. e. search the correct mo file for a locale when the first string is requested?
<zyga> I need to see how glibc did it
<zyga> pitti: didn't planned it but that's simple to add
<pitti> zyga: and just use the found domain for subsequent gettext()'s for the same locale?
<pitti> zyga: how you want to do it now?
<zyga> pitti: I need lazy transcoding to correct encoding based on locale
<seb128> Kamion: there is no "Select your keyboard" in the current installater or the string is not in the template ?
<pitti> zyga: oh, I didn't know that this works :-)
<jani> elmo could you please sync darcs 1.0.2 from debian (we have 1.0.1) now
<pitti> oh sure, it has to
<pitti> jani: MEEP, upstream version freeze. this requires mdz acknowledge first :-)
<zyga> pitti: it's generally a hash table (by domain name) of hash tables (by msgid) of translated (lazily) messages :)
<mdz> pitti: darcs is in universe, no?
<jani> universe of ocurse
<pitti> oh right, sorry
<jani> :_
<dholbach> yes, is universe
<jani> :)
<jani> It builds fine I tried it
<pitti> zyga: don't you need domain -> locale -> msgid?
<pitti> zyga: or locale -> domain -> msgid (dunno what is better)
<zyga> well yes .. currently working with one locale chain
<pitti> zyga: a program can call setlocale() several times with different locales
<pitti> zyga: or do you just destroy your data structure in this case (probably makes sense)?
<zyga> as I said I need to read glibc guts a little more to know about some stuff that's still missing in my head
<zyga> pitti: I don't think you can destroy anything
<pitti> zyga: oh, I just know the specification of it's interface :-) (a bit)
<zyga> pitti: there is not a single word about when the translated message becomes invalid
<zyga> to I must assume it never does :/
<pitti> zyga: if the program calls setlocale() with a different locale, for example
<zyga> pitti: do you mean that somewhere in the docs it says something like this
<zyga> const char *foo = gettext ("foo");
<zyga> setlocale (...);
<zyga>  /* foo is no longer valid */
<zyga> ?
<pitti> zyga: well, if I do gettext("foo") in en_US, then change my locale to de_DE, gettext("foo") should return German
<zyga> well yes
<zyga> but if you store the result of first gettext
<zyga> it should be still valid, right?
<pitti> zyga: yes, of course, you can't change this :-)
<Kamion> thom: ok, torrent tree nearly set up now; it'll contain at most one daily of each type ({Ubuntu,Kubuntu} {daily,daily-live,dvd}), one official release for each suite (e.g. Hoary preview), and one unofficial release for each suite (e.g. Array 7)
<zyga> pitti: so that means - no destruction at all
<pitti> zyga: oh right, gettext() returns a pointer to static memory
<pitti> zyga: then I'd suggest domain -> msgid -> locale -> translation
<Kamion> seb128: smurfix accidentally nuked templates.pot from the last upload; I put it back earlier today
<Kamion> seb128: so it doesn't appear in the current installer-po/
<seb128> hum; k
<Kamion> seb128: should be restored tomorrow
<seb128> nice, thanks
<seb128> is there a string freeze for the installer ?
<zyga> pitti: i think that locale should be higher
<zyga> after all... you set your locale once
<Kamion> seb128: no
<zyga> eg... there is no gettext_for_locale stuff
<zyga> so locale lookups could be avoided
<Kamion> seb128: after tomorrow's installer-po/ arrives, I don't expect more than maybe half a dozen string changes at most, though
<zyga> even if you change the locale later
<pitti> zyga: as you wish, it probably doesn't affect the speed in any way
<Kamion> seb128: upstream has been string-frozen for some time
<zyga> you still got one global locale for all new messages
<Kamion> I do have one netcfg change left to make that involves a string change
<seb128> Kamion: all right. And I guess there is no way to know what strings are displayed in the standard installation ?
* mvo is away to play some hockey. bbl for CC meeting
<Kamion> seb128: unfortunately not, priorities are only in code so extracting them automatically is hard
<Kamion> seb128: there's some attempt made to order the .pot by importance of udebs, but it may not be complete
<pitti> jbailey: still here?
<seb128> Kamion: k, I'll keep doing installation and to note things not translated so :)
<pitti> jbailey: I fixed remove-language-locales for #8000, too. I put the script to http://people.ubuntu.com/~pitti/libc/ and updated the changelog
<pitti> jbailey: can you please include this as well?
<jbailey> pitti: Lagging, on the phone with my accountant.
<jbailey> pitti: Sure.
<Kamion> seb128: should basically just be Ubuntu additions
<Kamion> seb128: don't bother with the untranslated country strings ("AD", "AE", etc.); there are translations for those in iso-codes, I just need to figure out how to suck them into choose-mirror automatically
<seb128> yeah, I've skipped them
<seb128> but there is a load of stuff non-translated
<Kamion> yeah, I just looked through the list, it's indeed just Ubuntu additions
<seb128> 963 translated messages, 2 fuzzy translations, 256 untranslated messages.
<Kamion> seb128: the urgent stuff there is apt-setup, archive-copier, casper
<seb128> how come than the stuff like the tz config have not translations, they are not ubuntu additions, are they ?
<Kamion> what tz config stuff?
<Kamion> msgid?
<seb128> all the tzsetup.template stuff
<Kamion> seb128: none of that shows up as untranslated here, and only one fuzzy string; are you sure you have the current version?
<Kamion> cjwatson@rookery:~/public_html/installer-po$ msgfmt --statistics -o /dev/null fr.po
<Kamion> 941 translated messages, 44 fuzzy translations, 236 untranslated messages.
<seb128> arg
<seb128> I've taken the fr.po yesterday, update around 50 strings
<Kamion> a lot of the fuzzy stuff seems to be in base-config; perhaps a bad merge, not sure
<Kamion> msgmerge?
<seb128> noticed than the template is not complete
<seb128> you have fixed it, and I've updated the po with today's template
<seb128> without taking the fr.po update 
<seb128> I'll try that, thanks
<Kamion> thom: little:/srv/cdimage.no-name-yet.com/www/torrent
<mdz> seb128: my panel crashed overnight again
<mdz> seb128: has upstream looked at the backtrace?
<seb128> no, Vincent is in .us for a conf for some days
<seb128> (he's a .fr guy)
<seb128> mdz: but seems to be specific to your configuration ... perhaps due to ~/.recently-used
<seb128> maybe you can try to move that out of the way
<mdz> I see nothing unusual there
<mdz> I will move it
<seb128> mdz: about #3159, the feature is the focus stealing prevention (which is basically most of the GNOME 2.10 work on it), and changing that is not an option
<mdz> but we receive more bug reports about the new behaviour than the old
<seb128> the solution is to fix gaim, but I don't know this code and upstream are not responsive
<seb128> I know, but that's an upstream decision, I don't think we want to fork metacity 
<mdz> seb128: is there someone we can bounty?
<seb128> not sure, jdub will probably better knows that
<mdz> jdub: ^^^ when you wake up
<pitti> seb128: Adi Attar submitted the Xhosa po files to the Gnome translation project
<pitti> seb128: how fast do these translations propagate into the upstream tarballs?
<dholbach> pitti: they should be in next tarball release
<dholbach> pitti: most translators have cvs accounts
<pitti> dholbach: Adi certainly doesn't
<dholbach> pitti: he can painlessly sign up for one
<Kamion> (she)
<dholbach> she... :-)
<pitti> oh, sorry :-)
* dholbach apologizes
<seb128> pitti: how ?
<dholbach> http://developer.gnome.org/doc/policies/accounts/requesting.html
<seb128> pitti: how did she submit them ?
<pitti> seb128: "For the Gnome files, I have been submitting them to the Gnome
<pitti> translation project."
<pitti> seb128: however, I don't see Xhosa at http://l10n-status.gnome.org/HEAD/index.html
<pitti> seb128: and I don't know where to get the files from
<pitti> seb128: She asked me to pull the files from there, to put them into the language packs
<seb128> pitti: Xhosa is on the GNOME CVS ?
<pitti> seb128: not right now, as it seems
<seb128> so nothing to do
<pitti> seb128: I didn't find any trace of it
<seb128> just wait
<pitti> seb128: okay, I will ask her
<schimmi> hi! how is a user supposed to login as root on fsck problems during boot? root has no valid password on normal Ubuntu box
<dholbach> what is the iso code being used?
<Kamion> dholbach: xh_ZA
<pitti> dholbach: xh_ZA (Xhosa SOuth Africa)
<dholbach> ok... thanks
<Kamion> schimmi: fsck uses sulogin, which is special-cased for this situation
<Kamion> schimmi: in the case where a root password isn't set, it will allow passwordless access
<schimmi> I got the normal root login, but maybe that's because I had set it before
<schimmi> just wondered...
<Kamion> schimmi: we thought about this and noted that it wasn't a problem to do that, because if you were being presented with sulogin then you could always just reboot with init=/bin/sh
<Kamion> schimmi: yes, if you have set your root password then we assume that you want to be asked for it :-)
<elmo> Kamion: well, unless there's a password on the bios, grub and the machine's physically tied down
<schimmi> Kamion, yes makes sense :) didn't expect that it just looks different with and without set root password
<Kamion> elmo: indeed
<Kamion> elmo: but then you generally wouldn't have got as far as sulogin in the first place
<Kamion> unless somebody typed in the password and then walked off and left you with the machine - in which case, er, don't do that then
<elmo> or the password only comes up when you try and do anything but the default?
<Kamion> that would apply to a grub password, but I imagine not to a BIOS password - but yes
* lamont lunches
<Kamion> in any case people locking down machines that way will generally set a root password, I suspect
<elmo> yeah
<Kamion> but we should probably document the sulogin thing better
<elmo> like in the manpage ;)
<Kamion> hah, yeah
<dholbach> seb128: i'm trying to get gmime2 building again, but the bug is #299098, which seems to get resolved by gtk-doc from incoming, what do you think about it?
<seb128> dholbach: need to fix gtk-doc-tools
<dholbach> seb128: is gtk-doc from incoming what we'd probably want?
<seb128> yep
<elmo> hey, anyone know how:
<elmo> shiri 19:17 ~ % grep -c de_DE.UTF-8 /etc/locale.gen
<elmo> 65
<elmo> that might have happened?
<pitti> elmo: ugh
<dholbach> elmo: not at all
<pitti> elmo: how did you manage to get this?
<elmo> pitti: that's my question dude :)
<elmo> pitti: I'm fairly sure I didn't do it ;)
<elmo> needless to say, it makes libc6 upgrades, err, fun
<pitti> elmo: grep -c de_DE.UTF-8 /usr/share/i18n/SUPPORTED
<elmo> 2
<pitti> elmo: this should be 2
<pitti> okay
<pitti> elmo: can you please do sort -u /etc/locale.gen ?
<pitti> elmo: I'm interested in the particular formatting
<pitti> elmo: i. e. whitespace at line start, etc.
<elmo> pitti: I copied it to http://people.ubuntu.com/~james/paste/locale.gen
<elmo> but they seem identical
<pitti> yeah
<pitti> elmo: do you get one additional entry with every language pack update? or locales update?
<elmo> it's worth noting de_UTF is the only non-UTFed locale I had in there
<elmo> i.e. this looks like the "you will be UTF-8 suckah" script at wor
<elmo> k
<pitti> interesting
<pitti> there are blocks of 2 - 4 - 8 - 16 - 32 entries
<pitti> so it seems to double the number with every invocation of whatever
<pitti> elmo: do you have l-p-de-base installed in the first place?
<pitti> elmo: btw, what do yout mean with "de_UTF is the only non-UTFed locale"?
<elmo> pitti: no l-p*
<pitti> elmo: hmm, then this is not a install-language-locales bug
<pitti> elmo: locales postinst maybe
<elmo> pitti: I added all the locales _except_ de_DE-UTF8 eons ago when I was testing some locale related bug in gawk or gnupg
* pitti stares at locales maintainer scripts
<pitti> ah
<elmo> pitti: and the locales I added all have both UTF8 and non-UTF8 variants, except de
<elmo> pitti: when is install-language-locales called?
<pitti> elmo: only in l-p-foo-base postinst currently
<elmo> boggle.
<pitti> I have an idea
<pitti> /var/lib/dpkg/info/locales.config
<pitti> # For each currently selected locale, try to select a corresponding UTF-8
<pitti> # locale as well.
<pitti> # TODO: We should check whether we've done this migration already. How? A
<pitti> # version comparison is problematic due to merges among distributions.
<pitti> elmo: can you please paste the value of debconf locales/locales_to_be_generated
<Kamion> that code's been working for ages
<pitti> Kamion: this UTF-8 migration, too?
<Kamion> yes
<Kamion> I mean I suppose it's possible, but I don't see why nobody else would have reported it in the three months since I added it
<elmo> * locales/locales_to_be_generated: de_DE ISO-8859-1, de_DE@euro ISO-8859-15, en_GB ISO-8859-1, en_GB.ISO-8859-15 ISO-8859-15, en_GB.UTF-8 UTF-8, fr_FR ISO-8859-1, fr_FR.UTF-8 UTF-8, fr_FR.UTF-8@euro UTF-8, fr_FR@euro ISO-8859-15, ja_JP.EUC-JP EUC-JP, ja_JP.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.U
<pitti> elmo: okay, it seems that we get closer
<Kamion> boggle
<pitti> Kamion: it would be interesting to see this loop after the comment in action
<Kamion> I'd like to see a 'set -x' trace of locales.config in action
<elmo> just running locales.config doesn't seem to do it
<elmo> lemme try a dpkg-reconfigure with set -x in the script
<Kamion> if anything I suspect dpkg-reconfigure will collapse it back down to one
<elmo> hasn't, also hasn't made it any worse :(
<Keito> Hi
<elmo> maybe it's not worth digging too deeply in, if there haven't been any other reports of it
<Kamion> elmo: seems worth investigating
* pitti newer encountered it, but it looks interesting
<elmo> ok, well - I'm currently generating 65 copies of the locale, any suggestions on what to try next?
<pitti> elmo: running locales.config doesn't add anything to locales/locales_to_be_generated debconf value?
<Kamion> cut some of the dups out of locale.gen (say down to 4), to save time, and try reinstalling a language pack?
<pitti> Kamion: he didn't install a language pack ever
<pitti> Kamion: so I doubt that this is a install-lanugage-locales thing
<Kamion> oh
<elmo> pitti: no, I don't have any installed now
<elmo> I could have installed some, I just don't remember
<elmo> and I don't have new supah powahed dpkg-with-logging yet
<pitti> elmo: in this case you would have other locales, too
<pitti> elmo: like de_AT
<elmo> pitti: even after purging?
<Kamion> elmo: try apt-get --reinstall install locales, see if that reproduces?
<pitti> elmo: no, purging cleans it again
<dholbach> elmo: could you please (later) sync  libhttpfetcher  from sid?
<andred> When you change session language in gdm it doesn't change the language used in gdm itself. Shouldn't it do that? How else can a user easily completely switch language?
<andred> Modifying /etc/environment doesn't even change gdm's language.
<elmo> grep -c de_DE.UTF-8 /etc/locale.gen     
<elmo> 129
<elmo> whee!
<elmo> but not set -x, 'cos it got wiped out by the reinstall, noo
<elmo> s/noo/boo/
* Kamion pokes
<elmo> I'm still regenerating :>
<ogra> hmm, thats a lot of german
<Kamion> elmo: is there any other output? like "Automatically selecting $tryloc locale in addition to $oldloc."
<Kamion> ohfuck, I guess outputting that to stdout isn't such a good plan
<elmo> Kamion: nope, nothing
<Kamion> elmo: try with DEBCONF_DEBUG=developer if you could; and definitely delete some of those duplicates first this time :)
<mdz> at what point did the CC meeting time change?
<zul> 2 weeks ago i think
<pitti> Kamion: as a remedy, in locale-gen, could we replace
<azeem> famous last words
<azeem> ah :)
<pitti> Kamion: bah, I was thrown out. Did you say anything after my "could we replace..:" question?
<Kamion> 19:53 < pitti> Kamion: as a remedy, in locale-gen, could we replace
<Kamion> that was the last thing I saw
<pitti> Kamion: this sort -u would at least not generate locales multiple times
<Kamion> pitti: but the existing code is not supposed to either (it checks)
<Kamion> pitti: I don't like applying workarounds for bugs we don't understand
<pitti> hmm
<elmo> Kamion: http://people.ubuntu.com/~james/paste/typescript
* T-Bone fights buildd, and lacks magic-fu :P
<pitti> Kamion: however, I just tried this, and de_DE.UTF-8 is generated twice for me, too
<pitti> Kamion: that doesn't mean that the initial bug shouldn't be fixed, but avoiding multiple generation could be a good idea (independently of the debconf bug)
<Kamion> pitti: sure, but I'd prefer to diagnose this first before it gets hidden
<pitti> hmm, I can't reproduce this; the debconf list is cleaned up for me
* pitti copies elmos list
<pitti> Kamion: hah, with elmos debconf value I can reproduce it
<Kamion> something is weird here, join is not doing what it's meant to do
<pitti> Kamion: (I didn't use the broken last entry, that was probably a copy&paste bug)
<Kamion> # grep de_DE.UTF-8 supported
<Kamion> de_DE.UTF-8@euro UTF-8
<Kamion> de_DE.UTF-8 UTF-8
<Kamion> # echo de_DE.UTF-8 | join - supported
<Kamion> #
<elmo> kamion: I thought join worked on the wholel ine tho?
<elmo> i.e. you're missing the trailing " UTF-8"?
<Kamion> no
<pitti> elmo: no, join uses the first field separated by space/tab
<Kamion> but I think the file might not be sorted properly
<elmo> oh, I'm getting confused with comm
<Kamion> OH, FOR FUCK'S SAKE
<Kamion> it works fine in LC_COLLATE=C :-P
<pitti> LOL
<Kamion> sometimes I really, really hate UTF-8
<elmo> but, err, I'm in C, I think?
<elmo> unless the defaults been changed?  I have no LANG or LC env vars set
<Kamion> this is just why I couldn't get the auto-adding to work at all
<Kamion> I haven't even got onto reproducing your bug yet :P
<pitti> Kamion: use elmo's debconf value and do apt-get install --reinstall locales
<Kamion> pitti: hold on, in the middle of stuff
<zyga> Kamion: what is de_DE.UTF-*@euro ?
<pitti> (no dpkg-reconfigure)
<Kamion> zyga: breakage
<zyga> ?
<pitti> zyga: they don't exist
<pitti> forget them :-)
<Kamion> zyga: don't use them
<zyga> Kamion: I see :-)
<Kamion> pitti: you mean stick that into the debconf database, or write it into locale.gen; which?
<pitti> Kamion: stick into debconf
<pitti> Kamion: btw, why "join"?
<pitti> Kamion: why not "grep -q" or so?
<Kamion> pitti: more correct
<Kamion> er, except when I screw up, but hey; I don't like grepping with user input as the regexp when I can avoid it, basically
<pitti> Kamion: -F?
<Kamion> pitti: doesn't let you use ^
<pitti> Kamion: okay, that depends on whether you want to take the encoding into account or not
<Kamion> pitti: I prefer join, mkay
<Kamion> :)
<pitti> sure, I just try to understand the reason :-)
<elmo> pitti: leave him be, he's happy with his old skool tools that most people don't even know exist
<elmo> ;P
<Kamion> heh
<pitti> elmo: I learned about join some months ago
<pitti> elmo: I was impressed that all database operations can be done at the shell level :-)
<Kamion> pitti: can't reproduce just by putting that in debconf
<Kamion> which doesn't surprise me
<pitti> Kamion: hmm, I can...
<pitti> Value: de_DE ISO-8859-1, de_DE@euro ISO-8859-15, en_GB ISO-8859-1, en_GB.ISO-8859-15 ISO-8859-15, en_GB.UTF-8 UTF-8, fr_FR ISO-8859-1, fr_FR.UTF-8 UTF-8, fr_FR.UTF-8@euro UTF-8, fr_FR@euro ISO-8859-15, ja_JP.EUC-JP EUC-JP, ja_JP.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8
* Kamion tries putting it in locale.gen
<pitti> Kamion: oh yes, I used elmos' original file, too
<Kamion> ah, there we go
<Kamion> ok, it's postinst breakage I think, working on it
<Kamion> look at that suspicious uncommenting/commenting code
<Kamion> pitti: do you have a glibc upload in progress? I'll send you a patch when I'm done
<pitti> Kamion: I sent my stuff to jbailey
<pitti> Kamion: he still has some things to fix
<Kamion> ok
<pitti> Kamion: so maybe just send it to him
* pitti -> food
<jbailey> Kamion: There's still time.
<zyga> why can't we just get rid of all ISO- EUC and KOR stuff?
<zyga> it's not like they're here to stay
<Kamion> zyga: deleting locales that users might be using is bad karma
<Kamion> hence why we just generate UTF-8 equivalents
<zyga> Kamion: hyhy
<zyga> Kamion: UTF-8 incompatible file deletion tool ;-)
<zyga> wipe-your-disk-wizard
<Kamion> zyga: utf8-migration-tool :P
* lamont_r takes the install process out back and hits it with a bo-staff.  repeatedly
<Kamion> pitti: aha; locales.postinst generates 1 + 2*(n-1) copies of each locale - so it's fine if n==1
<zyga> Kamion: yeah.. but still my /etc/locale.alias has UTF-8 entries :/
<Kamion> pitti: once you somehow end up with n>1 copies of any given locale, it will multiply without end
* Kamion fixes
<lamont_r> Kamion: base-mumble adds the user to /etc/aliases, but does not run newaliases...  I don't think postfix should automatically do it at startup, since the admin could have some other source for /etc/aliases.db than /etc/aliases... thoughts (#8067)
<dholbach> thank you, elmo
<Kamion> lamont_r: passwd.config is responsible for that; I don't have time to look at it just now but you're welcome to change as appropriate ...
<lamont_r> ok.  is that post debootstrap?
<Kamion> lamont_r: yeah
<Kamion> lamont_r: pre-reboot though
<lamont_r> that's fine - I just need newaliases to be != /bin/true. :-)
<drspin> is the default hoary kernel bootsplash ready?
<Kamion> drspin: no.
<lamont_r> drspin: and it won't be kernel bootsplash, either... it'll be userspace bootsplash, and post-hoary
<drspin> lamont_r: thanks for the tip - sorry to bug ;)
<lamont_r> np
<lamont_r> kernel bootsplash is too invasive, and breaks some hardware, etc, etc.
<zul> lamont_r: i bet you have canned resposnes dont you
<lamont_r> zul: nah, I just type fast
<zul> lamont_r, sure sure
<drspin> I've heard that before thanks for reinforcing :)
<Kamion> elmo: ok, getting rid of the old dups is a bit complicated, but I've stopped them reproducing
<lamont_r> hrm... why does 'acpi' print nothing on my laptop... wonder what we broke.
<zul> lamont_r: not me for once 
<lamont_r> zul:  it's been that way for a while..
<zul> lamont_r: still i didnt do it :)
<lamont_r> lol
<drspin> I have a question - in Hoary on my dual celerons even with acpi=off in my kernel options I still get apic errors on both of my CPUS occassionally
<lamont_r> drspin: you know that's really a #ubuntu question, right?
<Kamion> elmo: *ah*, I see how it happened
<Kamion> elmo: it generated one UTF-8 locale for de_DE ISO-8859-1, and another for de_DE@euro ISO-8859-15
<lamont_r> Kamion: damn euros anyway.:-)
<ogra> lamont_r, hey, we pay with them....
<Kamion> easy fix
<ogra> Kamion, pay with pound ?
<drspin> lamont: the only response I always get is acpi=off -- no one ever mentioned that I should turn off APM in my bios because it's not SMP safe -- and even if I do what the need I still get the errors -- I've googled like crazy and always just get the ACPI=off solution which doesn't seem to work and I can't find any rhyme or reason to it
<dholbach> hm, why didnt  openscenegraph  build on amd64, i mean... didnt even try to?
<mdz> dholbach: it looks like it might need some porting, looking at the rules file
<mdz> dholbach: it's probably failed in the past and been added to the exclusion list
<mdz> lamont_r: can confirm
<drspin> should I maybe take it to lkml for a solution?
<mdz> drspin: try google first
<Mitario> hey everyone
* lamont_r is checking
<dholbach> mdz: hmmm, should build on amd64    ( * Patch to fix FTBFS on amd64 (closes: #286674)  )
<lamont_r> drspin: the short answer is to look at http://people.ubuntu.com/~lamont/buildLogs/Lists/hoary.all.amd64
<lamont_r> and see what that says...
<dholbach> mdz: that's why i wanted mdz to sync it
* lamont_r is currently a bit challenged trying to run firefox over ssh... which sucketh
<dholbach> mdz: erm elmo :-)
<mdz> dholbach: the buildds have a list which excludes packages known not to build on certain architectures, in order to avoid wasting time on them.  this needs to be updated when this type of problem is fixed
<Kamion> jbailey: jbailey@ubuntu.com?
<dholbach> mdz: ok thanks, i see
<jbailey> Kamion: Please.
<Kamion> jbailey: sent
<drspin> lamont_r: "short answer" LOL
<drspin> thanks I'll google a bit more
<Kamion> drspin: I think lamont_r mentioned that to you by accident, rather than to dholbach
<lamont_r> drspin: er, sorry.  that was really aimed at dholbach 
<drspin> heh - LOL
<drspin> no worries - I thought it was rather funny
<dholbach> lamont_r: thanks, i'll have a look
<lamont_r> dholbach: if it says it's depwaited on something in error, holler...
<Kamion> jbailey: the sort -u when initialising SELECTED_LOCALES probably applies to Debian too; and in fact it turns out to be an alternative way to fix #271526
<dholbach> lamont_r: it says: Dep-Wait by buildd+king [optional:uncompiled]   Dependencies: giflib-dev            - which is provided by giflib3g-dev
<jbailey> Kamion: Thanks for that.
<dholbach> lamont_r: the other buildds resolved that, hmmmm
<Kamion> jbailey: (Denis' patch looks valid too, and there's probably no reason not to apply both :-))
<dholbach> hey mvo
<mvo> hey dholbach 
<ogra> hi mvo 
<mvo> hi ogra 
* sabmoc is away: onBlur();
<LeeJunFan> anyone else see us.archive.ubuntu.com (216.165.129.138) as being down?
<dredg> it pings
<LeeJunFan> no http
<dredg> that's different to it being down
<LeeJunFan> which screws apt.
<LeeJunFan> ok - so http on it is down.
<Kamion> yeah, seems so from here too
<LeeJunFan> if it doesn't work - it's down :)
<dholbach> what does   [Category: none]     not ours     in   http://people.ubuntu.com/~lamont/buildLogs/Lists/hoary.all.amd64    mean?   (sdl-stretch)
<LeeJunFan> ftp is working on it.
<lamont_r> dholbach: 'amd64 not in arch list ....
<lamont_r> debian/control needs an edit to include amd64 where appropriate.
<mdz> it's answering, it's just very slow
<dholbach> lamont_r: ok, good
<mdz> lamont_r: debian/control is Arch: any
<lamont_r> mdz: ??
<mdz> mizar:[/tmp]  zcat openscenegraph_0.9.8-2.diff.gz| filterdiff -i '*/debian/control' | grep Architecture| sort -u
<mdz> +Architecture: all
<mdz> +Architecture: any
<lamont_r> mdz: sdl-stretch
<mdz> oh
<lamont_r> ok.
<lamont_r> 'not ours' is _ALWAYS_ 'arch not in arch list', and since we auto try faileds (but not d-w's) on upload, it's self clearing.
<lamont_r> hrm.. filterdiff
<lamont_r> cool
<dholbach> lamont_r, mdz: sorry for asking two questions at once
<lamont_r> Architecture: i386
<lamont_r> dholbach: that's not to say that it _should_ be i386-only...
<lamont_r> i386 assembly, I guess that's ok...
<lamont_r> but if it builds on amd64, that's easy to fix.
<seb128> pitti: around ?
<lamont_r> and it's just !m68k in PaS, so you're good there too
<pitti> seb128: yes
<seb128> pitti: new ping about https://bugzilla.ubuntu.com/show_bug.cgi?id=7725 
<seb128> pitti: if you know about this file
<pitti> seb128: uh, no clue
* pitti reassigns *sigh*
<seb128> pitti: but /usr/share/gnome-volume-manager/gnome-volume-manager-gthumb.sh is a warty thing ?
<seb128> if not just close it as NOTWARTY
<pitti> seb128: this actually might be a regression in Hoary
<seb128> k
<pitti> seb128: I deliberately moved this script into /usr/share/g-v-m
<pitti> seb128: probably it got dropped in a sync
<Kamion> mdz: is casper 0.56 not in arch yet?
<seb128> hum
<Kamion> mdz: the changelog in casper--main--0 doesn't seem to match up
* seb128 has just noticed than g-v-p has 2 tabs now
<lamont_r> but I don't _want_ to make a custom install CD... </whine>
<zyga> seb128: it had them for a while now
* lamont_r heads for home, and a test machine.
<Kamion> mdz: please merge colin.watson@canonical.com--2005/casper--translations--0 up to patch-2 (http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005)
<zyga> Kamion: ah, you arch pepole :)
<thom> Kamion: rocking, thanks
<mdke> jdub, ping
<mdz> Kamion: my mirror isn't up-to-date
<mdz> Kamion: updating it now
<mdz> ...and merged
<Kamion> mdz: ta
<Kamion> though still doesn't show as up-to-date
<mdz> I bet you're looking at the old chinstrap mirror
<mdz> I'm publishing to people.u.c now
<mdz> hmm, no, I removed the chinstrap one when I moved it
<mdz> ** adding revision casper--main--0--patch-8
<mdz> do you not see patch-8?
<mdz> community council meeting -> #ubuntu-meeting
<Kamion> $ baz archives matt
<Kamion> matt.zimmerman@canonical.com--2004
<Kamion>     http://people.ubuntu.com/~mdz/archives/matt.zimmerman@canonical.com--2004
<Kamion> mdz: I'm using that
<mdz> that's correct
<mdz> and that should have patch-8
<Kamion> hmm, something is odd
<mdz> mdz@rookery:~/public_html/archives/matt.zimmerman@canonical.com--2004/casper--main--0 $ ls -ld patch-8
<mdz> drwxr-xr-x    3 mdz      warthogs     4096 Mar 22 21:53 patch-8
* doko is jalous about pitti's 21 minutes integrating xhosa support in mozilla ...
<pitti> doko: OO.o is certainly a lot more difficult?
<doko> :-(
<Kamion> mdz: oh, heh. You know what lifeless said earlier about proxy issues?
* Kamion unsets http_proxy and watches it all work fine
<mdz> ick, why does that break?
<Kamion> mdz: I think that could do with a more descriptive changelog though ...
<Kamion> mdz: the cache's copy of .listing only went up to patch-4
<mdz> Kamion: I'll fix it when I actually go back and see what it is you changed ;-)
<Kamion> hah
<mdz> one of these days one of us needs to write a tool for this
<Kamion> 'baz changelog' says
<mdz> to manage patch-logs vs. changelogs
<mdz> patch-logs vs. debian/changelog I mean
<mdz> ideally I would be able to merge changelog entries along with your changes
<mdz> but creating new versions in different branches is a big mess
<mdz> and merging changelogs in general
<Kamion> yeah, currently I'm avoiding creating debian/changelog entries for that exact reason
<Kamion> even for my own packages, I create them only when doing a new release
<Kamion> but that sucks for other reasons, it's more awkward to build test versions
<mdz> yeah
<Kamion> pitti: took a few hours to do the installer support, too
<Kamion> although it got quicker as I went through
<mdz> what I've started doing (when I think of it) is to put in a changeset which does nothing but open a new version in changelog
<mdz> and then commit changelog entries along with the changes
<pitti> Kamion: yeah, I didn't have to upload half of the world for it :-)
<mdz> this is something to be addressed with the next rev of the source package format
<Kamion> sounds more like a special hct merge op, to me ...
<Kamion> I mean upstreams that keep ChangeLog files have the same problem
<mdz> the existing changelog format is not very suitable
<mdz> ChangeLog is easier in this respect
* thom attempts to work out why when firefox calls getenv("HOME") it appears to get / as the answer
<mdz> thom: iirc, the maintainer script and/or a script it calls does that ON PURPOSE
<mdz> oh, it uses mktemp -d now
<mdz> and sets home to that
<thom> hrrrm
<thom> mdz: thanks, i'd forgotten about that
<thom> mdz: that seems to be part of the cause of 7711
<mdz> /usr/lib/mozilla-firefox/firefox is a nightmare of HOME madness
<thom> yeah; none looks to be setting HOME to something whacky unless you're running under sudo, tho
<mdz> it's the chrome update script which does the mktemp madness
<Amaranth> woohoo, pyxdg patched upstream
<lamont> Kamion: could you kick hoary_outdate.txt to current for me?
<Kamion> lamont: done as best I can (can only kick the mirror)
<dholbach> lamont: openscenegraph built fine on amd64, what do i have to do to make it build on the buildd too?   (Dep-Wait by buildd+king [optional:uncompiled]   Dependencies: giflib-dev)
<pitti> infinity: here?
<mdz> lamont: giflib-dev is provided by giflib3g-dev and libungif4-dev, both of which are built on amd64
<dholbach> and the other buildds have no hassle at all
<elmo> yes, but it's a virtual
<elmo> w-b doesn't understand virtuals
<elmo> a simple give-back will fix
<elmo> I suspect the dep-wait pre-dates lamont's auto-depwaiter, or maybe the ordering of the building was just unfortunate on amd64
<elmo> who uploaded pinfo?
<dholbach> elmo: me
<dholbach> sponsored the upload to a wannabe-motu
<elmo> dholbach: please remember to either fix the Changed-By: field or ask me to whitelist the email address
<elmo> (the latter is almost no work for me, and preferable in the long run)
<dholbach> elmo: just ask you and state the mail adress?
<elmo> dholbach: yah
<Kamion> latter definitely preferable so that the changed-by: field is there for future MOTU approvals and such
<dholbach> elmo: no signed mails by them to upload@ubuntulinux.org
<dholbach> Kamion: i totally agree
<elmo> dholbach: nah, it's just an email whitelist, doesn't give them any privs
<dholbach> elmo: alright, will do
<dholbach> elmo: and pass the word :-)
<zenwhen> hey Amaranth 
<elmo> pitttttttttttttti
<mdz> elmo: can you give-back openscenegraph, if you haven't already?
<pitti> ellllllllllllmo?
<elmo> mdz: done
<elmo> pitti: got some more security reviews for you, sorry dude
<mdz> thanks
<pitti> darn, I wasn't fast enough, just wanted to go to sleep :)
<pitti> elmo: which ones?
<pitti> elmo: ... and would tomorrow (i. e. now + 9 hours) be enough?
<elmo> pitti: sure
<elmo> I'll mail you
<elmo> go sleep
<pitti> okay, fine
<pitti> night everybody!
* lamont kicks giflib-dev
#ubuntu-devel 2005-04-03
* T-Bone kicks lamont ;)
* zul kicks T-Bone gratuiously
<T-Bone> zul: you're welcome :)
<zul> heh and i cant spell
<T-Bone> yeah. I assumed that was gratuitous as well ;)
* T-Bone ducks
<Kamion> svenl: ok, mkvmlinuz stuff should automatically appear in debian-installer initrd builds; it doesn't look to me as if any source changes are required
<Kamion> svenl: i.e. there's no "SUBARCHES = <whatever>" in our diff against Debian
<lamont> note to self: find faster cdrw media
<svenl> Kamion: what did you do ? just build chrp ones, or prep, ppcbug and coff too ?
<Kamion> svenl: ./powerpc/powerpc.cfg:11:SUBARCHES = chrp prep coff ppcbug
<Kamion> same as Debian as of last time we synced
<svenl> Kamion: yep, that one was in since months now, maybe even since before christmas.
<svenl> Cool.
<Kamion> our d-i package is based on 20041227
<svenl> Ah, ok.
<Kamion> elmo: did my floppy-retriever sync request get lost?
<elmo> Kamion: yes, sorry
<elmo> done
<Kamion> elmo: thanks
<seb128> time to sleep
<mdke> smurfix, ping
<smurfix> mdke: 
<mdke> smurfix, hmm
<mdke> can't visualise that character
<mdke> anyhow
<mdke> smurfix, saw your amendment to the wiki
<mdke> smurfix, is it a good idea to add suggestions directly there? if so i'll add those brought up during the meeting
<smurfix> mdke: For the team name? Best add another section to the end of the LoCoTeamLeader page for that
<smurfix> mdke: I don't want to clutter the main text too much
<jdub> GOOOOOOOD MORNING FREEDOM LOVERS!
<smurfix> mdke: alternately you can create a subpage -- your choice
<mdke> smurfix, no i mean where you say "suggestions welcome" for the team leader expression
<mdke> morning jdub 
<tseng> hi jdub.
<smurfix> mdke: s/team name/name of the role the team 'leader' has/
<mdke> lol
<smurfix> mdke: sure, that's what I meant to say ;-)
<mdke> ok separate page it is
<Amaranth> jdub: that scares me
<smurfix> Amaranth: Get used to it, he does that quite often
<mdke> lol
<mdke> smurfix, done
<smurfix> mdke: thanks
<mkedwards> mdz, lamont: According to Ubuntu Traffic #22, the cloop on the LiveCD is made with a variant of advfs.  Will stock advfs work?
<Amaranth> hey, does dpkg support upgrading with binary diffs?
<mkedwards> And should I be dd'ing /dev/zero to my remastering partition before making a filesystem on it?
<zenwhen> wont make much if any difference'
<lamont> mkedwards: it's made with create_compressed_fs from clooputils
<mkedwards> lamont: is create_compressed_fs smart enough to ignore unallocated blocks in an ext2?
<lamont> mkedwards: in the simple case, we say dd if=/dev/zero of=new-${IMGNAME} count=$SZ bs=1M
<Kamion> Amaranth: no
<Amaranth> :/
<lamont> mkedwards: no, but they compress really small when you start with a zero'ed lofs...
<lamont> mkedwards: that is, I'd zero the partition if you're actually going to use a disk partition
<mjg59> daniels: You are now obliged to love me forever
<jani> fabbione a kernel/ipsec related question
<mjg59> Argh, must write a UKUUG abstract.
<fabbione> jani: i am going to sleep right now...
<fabbione> jani: keep it for tomorrow :-)
<fabbione> good night everybody
* fabbione &
<marcin_ant> hi develoeprs
<marcin_ant> developers
<dholbach> bye fabbione 
<marcin_ant> I got a question about cups server on ubuntu
<daniels> mjg59: yes
<marcin_ant> I just cannot to get this working as print server
<marcin_ant> and I would like to ask if this is because I do something wrong
<marcin_ant> or maybe
<marcin_ant> because cupsys package
<marcin_ant> is set by you developers
<marcin_ant> that it can work only on localhost and cannot work as real printserver on lan?
<mkedwards> lamont: recommended blocksize for create_compressed_fs?
<mjg59> daniels: I expect you to buy me beer in .au
<daniels> mjg59: sure, but I can't guarantee that I'll spot blondes for you
<mjg59> I'll get bob2 to do that
<jani> I read in the VPN howto that ipsec-tools > 5 is needed for kernel 2.6.10
<jani> we have ipsec-tools 3.3 something as debian
<jani> I am not sure of the details just thought I'd mention it
<mdz> mkedwards: it's made with the tool in cloop-utils
<lamont> we use 65536
<mdz> mkedwards: which as far as I know is a stock advfs
<mdz> mkedwards: even though it's named "create_compressed_fs" and the source package contains an _entirely different_ tool with the same name
<mkedwards> mdz: that's a relief; I thought it was going to need to build the image in memory.
<mkedwards> I'll update LiveCDCustomizationHowTo once I have this working smoothly (you want to mount more than /proc in the chroot)
<mkedwards> lamont, mdz: thanks very much.
<lamont> proc and dev/pts are generally a good idea
<mkedwards> lamont: /tmp /dev/shm /dev/pts /proc /sys and maybe /proc/bus/usb
<mkedwards> lamont: plus syslogd -a /chroot/dev/log
<mkedwards> lamont: especially if you're adding mysql-server.  :)
<lamont> heh
<mkedwards> lamont: why regenerate filesystem.manifest?
<loaofwar3> hi i have a problem with apt-get update
<lamont> mkedwards: manifest is there so mdz doesn't have to mount the image to see what's in it...
<lamont> that's the only thing it's used for 
<loaofwar3> i get an error message every time i try to update
<loaofwar3> http://pastebin.com/261555
<loaofwar3> even tho i commented out 3 *.nerim. sites
<loaofwar3> it still gives errors
<lamont> loaofwar3: and you realize that your question really belongs in #ubuntu, right?
<loaofwar3> o sorry
<loaofwar3> thats a wrong error
<loaofwar3> i cant install acroread
<loaofwar3> this is what i get
<lamont> loaofwar3: --> #ubuntu please
<loaofwar3> http://pastebin.com/261561
<loaofwar3> i asked someone at ubuntu
<loaofwar3> and they told me to ask here
<sabmoc> loaofwar3, they are wrong
<apokryphos> His question here is about whether acroread still exists... Ubuntu packages suggets that it exists in Multiverse.
<lamont> loaofwar3: this would be the correct channel to discuss your _patch_ for the problem
<jani> elmo ping
<mkedwards> lamont: if you get around to packaging the cloop constructor at some point, I'd like to look at it.  Always nice to be able to regenerate from scratch rather than relying on a base cloop.
<mdz> mkedwards: it's cheap to regenerate, and useful as a reference
<lamont> loaofwar3: and your problem appears to be nothing more than a broken archive
<mdz> mkedwards: same reason we generate .list files for the ISOs
<sabmoc> apokryphos, yes, but that but that is not a question about development 
<mkedwards> mdz: of course, just wonder if casper used it in some way
<lamont> mkedwards: it's on my list of things to discuss with folks...
<apokryphos> sabmoc: Ok. Thought it might be the place to ask about possible obsolete packages. My mistake
<mkedwards> lamont: would be nice to integrate it with a local mirror so that one can change something, re-run, not have all the package versions change out from under one.
<lamont> yeah
<mkedwards> weird.  Does blockdev overestimate size?
<mkedwards> ieee1394: sbp2: sbp2util_node_write_no_wait failed
<mkedwards> :)
<mkedwards> Word to the wise: don't dd /dev/zero to a mounted partition.  :(
<mkedwards> Boy, am I glad I'm doing this while booted into the livecd.
<ogra> night all
<mkedwards> lamont: of course, the hazard of distributing a well written custom LiveCD baker is that your archive will get hammered.  :)
* lamont goes to a meeting for a bit - back in about 90 min or so.
<lamont> \heh
<loaofwar3> what do you mean broken archive? how would i fix that?
<mkedwards> gnu cp is amazing.  cp -a works on an entire installed system, device nodes, symlinks, and all.
<infinity> mkedwards : Yes, after using 'cp -a' as a lazy man's recovery/backup tool, it's hard to imagine how we lived without.
<zenwhen> cp -a for life
* mvo -> bed
<zenwhen> I love how easy it is to switch a linux install between drives
<LeeJunFan> zenwhen: rsync is even better.
<zenwhen> orly
<mkedwards> Some piece of my ieee1394 subsystem is not happy.  :(
<JanC> zenwhen : C:\>cp -a for life
<JanC> cp: cannot stat `for': No such file or directory
<JanC> doesn't work  ;-)
<infinity> C:\> ?
<JanC> :-P
<JanC> gnu tools work under windows too  :)
<infinity> Yes, but... But.. Why?
<JanC> i was doing some stuff with windows-only programs...
<helix> infinity: to make work life liveable for some people, I assume
<helix> livable?
<JanC> 52% ... waiting before i can reboot
<wasabi_> lamont, ping.  need another j2sdk1.4 bump, working on some more packages and they are all locked again.
<mkedwards> wasabi_: what does that mean?
<wasabi_> http://people.ubuntu.com/~lamont/buildLogs/Lists/hoary.dep-wait.i386
<wasabi_> It means I uploaded a new version of libxalan2, which removes the dependency on j2sdk1.4
<wasabi_> But the buildds aren't smart enough to recognize it, so the package won't be built until we beat them with lamont.
<mkedwards> wasabi_: xalan2 down? Excellent.
<wasabi_> yeah this clears libbsf, bsf, and ant.
<mkedwards> That's a very interesting log page.  I presume that none of these are hoary blockers?
<mkedwards> (being universe/multiverse, and all)
<mkedwards> Is there an explicit release goal for Java in hoary?
<wasabi_> no
<mkedwards> Sure would be nice if ant were to get in before universe freezes.
<wasabi_> Probably will.
<wasabi_> Probably will be in before end of the day actually.
<mkedwards> Have you looked at mysql-connector-java at all?
<wasabi_> No.
<mkedwards> tomcat?
<wasabi_> that's next.
<mkedwards> xerces2 is done?
<wasabi_> maybe that's next. ;)
<wasabi_> I'm following the dep tree under Eclipse
<mkedwards> Eclipse 3.1pre, I assume?
<wasabi_> I'm probably going to try hard to get 3.0 up first, since I already have that package done.
<mkedwards> OK.  Once ant is in, I'll try mysql-connector-java; that's the one non-Eclipse-dependency I would dearly love to see in hoary's universe.
<mkedwards> brb... rumaki-and-sherry break.  :)
<dholbach> good night everyone
<wasabi_> mdz, requesting multiverse->universe for libxalan2-java (source and binary), libxalan2-java-doc and libbsf-java (source and binary). All previous slaves to j2sdk1.4.
<lamont> wasabi_: just 1.4?
<wasabi_> Actually now that I put libbsf up also I'm not sure.
<wasabi_> checking.
<wasabi_> Nope, j2sdk1.3 also
<wasabi_> ANd as soon as those get in, I'll be doing another. ;)
<lamont> you know, you could upload a bunch and _then_ have me kick it...
<lamont> it's not like they could be any more broken than they currently are... :)
<wasabi_> Good point.
<wasabi_> Breaking ant would be fun anyways.
<mdz> wasabi_: please send those requests to elmo
<wasabi_> ok
<wasabi_> lamont, go ahead and do it, im done for now. =)
<lamont> uh... well, did it 10 min ago...
<wasabi_> oh. ;)
<lamont> do I need to do it again?
<wasabi_> nope
* koke getting really asleep
* sabmoc is back (gone 05:31:20)
<mkedwards> lamont: why does the howto suggest dd of=extracted_cd/casper/filesystem.cloop ?  No bs=?
<mkedwards> why is sysstat not in main?  iostat seems pretty important.
<lamont> mkedwards: bs has a default... not sure - didn't write the howto
<mkedwards> I think default bs=512 -- seems to be painfully slow.
<mdz> daniels: should we have an fglrx-driver dummy package to provide an upgrade path to xorg-driver-fglrx?
<mdz> mkedwards: it's the compression that's slow, not the dd
<mkedwards> mdz: 50% iowait, create_compressed
<mkedwards> _fs using almost no CPU
<mdz> I've never seen that; create_compressed_fs is painfully slow for me no matter where the output goes
<mdz> the example uses dd in order to avoid an awkward sudo command-line; it could be changed if it's really a problem
<mdz> sudo 'sh -c ... > filesystem.cloop'
<mdz> er, sudo sh -c '... > filesystem.cloop'
<mkedwards> mdz: I suspected as much, but wasn't sure.
<mdz> feel free to edit it
<mkedwards> mdz: I will, as soon as I've actually performed a successful remaster.  :)
<mkedwards> mdz: I am experiencing a certain amount of ieee1394 unhappiness when mixing heavy read and write traffic.
<mdz> mkedwards: that would explain 50% iowait better than dd ;-)
<mkedwards> mdz: right now it's over 90% write activity.
<mkedwards> mdz: almost nothing going on except create_compressed_fs dumping its image
<justdave> wow, was optimizing UI speed one of the big things in gnome 2.10 by any chance?
<mkedwards> mdz: (and it does indeed seem to have composed the entire image in memory)
<justdave> just picked up the gnome 2.10 update on my Beige G3 and it just feels a lot faster. (the menus just pop up instead of stalling for 5 seconds to load them off the disk :)
<mdz> mkedwards: swapping perhaps?
<mkedwards> swap's on a separate disk, basically idle
<mdz> it's entirely cpu-bound here
<mkedwards> mdz: after "Block size 65536, number of blocks 62629."?
<mdz> dunno, I only took statistics for the whole process
<mkedwards> I think it's the combination of dd with no bs= and the sbp2 driver that's to blame.
<daniels> mdz: we tried that, and there was some reason we didn't
<daniels> mdz: ah, that was it.  diversions.
<mdz> daniels: ugh
<aj> heh, "dd with no bs="
<daniels> mdz: yeah, it's a mess
<daniels> mdz: in an ideal world, they would just provide fglrx_drv.o and fglrx_dri.so and not need to do all this libGL diversion bullshi
<daniels> t
<mkedwards> aj: that's what I get for following a Howto.  :)
<zul> mdz: i should have something for you tomorrow
<mdz> zul: great, thanks
<zul> but now my wife is calling
<zul> so i bid you adieu
<lamont> mdz: 8088.  complete boggle.
<mdz> SWEET
<spiv> The python2.4-samba package is surprisingly large.
<lamont> mdz: uh, yeah.  if I can't get any info out of the maintainer by the end of the week, I'll just bump the magic internal version and leave a big fat love letter in changelog.
<spiv> And suspiciously contains 8 seperate 1.5MB .so files (that it installs in /usr/lib/python2.4/samba).
<|QuaD-> any developers want to tell me where ifolder is, in regards to being available for breezy?
<elmo> website's going to become readonly and/or break in 2-3 minutes
<elmo> shout now if that's a big problem for you
<elmo> www.ubuntulinux.org/www.ubuntu.com that is
<infinity> mdz : Would it be seriously out of line to ask for autogen to be synced with Debian?... It's a minor upstream bump (from 5.6.5 to 5.6.6), but it's been festering in Sarge/Sid for almost two months with no bugs, and it fixes the FTBFS on ia64.
<infinity> mdz : It's also only depended on by one other package, so not much can go wrong with it.
<lamont> infinity: the question is: what else is there in that upstream bump?
<lamont> if it's exactly congruent to hoary+ia64 ftbfs fix, then it's almost a nobrainer
<lamont> outside of ia64 not being a release goal atm...
<lamont> I admit that does still cause me some pain to say...
<infinity> Ahh, well if it's not, then I care not.
<infinity> The upstream bump is pretty minor, but the ia64 fix isn't terribly easy to isolate.  It looks more like a side-effect of having rewritten a few things.
<lamont> oh joy
<lamont> those are my favoritest
* lamont likes it when bzip takes a 61MB file down to 4.2MB
<calc> so who sells ia64 desktops now, or is the ia64 port intended as a server role?
<lamont> prolly server
<lamont> at the time it was conceived, there were still ia64 desktops
<calc> ah ok
<lamont> hell, I have 2 of them. :-)
<calc> heh
<calc> they are collectors items now
<lamont> something like that
<jbailey> lamont: s/have 2/have all 2/ ?
<jbailey> =)
<lamont> heh
* lamont has an i2000, and a zx2600
<jbailey> lamont: Are the zx series really considered workstations?
<lamont> I think the DC machines are inbetween them as far as perf goes
<jbailey> lamont: You bloody need hearing protection to work near them.
<lamont> jbailey: well, the zx2600 isn't exactly in a rackable config.
<jbailey> Hmm,. right.  mine is the 6000, I think.
<calc> i think i'll have to get a mac for my next system, i think i already have nearly the quietest x86 system you can build
<mdz> infinity: what depends on it?
<mdz> infinity: if you can confirm that it doesn't break it (we've already done our test-build cycle for the release), I don't mind
<elmo> mdz: we can probably do another of those for main, btw - and/or update the snapshot I have atm
<infinity> mdz : anjuta uses it.  It's a pretty simple thing, though (not anjuta, but autogen)
<mdz> infinity: anjuta is in universe
<infinity> mdz : I can test it, but if ia64 isn't a goal anyway, I can just as easily not. :)
<mdz> it isn't, and it has bigger problems
<infinity> Oh, and freefem3d depends on libopts9 from autogen, my bad.  So, it has a whopping TWO packages that depend on it.
<infinity> I'm inclined, however, to just drop the bug on the floor with "this will be magically fixed post-Hoary, when we re-sync", and go work on more important things, if ia64 really is that unhappy.
<Amaranth> calc: You have a Pentium M system?
<calc> Amaranth: my desktop is a athlon64 with 120mm low speed fans
<Amaranth> calc: Nice.
<Amaranth> calc: Good sturdy case that absorbs sound? :)
<calc> yea i have the antec sonata case
<calc> i think the loudest part is the oem cooler on the cpu, i used to have a p4 in it with a copper 92mm hsf which was a bit quieter
<mdz> Needed for integrated VGA (Unichrome) found on KM400 and K8M800 (my case) family of VIA chipsets. The "via" driver (unichrome.sourceforge.net)
<mdz> is included in upstream xorg 6.8.x but it's missing in Hoary.
<mdz> daniels: ^^ whaa?
<daniels> mdz: bullshit
<daniels> to be blunt
<mdz> smells like it
<daniels> our version of unichrome is far more up to date than 6.8.x, even
<mdz> Needed for integrated VGA (Unichrome) found on KM400 and K8M800 (my case) family of VIA chipsets. The "via" driver (unichrome.sourceforge.net)
<mdz> is included in upstream xorg 6.8.x but it's missing in Hoary.
<mdz> er
<daniels> 6.8.x has release 27, we have a bit over 30
<mdz> https://www.ubuntulinux.org/wiki/KubuntuPreviewComments#msg20050323034827+0000@https://www.ubuntulinux.org
<daniels> ... that url
* daniels drops a comment on the page, heads back to hacking i810.
<bob2> mjg59: she was *totally* checking you out
* jbailey decides that glibc can wait until morning before upload so that he can make sure one last time when he's awake that he truly hasn't broken anyway.
<mdz> jbailey: consciousness is recommended for glibc uploads :-)
<schweeb> way to exercise restraint
<schweeb> :p
<jbailey> mdz: Aside from that, the JAva fix is in, the xmms with nvidia fix is in, tzdata update, locales update, pitti's stat fix, and colin's locale fixes are in.
<mdz> jbailey: sounds good
<mkedwards> iostat output on ieee1394 seems to be out by a factor 8.  Very weird.
<mkedwards> mdz: hmm ... probably wasn't too smart of me to settle for pmount's sync mount of this 1394 drive, eh?  :-/
<infinity> Does anyone have an opinion about fontconfig printing "Fontconfig error: Cannot load default config file" on initial install when fonts are configured before fontconfig?  (note that it's just a cosmetic issue, as fontconfig will regenerate its own cache when its postinst is run)
<daniels> infinity: >/dev/null 2>&1 ?
<infinity> daniels : In every font package? :)
<daniels> hm.
<infinity> Actually, if they all use defoma, maybe I can work around it there...
<infinity> It should be defoma calling fc-cache, not the fonts doing it directly.. I hope..
<infinity> Ahh, even better, it's fontconfig's defoma config snippet.
<infinity> Of course, the question is, do we want to lose those error messages when they ARE meaningful?
<mkedwards> mdz: sync mount slowed down the ieee1394 device by a factor of ten.
<mkedwards> infinity: | logger -t fontconfig ?
<fabbione> morning
<infinity> pitti!
<pitti> Morning
<pitti> infinity: ping
<dholbach> good morning
<pitti> Hi dholbach 
<dholbach> hey pitti :-)
<fabbione> hey pitti
<fabbione> mdz: did you test zul fix to your problem?
<pitti> Hey fabbione, how are your dildos? SCNR
<fabbione> pitti: still there... working on extraction :-)
<pitti> fabbione: erm, they are stuck?
<dholbach> haha, morning fabbione 
<fabbione> pitti: kinda...
<fabbione> pitti: what line was the printk() in scsi_ioctl.c?
<fabbione> pitti: 121?
<pitti> fabbione: 121, yes
<fabbione> done
<pitti> fabbione: this is really a bit silly (the IDE driver doesn't do this), this should be done upstream as well
<pitti> fabbione: thanks
<pitti> fabbione: the reporter asked upstream for this, too
<fabbione> ok
<fabbione> hell if i feel trashed
<fabbione> i am not used to sleep so few hours anymore
* dholbach nods uncaffeinated towards fabbione 
<fabbione> dholbach: i am already at the first half liter
<fabbione> but i am getting headacke and that's good
<fabbione> usually i work twice as fast with it
<fabbione> (due ot the lacking of sleep)
<dholbach> headache is good?
<dholbach> hey d3vic3!
<d3vic3> morning dholbach 
<fabbione> hey d3vic3 
<fabbione> dholbach: depends from what kind of headacke :)
<d3vic3> morning fabbione 
<dholbach> hrm
<dholbach> dunno
<dholbach> d3vic3: i'll compile a priority list for universe today,... or well have a general look, because i'll have to wait for lamonts testbuild to finish
<d3vic3> ok 
<dholbach> d3vic3: you already saw  UniverseUnmetDeps  and  UniverseDoesNotBuild ?
<d3vic3> yes 
<dholbach> ok :-)
<d3vic3> I don't have a x64 or ppc, only x86 
<csj> hello, where can I about about liveCD cusdomize?
<csj> s/about/ask
<crimsun> this channel's better
<csj> thank you, and I extract filesystem.cloop and chroot into remove many packages, and now I want to compress it
<csj> but it use iso9660 filesystem, could I compress it as ext3?
<csj> I mean use module-builder
<csj> module-builder -t ext3
<csj> it says: ext3 - slower buildtime, better compression, cowloop-overlayable
<csj> it is strange that in chroot eenvironment I df and got about 500 MB
<csj> but the filesystem.cloop is 2GB
<csj> aren't they the same things?
<csj> and I use `create_compressed_fs` to compress the extract_fs I got 500MB filesystem.cloop
<csj> compresion ratio is 1:1 :(
<csj> and morphix now change its base mod to use ext3 main mod now. I dont know if ubuntu will take this?
<pitti> lamont: ping
<dholbach> are you all able to log into the wiki?
<pitti> dholbach: indeed, this fails (elmo?)
<dholbach> *cry*
<infinity> elmo brought the wiki down for a bit.  Maybe he's still breaking it. :)
<dholbach> my most beloved tool :-)
<d3vic3> indeed 
<csj> hmm, I found that the compression ratio of  module-builder -t iso9660 is much  better than create_compressed_fs
<csj> and reboot to try new liveCD
<fabbione> elmo: please kill 2.6.11 from universe
<pitti> Hi carlos
<carlos> hi
<dholbach> hey seb128 
<seb128> hi
<sabmoc> I dont see an art team on the Teams page of the wiki, but I seem to remember something about an art does. Is there an art team?
<dholbach> sabmoc: you could create that page and people could sign up on it
<dholbach> (given the wiki-login works again)
<dholbach> seb128: can i do a fix-upload of gnome-meta-package? (chucking out nautilus-media and gcompris)
<sabmoc> dholbach, maybe Im crazy, but I swear I saw something about an art team somewhere..
<dholbach> sabmoc: if you didnt see it anywhere, it's time to make it happen :-)
<seb128> dholbach: feel free to fix them, that should be done for a while but nobody seems to care (ie: update to GNOME 2.10)
<dholbach> seb128: i don't have the time to adjust all of the dependencies, but it should be installable again -- what say you?
<seb128> fixing it is better than nothing
<seb128> updating it is even better
<dholbach> alright
<fabbione> jbailey: ping?
* pitti slaps sjoerd
<dholbach> hey jani
<jani> hey dholbach
<crimsun> hi jani.  When you have a few moments, let's go ahead and whip up a list of core XFce 4.2 packages so we can pass it to elmo for syncing.
<jani> crimsun ok I'll try now
<sabmoc> crimsun, does that mean we are getting xubuntu?
<crimsun> sabmoc: not exactly :)
<dholbach> oh please... not another *ubuntu :-)
<sabmoc> they are poping up everywhere
<sabmoc> "try new toastbuntu"
<Treenaks> pubuntu?
<Amaranth> :/
<Amaranth> wiki is busted
<jani> these are the sources I got http://sourcecontrol.net/~jmonoses/xf
<jani> have to sort out which are core
<crimsun> hmm, those are actually binary packages
* Amaranth wants an eubuntu
<Amaranth> e17 CVS ;)
<crimsun> the libxfce* are required
<jani> I have tar.gz dsc and diffs for all of them
<torkel> Amaranth: the european version? ;-)
<jani> there are this many source packages :(
<jani> the libxfce* are there too
<Amaranth> torkel: Yeah, it just boots up to a white screen with black text in the middle that says "Sorry, we violate too many patents to release here."
<crimsun> jani: as long as we have the source packages for everything listed in the Depends field of meta-xfce4, we should be set
<crimsun> that's what I'm working through now
<jani> crimsun ok then 
<jani> fabbione ping
<fabbione> jani: pong
<jani> ipsec/kernel question
<jani> I read ipsec-tools > 5.0 needed for kernel 2.6 10
<jani> we have 3.3 as debian
<jani> a minor incompatiblity but maybe bugzilla worthy?
<jani> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145507
<jani> read it in theipsec howto
<Treenaks> jani: yes!
<jani> don't know how problematic it is just thought I mention it 
<fabbione> jani: i am raeding.. gimme a sec
<jani> also google for ipsec tools kernel 2.6.10 
<fabbione> it looks to me that the bugs are related to RH only.
<fabbione> due to some kind of borked init script
<zyga> hello
<zyga> anyone with ppc around
<zyga> ?
<fabbione> jani: i would check if we have the same problem in debian/ubuntu before opening bugs or whatever
<jani> I think the kernel itself introdused a change
<jani> the googled links do not mention RH
<fabbione> jani: it is still a fix that needs to be done in userland
<fabbione> it is not a kernel bug.
<fabbione> jani: the first 4 hits i get from your search are 2 RH/Fedora bugs and 2 from kame
<jani> not a bug just kernel/usrland playing catch up IMHO
<jani> ok I'll look into it sorry for the noise :)
<Kamion> elmo: if rookery's mirror could update more often than once a day, it'd be really good (for stuff like my collated installer .pot/.po files)
<fabbione> jani: please look at it directly.
<fabbione> hey Kamion 
<Kamion> morning
<fabbione> Kamion: do you have any comment on 7800 ???
<fabbione> it can still make it for -30
<Kamion> fabbione: seems reasonable. no need for a separate i2o-modules though (and in fact that'd probably be counterproductive)
<Kamion> fabbione: could you put them in the same udeb as mpt*, please?
<fabbione> Kamion: sure.. do you have any clue of which modules we need exaclty?
<Kamion> fabbione: that's scsi-extra-modules on amd64/i386/powerpc, scsi-modules on ia64
<Kamion> fabbione: I think i2o_block, i2o_proc, i2o_scsi
<fabbione> Kamion: i can add them easily there...
<fabbione> ok
<Kamion> no need for i2o_config in this context, and i2o_core will get pulled in by module dependencies
<Kamion> oh, hm
<Kamion> fabbione: actually, I misread I think, add i2o_config too
<fabbione> Kamion: ok.. we are adding all of them :-)
<Kamion> they're not particularly large
<fabbione> Kamion: are we sure we don't want them in another udeb?
<Kamion> fabbione: yes, sure
<fabbione> no i don't really care about the size
<fabbione> they are all pretty small
<fabbione> Kamion: ok.. will do :-)
<fabbione> thanks
<Kamion> at least for now; all another udeb would achieve would be having to figure out when to get that udeb installed
<Kamion> if we run into size problems we can change it later, but scsi-extra-modules or scsi-modules as above should be the right place to start
<fabbione> ok
<fabbione> what about hppa?
<fabbione> it has I2O too, but i don't see any mpt_ drivers around
<Kamion> can go in scsi-modules
<fabbione> ok
<fabbione> i wonder if i should make them optional... hmmm
<fabbione> nah let's just ship them
<fabbione> MEH let's just be sure they all there
<sabmoc> dholbach, but I dont think Im aloud to just 'make' a new team
<Kamion> sabmoc: get some people together first, then ask the community council about it when it's up and running and we can bless it
<fabbione> Kamion: thanks. all committed for -30
<Kamion> cool
<sabmoc> Kamion, you are on the community counsil?
<Kamion> sabmoc: yes
<sabmoc> Kamion, I have another page I would like to ask you about, but I think jdub is already checking into it.
<sabmoc> Kamion, I was wondering if the CanadianTeam can be recognized as official, but as I said, jdub said he is checking into it.
<jdub> sabmoc: no, i said you needed to make sure the community council confirmed it :)
<sabmoc> jdub, oh I thought thats what you were doing 
<sabmoc> ok good
<sabmoc> jdub, so then do I have to go to a meeting and ask, or can I just email someone. How does that work?
<jdub> i don't believe there's a CC mail alias
<jdub> put CanadianTeam on the agenda
<jdub> it would be best if you went to the meeting
<jdub> but if it's on the agenda, it'll be discussed anyway
<sabmoc> jdub, ok
<Kamion> infinity: #8046> meh, now I have to change debootstrap
<sabmoc> jdub, I'll bug jbailey to go, its not like he is busy
<zyga> anyone with ppc around?
<crimsun> elmo: When you have time, for the XFce 4.2.1.1 sync into universe, please pull the source packages listed at [http://sh.nu/~crimsun/list.sources]  from [deb-src http://www.os-works.com/debian/ testing main] .  The source packages are at the former URL are dependency-ordered, so packages A..B listed above any other package C will satisfy package C's build-dep.
<sabmoc> Is the next community council meeting today, or was it yesterday?
<crimsun> sabmoc: yesterday
<dholbach> sabdfl: yesterday wiki/Calendar
<sabmoc> omg
<sabmoc> oh well
<Kamion> next one's in three weeks' time
<crimsun> thanks, jani :)
<Kamion> would be two weeks but that collides with the hoary release
<jani> crimsun , thank _you_
<jani> I mostly just watched what you did :)
<sabmoc> thats just really disapointing, im so stupid
<dholbach> see you later
<Kamion> sabmoc: nothing stopping you getting people together in the meantime; in fact that's actively preferred
<Kamion> sabmoc: also, please talk to smurfix, if you haven't already; he's the local teams coordinator
<sabmoc> Kamion, I have talked to him. The problem is that the team has no way to communicate. We need a mailing list or a forum. 
<sabmoc> But its ok, three weeks isnt so long to wait, but we have 10 members after 3 days, I dont know what it will be in 3 weeks.
<jani> elmo, when you have time please add me to uploader privs (mako got the papers and sent me to you). key id is for Jani Monoses thanks
<jani> for MOTU only of course :)
<Kamion> sabmoc: maybe some kind of extraordinary meeting after next week's TB meeting would make sense, dunno
<lupusBE> is it normal that eog is version 2.9?
<Keybuk> yeah, there was no 2.10 release
<fabbione> elmo: ping?
<fabbione> elmo: for some reason gconmm2.6 on sparc landed in universe, while it is in main for all the other arches. Mind to move it?
<fabbione> gconfmm2.6 i mean
<fabbione> (or is it just sparc.u.c out of sync?)
<fabbione> the latter
<fabbione> 4 -r--r--r--  1 root root    1 2005-03-21 18:14 Archive-Update-in-Progress-mirnyy.ubuntu.com
<Kamion> jdub: how come CC approval is a prerequisite for a mailing list? for CC approval, we want the group to already be talking to each other and functioning as a proto-team
<Kamion> seems like a bit of a chicken-and-egg situation at the moment
<jdub> Kamion: it's not
<Kamion> jdub: sabmoc is under the impression that it is
* sabmoc _was_ under that impression. But it appears he made a mistake
<Kamion> ok, sorted then :)
<sabmoc> infact I just sent jdub an email saying just that.
<Kamion> good good
<sabmoc> Kamion, jdub sorry for the mix up
* jdub thought that was sorted last night :)
<sabmoc> I thought it was sorted too, but the other way
<sabmoc> jdub remember, I thought you were going to ask the CC about it, apparently the whole thing is a shambles. I've got it now though.
<pitti> dholbach: you are crazy, dude
<jbailey> fabbione: Here
<pitti> Hey jbailey 
<pitti> jbailey: morning :-)
<pitti> libc time?
<jbailey> pitti: moin
<jbailey> pitti: 1440 time, although a bit of libc while I'm waiting for answers and stuff.
<jbailey> The joys of 40 minute compiles. =)
<pitti> jbailey: it takes about three hours on my computer :-)
* pitti pats concordia
<mantiena> hi all
<sabmoc> jbailey, howdy
<mantiena> mdz: alive ?
<mvo> mantiena: probably sleeping
<jbailey> Heya sabmoc|slp 
<mantiena> mdz: good sleep then :)
<mantiena> mvo: have you got my question about .deb installation in ubuntu at monday ?
<mvo> mantiena: installing .deb is a bit tricky as apt-get does not support them directly (without a packages file). see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=47379
<mvo> mantiena: that means that we won't have dependency resolution 
<mantien1> AFAIK in ubuntu simply clicking on .deb file in file manager does nothing, I'm right?
<torkel> mantien1: they are opened in file-roller for me
<mantien1> torkel: yea, I forgot, that file-roller since 2.9.x supports deb ;)
<Kamion> elmo,thom: uh, in fact the mirror on rookery hasn't been updated in a couple of days; could you have a look at it and see what's broken?
<fabbione> jbailey: i did send you the info via email
<thom> i *really* hope this fix continues to work when i build firefox without debug
* fabbione gets some more coffee
<jbailey> fabbione: Are the previous build logs stored somewhere for that arch?  The only change was moving it to use gcc-3.4 from 3.3.
<fabbione> jbailey: i did check the one on buildd.d.o
<fabbione> i don't have old logs.. sorry
<fabbione> but if you really really need them i can grab the sources from the morgue
<mantien1> mvo: there is simple workaround for dependancy resolution: apt-get -f install :)
<mantien1> mvo: do you know gdeb tool ?
<seb128> pitti: any idea if #7981 is a nautilus issue or not ?
<mvo> mantien1: what happens when the deb file has broken dependencies?
<jbailey> fabbione: For all that, just comment the one line in the rules file CC=gcc-3.4 out.  Sorry I can't just do it myself, my sparc died almost a year ago, and I'm not getting another one for a couple of months.
<fabbione> jbailey: ok.. don't worry.. i will let you know in a few minutes :-)
<mvo> mantien1: I know gdeb and I think we need native apt-get support for debs. everything else is too hackish IMO
<pitti> seb128: uh, that's ugly
<pitti> seb128: actually this sounds more like a kernel issue
<pitti> seb128: r/w mount shouldn't be possible with a write-protected stick
<seb128> right
<mantien1> mvo: I also think, that native apt-get support for debs would be the best solution, but it seems this solution won't be implemented until 2010 :(
<seb128> should I reassign ? or rather ping to know if he has the issue from the command line too ?
<Keybuk> hmm, why isn't the update icon going away now I've updated?
<Keybuk> because I haven't updated
<robtaylor_> hmm, just found a src diff.gz that has an md5sum mismatch in universe.. 
<mantien1> mvo: problem is, that ubuntu and debian users don't have an ability to install .deb package without using not intuitive command line tools :(
<robtaylor_> http://archive.ubuntu.com/ubuntu/pool/universe/e/encompass/encompass_0.5.99.3-4.diff.gz if anyone is interested
<dholbach> robtaylor_: please join #ubuntu-motu and tell us there
<mvo> mantien1: I hope we can sort the local install stuff out for breezy 
<mantien1> mvo: some commercial software makers are providing .deb packages, look for example here http://www.skype.com/products/skype/linux/
<mantien1> but majority of simple desktop users (not linux profesionals) don't know how to install software from .deb packages, because there are no simple way :(
<robtaylor_> dholbach: thanks
<mvo> mantien1: gdeb is in universe, I don't really think we can do a lot here for hoary (it's way to close before the release)
<mvo> mantien1: don't get me wrong, I would love to have a easy-to-use install for deb files
<mantien1> mvo: I know that now is a little bit to late ;)
<mantien1> in reality there are so many usability bugs, that I don't have a time to report these, not talking about fixing :(
<mvo> mantien1: you talk about general usability bugs? or package-managment specific ones?
<mantien1> mvo: both :)
<mantien1> gdeb can't be included as workaround for user-friendly installation of local debs in hoary ? 
<mvo> mantien1: sorry, it's really too late for that. even if I would think otherwise, the release-managers wouldn't allow it into main at this stage
<mantien1> mvo: hehe, I found simple solution ;)
<pitti> seb128: the result of the "mount" command (look for "ro") would be interesting
<mantien1> mvo: ubuntu packages from main can suggest packages from universe ?
<pitti> seb128: if mount shows r/w and open-for-write calls are dropped silently, then this is a kernel issue
<pitti> mantien1: yes
<pitti> mantien1: just not recommend
<seb128> pitti: k, thanks
<mantien1> pitti: thanks for info
<mantien1> mvo: so, what you think about adding gdeb package to suggest field of synaptic ?
<mantien1> mvo: until apt-get will be able to install local debs
<pitti> dpkg -i ?
<fabbione> jbailey: it builds fine with gcc-3.3
<mantien1> pitti: ?
<mvo> mantien1: it would be a option, but I'm not really in favour of it. we could just document it in the wiki and be done with it
<zul> mdz: http://zulinux.homelinux.net/ubuntu/kernel/snd-via82xx.ko   bbl
<fabbione> hey zul
<pitti> mantien1: I mean what does gdb differently, compared to dpkg -i foo.deb?
<jbailey> fabbione: Nasty.  I'll look it up to see if it's known errata for sparc gcc then on 3.4
<fabbione> jbailey: thanks!
<zul> hey fabbione, thats the patched snd module for mdz...bbl must head off to work
<mantien1> pitti: gdeb does in user-friendly way, without reading documentation :)
<fabbione> zul: ttyl
<mantien1> mvo: btw, it seems bug http://bugs.debian.org/271904 isn't fixed in ubuntu, I'm right ?
<mvo> mantien1: possible, I haven't really looked much into gdeb
<Burgundavia> mantien1: it is not
<Burgundavia> mantien1: the motu team is working on getting .desktop is various things
<Burgundavia> mantien1: join us at #ubuntu-motu
<mantien1> Burgundavia: thanks
<zyga> anyone with ppc around?
<Kamion> zyga: what for?
* pitti raises hand
<zyga> pitti: really?
<pitti> zyga: yeah
<thom> i have ppc
<zyga> great ;-0
<zyga> soon I'll need to run some small tests
<zyga> to make sure that big endian stuff works too
<pitti> zyga: don't tell me you already rewrote libintl :-)
<zyga> not fully yet but soon
<zyga> tonight I'll be done
<pitti> you rock :)
<zyga> spring looks so great :-)
<zyga> I'm energized to code fast; >
<mantien1> mvo: what you think about adding gdeb package to suggest/recommend field of synaptic in *debian* sarge/sid ?
<mvo> mantien1: I still think that gdeb is not the right approach for the problem, but I agree that there is a need for something like it
<mantien1> mvo: I don't know better solution for now, maybe you know ?
<Burgundavia> mantien1: ideally, the user should never have to download stuff of the internet
<Burgundavia> that is very unsafe
<Burgundavia> if you train your users never to do that, then malware might not spread as fast
<mantien1> Burgundavia: yes, i know this, but in reality there are no other way for example to install skype
<Burgundavia> along with installing from the webbrowser
<Burgundavia> hmm
<mantien1> Burgundavia: ideally the user should never use closed source, but reality is different :(
<fabbione> thom: is the rsync script running again for sparc.u.c?
<Burgundavia> yes, I see that
<mantien1> Burgundavia: in any case problem is not in downloading software from internet
<Burgundavia> well, yes it is
<Burgundavia> how else is the deb going to appear on their machine?
<Burgundavia> if they can compile from source, they can install by cli
<mantien1> Burgundavia: there are lots of ways
<Burgundavia> how?
<mantien1> Burgundavia: for example by copying from usb-stick
<Burgundavia> or a cd?
<mantien1> ;)
<Burgundavia> if it can be redistributed by cd, then almost always it can go in a repo
<Burgundavia> I just don't see a good use case for gdeb
<mantien1> Burgundavia: try to support at least 10 linux desktop users, who used only windows before and then you understand usability problems ;)
<Burgundavia> I do
<mantien1> Burgundavia: I told you one use case 10 minutes ago
<zyga> mantien1: you are very right 
<Burgundavia> downloading software off the internet is a bad thing
* mvo is away to get some food
<zyga> Burgundavia: why?
<Burgundavia> if it comes on a cd, an installer can be included
<Burgundavia> zyga: security
<Burgundavia> zyga: do you trust the internet?
<Burgundavia> bad usablity
<zyga> Burgundavia: I trust distros and their keys
<Burgundavia> but that is not the wild internet
<zyga> Burgundavia: if you ment downloading from random sources
<zyga> Burgundavia: then I fully agree
<Kamion> but distributions with keys can produce signed repositories
<Burgundavia> windows style
<Burgundavia> yes
<Kamion> there is currently no infrastructure for individual signed .debs
<mantien1> Burgundavia: :-P
<Kamion> so any .deb you download on its own is totally untrusted
<zyga> Kamion: anyone can sign anything and publish their keys
<Kamion> I know I've explained this to mantien1 before, but he doesn't seem to care about security
<mantien1> Kamion: I care
<Burgundavia> zyga: too much infrastructure not in place
<Kamion> zyga: sure; but nothing knows how to process signatures on individual .debs, only on Release files
<zyga> Burgundavia: yes, but it's possible (not automated but possible)
<Burgundavia> I understand your point mantien1
<fabbione> pitti: ?
<Burgundavia> zyga: I didn't say it wouldn't be, just that is isn't
<pitti> fabbione: yeah?
<Burgundavia> Kamion: I am glad someone agrees with me
<zyga> I don't know about internal deb workings but I'm pretty sure it can be signed as soon as tools are patched to support that
<fabbione> pitti: gibb0r m3 4 c0up73 0f C4N'5 numz...
<Burgundavia> Kamion: I have been doing a lot of thinking about software and installing, security wise
<pitti> fabbione: I already gave you all my crack
<Kamion> zyga: there were extensive discussions about this on debian-devel a couple of years ago; might want to go back and read the archives
<mantien1> Kamion: problem with installing from .deb packages is not for me - it's for thousands simple desktop users
<fabbione> pitti: gimme more :-)
<Burgundavia> and came to the conclusion that a lot of problems would be solved if users never downloaded off the internet
<Kamion> mantien1: so create a repository for them to use
<Kamion> mantien1: it will take about ten seconds
<pitti> fabbione: you must learn to take care of your playdolls and don't use them all up on the first day :)
<fabbione> pitti: ahahaha
<Kamion> and you'll be able to sign it, and the problems will go away
<mantien1> Kamion: some commercial software makers are providing .deb packages without repositories, look for example here http://www.skype.com/products/skype/linux/
<Burgundavia> mantien1: that is their issue, not ours
<pitti> fabbione: since I didn't give you vulns today, will you not hate me today? *blink*
<Kamion> mantien1: (a) what Burgundavia said, (b) if you have users to support who need skype, take a local copy of it and put it in a proper repository
<mantien1> Kamion: I can't teach *all* commercial vendors, but I can make software more user-friendly
<Kamion> mantien1: or encourage skype to create a repository
<Burgundavia> mantien1: but at what expense?
<fabbione> pitti: i always love you
* pitti feels loved and is happy
<pitti> "Dobby loves you"
<Kamion> mantien1: in the long run, encouraging people to use unsigned software is not user-friendly, even though it might look that way on the surface
<Micksa> cd
<Micksa> ack
<Kamion> not everything with a GUI is user-friendly :)
<zyga> Burgundavia: signing alone does not provide security
<mantien1> if someone wants to find 10 reasons why don't make theyr software user friendly, then he finds
<Burgundavia> zyga: it helps
<Kamion> zyga: it's a necessary condition, even if not a sufficient one
<zyga> Burgundavia: you must be able to identify the signer and be sure you trust him/her
<Burgundavia> mantien1: user friendly also includes secure
<zyga> Kamion: yes it is
<zyga> Kamion: but look at all those 'signed and safe' activex crap 
<Kamion> zyga: sure
<Burgundavia> if you have no security, it doesn't matter how nice it is to use
<Kamion> zyga: like I say, it's not a sufficient condition
<Burgundavia> malware will bring you to a screeching halt very quickly
<mantien1> in any case I just want to make ubuntu more user-friendly, if ubuntu developers don't want this it's up to them 
<zyga> Burgundavia: the only way to stop signed malware is to get trusted external programs signed by more than one group
<Burgundavia> zyga: and to make users really think before installing anything
<Kamion> mantien1: you are taking what people are telling you and reducing it to trivialities in an unfair way
<zyga> Burgundavia: that is simply not possible
<Burgundavia> zyga: and to make them think, provide a seperate program, not a webbrowser
<Burgundavia> so they get into the thinking that a webbrowser is for browsing, not for installing
<Kamion> mantien1: other people are trying to think about user-friendliness in ways that go beyond "wrap GUI around command-line tool"
<zyga> Burgundavia: people are not only afraid of computers, they are totally clueless
<zyga> Burgundavia: hey there are such tools
<Burgundavia> zyga: I have done windows helpdesking, so I have seen this a lot
<Burgundavia> zyga: exactly
<zyga> Burgundavia: fedora had this nice program (bound to .rpm by default)
<zyga> Burgundavia: not only does it allow you to do a one click instaqll
<Burgundavia> gdeb is part of the download stuff with the webbrowser chain
<zyga> Burgundavia: it also tells you that it's not signed and such
<zyga> Burgundavia: gdeb? 
<mantien1> Kamion: if there are no other solution then "wrap GUI around command-line tool" is better solution than nothing
<Burgundavia> graphical installer for local debs
<zyga> Burgundavia: but it's stand alone - right?
<Burgundavia> yes
<Kamion> mantien1: I disagree.
<Burgundavia> but the debs have to get to the computer somehow
<Kamion> mantien1: I think that would do more harm than good.
<Burgundavia> mantien1: I would disagree as well
<zyga> Burgundavia: then give it a whitelist of keys, online update and nice big red exclamation mark telling that something is not secure
<Burgundavia> zyga: users don't read error messages
<Kamion> I absolutely do not ever want to see "click on this .deb to automatically install it on your Ubuntu system" (oh, by the way, no security) on a web site
<zyga> Burgundavia: then make them - see firefox XPI install window
<Burgundavia> zyga: that is part of the issue
<Kamion> zyga: we already have whitelist, online update, big red exclamation mark for repositories
<Burgundavia> we have trained users to ignore error messages
<Burgundavia> so we need to rethink
<zyga> Kamion: then you've done all you could
<Burgundavia> zyga: that is not enough
<zyga> Kamion: unless you want to make 'dummy' accounts by default
<zyga> that need assistance from professional personel to do anything 
<zyga> Kamion: but that eliminates 99% of average joes and their malware-crippled windos boxes
<Burgundavia> we can let users install their own stuff, but in the safe confines of something like gnome-app-install
<mantien1> Kamion: I think we can find more productive subject to talk about
<zyga> Burgundavia: safe confines - chroot app install with vm like vmware ;] 
<zyga> Burgundavia: if this app screws something up - to hell with it
<zyga> but that's a few years away...
<zyga> ok back to coding :-)
<Burgundavia> hmm
<jdub> Amaranth: around?
<Amaranth> jdub: Yeah.
<Amaranth> jdub: What's up?
<jdub>        Module: gnome-menus
<jdub>       Version: 2.10.1
<jdub>         * Make user desktop entries override system ones (Mark)
<jdub> :-)
<ogra> jdub, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300962
<ogra> ;)
<Amaranth> jdub: lmao, i already hacked around it and got a bug fixed to make the hack around work with python-xdg
<Amaranth> This whole thing has been one brick wall to another.
<jdub> ogra: ;-)
<Amaranth> jdub: Thanks though. ;)
<Amaranth> wow, xscreensaver doens't look like ass anymore
<Amaranth> i guess i never noticed. :P
<Kamion> wow, it worked
* Kamion prepares to add >9000 translated strings to the installer in one shot
<fabbione> Kamion: EH?
<fabbione> does that mean another full installer translation?
<fabbione> s/translation/upload/
<Kamion> no, it means importing iso-codes translations into choose-mirror :)
<fabbione> ah ok
<Kamion> but there are quite a spectacular number of strings there
<Kamion> s/are/is/
<fabbione> i can see :-)
<fabbione> YAY the i2o addition was perfect at the first shot
<Kamion> -rw-r--r--  1 cjwatson cjwatson 449054 2005-03-23 13:04 debian/choose-mirror/DEBIAN/templates
<Kamion> wow
<dholbach> is the wiki back on track?
<elmo> dholbach: yes
<dholbach> elmo: YOU! ROCK! :-)
<fabbione> Kamion: eheheh
<fabbione> elmo: did you read the scrollback in here?
<elmo> fabbione: meh, just am
<elmo> there's far too much in here for me
<fabbione> elmo: sure.. take your time
<elmo> fabbione: sparc.u.c is down ATM, in terms of updating, I need to relocate it
<fabbione> elmo: ok. Kamion was also mentioning the mirror on roockery
<elmo> yes, same problem
<fabbione> ah ok
<elmo> mirnyy's load problems were due in no small part to the 30min write-fests that are cron.daily pulses
<elmo> so mirnyy's becoming a cdimage only mirror
<fabbione> make sense.. we all trust your judgement :-)
<fabbione> i will work around it while you fix it
<fabbione> s/fix/move
<elmo> fabbione: confirm you want 2.6.11 killed?
<mjg59> jdub: I've just been hit by the realisation that I could take in a trip to Cockfosters on my way to Sydney
<fabbione> elmo: yes.
<jdub> mjg59: COCKFOSTERS!
<Kamion> elmo: anywhere I could reasonably move the installer translation files generation in the meantime?
<Kamion> I suppose I could run it at home or something
<elmo> Kamion: I'm syncing rookery now
<fabbione> elmo: do you think it will possible to allow just one pulse to sync sparc.u.c and move it later? there are some packages that i upload that are not there and i need them as Build-Dep for other stuff 
<Kamion> elmo: ah, ok, thanks
<elmo> hmm, no I'm not.  meh.  stupid rsync limits.  one sec.
<elmo> fabbione: ok
<fabbione> elmo
<fabbione> elmo: thanks!
<dholbach> elmo: will you need the source package name for morgue-packages?
<elmo> dholbach: yes, pls
<dholbach> elmo: alright, thanks - will compile a HUGE list, to make sure, universe has no bugs and all lists are cleared, right?
* dholbach was simply expressing his feelings ;-p
<elmo> boggle?
<wasabi> elmo, get all my messages?
<elmo> wasabi: the java stuff?  probably, but i'm a bit flooded by msg backlog - any chance you could please mail me?  
<wasabi> sure
<wasabi> elmo@ubuntu.com?
<elmo> wasabi: james@ubuntu.com
* fabbione -> bbl
<elmo> mirnyy synced; rookery syncing
<fabbione> elmo: great thanks
<zyga> hmm
<zyga> some portable byte swap functions you know of?
<zyga> byteswap.h?
<fabbione> elmo: feel free to stop syncing sparc and move it whenever you want.. i increased the local archive to spool 10 days of packages and not be dependent on sparc.u.c
<Kamion> zyga: how about hton[sl] () and ntoh[sl] ()?
<pitti> zyga: htons(), ntohs() maybe?
<pitti> :-)
<pitti> amu: why can't kdepim use some stable libraries, but must insist on taking the bleeding edge unstable crack?
<dholbach> seb128: i'll remove gcompris and nautilus-media from meta-gnome2
<ogra> pitti, thats KDE (Keep Da Edge) ;)
<seb128> dholbach: k
<pitti> elmo, amu: https://www.ubuntulinux.org/wiki/KubuntuPackagesForMain
<elmo> MartinPitt?: These ship multiple shared libraries in one deb which violates Debian packaging standards. 
<elmo> pitti: dude, that's BS
<elmo> it "violates" junichi's crackful not-even-close-to-being-a-standard "packaging guide"
<pitti> elmo: doing this is not really the recommended way
<pitti> elmo: you get into hell if only one SONAME changes, but the others don't, etc.
<elmo> I really don't see how
<elmo> and no one's ever explained to me why it's hell
<pitti> elmo: if I have libfoo.so.2, this is packageed into libfoo2
<pitti> a new API comes around, fine -> libfoo.so.3 -> libfoo3
<pitti> but if there is libbar.so.4, how do you name the package then?
<elmo> it doesn't matter as long as you change it?
<pitti> if you stuff them itno one package?
<elmo> the name of the package is cosmetic
<pitti> elmo: no, it's important for dependencies
<elmo> no, it's cosmetic
<Kamion> pitti: changing it is important for dependencies; the name itself isn't
<pitti> elmo: you have to upload the same libraries again in a new package
<elmo> it doesn't matter if it's libfoo3 or libfoopkguidesucks3
<elmo> pitti: so what?  in a lot of cases where people advocate splitting, any given program is going to be linked to both libraries anyway
<pitti> so if libfoo1 ships {libfoo.so.1, libbar.so.2} and libfoo2 ships {libfoo.so.2, libbar.so2} you have a file conflict
<pitti> ^ BAM
<jbailey> Anyone have some spare cycles on an amd64 for a test glibc build?
<pitti> so you have to increase the SONAME of libbar too
<elmo> jbailey: err, yeah, concordia
<pitti> which is crack, because it didn't change
<elmo> pitti: replaces: the old one :P
<pitti> elmo: you also need a virtual package to not break existing dependencies
<elmo> eh?
<elmo> no you don't
<pitti> this gets so clumsy if it happens again...
<pitti> libfoo2 has to provide libfoo1 for the libbar part
<elmo> sorry dude, but you're on crack, debian has shipped multiple libraries in a package since day zero.  and it WORKS.
<jbailey> elmo: Ah neat, didn't know about that one.  Doesn't seem to have my ssh key on it.
<pitti> it works as long as all the libraries in it are changed at the same time
<elmo> you need to start from that premise, rather than pretending like it's so broken it could never possibly work
<elmo> (hello, {g,}libc)
<elmo> jbailey: yeah, one sec, I need to add you to the porting_team group
<pitti> well, I just noted it, that doesn't mean that I say no to main inclusion
<elmo> pitti: again, no, not true
<jbailey> elmo: Thanks.  How do I arrange to install build-deps / is it possible to arrange a chroot for testing afterwards?
<pitti> elmo: if libc5 and libc6 shipped another library with the same soname, they would clash as well
<elmo> jbailey: ask for build-deps for build-deps, I can trash the hoary-clean chroot with whatever packages you produce if you want
<jbailey> elmo: Wonderful.  In the unlikely event that you choose to sleep sometime, is there someone else to ping for build-deps?
<pitti> lamont: ping
<elmo> jbailey: thom
<elmo> jbailey: both i386 and amd64 chroots have glibc's build-dep (and a huge bunch besides) installed tho
<elmo> jbailey: your accounts should work now
<jbailey> Cool, thanks.
<elmo> remember to 'linux32 dchroot' to get to the i386 one
<mjg59> Gah!
<mjg59> hwdb-client failed to send mail
<elmo> (well 'linux32 dchroot -c hoary-i386'
<mjg59> How's it meant to work?
<ogra> mjg59, its not supposed to send mail ;)
* pitti -> food
<mjg59> ogra: Hm. It failed with Unable to connect to server
<ogra> mjg59, hopefully it dropped a file on your Desktop as it should, mail it to me ;)
<jbailey> elmo: Yup thanks.
<zul> hey
<jbailey> Ah, linux32, nice.  This is my first time on an amd64 box.
<ogra> mjg59, there is no server to connect to yet :)
<mjg59> ogra: Is it supposed to work?
<mjg59> ogra: Ah! 
<elmo> Kamion: rookery's synced btw
<Amaranth> seb128: Switched to PyXDG 0.9 instead of keeping 0.8 with the patch?
<Kamion> elmo: thanks, updating translation bits nw
<ogra> mjg59, its supposed to work on release .... for now i'm only collecting the data by mail to get an overview about whats out there and what i have to regard on transfer
<Kamion> now
<jdub> thom: around?
<thom> jdub: yo
<mjg59> ogra: Ok, cool. Sent.
<seb128> Amaranth: any reason to not update ? The changelog is small
<ogra> mjg59, thanks :)
<dholbach> i'm looking through    wiki/MorgueCandidates   - Mithrandir requested removal of phpbb2 - any opinions?
<Amaranth> seb128: Nope, afaik it was just that patch. :P
<mjg59> ogra: One minor issue with hwdb-client - I needed to move the mouse off the forward button and back onto it before I could click
<seb128> Amaranth: according to the changelog that's not
<mjg59> If I just left the mouse pointer in the same place, I couldn't repeatedly click forward
<Amaranth> ah
<ogra> mjg59, was it active before ?
<mjg59> Also, some of the text was appearing on top of the line
<mjg59> I clicked forward, it turned grey, the next page appeared, it became active again, I clicked, nothing happened, I moved the mouse up, I moved the mouse down, I clicked, it went forward
<ogra> mjg59, thats an rtf issue, i'll fix it with the next upload....the button thing is a gtk bug i dont know how to solve, gtk requires yu to move the mouse before ou can click a button if it was non active inbetween...
<mjg59> Ok, cool
<mjg59> Other than that, it's very nice!
<ogra> seb128, ^^^ any known way arund that ?
<ogra> mjg59, thanks :)
<mjg59> thom: seb128: Thanks, I'm able to sleep with the sleep key now
<thom> mjg59: cool
<zyga> Kamion, pitti: htons ands stuff - thanks :)
<zyga> pitti: mo files from ppc are written in big endian or little endian?
* zyga goes to fetch ppc package
<jordi> w
<jbailey> 4 glibc compiles on the go, time for a walk.
<Kamion> elmo: how often does rookery sync, normally? I'd like to generate collated translation files as often as is reasonable, since they're useful to Adi.
<dholbach> elmo: could you please morgu-ify: vdkxdb, chill, cursel, ipmenu, nautilus-media, update, kernel-patch-2.4.25-m68k, kernel-patch-2.4.26-m68k, glademm, torch-examples, libmrproject ?
<pitti> amu: is it possible to get rid of the smartcard stuff (opensc/openct)?
<pitti> amu: or even better, drop these to a suggests: and use them if they are installed?
<dholbach> and i'd like to morgu-ify  phpbb2  and  gcc3.2 (doko gave ok)  too, could anybody please help me with judging those?
<seb128_> ogra: no idea
<seb128_> mjg59: np, thanks for the patches
<ogra> seb128, i thought so :) thanks
<zyga> pitti: ping?
<pitti> zyga: pong
<zyga> pitti: www.suxx.pl/i18n/ppc-test.tar.gz
<zyga> pitti: could you please make && ./test some-mo-file.mo
<zyga> just to make sure ;] 
<zyga> I've never had to deal with endianess before
<zyga> ignore the warrning... i've cut stdio.h away by accident
<pitti> zyga: ~/ppc-test $ ./test gtk+.mo
<pitti> Big endian
<zyga> great so no suprise here, thanks :)
<seb128> jdub: when is planned GNOME 2.10.1 ?
<jdub> seb128: april 4th/6th
* jdub pokes tongue out at seb. :-)
<pitti> seb128: will you upload the new crack at april 4?
<seb128> pitti: that's the question
<jdub> i was wearing my gnome hat when i scheduled that ;)
<pitti> seb128: I need some hours to update the language packs
<seb128> do I need to backport fixes
<seb128> or am I allowed to package 2.10.1 :)
<jdub> seb128: i think we need to choose our battles wisely for 2.10.1 uploads
<pitti> seb128: if you just do this again, mdz will suffer another heart attack
<jdub> we can always update translations post-release
<seb128> pitti: that went fine for warty
<jdub> so let's not do package updates just for translations
<pitti> jdub: no, that's not what I meant
<pitti> jdub: but _if_ seb uploads new packages, then these will certainly carry new translations
<jdub> pitti: yes
<jdub> pitti: i'm just want to limit the damage
<pitti> jdub: and I'd like to build fresh base packages right before the release
<seb128> jdub: how do we get translations updates if that's not from these uploads ?
<jdub> seb128: import into rosetta, etc.
<seb128> jdub: what damage ?
<seb128> jdub: dude, that doesn't work
<pitti> jdub: sure, I in no way encourage to upload the new crack without looking at it :)
<jdub> seb128: basically, we want to get away with uploading as little as possible
<seb128> jdub: rosetta is not ready yet, we can't rely on it for hoary
<pitti> jdub, seb128: my scripts can emulate Rosetta almost perfectly now :)
* pitti currently builds crack to import translations directly from gnome cvs
<seb128> pitti: rosetta is not automatically update with upstream translations, is it ?
<pitti> seb128: no, but langpack-o-matic will do soon *hehe*
<pitti> seb128: I have to do this anyway now for the Xhosa crack
<jdub> seb128: i suppose we should not be scared of new tarballs that only contain translations :)
<seb128> speaking about xhosa, there is some po in the GNOME CVS now
<pitti> seb128: yes, I know. I'm going to extract these right now
<seb128> jdub: we should not be scared at point versions for GNOME modules :p
<pitti> seb128: it's a bit difficult since they need to be mapped to translation domain names
<jdub> seb128: "careful" more than "scared" ;)
<seb128> jdub: epiphany has a fix in the CVS now, and I want it for hoary
<seb128> should I start spending time tracking the CVS and backporting fixes ?
<seb128> or wait for 4th april and upload 10.0.1 ?
<jdub> GNOME 10!
<seb128> ups, 2.10.1
<jdub> YAY!
<jdub> ;-)
<seb128> Can I blog about the new GNOME 10 ? :p
<pitti> Ubuntu, the future distro
<jdub> i'll leave it up to you, we just need to be very careful :)
<jdub> man
<Treenaks> hey, if Sun can do it (Java 5!)...
<jdub> so many people thought i was serious
<jdub> i couldn't believe it
<seb128> lol
<jdub> nutballs
<seb128> so mdz will track me down if I upload 30 modules in 2 days again for 2.10.1 ? :)
<pitti> if he survives this shock, yes :)
* seb128 will consider the changelogs and what fixes we want
<zul> and he will probably kill you :)
<pitti> seb128: you might consider going to .au a bit earlier and hide in the outback
<seb128> ah ah
<pitti> seb128: why is gconf in main when we have gconf2?
<pitti> or is gconf still used?
<seb128> it is ?
<seb128> that's an old GNOME 1 stuff
<pitti> yes
<pitti> seb128: I just wonder whether upstream's "gconf.po" belongs to gconf or gconf2
<pitti> I assume the latter
<seb128> pitti: GConf2.pot in gconf2
<pitti> seb128: okay, thanks
<seb128> np
<pitti> seb128: now I have the translation domain, the Ubuntu source package, and the po file name and have to map them to each other
<pitti> all three are different in some cases :-/
<amu> pitti: the only real needed is the agent
<seb128> Amaranth: 
<seb128> Version 2.10.1
<seb128>         * Make user desktop entries override system ones (Mark)
<seb128> (gnome-menus)
* jdub mentioned that earlier ;-)
<jdub> Amaranth swore ;)
<seb128> jdub: have you tried the menu editor ?
<jdub> nup
<lamont> pitti: ack
<pitti> lamont: PHP4 failed on ppc with a mysterious error (amd64 and i386 work fine)
<pitti> lamont: probably a give-back issue
<pitti> lamont: (warty-security)
<lamont> pitti: yeah -that's our ppc friend. given back
<pitti> thanks
<amu> pitti: no way to suggest them, ex. kdepim needs gpgsm at buildtime, if it's not there, it will be not supported by kontact
<lamont> daniels: you around?
<pitti> amu: if you have the feeling that this can be supported for 18 months in any way, and we won't run into trouble with broken smart cards, then go ahead
<pitti> amu: personally I don't think dropping smartcard support is particularly bad
<amu> pitti: i suggest to haggai let's drop it one more time. If you can accept just the agent would be enough for now
<pitti> amu: yeah, thats fine for me
<amu> pitti: cool,thx
<daniels> lamont: trying not to be.  sup?
<lamont> daniels: nvidia-settings... you care about that?
<lamont> because it's ftbfs on amd64
<amu> daniels: btw. is there a way to STOP services which run from /etc/X11/Xsession.d
<daniels> lamont: bleh.  will check it out tomorrow, thanks.
<daniels> amu: errr ... nope
<daniels> amu: what in particular?
<daniels> amu: most of the stuff you can configure to not start with /etc/X11/Xsession.options
<daniels> amu: but nothing like invoke-rc.d
<daniels> g'night folks
<lamont> daniels: will file a bug for you then...
<daniels> lamont: cheers
<amu> daniels: gpg-agent, on a multiusersystem there's no glabal way to end their session
<lamont> seb128: you aroudn?
<seb128> yep
<seb128> jdub: the new gnome-menus is bong
<seb128> jdub: http://bugzilla.gnome.org/attachment.cgi?id=39135&action=view
<zyga> pitti: ping
<pitti> zyga: I'm still here :)
<zyga> pitti: www.suxx.pl/i18n/ppc-test2.tar.gz
<zyga> still tiny but this time it may find something usefull (eg number of strings)
<zyga> It'd be great if we could work on the same .mo though...
<zyga> maybe I'll upload a some common reference?
<pitti> zyga: same mo:
<pitti> ~/ppc-test2 $ ./test ../ppc-test/gtk+.mo
<pitti> Big endian
<pitti> We've got 106 strings
<pitti> zyga: sure, just stick a mo file into the tarball
<Kamion> mdz: please merge colin.watson@canonical.com--2005/casper--netcfg--0 patch-1; extra netcfg question added while fixing #7098
<zyga> my gtk+.mo has 106 strings too, that means it's okay :)
<zyga> ok all I needed is here
<zyga> back to putting it all together
<zyga> thanks a lot :)
<jbailey> elmo: ping?
<jbailey> Actually, anyone here insane enough to try my amd64 glibc debs? =)
<jbailey> It'd be nicer to get broader testing than I'll get with running shell commands in a chroot.
<zul> heh..
<zyga> jbailey: compile or run?
<zul> jbailey: you could try #ubuntu ;)
<jbailey> zyga: To run.  I've got them built.  It should be quite safe, I've got it running as my main glibc on my k7, and am about to do it on my ppc box.
<jbailey> zul: That's just cruel if there's a problem.
<zyga> jbailey: toss the url, I'll play with them in free time
<zul> jbailey: :)
<zyga> btw as for ppc
<zyga> how is g5 different from g4?
<zyga> apart from 64bit stuff?
<jbailey> zyga: Thanks, I'll probably look for someone with a system sooner, or just do a chroot test.  I'd like to get these uploaded pretty quick.
<elmo> jbailey: ?
<jbailey> zyga: There's a pile of things that are optional in some chips, like altivec, sqrt instruction, etc that you can assume are in a g5.
<zyga> jbailey: so not all g4 have got vector stuff?
<jbailey> elmo: Can you toss libc6_*deb and locales_*deb from concordia:~jbailey/glibc into a chroot please?
<zyga> jbailey: If I were to buy ibook for example?
<jbailey> zyga: I'm not a PPC guru, so I really don't know more than what I've said.  Like I don't know what the guarnatees are between a g3 and a g4.
<jbailey> zyga: But I think that's right from when svenl has told me.
<jbailey> And Phython.
<zyga> AFAIR g3 are really different things but I may be wrong
<elmo> jbailey: installed in clean chroot, stuff seems to still work
<jbailey> elmo: Thanks. =)
<jdub> seb128: cripes, you're right - it's all french!
<lamont> jdub: it's all part of the french plot for world domination
<zul> piquistes
<jbailey> Zut!  Ils ont dcouvert l'ide!
<seb128> jdub: ah ah
<lamont> jbailey: lol
<jbailey> lamont: Well, at least now I won't have to hide my thick qubecor accent when I talk English now ;)
<zul> jbailey: heh
* ogra starts to hate pcmcia-cs, no way to upgrade it without a reboot
<zyga> jbailey: qubec?
<jbailey> zyga: The primarily french speaker province in Canada to which I'm moving in a few months.
<jbailey> s/speaker/speaking/
<jbailey> Bah.
<adobbie> yeah, it's french outside of Montreal
<zyga> jbailey: I studied french some time ago
<jbailey> adobbie: There's a reasonable amount of french w/in Montral too.
<zyga> jbailey: need to practice sometime
<adobbie> jbailey: yes there is, just as there is in many places in N.B. and Ontario
<csj> hi all, I want to customize the hoary liveCD and I `mount /mnt/extracted_fs /mnt/build -o loop` then chroot into remove many packages and now I got 563M = `du -sh build`, but why extracted_fs is 2G and I use create_compressed_fs to compress extracted_fs and I got 507M filesystem.cloop?
<csj> isn't it should much smaller than 563M?
<csj> I mean I remove so many packages in chroot environment but no big effect in its size of  filesystem.cloop
<zyga> hmm
<zyga> any gstreamer experts around?
<Kamion> zyga: G5's more different from G4 than G4 is from G3, as far as I know - for example you can't run the same kernel on a G4 and a G5
<thom> jbailey: i can test amd64 libc
* zyga wishes he had some ppc box
<jbailey> thom: I just hit the upload button. =)
<Keybuk> jbailey: how Linus-like of you
<thom> rock'n'roll
<Keybuk> "it boots?  it's 2.3, you're lucky it even built!"
<elmo> Keybuk: dude, he's done far more testing than most people uploading glibc to ubuntu do
<jbailey> Keybuk: Nah, I actually tested graphics and sound on two arch's, chroot tests on two others.
<thom> zyga: i have a dual g4 here which is more or less idle; if you need test cycles just ask
<jbailey> Keybuk: I tend to figure any glibc that can run mozilla and gnome is good enough. =)
<zyga> thom: not really cycles - feel of what's different and why :)
<elmo> thom: oh, so that's where the other buildd went?
<Keybuk> heh, that's like my old libtool test suite
<Keybuk> "if it can build gnome and evolution, it passes"
<zyga> thom: too bad that apple wants big $$$ for their stuff
<thom> elmo: rofl, that'd be a G5 ;-)
<zyga> thom: btw, DUAL g4?
<zyga> I thought there were only dual g5's
* Keybuk pets his dual-opteron
<Keybuk> *IN MY MIND*
<thom> zyga: sure; this a quicksilver dual 450 g4
<zyga> thom: good to know
<jdub> mmm, dual opteron
<zyga> jdub: I'll wait for dual core ;] 
<trulux> hey adobbie 
<trulux> pitti: hi
<adobbie> hey
<thom> zyga: i hope they do it right and have dual hypertransport per chip
<adobbie> I'm sure they will
<zyga> thom: I was thinking about amd
<adobbie> everyone wants dualcore Xeon with EMT64 and hyperthreading :)
<Mitario> hi everyone
<trulux> pitti: adobbie and me are talking on the overhead of having to maintaine separate gcc packages, after testing, and after the study of what modifications the SSP can introduce to the toolchain, we think that having it available but not enabled by default on compilation is the way to go
<Keybuk> jdub: it will be mine, OH YES, it will be mine
<Mitario> koke, around?
<zyga> thom: Intel can go to hell with the temperature of their chips
<zyga> thom: my amd box is cooler than my own skin
<thom> adobbie: ew; em64t is a waste of time compared to full fat opteron
<adobbie> pitti: ie. you only execute the gcc modifications of you explicitly tell gcc to do so
<pitti> trulux: well, not for Hoary :)
<zyga> thom: em64t is slower in 64bit mode, it pretty much suxx 
<adobbie> thom: what is it lacking that AMD64 has?
<trulux> pitti: of course
<trulux> pitti: Hoary+1
<thom> zyga: eh? so was I (talking about amd)
<pitti> adobbie: a wrapper around the standard gcc is not possible somehow?
<zyga> adobbie: speed, low power factor
<thom> decent memory controllers
<adobbie> zyga: will be interesting to see benchmark comparisions
<zyga> adobbie: go and google them out, there's plenty of them
<trulux> pitti: yeah, we have C-based wrappers for ld and gcc, provide gcc-hardened and ld-hardened wrappers, but the way to go I think is related with right use of specs file (ie. profiles)
<zyga> and all support what I've said unfortunatly
<trulux> tseng: ping
<pitti> trulux, adobbie: btw, you know that breezy (= hoary+1) will use gcc 4?
<zyga> pitti: really?
<zyga> pitti: gcc 4 is ready for prime time?
<pitti> this was planned AFAIK
<pitti> doko: ?
<seb128> jbailey: around ?
<zyga> (msg list traffic suggests otherwise AFAIK)
<adobbie> pitti: when is breezy planned for release?
<pitti> adobbie: october 2005
<jbailey> seb128: Ayup
<seb128> jbailey: could you join #gnome-hackers on irc.gnome.org ?
<trulux> pitti: kein Probleme, I will work on it
<dholbach> ok... i'll be off - see you later
<adobbie> trulux: I do believe pappy is already looking into gcc-4.0
<pitti> trulux: "kein Problem" btw :)
<trulux> pitti: right, dman typos
<trulux> :D
<adobbie> trulux: I do not know however what Etoh plans to do.  afaik he's quite busy
<pitti> brb
<trulux> adobbie: yes, I need to look at him
<trulux> adobbie: I talked to him when he was firslty planning to do it
<pitti> gotta go, cu later
<adobbie> gcc site doesn't have detailed branch status for 4.0
<mjg59> Argh.
<trulux> adobbie: I'm going to start it today
<trulux> adobbie: jsut in need of toolchain messing
<trulux> shit, typos... ;P
<adobbie> trulux: you plan to mess with 4.0?
<trulux> adobbie: yes
<adobbie> I'll warn you now that it's no simple task
<trulux> adobbie: "co'ing" gcc-4_0-branch
<trulux> NP
<adobbie> 3.3 to 3.4 was big so I imagine 4.0 is even bigger
<trulux> it's
<trulux> :)
<mjg59> g-s-t unconditionally sends a command to set the modem volume. sl-modem then says ERROR. g-s-t waits 75 seconds and then tries to connect anyway, then succeeds.
<mvo> mjg59: does sl-modem not support "atl"?
<jbailey> fabbione: ping?
<mdz> morning
<ogra> morning mdz 
<mvo> morning mdz
<mjg59> Anyone have any idea how we can work around this?
<mdz> mjg59: teach slmodem to just say OK?
<mdz> is slmodem waiting 75 seconds because it doesn't recognize ERROR, or is it just being silly?
<mvo> mdz: I think g-s-t is silly :/
<mvo> I remember a irc discussion with carolosg about a similar problem some time ago, this 75 timeout may be his workaround
<zul> hey mdz
<jdub> mvo: 75s? that's a *long* time ;)
<mdz> zul: downloaded your module, will test after I catch up this morning
<zul> mdz: cool no problem
<Kamion> mdz: what's your opinion on the last date when I could upload installer translation changes for hoary?
<Kamion> mdz: the Xhosa team are working to quite a tight deadline
* lamont grumbles at #301044
<Kamion> mdz: as far as I'm concerned any time up to two days before release is possible, but I wanted to check
<mdz> Kamion: fine by me
<mvo> jdub: *nod*
<Kamion> mdz: ok; I'll try to get as much in before that time as possible
<koke> Mitario: I'm back
<mvo> hey Mitario :)
<koke> Mitario: I'm looking to CVS now and you've uploaded update-notifier's translation into update-manager :)
<mdz> Kamion: casper merged
<mdz> Kamion: I assume this ought to be uploaded as well?
<mjg59> Can someone upload a single-line patch to sl-modem in multiverse?
<mvo> mjg59: yes, what url?
<mjg59> mvo: Hang on
<Mithrandir> mvo: can you test and give me feedback on the utf8-migration-tool?
<mvo> Mithrandir: yes, about the rename stuff? 
<Mithrandir> yeah
<mjg59> mvo: http://www.codon.org.uk/~mjg59/tmp/slmodem.diff
<Mithrandir> and in general, if you care. ;)
<mvo> Mithrandir: sure :) will try it in a couple of minutes
<Mithrandir> mvo: thanks
<seb128> jdub: around ?
<jdub> yo
<seb128> about the new gnome-menus
<seb128> comment from markmc
<seb128> "(They are being pulled in because of the <KDELegacyDirs/> in the .menu file -
<seb128> see the menu spec for more details of the whys and wherefors)"
<seb128> (the dup internet category is a dup though)
<seb128> ups
<seb128> is a bug
<seb128> jdub: do we want to update it ? if yep, do you know what the right way to kick the craps from /usr/share/applnk out of the menu ?
<jordi> is there a known bug that would make array6 not install a kernel meta-package?
<mjg59> seb128: Modemlights doesn't seem to work at all
<jdub> seb128: we don't have to worry about KDELegacyDirs anymore
<Kamion> mdz: yeah
<Kamion> jordi: yeah
<seb128> mjg59: http://bugzilla.ubuntu.com/show_bug.cgi?id=7950
<jdub> seb128: we ought to be able to drop that
<Kamion> jordi: fixed between array 6 and preview
<seb128> jdub: k
<jordi> Kamion: alright
<jdub> seb128: also, when you update, can you kill off the bad preferences items? :)
<mjg59> seb128: Even allowing for that
<seb128> mjg59: your bug is a dup of this one ?
<seb128> mjg59: http://bugzilla.ubuntu.com/show_bug.cgi?id=7761 too
<mjg59> Gah. Yes, the first one I submitted was - please close it
<seb128> k
<mjg59> seb128: Hrm. Hang on. I've got latest gnome-applets installed, but it still wants the root password as far as I can tell
<seb128> mvo: a client for you :p
<mjg59> seb128: Ok, it looks like my password may work, but the applet still does nothing
<mvo> mjg59: I look into it later, I noticed that it still has issues (which means another perl debugging session *arg*)
<xuzo> hi
<mjg59> mvo: Heh, thanks :)
* mjg59 gets very confused by the applet's behaviour
<xuzo> i think that found a bug in hoary's instalation, any developer here :) ?
<mvo> mjg59: this applet is _so_ fragile
<mjg59> mvo: Argh!
<mjg59> mvo: It does ifup ppp0 and gets Interface ppp0 already up
<mjg59> mvo: So the issue seems to be that ifup ppp0 does nothing
<mjg59> It starts a pppd that immediately hangs up
<mvo> mjg59: *autsch* 
<Kamion> xuzo: it would be better to say what your problem is and see if anyone knows the answer, rather than waiting for somebody to respond first :)
<xuzo> Kamion, ok, but somethings people say you: use bugzilla better :)
<Kamion> xuzo: that too
<mvo> mjg59: feel free to report a bug and assign it to me as a reminder :)
<xuzo> Kamion: but I not know which component is the correct
<xuzo> averything works ok on Hoary install
<Kamion> xuzo: for installation bugs, use "debian-installer" as a default
<mjg59> Gah
* mjg59 accidently manages to submit another copy of the same bug
<xuzo> but on console (ttyX), keymap is not correct, I install Hoary using spanish settings, but on console keymap is US
<mjg59> mvo: What's your address for bugzilla?
<Riddell> elmo: is it possible to set up a baz archive (or other version control) for the kubuntu website which we could give people write access to?
<mvo> mjg59: michael.vogt@ubuntu.com
<Kamion> xuzo: that was fixed recently I believe
<Kamion> xuzo: try a daily build
<mdz> jdub: cursors?
<xuzo> Kamion: ok, thanks
<mjg59> mvo: Ok, done
<jdub> mdz: u-a upload in an hour or so
<mvo> mjg59: thanks
<Mitario> mvo, heya
<jdub> mdz: with ace new stuff from cliff
<Mitario> mvo, was there something you'd liked tested in u-m?
<mdz> jdub: fantabulous
<mdz> jdub: login screen and splash?
<jdub> yeah
<mjg59> mvo: Ok, I've got it down to pppd call ppp0 - that does nothing
<jdub> login screen is being a beeyatch though
<mvo> mjg59: what do you get when you call it by hand? a error message about "the remote system is required to authenticate itself"?
<mjg59> mvo: ARGH. Got it.
<mjg59> mvo: It's calling chat -v -f ppp0
<mjg59> It should be chat -v -f /etc/chatscripts/ppp0
<mvo> mjg59: cool, thanks
<mjg59> mvo: So it's g-s-t miswriting /etc/ppp/peers/ppp0
<mjg59> Plus it not being resiliant enough - it should make sure ppp0 is down before trying to bring it up
* lamont fails in his effort to remember where $DEB_HOST_* are documented
<Kamion> lamont: dpkg-architecture(1)
<mvo> mjg59: thanks!
<mdz> jdub: where's that list we made in Mataro of each component which needs branding and which strategy we would use to implement the branding?
<jdub> SomethingOrOtherBranding on the wiki
<mdz> ah, ManagingBrandingChanges
<jdub> oh, SomethingOrOtherBrandingSomething ;)
<ogra> jdub, seb128, koke has made a default icon for us for .desktop entrys without a icon 
<schweeb> jdub: so how'd that index w/ gsf# go?
<mdz> jdub: what was the rationale for separating foo-branding and foo-artwork?  I don't remember
<jdub> mdz: so you can switch artwork/branding independently
<ogra> jdub, seb128 to use it there should be a patch against gnome-panel or gnome-menus .... would you accept that one ? (and against which of them should the patch be if yes)
<jdub> mdz: there was something else, too
<jdub> ogra: what's the icon?
<ogra> koke ? ^^^
<koke> jdub: http://amedias.org/img/menus_default_icon_patch_3.png
<ogra> jdub, quite similar to what vincent just mailed in reply to my meeting summary
<koke> http://www.amedias.org/~koke/debian/hoary/gnome-panel_2.10.0-0ubuntu8.diff.gz
<ogra> http://bugzilla.gnome.org/show_bug.cgi?id=76495
<jdub> koke: ah, nicely generic but also not hideous ;-)
<ogra> yeah
<ogra> and much better then a empty entry
<koke> jdub: heh, see the first try http://amedias.org/img/menus_default_icon_patch_1.png :)
<jdub> koke: heh, mushy ;)
<koke> jdub: it's the libwnck's default_icon.png
<koke> the patch is just a proof of concept
<koke> I guess the icon should go into gnome-icon-theme
<koke> or someway into the stock set
<ogra> koke, but i'm sure you can flesh out the patch ;)
<koke> now is placed at /usr/share/icons
<mdz> jdub: so that that fellow from bugzilla/wiki can use ubuntu-branding but crazymask-artwork?
<Burgundavia> koke: by default, all icons go to /usr/share/pixmaps
<jdub> mdz: ha ha
<jdub> :-)
<ogra> Burgundavia, depends...stock icons are in /usr/share/icons
<jdub> Burgundavia: not icon theme icons
<Burgundavia> ok
<Burgundavia> I stand corrected
<koke> ogra: I'm an english blogger now!! :)
<koke> http://koke.amedias.org/
<ogra> yeah
<koke> I really love the GNOMEish screenshot style :D
<ogra> jdub ^^^ next planet candidate ;)
<jdub> koke: your gnome/ubuntu/self-portrait at the bottom left is rad ;)
<ogra> koke, funny picture of you
<jdub> koke: you're an ubuntu member already, aren't you?
<jordi> koke: lol
<jordi> jdub: dude I am not!
<koke> jdub: yes
<jdub> koke: wanna be on planet ubuntu? :)
<ogra> koke <- gnomerooster
<koke> I have to make a big note ***^W closes the window***
<jdub> jordi: hurry up!
<koke> :D
<koke> jdub: that would be great :)
<ogra> jordi, !
<jordi> ogra: yeah dude
* ogra finally knows what he was missing all the time :)
<koke> ogra: gnomerooster??
<ogra> koke, yeah, it looks a bit like a rooster ;)
<koke> :D
<ogra> :)
<koke> jordi: are you going to Madrid this weekend??
<jordi> koke: nope. Are you coming to Norway this week? :P
<koke> ogra: I have to do some style changes 
* jdub wonders why some hackergotchis are not appearing
<ogra> hehe
<koke> jordi: too far for me, and I already have the tickets to Madrid
<jordi> for the assembly?
<ogra> jdub, yeah, where is yours ?
<koke> jordi: yep, the AVE is *very* expensive :)
<jdub> mine is on there
<ogra> jdub, hmm, then i should talk to thom, seems ff supresses it....
<jordi> koke: no other way of getting there?
<thom> ogra: hrm?
<koke> jordi: bus, but there was no tickets at the hour we wanted
<koke> and it's too slow :)
<ogra> thom, planet.ubuntu.com, i dont see jdubs hackergotchi ... was kidding with the ff stuff...
<thom> ah
<thom> heh :-)
<jordi> koke: no other trains?
<koke> nop, only a daily regional in the afternoon
<koke> now there's only aves and altarias at 44 or 36 with euro<26
<zenrox> what do i need to fix when gnome take 15-20 mins to load a desktop
<zenrox> then when i start a program it segfaults
<zyga> mvo: ping?
<enrico> Hello.  Does someone know of internationalised Ubuntu Live CDs?  We would like to distribute some Ubuntu live CDs in Italy, but we'd need them preset to Italian, with OOo Italian spellchecking, thesaurus and so on.  Does someone like this already exist?
<koke> ogra: jdub : the patch is at http://amedias.org/~koke/patches/gnome-panel_add-icon-to-items-without-one_1.diff if you want to look at it directly
<koke> just 2 lines :)
<koke> but it needs the icon
<zyga> is there a word  'maximal'?
<zyga> or should it be 'maximum'
<luis> enrico: there is a little bit of information on the wiki about customizing a liveCD, including language stuff
<luis> zyga: there is such a word, but it is not in common usage
<zyga> luis: tank you
<jdub> *BOOM*
<zyga> s/ta/tha/
<ogra> jdub, ??
<luis> enrico: but it doesn't include everything you want, I think, specifically defaulting the installer language to not-english
<luis> enrico: if you find that part out, let me know and/or put it on the wiki, please :)
<jdub> ogra: that's what happens after "tank you"
<ogra> heh
<zyga> jdub: heh :)
<ogra> jdub, you play to much barrage....
<zyga> what happens afer s/ta/tha/ ;]  ?
<enrico> luis: thanks!
* mvo is away for ~1,5h, bbl
<dholbach> bye mvo
<toresbe> what the hell
<toresbe> Ubuntu doesn't have  tuxracer?
<lamont> Filename: pool/universe/t/tuxracer/tuxracer_0.61-6.4_i386.deb
<lamont> toresbe: it's there on warty and hoary
<toresbe> strange
<toresbe> oh shit
<toresbe> I am an idiot
<toresbe> feel free to verbally and physically abuse me
<ogra> herzi, how are the hula packages ?
* enrico tickles toresbe
<herzi> ogra: will build some new ones today
<toresbe> ehhehehehhehehehe be nihihahahahahahahaice
<herzi> they shoudl fix any outstanding issues except the missing manpages
<enrico> toresbe: :)
<ogra> herzi, yeah, great....i'll review them before weekend
<herzi> ogra: no need to hurry or I won't have time to hack on my presentation application
<dholbach> herzi: you know when hoary releases? there IS need to hurry :-)
<jdub> elmo: planet sync please :)
<herzi> dholbach: i don't think so, as hula is universe stuff
<ogra> herzi, i'd love to have them in universe for release, even if they are experimental (tagged inteh version number indeed)
<ogra> herzi, universe freezes with the release, so time is short
<ogra> (2 weeks)
<robertj> how much of the behavior exhibited here --> http://www.music.uga.edu/wip/grumpyness/gripe_1.swf is ubuntu and how much of it is upstream?
<cartman> libc6-i686 package has problems?
<cartman> its no longer installable
<cartman> neither nscd
<fabbione> jbailey: pong?
<cartman> both says "Depends: libc6.1 (>= 2.3.2.ds1-20ubuntu12) but it is not installable"
<Kamion> *6.1*?
<fabbione> what arch?
<cartman> i386
<fabbione> isn't ubuntu13 around?
<Kamion> ubuntu12 was just uploaded today
<cartman> 6.1 is the weird part...
<Kamion> yes, that's an ia64 thing
<Kamion> jbailey: glibc fucked, dude :)
<cartman> heh
<cartman> I bet my machine won't work if I reboot :P
<ogra> cartman, dont reboot then 
<Kamion> I imagine libc6 refused to upgrade; you should be ok
<cartman> ogra: /me prays for electricity not goes off
<cartman> Kamion: libc6-i686 and nscd did
<cartman> rest went well actually
<ogra> cartman, you got a ia64 without UPS ?
<cartman> ogra: I have an i386 machine
<cartman> P3
<ogra> ah, sorry misread
<cartman> np guess arches got mixed
<Burgundavia> it is the latest update
<Kamion> cartman: remove libc6-i686 for the moment
<Burgundavia> I just tested that and then updated
<cartman> Kamion: yup I did but I need it as it has NPTL
<Burgundavia> I see that libc686 was going to be removed from my system
<cartman> Burgundavia: yep same
<schweeb> Other
<Burgundavia> it worked until about 9am PST this morning
<schweeb> woops
<LeeJunFan> openoffice seems broken on amd64 now. :(
<nasdaq7> hi does anyone know how to open .wdp files?
<nasdaq7> .wpd
<cartman> nasdaq7: get openoffice
<nasdaq7> ok
<cartman> nasdaq7: and try #ubuntu next time
<nasdaq7> thanx
<nasdaq7> i just did cartman
<nasdaq7> sorry
<Kamion> -Pre-Depends: libc6 (= ${Source-Version})
<Kamion> +Pre-Depends: libc6.1 (= ${Source-Version})
<Kamion>  Description: GNU C Library: Shared libraries [i686 optimized] 
<Kamion> stuff like that might break :) something in glibc's build process has done this to debian/control in the past, IIRC
<cartman> same problem in nscd too
<Kamion> indeed, it's all visible in the source diff
<mdz> seb128: we still seem to be receiving many bug reports about missing icons for removable media
<mdz> seb128: do you have an idea about what is wrong?  is pitti looking at it?
<seb128> mdz: pitti has fixed 2 crashers in gnome-vfs-daemon causing this
<seb128> mdz: be sure they have the current version
<seb128> for hal and gnome-vfs-daemon
<seb128> mdz: have we got some new bug about that today ?
<mdz> seb128: I saw some yesterday or the day before
<mdz> I have not reached my bugs folder yet today :-/
<Kamion> hmm, jbailey doesn't seem to be around; I guess I'll start fixing glibc here
<mdz> jbailey: PING
<seb128> mdz: hum, right, https://bugzilla.ubuntu.com/show_bug.cgi?id=7641 has been reopened, pitti is working on it.
<mdz> I thought the version skew breakage was fixed long ago in Debian
<mdz> I remember it bit us for security updates
<mdz> thom: so we hope the new firefox addresses/avoids the filechooser problems?
<zyga> could somebody take a look at update-manager?
<mdz> I wasn't able to reproduce them in the first place
<zyga> (current cvs)
<mdz> zyga: mvo would be the person to talk to
<zyga> mdz: I know, he's not avail right now
<zyga> It's something really simple
<zyga> but I'm not familiar with autotools
<zyga> one .in file doesn't build
<Kamion> mdz: I don't see anything in the stable-security changelog about it
<zyga> it is listed in configure.in 
<zyga> but unlike many others in the same directory, it doesn't build
<zyga> anyway
<zyga> if someone is free I'd be gratefull
<Kamion> mdz: also it's all been debhelperised since then
<mdz> thom: please oh please include bug numbers in the powernowd changelog
<dredg> mako: fantastic example of fingers operating independantly of brain... "carefully dropped the password into the envelope" :)
<mdz> thom: I have had to endure bugzilla's search page to find the p4-clockmod bug references several times
<mako> dredg: i've already fixed it 
<dredg> mako: ah, reading through liferea
<mako> dredg: yeah.. give it a cycle to catch up.. my gf already made fun of me for it :)
<dredg> mako: i only find it amusing because i do it a lot :) more than once i've tried typing passport and ended up with passwd
<_d4vid> hi all
<Kamion> jbailey: how about making debian/control a double-colon rule with no prereqs (the way cdbs does it)?
<Kamion> hm, no
<Kamion> might just add a FORCE prerequisite
<mdz> Kamion: do we set the 'splash' boot parameter on server installs?
<Kamion> mdz: yes
<Kamion> we probably shouldn't
<mdz> probably not, I agree
<Riddell> mdz: fancy holding a kubuntu meeting?
<jdub> tseng: around?
<bluefoxicy> tcl/tk is unstable
<bluefoxicy> apps randomly freeze after prolonged use; they worked for weeks/months nonstop on gentoo.
<Seveas> hello
<Seveas> what's up with libc6?
<Seveas> apt-get -s dist-upgrade wants to remove libc6-i686 and install libc6
<Seveas> looks weird to me...
<Seveas> any devels who can shed a light?
<Seveas> especially since this also removes ubuntu-base
<Kamion> we're working on it
<Seveas> ok, thanks
<Seveas> any ETA?
<Kamion> well more accurately I'm working on it since jbailey seems not to be around
<Kamion> not as yet
<Kamion> it's test-building
<xuzo> bye
<zyga> Kamion: does this libc revert gettext patch that broke it several days ago?
<Kamion> zyga: the version I'm building has precisely one change which has nothing to do with gettext
<Kamion> zyga: there were fixes for your problem in -20ubuntu12, I believe
<zyga> Kamion: I see, thanks
<svenl> Kamion: cd booting should work.
<Kamion> svenl: new OF?
<svenl> Kamion: but it seems as if the iso code can't follow symlinks, which sucks bigtime for the ubuntu CD.
<svenl> Kamion: yep.
<Kamion> fantastic
<Kamion> what symlinks are relevant?
<svenl> well, i just got it working.
<svenl> /etc/yaboot.conf :)
<Kamion> I'll just copy that instead
<zyga> Kamion: That's current version in hoary (-20ubuntu12)
<Kamion> zyga: right
<svenl> but i guess i can just fix iso symlinks not sure, i know nothing baout
<Kamion> svenl: next daily CD will have a copy rather than a symlink
* zyga really needs to re-login sometime soon
<Kamion> svenl: thanks for fixing that, it'll make a big difference
<svenl> Kamion: yep.
<Kamion> I'll try to get some Pegasos documentation into the next d-i upload
<svenl> Kamion: can you kick of a netinst build with it i can try ...
* Kamion -> dinner
<svenl> wait, no, i will fake it.
<Kamion> svenl: don't have netinsts ...
<Kamion> implementing those is kind of on the to-do list somewhere, but isn't a single night's work :)
* svenl uses a netbooted yaboot with faked bootpath entry to have it believe it comes from the CD :)
<Kamion> svenl: I've kicked a new daily CD build, ETA about an hour
<Kamion> really gone for dinner now
<svenl> ok,ping me the url when i am ready, and i will give it a try.
* svenl too.
<zyga> Kamion: dinner, what's your timezone?
<jbailey> Kamion, mdz: Here now.
<jbailey> Kamion: What happened?  I tested with -686 and with some LD_ASSUME_KERNEL=2.4.1 tests to make sure that both libc's were working.
<svenl> Kamion: ARG.
<svenl> Kamion: it tells me Can only load kernels with one program header :/
<schweeb> jdub: poke
<jdub> schweeb: in mtg atm, back soon
<schweeb> alright
<fabbione> schweeb: hey.. i solved the xen problem
<fabbione> schweeb: it was a python2.4/2.3 issue
<schweeb> cool, what was the issue?
<fabbione> it doesn't run on 2.4
<schweeb> oh really?
<fabbione> yeps
<fabbione> it was enough to install a few 2.3 packages 
<schweeb> guess I'll have to modify my packages then, cause I was making them against 2.4 (albeit not testing them yet)
<fabbione> and change the default /usr/bin/python symlink
<fabbione> schweeb: well see if you can get xend to start
<fabbione> perhaps my system isn't really state of the art
<schweeb> well, can't start xend unless you're in a xen kernel
<fabbione> (it's one of my test and destroy boxes)
<schweeb> it needs the proc control interface
<fabbione> schweeb: yes i know.. i mean once you get the kernel, you can check xend
<schweeb> yea
<schweeb> probably should be reported upstream
<fabbione> yes
<fabbione> but i have no contact with upstream tho
<jbailey> Kamion: .PHONY is the usual place to put that sort of magic.
<jbailey> Lemme see if it works with files in subdirectories.
<schweeb> fabbione: xen-devel@lists.sourceforge.net
<jbailey> Kamion: Yeah it seems to.  So .PHONY is a better choice than an empty :: rule, incase some of the prereq's do actually need to get built.
<Burgundavia> jdub: ping
<jdub> Burgundavia: in mtg atm
<Burgundavia> jdub: np
<thom> mdz: *which* filechooser problem? there are two - there's a crasher when you create new directories, which is a GTK bug, and there's the not fucking downloading anything, which i've fixed
<mvo> zyga: update-manager?
<mdz> thom: not-fucking-downloading anything
<mdz> I couldn't reproduce either of them, fwiw
<thom> the not downloading one i nailed down last night and fixed this morning
<thom> i can reproduce the crasher occasionally but only in french
<seb128> thom: I see you coming dude
<thom> (seriously, in en_GB i can't crash it, in fr_FR i can)
<zyga> does anyone around have access to all .mo files _locally_ ?
<zyga> I'd rather avoid getting all langpack-xx packages 
<thom> seb128: just tried it again to confirm
<zyga> I need to run small script
<thom> seb128: epiphany does exactly the same
<seb128> what do you do ?
<zyga>  for domain in /usr/share/locale-langpack/*/LC_MESSAGES/*.mo; do gettext -d `basename $domain .mo` "" | grep 'Plural-Forms'; done | sort -u
<zyga> if anyone can, please send results to zyga@www.suxx.pl
<thom> seb128: open epiphany, right click, "save as", "parcourir pour d'atures dossiers", "creer un dossier", type something, ephy gets SIGABRT
<seb128> works fine
<thom> maybe you should try it in english *g*
<seb128> ah ah
<seb128> where is the fileselector when you do that ?
<thom> seriously, i can't do it with my normal account, just my french test account
<thom> how do you meant?
<seb128> and seriously I'm in fr_FR.UTF-8 and it doesn't crash
<seb128> do you have ~/Documents as the default fileselector folder ?
<seb128> when you click on "parcourir pour d'autres dossiers"
<seb128> it picks the previous choice ?
<seb128> ~/Documents ?
<seb128> $HOME ?
<thom> $HOME
<seb128> and it crashes every time ?
<thom> yep
<seb128> doesn't crash :/
<seb128> neither in firefox or epiphany
<thom> i really dunno what causes it, then
<thom> seb128: you have a totally blank test account (or could you make one) to try it on?
<seb128> lemme try in a gdmflexiserver 
<seb128> doesn't crash, grumpf
<Kamion> jbailey: yeah, I went through the mental process of "::? no. depend on FORCE? no. .PHONY: yes" earlier and forgot to mention the last bit; I ran a test build and it succeeded
<seb128> thom: what theme are you using ?
<seb128> thom: I don't think that's it but who knows ...
<thom> seb128: absolute total default hoary, so clearlooks
<Kamion> jbailey: diff is just:
<Kamion> --- glibc-2.3.2.ds1/debian/rules.d/control.mk
<Kamion> +++ glibc-2.3.2.ds1/debian/rules.d/control.mk
<Kamion> @@ -33,0 +34,2 @@
<Kamion> +
<Kamion> +.PHONY: debian/control
<Kamion> jbailey: shall I upload that?
<thom> seb128: are you testing on amd64 or x86?
<seb128> x86
<thom> hrm
* thom goes to try it on x86
<thom> (i'm on amd64)
<Kamion> zyga: I'm in England, so UTC
<jbailey> Kamion: Yeah, that looks right.  I'm surprised this didn't eat me on the tests, though.  I carted aroudn the .dsc and .diff and unpacked on the various systems.
<Kamion> jbailey: less loaded test systems than the buildds, maybe?
<thom> seb128: works fine on x86 with a brand new user
<seb128> grumpf
<seb128> I don't like that
<Kamion> jbailey: debian/control is in the diff earlier than debian/control.in/*, so it could certainly end up with a lower timestamp
<jbailey> Evil.
<thom> seb128: no, i can't say i'm keen
<Kamion> ok, uploading
<jbailey> I know that ia64 would occasionally fail on Debian buildd's with this type of problem, and we never figured out why.  It used to be fun to just blame lamont.
<Kamion> haha
<Kamion> jbailey: I left debian/control in the source package the way it was (libc6.1, I assume you built the source package on ia64); should give it more chance to break if it's still dodgy, so that we can fix it permanently
<jbailey> Cool, and yup I did build on ia64.
<Kamion> svenl: http://cdimage.ubuntu.com/daily/current/, or similar rsync address, updated
<Kamion> svenl: (i386 is broken, but powerpc should be fine
<Kamion> )
<thom> mdz: so, firefox 1.0.2
* mdz glares at thom
<thom> mdz: basically, i have to either backport 2 thirds of it, or upload it
<mdz> Kamion: i386 broken?
<Kamion> mdz: glibc
<mdz> oh, that's i386-only?
<thom> (i'm not thrilled by either option)
<mdz> thom: security fixes?
<thom> mdz: yes
<Kamion> mdz: it was a race
<mdz> that excuse won't hold out forever; firefox has new vulnerabilities in every release
<mdz> someday we have to stabilize
<mroth> didnt they release a security 1.0.2 for thunderbird too?
<thom> i know; i promise 1.0.2 will be the last upstream version i upload to hoary, if i can
<thom> mroth: yes
<mdz> thom: can you have it uploaded tonight?
<mroth> thom: ugh
<thom> mdz: tomorrow morning latest; i'll try and do tonight
<mdz> 7 days testing and fixing >> 6 days
<thom> nod
<mjg59> Oh argh NO.
<mroth> were the security holes even serious this time?
* mjg59 discovers that the problem he thought was fixed on the HPs is not, in fact, fixed on the HPs
<mroth> last time it was just the IDN thing
<thom> mroth: last time had rather more than just that; and 1.0.2 firefox has at least 5 serious problems fixed
<mroth> thom: ouch
* thom goes to get dinner while firefox downloads
<mroth> how about the thunderbird changes?
<jdub> schweeb: yo?
<mroth> yuck, 6 security fixes in TB1.0.2
<schweeb> jdub: used pbuilder, and found 2 missing build-deps on that gsf-sharp package
<schweeb> jdub: and is that actually going in universe or not?
<jdub> schweeb: i'd like to put a gsf-sharp package in
<Burgundavia> jdub: you wait ./ -- http://linux.slashdot.org/article.pl?sid=05/03/23/1820243&from=rss
<lamont> jbailey: oh, I knew exactly why it failed, and indicated why
<lamont> it's a b0rken package
<mroth> Burgundavia: the Bruce Perens reply to that thread is pretty funny
<Burgundavia> mroth: it is
<Burgundavia> mroth: "it will be checked into debian"
<schweeb> jdub: alright, well I'm lookin into tryin to be motu... should I consult an MOTU about this package, or you want to?  I know metallikop personally and he's MOTU now
<lamont> jbailey: and the fix was always taht some debian developer would just upload their home-built binaries instead of fixing the source pacakage.
<Kamion> lamont: with any luck that's it fixed a bit more permanently now
<thom> oh dear "I think there's a natural synergy here with Bruce Perens being an "industry insider" and Shuttleworth having deep pockets.
<thom> I too have a natural synergy with people who have deep pockets."
<jdub> schweeb: yes, please do -> i'm happy to vouch for your fast learning on it ;)
<schweeb> jdub: alright, awesome
<dholbach> schweeb: is it a NEW package?
<schweeb> dholbach: yep
<lamont> Kamion: woot
<dholbach> schweeb: wiki/MOTUNewPackagePolicy then... sorry for being anal, but if it's cool, you'll surely find 3 people to review it
<schweeb> dholbach: yea, I asked a while ago in -motu actually, no one was paying attention ;)
<jdub> schweeb: you can put me as a reviewer :)
<dholbach> schweeb: must be the end-of-release-cycle hectic :-)
<schweeb> yep
<jbailey> lamont: Well, we usually tried to build all of the binaries on our local machines anyway so that we knew what we uploaded would work.
<dholbach> jdub: yeah ... wiki/MOTUNewPackages - a bit of work on top :-)
<schweeb> dholbach: well, it was while lamont was spewing all that package status stuff
<dholbach> jdub: hula-server for example
<jbailey> lamont: I Don't think I ever heard about the bug, but any upload I did would've included ia64 in the merged changes.
<lamont> I know I filed it in the bts at least once
<lamont> and it was closed with something along the lines of "it's uploaded now, closing."
<lamont> IIRC
<mjg59> What's the best way for me to add extra applets to the default login?
<ogra> jdub, any comment on kokes patch ? 
<jdub> ogra: no, up to seb
<ogra> jdub, but the idea of a default icon instead of no icon is ok with you ?
<ogra> (as our desktop team lead)
<koke> it seems I arrive at a good time :)
<ogra> koke, i waited until youre back ;)
<seb128> have you read the upstream bug ?
<ogra> seb128, only the part vincent sent as reply in u-d@
* ogra reads the whole bug
<jdub> ogra: yes, totally (wiki koke's nice icon)
<ogra> jdub, great
<seb128> bah I don't like the idea :p
<seb128> (you'll learn to be carreful when jdub totally agrees with something :p)
<ogra> seb128, i understand you, but itsunlikely that we will have any additional icons in place for hoary
<bluefoxicy> ping, is dosfsck known to be broken, or vfat?
<ogra> seb128, so the choice it to have no icon or a default icon for 6 months, i vote for default here, i agree with the lazy developers aspect.... but currently my focus is on the user...
<bluefoxicy> because I just crossposted to lkml and ubuntu-devel about it being unsafe to write to vfat filesystems
<Kamion> bluefoxicy: there's a bug on dosfstools about breakage certainly
* Kamion -> bed; night all
<ogra> night Kamion 
<jbailey> g'n Colin.
<bluefoxicy> Kamion:  oh damn.
<seb128> ogra: apparently you didn't get the joke :/
<jdub> heh
<ogra> seb128, all work and no play makes ogra a dull boy :-P
<jdub> seb128: a german man getting a french man's joke? ah ha ha ha!
<seb128> :)
<seb128> rohhh
<ogra> jdub, ah, come on... 
<ogra> koke, so dod you manage the rest with seb128 ?
<ogra> -d
<seb128> patches are welcome
<zyga>  for domain in /usr/share/locale-langpack/*/LC_MESSAGES/*.mo; do gettext -d `basename $domain .mo` "" | grep 'Plural-Forms'; done | sort -u
<zyga> if anyone can, please send results to zyga@www.suxx.pl
<schweeb> jdub: well, I threw it on MOTUNewPackages, guess you're supposed to add any comments on my pkg there and say you reviewed it
<koke> seb128: http://www.amedias.org/~koke/debian/hoary/gnome-panel_2.10.0-0ubuntu8.diff.gz
<jdub> oh man
<jdub> i have to use the wiki to give you love?
<schweeb> I guess
<schweeb> dholbach's bein kinda anal right now
<schweeb> heh
<seb128> koke: please open a bugzilla bug with only the diff for this change
<koke> seb128: you mean debdiff *ubuntu7.dsc *ubuntu8.dsc ??
<ogra> jdub, yeah, blame dholbach ;)
<seb128> koke: I mean a diff to put in debian/patches
<seb128> koke: or a diff between current revision and your version
<koke> seb128: the patch is here http://amedias.org/~koke/patches/gnome-panel_add-icon-to-items-without-one_1.diff
<koke> but you also need the icon
<koke> <seb128> koke: or a diff between current revision and your version <-- I guess this equivs to debdiff
<seb128> yep
<koke> seb128: http://amedias.org/~koke/patches/gnome-panel_add-icon-to-items-without-one_ubuntu.diff <-- is this what you want??
<seb128> koke: exactly, thanks
<ogra> jdub, read seths recent blog entry ? 
* ogra cant wait to play with cairo
<koke> seb128: should I file the bug anyway??
<seb128> koke: I'll handle that now
<koke> ok :)
<seb128> thanks
<thom> jdub: 8103 probably fixed
<zyga> anyone with ppc around?
<jbailey> zyga: <--
* thom is checking out luminocity right now :-)
<ogra> thom, yeah
<seb128> thom: let me know how that works :)
<zyga> jbailey: www.suxx.pl/i18n/new-libintl/tests/ppc-test3.tar.gz
<zyga> jbailey: please run and msg the results
* ogra has to much on the TODO, has to wait for breezy
<jbailey> zyga: Umm..  There's source code in that, right?
<zyga> jbailey: of course :)
<zyga> s/ //
<thom> yeah, as soon as new firefox finishes building
<lamont> mdz: http://people.ubuntu.com/~lamont/buildLogs/Test/Lists/hoary-test.report.i386
<lamont> et al.
<lamont> seb128: you around?
<seb128> yep
<infinity> kamont : Did the retry of php4 on PPC go okay?
<infinity> s/kamont/lamont/
* infinity stares accusingly at his fingers.
<lamont> no failure log yet...:-)
<lamont> that is, I think it did
<infinity> Mmkay.
* ogra hands infinity some spellchecking gloves
<ogra> (mind driven)
<lamont> Kamion: how often is hoary_outdate.txt updated?
<koke> Accepted gnome-panel 2.10.0-0ubuntu8 (source) <-- seb128 great :)
<seb128> looks nice with an icon :)
<ogra> yay
<sPoof> hi
<thom> ber, seth didn't actually link to the trivial patch you need
<thom> suck
<sPoof> I am Jonas Smedegaard, Debian maintainer of MoinMoin.
<tseng> ello, Jonas
<sPoof> I have prepared a package of 3.4 - requested by Mark Shuttleworth.
<tseng> coolness
<sPoof> how to pass that on to Ubuntu?
<tseng> well since mark is the SABDFL i guess he wants one of his cronies to fast track it
<thom> sPoof: you should speak to mdz
<tseng> but youll have to talk to him.. it would normally be a MOTU matter
<sPoof> I was told you needed it by 23rd - which is about now.
<sPoof> ...and Mark hasn't responded to my emails last couple of days.
<dholbach> sPoof: drop into #ubuntu-motu :-)
<sPoof> Jane Silber told me yesterday to go here for technical questions
<sabdfl> sPoof: i'm on holiday :-)
<sPoof> I should get in touch with Kamion or Colin Watson...
<sPoof> Oh - sabdfl is Mark? :-)
<infinity> sPoof : Yes.
<infinity> And Kamion is Colin... So, "Kamion or Colin" sounds a bit odd. :)
<sPoof> sorry - last time I used IRC was two years ago... :-P
<mjg59> mdz: http://seclists.org/lists/linux-kernel/2005/Mar/6078.html is a fix for PCI interrupts on some VIA-based systems
#ubuntu-devel 2006-03-27
<stewart> although device manager shows a bt878
<Keybuk> I don't know anything about tvtime I'm afraid
<Keybuk> if device manager shows it, it's a bug in tvtime
<Keybuk> (though when detected, your audio won't work because of the above bug :p)
<Keybuk> it could be related to it
<stewart> in breezy there was a multimedia test tool
<Keybuk> I'd certainly do the blacklist/modules trick and see if it works after a reboot
<stewart> you could check see if your capture card was there is there similar under dapper?
<Keybuk> does the same test tool not exist?
<HiddenWolf> Keybuk: taken from the menu's, I guess
<stewart> yeah its not on themenus
<Keybuk> what was the tool?
<ogra> gstreamer-properties
<stewart> system>adminsitration>multimedia I think
<Keybuk> stewart: try just running what ogra suggested
<HiddenWolf> that's it
<HiddenWolf> Keybuk: thank you for your time
<stewart> yeah cheers thats the same panel, didnt realise it was a gstreamer thing
<HiddenWolf> ack, Keybuk, I pressed the wrong button on LP, now I assigned it to udev again. :(
<Keybuk> put it back :p
<HiddenWolf> Keybuk: how? :P
<HiddenWolf> Can I just have bugzilla back?
* HiddenWolf sobs
<Keybuk> fixed
<HiddenWolf> mental note: stay away from unfamiliar buttons
<stewart> Keybuk what do you make of xgl from a dev perspective?
<Keybuk> stewart: personally I'm waiting for X to go away
<Keybuk> it's an evil monolithic hunk of crap that belongs in the 70s
* jdub kicks Keybuk in the pants.
<Keybuk> the most we need (imo) is a GL proxy server; that directs GL received from apps across the network, or to the appropriate video device
<jdub> and X11 wouldn't be a good protocol to do that with, given its backwards compatibility and other benefits...?
<Keybuk> as I understand X11, you end up with apps using GL to draw on a pixmap which is sent to a card that could receive GL just fine
<Keybuk> I'm not necessarily against X11 being extended to support GL drawing commands directly
<Keybuk> I'm definitely against the Xorg/X386 implementation
<jdub> no, that is bollocks
<jdub> that's precisely what GLX is for
<Keybuk> for example, if I unplug an Nvidia graphics card and plug an ATI one in instead, I shouldn't have to stop all my running applications
<Keybuk> ok
<Keybuk> then I guess as a dev, I like the direction GLX is taking us :)
<jdub> you're thinking of software rendering, which is an option everywhere
* Keybuk knows not much about it
<jdub> GLX is an extension to send GL commands over the X protocol
<jdub> that's why you can run glxgears from OS X, over ssh, displaying on your linux box, and it still works well
<jdub> hooray for architecture, operating system, and network independence
<Keybuk> the thing I don't like about X is the way that it's a huge thing sitting on top that needs to be configured and stuff
<jdub> X is not huge *at all*
<Keybuk> my display should be independant to my hardware
<jdub> it was invented for machines smaller than your calculator
<jdub> the fact that it needs to be configured is a relic, rapidly being fixed now we have Xorg
<Keybuk> Xorg doesn't seem to be moving in the right direction though
<Keybuk> you can't unload one video driver, and load another, without the display needing to be killed
<jdub> (keith has done some really interesting work on autoconfiguration and hotplug in kdrive)
<jdub> well, that's a very niche case that could be attended to
<Keybuk> likewise X doesn't automatically deal with me plugging a monitor into my laptop, and then unplugging it again
<jdub> it will be able to do that very soon
<Keybuk> plug a monitor in, I should get a new screen to put things on, unplug it, that screen should get tidied away
<Keybuk> (just going to bounce, brb)
<Keybuk> jdub: X is still the one thing about Linux that makes me ashamed though
<HiddenWolf> Keybuk: try the sound stack
<Keybuk> we're so far behind the way Windows and Mac OS X deal with displays :(
<Keybuk> HiddenWolf: nothing especially wrong with ALSA and Gstreamer
<jdub> Keybuk: not really, and in some ways, we're ahead. :-)
<Keybuk> jdub: Windows has had on-the-fly driver, resolution, depth, etc. changing and direct-to-card rendering for nearly a decade
<Keybuk> in fact, over a decade
<jdub> Keybuk: there are some warts, but not enough that it's worth throwing away. indeed, few of these problems actually need extensions and all that kind of stuff.
<Keybuk> jdub: I don't necessarily disagree; when I talk about "X" I guess I refer to the implementation we have today -- rather than the underlying protocol
<jdub> Keybuk: X can do resolution, depth and direct rendering. we can't do on-the-fly driver changing yet.
<Keybuk> jdub: it can only change between existing preconfigured resolutions
<Keybuk> and as I recall, it _can't_ do depth changing
<jdub> Keybuk: that's not true at all - look at XRANDR
<Keybuk> XRandR only supports changing between the configured resolutions
<jdub> nup :-)
<jdub> i only have one resolution in my xorg.conf
<Keybuk> oh ok
<jdub> but i can change to all the resolutions my monitor supports
<Keybuk> it can't change between depths though
<Keybuk> you have to kill every running X app to do that
<stewart> XRandR only supports changing between the configured resolutions <-- is that different to windows?
<jdub> stewart: it's untrue to begin with, but no
<stewart> if I want a custom resolition I still have to hack my drivers inf file on xp
<jdub> Keybuk: ok - depth is not implemented because it wasn't deemed necessary, which i tend to agree with.
<jdub> Keybuk: the only computer i have running anything less than 24/32bit is an old laptop of pia's.
<Keybuk> jdub: what if you plug in an old monitor for some reason
<jdub> Keybuk: which only does 16 bit at its full screen resolution.
<stewart> still from an end user "could my ma use it" point of view x configs are still overly messy
<Keybuk> or plug into one of those annoying projectors
<jdub> Keybuk: old monitors and projectors do 32 bit. it's not a display issue, it's a memory / video chipset issue.
<stewart> and my ma is/was a design engineer so theres plenty of refinement
<Keybuk> Linux users at conferences are funny
<Keybuk> the first day where everyone has to deal with the projector
<jdub> stewart: xrandr works nicely now - xorg autoconfiguration is being worked on.
<stewart> good good
<jdub> Keybuk: that has more to do with bad video drivers than anything else.
<Keybuk> jdub: yeah, that's certainly part of the problem
* Keybuk just wants everything to "just work"
<stewart> I think drivers must be a sticking point for the FLOSS world in general but never more so than video
<jdub> you're blaming X about things for which it alone is not responsible ;)
<Keybuk> how is X alone not responsible?
<Keybuk> where X ~= everything X and X-related
<jdub> ok
<jdub> so
<jdub> you're blaming X for being "big"
<jdub> which it is not
<Keybuk> xorg-* is a large set of packages
<jdub> you're blaming it for features it doesn't have
<jdub> which it does
<jdub> you're blaming it for features it doesn't have
<jdub> that are extremely shallow use cases
<stewart> well without getting on too much of a downer improvements from a user point of view seem to have been accelerating
<Keybuk> I don't think they are shallow use cases
<jdub> and blaming it for problems that we would have with *any* system
<jdub> such as drivers
<Keybuk> sure :)
<jdub> Keybuk: changing depth? in this day and age?
<jdub> stewart: very rapidly with the Xorg split
<jdub> stewart: (both from XFree86 and its build split)
<Keybuk> jdub: I've frequently had to deal with projectors that can only do 16-bit
<Keybuk> so I think it's still relevant
<jdub> i'd still call that a shallow use case
<jdub> those projectors are broken
<jdub> and rare
<Keybuk> sorry, but that's just something I don't agree with
<Keybuk> it's our job to work with the hardware the user has
<jdub> depth is not a display side issue to a massive degree
<Keybuk> not tell the user it's their hardware's fault
<stewart> but exactky jdub you both seem to be saying a more similar thing than you realise
<jdub> sure, but there's massively deployed hardware and pitifully deplpyed hardware
<jdub> i'm more interested in the problems posed by massively deployed hardware
<Keybuk> we should work with both
<stewart> what kb is saying is that people are frustrated with x becuase in honesty it didnt seem to move for like 5-10 years
<HrdwrBoB> for example, xv crashes X on my X40
<HrdwrBoB> quite often
<HrdwrBoB> requiring a reboot
<jdub> stewart: when Keybuk says "X is 70s technology that should be dumped", i am in absolute opposition to that idea :)
<stewart> and what you're saying is hang on its moving rapidly now that everyones moaning at it
<jdub> Keybuk: sure, but there are priorities. depth changing in XRANDR is possible, but not a priority.
<Keybuk> Keybuk doesn't know *much* about X, it's both above and below the areas I tend to deal with
<Keybuk> you probably know more than I do
<mjg59> How on earth do projectors end up refusing to accept more than 16-bit?
<mjg59> It's an analogue signal...
<HrdwrBoB> designed by rent-an-ee in some cheap country?
<Keybuk> so where I tend to throw a problem at "X", you know more about where that problem truly should be directed
<jdub> mjg59: maybe a bandwidth issue? sounds completely nuts to me.
<jdub> Keybuk: mmm - i've had to learn and keep up, given gnome stuff.
<HrdwrBoB> jdub: it probably translates it back to digital, and the software is just crap
<mjg59> Red Hat are dealing with many of the current problems with X
<Keybuk> mjg59: my experience was a projector that only did 640x480 at default depth; but was happy to do 800x600 or 1024x768 at 16-bit
<mjg59> The biggest one being run-time reconfiguration
<stewart> well this isnt gettingmy TVTIME fixed ;-)
<Keybuk> jdub: aye; currently I'm more interested in the underlying problems of getting kernel and userspace to play nice together -- and the higher problem of graphical users being able to see and change what's happening with their system
<stewart> Im gonna hit the hay night guys and keep up the great work
<Keybuk> X is somewhere in the middle of that, and not something I keep up to date with
<mjg59> The biggest technology problem with X would be that changing depth on the fly is awkward
<mjg59> But other than that...
<infinity> AFAIUI, depth is becoming a non-issue as we're seeing the ability for windows to set their own depth.
<infinity> (So, changing the server depth would just mean resetting the depth on all windows, including the root)
<infinity> Which can probably be done today, but there's no cute tool to do it.
<joelbryan> X can deal with those things, all it need is a smart script to do this and that.
<joelbryan> I personally believe that x.org is way cooler than Windows, and has magical powers.
* jdub massages X love into Keybuk's temples.
<Keybuk> jdub: mmm, harder!
<jdub> temple pressure is good :)
<sivang> hehe
<HiddenWolf> jdub: for dapper+1, will we see xgl or aiglx?
<Keybuk> jdub: perhaps you could explain what the difference between those two is? :)
<HiddenWolf> Keybuk: one is cocaine, the other is heroin. 
<Keybuk> that doesn't actually help me
<jdub> HiddenWolf: they're both in dapper universe
<hunger> Keybuk: It does not really matter which one is chosen anyway... the "cool thing" is compris:-)
<HiddenWolf> hunger: Oh please
<HiddenWolf> metacity++
<_ion> hunger: Do you mean compiz?
<hunger> Keybuk: Which is a GLX based composition manager enableing all kinds of graphic gimicks.
<hunger> _ion: Aehm... yes, of course:-)
<HiddenWolf> jdub: I know, but unless things move forward and some distro's actually ship it as default, not a whole lot will happen.
<HiddenWolf> Keybuk: http://www.freesoftwaremagazine.com/free_issues/newsletters/accelerated_x/
<hunger> By dapper+1 it should run on both xgl and the other one.
<jdub> Keybuk: Xgl is an xserver that uses GL to render *everything*. AIGLX is a set of extensions that let you do indirect acceleration (into off-screen memory), which lets your compositing manager do all kinds of cool things faster.
<jdub> Keybuk: we'll get AIGLX bits as a matter of course; Xgl will probably continue to be an option for people who's hardware can handle it.
<jdub> s/who's/whose/
<Keybuk> what does AIGLX give us that GLX doesn't?
<jdub> interesting question
<jdub> basically, it gives us a lot of love for a lower cost
<jdub> Keybuk: GLX != Xgl
<jdub> we're always using GLX here
<jdub> Xgl is designed for a world where graphics cards are just 3d cards that happen to be drawing 2d objects
<jdub> AIGLX is a bit more hospitable to reality as it is now
<hunger> Keybuk: From what I understand aiglx adds an extension to do GLX-based compositing. But that is from a Xgl developer, so I do not completly trust that statement;-)
<Keybuk> as I understand the world-to-be though, we're going to fast see graphics cards dropping 2d chips?
<jdub> for instance, video overlays - with AIGLX, you use the existing XVideo overlay foo, but don't get tasty 3d manipulation of overlayed video. with Xgl, all of that video stuff is done through pixel shaders and crap like that on the GPU.
<Amaranth> iirc the cards in the new macs don't have dedicated 2d
<jdub> hunger: they're not nasty to each other. Xgl has switched to the same extensions.
<jdub> Amaranth: no, that's more of a bios issue than what's going on on the chipset
<hunger> Keybuk: Didn't that happen already? I remember reading that some cards no longer have 2D ops.
<jdub> Keybuk: possibly. in the future.
<Keybuk> BenC: I just had a rather nasty idea ... if only we could symlink hdaX -> sdaX reliably <g>
<hunger> jdub: Yes, that is what he said, too.
<ogra> Keybuk, unionfs ? or bind mount it ?
<Keybuk> ogra: thinking about dapper+1, when IDE subsystem go bye-bye
<Keybuk> and we'll have to deal with replacing /dev/hdXY in everyone's configs, fstab, etc. with /dev/sdZA
<ogra> aiee
<ogra> who decided such a crazy thing like removing potential root device nodes ? 
<Keybuk> it makes sense
<ogra> thats evil
<Keybuk> it unifies every single disk-like device into one subsystem
<Amaranth> 2.6.16 doesn't have the IDE subsystem?
<Keybuk> Amaranth: 2.6.17
<Amaranth> ogra: the SCSI subsystem is much better than the others
<Amaranth> that's why all new devices use it
<ogra> may make sense, but i doubt *anybody* provides a good upgrade path from krenel.org ...
<Keybuk> Amaranth: indeed; which is why SATA is implemented under SCSI, not IDE
<Amaranth> usb, sata, etc
<Keybuk> ogra: since when do kernel.org care about upgrade paths? :p
<Keybuk> they leave that for us
<infinity> ogra: We had no upgrade path when SATA stuff jumped from IDE to SCSI (via libata) either.
<ogra> thats what i mean *sigh*
<infinity> ogra: Such is life.
<ogra> yeah
<ogra> but still :)
<Amaranth> it's better in the long run
<Keybuk> infinity: fortunately at that point not many people were using SATA
<Amaranth> hard upgrade, easier maintenance
<infinity> Keybuk: I was. :)
<infinity> Keybuk: And it freaked me right out.
<infinity> Keybuk: (Though not for long)
<Keybuk> the switch has an annoyingly upcoming problem
<infinity> Keybuk: The largest headache was orchestrating kernel upgrades on some remote machines where I knew the device would swap.
<Keybuk> most modern motherboards have SATA for the disks, and IDE for the CD drives
<alp> mjg59: ping
<Keybuk> I wonder what kind of random disk ordering we'll get from that
<hunger> _ion: Does NM start the scripts in /etc/network/ip-*?
* infinity wonders where all his hppa upload have gone...
<Keybuk> hunger: yes, via NetworkManagerDispatcher
<hunger> Keybuk: Great! Thanks. I was getting worried that my mails won't be delivered once I switched to NM:-)
<mjg59> alp: Hi
<_ion> hunger: If you mean if-*, yes.
<infinity> Or, for that matter, where ANY of the uploads have gone since the last LP rollout.
<infinity> Fuck.
<alp> mjg59: what's the right wiki/list to notify that i've got sdhci working with a TI on a sony t1xp using the modified fakephp patch and liberal setpci based on the docs?
<mjg59> alp: Unsure. It's not really a patch we can support
<mjg59> (Though if we're /really/ lucky, the native tifmxx driver will drive it soon and we can stop worrying)
<alp> mjg59: sure. i might be able to generalise this into a catch-all bash script to bring a few smiles to some laptop owners' faces in the meantime. will take it to the sdhci list. also, on a different topic, there's a few bugs open about a trivial variable misnomer in a laptop-mode bash script that should get fixed and uploaded
<Keybuk> ooh, visualisations are working again
* Keybuk wonders when that happened
<hunger> Any idea why NM applet always pops up a window that it does not work when starting gnome while kNM in KDE works great?
<Keybuk> hunger: which version?
<hunger> Is that because of different permissions of the users?
<hunger> Keybuk: NM is 0.6.1-0ubuntu1
<hunger> The gnome user may not do sudo... maybe that's the problem?
<_ion> Is the gnome user in plugdev group?
<hunger> _ion: Nope.
<hunger> _ion: He shouldn't meddle with things:-)
<Keybuk> why does the user have to be in plugdev?
<_ion> keybuk: Fixing that is in TODO.
<hunger> But this should explain why the mount popups always die:-)
<Keybuk> _ion: the 0.5 packages used libpamforeground, no?
<alp> mjg59: s/THIS_GOVERNOR/THIS_CPU_GOVERNOR/ in /usr/sbin/laptop_mode fixes cpu scaling. can't figure out how to use malone or i'd report it
<Keybuk> mjg59: weird bug ... something saved my session when the battery ran out
<Keybuk> would that be a g-p-m bug?
<infinity> I think something's just randomly saving sessions the whole time you're logged in.
<infinity> Cause if I violently hit the power, I'll come back with where I left off (ish), not with my last saved session (which is what I'd expect)
<Keybuk> infinity: I get worse; I never save my session, I leave it blank
<Keybuk> now, after loosing power, I have a dozen loaded apps which I need to kill
<infinity> Fun.
<Keybuk> and no way to fix that, fwict
<infinity> Session handling's gone very goofy in dapper.
<infinity> I just wish the little tickbox would come back in my logout screen, but it was deemed too unintuitive, or something.
<_ion> keybuk: I grepped for pam and foreground in the 0.5.1 directory and didn't find anything. But yeah, seems like that could be fixed with libpam-foreground.
<Keybuk> _ion: is in the dbus policy, at-console="true" or whatever
<_ion> keybuk: The policy contains the at_console="true" stuff, but it doesn't seem to be enough at least on my computer.
<mjg59> Nngh why is laptop-mode playing with CPU frequency stuff?
<mjg59> "Oh, upgrade laptop-mode, that's why things are crashing. It'll be MUCH BETTER"
<mjg59> Except it also does insane amounts of other stuff that we already deal with
<tseng> the laptop-mode wrapper a script is a "scratch my own itch, the rest of you be damned" deal
<alp> it is sick, but it seems to have got installed, so it might as well work
<Kinnison> Never fear, I am here, (Not that I know what I'm doing, vodka on pasta can do that to a guy)
* infinity laughs.
* Burgwork hugs Kinnison 
<ogra> :)
* Kinnison waits for ssh to wake up goddamnit
<Surak> :-)
<Kinnison> Okay, running commentary on ##soyuz1.0 if anyone cares
<jdub> o/~ we built this kitty on rock and roll! o/~
<Amaranth> Kinnison: I need to stop joining random channels.
<Kinnison> heh
<Amaranth> Keybuk: is this "move to SCSI subsystem" roadmap posted anywhere?
<bddebian> Vodka on pasta?
<Keybuk> hahahahaha  "road map"
<Keybuk> Amaranth: the current patch set is:
<Keybuk> http://www.ussg.iu.edu/hypermail/linux/kernel/0603.2/1402.html
<Amaranth> Keybuk: Is there at least a drunken rant on lkml about why it should be done?
<Keybuk> Amaranth: it's reasonably obvious why it should be done; because it's the right thing to do
<mjg59> Amaranth: Have you /read/ the code in drivers/ide
<mjg59> ?
<mjg59> If so, that should give you a good idea :)
<Amaranth> mjg59: I try to stay away from the kernel.
<mjg59> The legacy IDE code is horrible, full of locking races and makes hotplug almost impossible
<Amaranth> mjg59: I almost got into it once, whiskey was needed. :P
<mjg59> libata is readable
<infinity> mjg59: So, are people madly porting ancient IDE drivers to libata, or will there still be some mix-n-match hell for crazies with 486 machines?
<Keybuk> PATA support in libata is one of those things where just about everyone goes "yup, please!"
<mjg59> infinity: Alan Cox is doing it. So, yes.
<infinity> Sex.
<infinity> Go Cox.
<mjg59> In fact he's written support for some hardware that was never previously supported...
<infinity> That's very Alan.
<mjg59> Amaranth: As a reference, piix.c (from drivers/ide) is 20K. ata_piix is 17K, and does SATA as well as legacy IDE
<Amaranth> damn
<mjg59> And is /much/ more readable
<Keybuk> not to mention any comments about the IDE subsystem maintainer being almost as hard to work with as the IDE subsystem code ;)
<mjg59> Whoever the IDE subsystem maintainer happens to be at that point in time
<jdub> yay _A_
<Keybuk> he rejected our patch to take away the race condition between the "ADD /dev/hda" and "/proc/ide/hda" actually existing
<Amaranth> mjg59: so crappy code attracts assholes?
<Keybuk> likewise the patch to put the /proc information into /sys where it belonged
<mjg59> Amaranth: Or, rather, sane people stay away
<mjg59> Anyway. The world will All be Good once this is sorted
<Keybuk> well, not All good
<Keybuk> if only we could mv drivers/scsi drivers/disk or something
<mjg59> Keybuk: That's the long-term goal
<mjg59> Or, rather, the long term goal is to move it away from scsi again
<mjg59> There's no need for it to all go through the scsi layer
<Keybuk> ah, so drivers/scsi would just be scsi controller drivers using a common disk subsystem?
<mjg59> Yeah
<Keybuk> instead of using the scsi core as the common disk subsystme
<mjg59> Yes
<Keybuk> we decided that we'd hum loudly and pretend "sda1" stands for "storage device 'a' partion '1'" :)
<mjg59> Heh
<mjg59> The migration is going to be "fun"
<Keybuk> o/~ It's givin' me good migrations
<Keybuk> o/~ Ooh! Ooh! Ooh! Good migrations
<jdub> Keybuk: ha ha
<ogra> lol
<Amaranth> oh no, my hda is going away
* Amaranth wonders what this means for yaboot
<Amaranth> i guess that converts to OF calls or whatever on install so it would still work, right?
<mjg59> Well, with luck
<Amaranth> heh
<Amaranth> i think i'll stick with 2.6.15 for a while
<Amaranth> err, crap
<Amaranth> all the migration stuff will force usage of 2.6.17
<predius_> nvidia doesn't work on .16 :(
* Amaranth gets a headache
<Amaranth> predius_: small change needed to fix it
<predius_> Amaranth: link?
<Amaranth> *shrug*
<Amaranth> google
<Surak> huh
<Keybuk> Amaranth: if you're running dapper, I'd recommend sticking with 2.6.15 anyway
<Keybuk> they are /sys changes in 16 onwards that could break udev
<Amaranth> Keybuk: i meant when i switch to dapper+1
<Amaranth> like, 4 days after it opens :P
<Keybuk> if you're gonna run dapper+1, you gotta enjoy the ride <g>
<ogra> yeah
<Keybuk> release cycles are like rollercoasters
<infinity> It'll be a good ride.
<ogra> we'll break the world :)
<Keybuk> sometimes there's dips, and sometimes there's climbs
<Keybuk> and sometimes you fall off, cheat death, and then get hunted down with bizarre things happening to you
<Amaranth> i missed most of dapper
<Amaranth> i got the "omg we're gonna die" parts
<Keybuk> infinity: albeit a very quick one
<Keybuk> we'll have just enough time to break everything, and no time to fix it
<infinity> That seems ideal.
<predius_> i'm sure dapper+1 will be broken for the first couple of months
<infinity> Mark wanted it to be another warty, I think we can pull that off. :)
<ogra> you mean the first *pair* ?
<Amaranth> hmm
<Amaranth> i actuallly didn't ever use warty
<predius_> ogra: hm?
<infinity> warty worked, but was aptly named.
<Amaranth> i jumped right on to hoary when it opened
<Keybuk> infinity: "erratic" ?
<ogra> predius_, dapper+1 has only a ~4 month release cycle ...
<Keybuk> "enfeebled"?
<Amaranth> 4 1/2
<predius_> ogra: yeah.
<Amaranth> at least that 1/2 is taking a break
<predius_> well, at least we have until dapper+2 to get #1 closed
<Keybuk> I think we should skip to 'f'
<Keybuk> "frightening"
<Keybuk> "fragmented
<Keybuk> "flickering"
<Keybuk> "failed"
<ogra> hah
<mjg59> jdub: Seen http://www.mepis.org/node/9454 ?
<Keybuk> "fractured"
<lamont> ENOPITTI
<Amaranth> what's wrong with edgy? it seems to fit
<Keybuk> theres a lot of good words in "f"
<lamont> gnome-volume-manager
<lamont> -mix.mmjgroup.com 312: 
<lamont> :-(
<_ion> "f****d"
* lamont wonders where gvm might dump it's output if not to stdout...
<ogra> mjg59, cool !
<Amaranth> _ion: what animal could go with that?
<predius_> dingo?
<predius_> dodo.
<Amaranth> needs to start with f, we like alliteration (sp?)
<ogra> furrylittlethingie ?
<predius_> heh, I know.
<predius_> fairy?
<mjg59> ferret
<predius_> dat
<_ion> fish, flamingo(?)
<ogra> frightening ferret ? 
<jdub> mjg59: seen teh fridge? :)
<predius_> furious flamingo
<mjg59> jdub: Pf. Don't be silly
<predius_> as good as it gets
<Surak> furious flamingo... hum
<predius_> i'd hate to see the boxart on that
<jdub> oh man
<jdub> ControlMaster in ssh config
<mjg59> jdub: Anyway, where's the RSS feed from fridge?
<jdub> AWESOME INSIDE
<jdub> mjg59: atom/feed or node/feed
<_ion> http://fridge.ubuntu.com/atom/feed
<predius_> mjg59: ttp://fridge.ubuntu.com/node/feed
<_ion> RSS is teh suxor, Atom ftw.
<mjg59> jdub: Pff. Why is there no buzzword compliant button on the front page?
<jdub> mjg59: i will make it compliant immediately, with the new orange buzz compliant icon
<mjg59> Excellent
<_ion> Be sure to put a lot of enterprise into it.
<mjg59> COMMUNITY FEEDBACK AT ITS FINEST
<jdub> i will
<mjg59> Haha
<jdub> The Fridge is totally ready for Star Trek
<mjg59> The Daily WTF has been excellent this week in that respect
<Keybuk> WARP FACTOR FIVE MR WAUGH!
<_ion> mjg: Yeah. :-)
<Surak> engage
* sivang is tired of long HUB hacking, goes to sleep.
<sivang> night all!
<Surak> night sivang.
<sivang> (3:26am here, so nobody would think I'm a slacker ;-)
<sivang> nite
<nictuku> should a dist-upgrade using aptitude work fine? is it recommended? in debian it's the prefered method
<_ion> Wow, the same timezone.
<_ion> sivang: Where do you live?
<CarlFK> dapper-server doesn't react to the power button, same box, dapper live cd from a few days ago does.  what package do I bug?
<_ion> Probably something ACPI-related.
<Kinnison> _ion: sivang lives in israel I believe
<CarlFK> dern... keep forgetting about #u-bugs
<Amaranth> bah, the network manager 0.6 stuff is x86 only
<infinity> That's easily solved.
<Amaranth> yep, building now
<Amaranth> well, it works just as good as the one in dapper
<Amaranth> i blame the bcm43xx driver for wireless networks not working
<Amaranth> [76583.711537]  SoftMAC: Authentication response received from 00:16:b6:1b:dc:e3 but no queue item exists. <--that's a new one
<mjg59> Amaranth: Yeah, bcm43xx seems to fail to switch back to your network after doing a scan
<mjg59> Amaranth: There's a patch on the mailing list to fix that
<Amaranth> i've never been able to connect with it (longer than 2 minutes, once, with a static ip)
<mjg59> You need to limit your rate to 11M for it to work even vaguely reliably
<mjg59> But then it's fairly good
<LaserJock> mjg59: how's the macintel work going? I looked like from the changelog you have got it running
<mjg59> LaserJock: Yeah, just need a couple of installer fixes
<LaserJock> mjg59: will it make it in Dapper? I'm talking to some fink guys and they wondered
<mjg59> LaserJock: Should do
<mjg59> By the end of the week, with luck
<LaserJock> great news. This iMac is kicking my tail
<LaserJock> Nothing *nixy is working well at all
<Keybuk> oh, that's quite cute
<LaserJock> python and gcc seem to be a mess
<Keybuk> this package compiles on i386 but not amd64
* Amaranth want Intel Mac mini
<jdub> mjg59: delivered/
<mjg59> jdub: Mm?
<Amaranth> LaserJock: i spent a week getting qt4 compiled on os x
<jdub> mjg59: feeds in the html
<jdub> mjg59: for wetware
<mjg59> jdub: Hurrah!
<jdub> (rather than html for software, which was already there)
<Amaranth> then another week teaching sip and pyqt4 about os x
<jdub> mjg59: i even got a skanky food reference in
<mjg59> jdub: Indeed
<mjg59> I'm very impressed
<neuralis> mjg59: in case you don't hear it enough, your work is awesome and very much appreciated.
<mjg59> neuralis: Thank you :)
<infinity> I also would like to sup on mjg59's wang.
<infinity> Or anything for that matter.
<Burgundavia> Seveas: we need your quote bot ^
* infinity -> gone for a very, very late breakfast (or is it lunch?)
<mjg59> infinity: You may have to negotiate with Fiona first
<jdub> mjg59: "MEPIS is no longer involved with the DCC due to 'creative differences.' We wish Progeny, Xandros, and Linspire the best of luck in their mutual endeavors," said Woodford.
<ajmitch> hah
<mjg59> Go DCC
<jdub> 'creative differences' such as... 'creating anything'
* Burgundavia watches the foundations crack
<jdub> or perhaps 'creating trademark confusion'
<Burgundavia> hmm, dcc needs to update their website. Mepis is still there
<mjg59> jdub: Where's that from?
<crimsun> isn't the 6.0 beta release based on dapper?
<Amaranth> jdub: hey, no images in the feeds?
<mjg59> crimsun: Yup
<crimsun> rock
<mjg59> jdub: Ah, never mind, found it
<jdub> Amaranth: so i'm wondering about that too
<jdub> Amaranth: appears to be an atom thing (they're in the rss feed)
* Amaranth stabs atom
* jdub checks the atom plugin thingy
<jdub> not atom's fault
<Amaranth> "let's unify all the syndication methods by...get this...making a new one!"
<Keybuk> it fills me with infinite joy that this library designed to provide an easier kernel interface has *never* been tested on a 64-bit machine
<Kinnison> well that'd be too goddamn easy
<Keybuk> in fact, it looks like it's never been tested on anything other than i386
<Kinnison> common
<Keybuk> nl-tctree-dump.c:31: warning: cast from pointer to integer of different size
<Keybuk> WWAAAAHHH!!!!
<Keybuk> MUMMY!!!!!!
<bddebian> heh
<Keybuk> and this is supposed to work, is it?
<Amaranth> Keybuk: magic fairy dust
<Keybuk> Amaranth: no, this is magic SEGV dust
<Amaranth> those are always fun
<Keybuk> "dear authors; you cannot stuff an int into a pointer on every architecture"
* jdub pushes int harder.
<bddebian> hehe
<Amaranth> that's actually the reason i don't use C: everything i touch segfaults
<Amaranth> gcc is like "you added a comment? i'll add a segfault!"
<sladen> jdub: where's the DCC quote?
<bddebian> Amaranth: :-)
<jdub> sladen: top ITP story on teh fridge
<Fjodor> Would someone be interested in trying out some supposedly performance-on-amd64-improving patches for glibc, that I notified Jeff Bailey about, or should I wait for him to include it and call for testers?
<robertj> hrmm, wesnoth isn't playable in multiplayer at version 1.1, it's too old for the dev server and too new for the stable server
<sladen> jdub: yeah, I couldn't see the actual quote in it (or in the linked linuxtoday article)
<xhaker> just asking, gaim2.0 = dapper+1 right?
<xhaker> i'm asking this since watching cvs commits they seem to be almost there
<jdub> sladen: that is not the top one
<xhaker> another thing, has anyone thought of making a gaim smiley theme for Ubuntu as part of the UI revamp?
<Robot101> xhaker: it was discussed with them (upstream) and me (Debian maintainer) and we decided it wasn't a safe bet to be ready on the dapper timeframe
<Robot101> xhaker: I wouldn't go for 2.0.0 either, it will be followed up after a week or two with a load of "oh shit" bugfixes
<xhaker> lol
<xhaker> Robot101: thanks for the heads up then
<Robot101> what concerns me more is the 70 or so issues found by the coverity checker
<Robot101> which they've fixed most of in cvs
<xhaker> in 1.5?
<Robot101> but nobody has looked to see a) which are security problems or b) remotely exploitable or c) applicable to 1.5.x
<xhaker> Robot101: handpicking cvs blocks is not doable too
<Robot101> I don't have time to do any of those, but based on Gaim's track record it's not only likely, but inevitable
<xhaker> argh, stuff for backports hopefully
<Robot101> yeah but even in Debian there's no real way to sign off on a Gaim release and call it fit for stable
<Robot101> maybe even its stuff for volatile
<xhaker> Robot101: what do you mean, they change too much?
<Robot101> yeah, it's too much work to track the changes between a fixed release of gaim and HEAD and know what is or isn't worthy for backporting
<Robot101> I suppose it's nowhere near as bad as mozilla, but it still worries me
<Robot101> people try crashing IM clients far more than they do web browsers
<Fjodor> No testers for my amd64 patch? Anyone want to advise as to what I should try to run on a patched vs. an unpatched system then?
<childe> Hi, where can I get a debug kernel?
<childe> To use with addr2line.
<xhaker> childe: i think if you want it in ubuntu the way is to compile it yourself
<xhaker> with the debug options turned on
<childe> xhaker: Hmmm...why don't Ubuntu provide such a package, like in RedHat. Compiling a kernel on my own system costs a lot of time. It will be better to provide a package.
<xhaker> it would indeed, i don't think it's a lot of time though, depends on the hardware/connection
<xhaker> childe: do you think a -debug kernel is necessary? really really? if you file a bug in launchpad.net the kernel team might hear you
<childe> xhaker: I reported that bug to X team because it's that i810 X driver causes kernel panic. 
<childe> xhaker: Should I report it to the kernel team?
<xhaker> childe: just file a wishlist bug asking for a fully ready -debug kernel
<childe> xhaker: If the kernel team put their debug kernels online, other people who have time can help them.
<childe> ok
<xhaker> childe: i don't know if they are debug kernels
<xhaker> but they might, i mean.. the daily kernels BenC hosts
<childe> xhaker: Could you please tell me the URL of the daily kernels?
<xhaker> http://people.ubuntu.com/~bcollins/
<xhaker> it seems that he stopped doing them.. atleast the last one dates from january :S
<xhaker> childe: those are old kernels :/
<childe> xhaker: It's OK because this bug is reproducible even on Breezy.
<childe> xhaker: But it seems these kernels are not debug kernels :-(
<childe> xhaker: The bug is #34697 on launchpad
<xhaker> crap.. double clicked it
<xhaker> lol
<childe> xhaker: This bug is really anonying. Now I can only use xfs_freeze then Sysrq+O to shutdown the machine :(
<xhaker> i read it
<xhaker> too bad :/ 
<xhaker> have you tried the i386 kernel?
<childe> And the X team seems too busy and have no time to deal with this non-critical bug...so I want to try to debug it by myself.
<childe> xhaker: AFAIK, it's a x86_64 only bug.
<xhaker> figured
<jdub> BenC: ping
<jdub> BenC: ping (payload: smaps)
<_ion> jdub: Pong.
<_ion> There seems to be a routing error.
<childe> _ion: Do you know where I can download a debug kernel?
<_ion> childe: Uh, no.
<childe> OK...maybe I need to compile it on my own machine :-(
<_ion> I have had to compile my own kernel, so that i can use /dev/fb* with Matrox G400 properly.
<childe> _ion: What machine do you use and how long it took?
<_ion> childe: PIII 500MHz, 384MiB memory; i don't remember.
<_ion> Not too long.
<childe> _ion: I think you configured the kernel to meet your specific hardware devices
<_ion> Yes.
<childe> _ion: But I need the debug version of the official full kernel
<childe> :-(
<jdub> Amaranth: that feed images thing is fixed
<jdub> anyone have ideas for a new poll on the fridge?
<nictuku> ahmm music player of choice?
<nictuku> how can I ask for an update of https://launchpad.net/distros/ubuntu/+spec/network-wide-updates /
<nictuku> *?
<nictuku> I suppose I should not change it myself
<robitaille> jdub:  for a pool:   kubuntu?  ubuntu?  xubuntu?  etc.  I'm curious of the ratio ubuntu vs kubuntu these days
<robitaille> s/pool/poll
<jdub> robitaille: feel kinda uncomfortable with obviously competitive stuff on there
<_ion> jdub: Emacs vs. KDE
<_ion> "Which one is better?"
<infinity> "Who's a better source of information?" [ ]  The Fridge  [ ]  Your mom
<nictuku> what do you use at home? a) Ubuntu b) Windows 3.11
<robitaille> how about a poll about potential names for Dapper+1
<nictuku> isn't that decided already?
<_ion> nictuku: In that case the poll could have just one radio button and the submit button. :-)
<_ion> A poll about potential names for Dapper.
<_ion> [ ]  Dapper
<_ion> [ submit ] 
<nictuku> and the second radio button is inselectable
<nictuku> *un
<jdub> robitaille: hrm, wish i could do a write-in poll, then we could ask for suggestions for animal names that start with E
<Burgundavia> jdub: marks hair styles for a laugh?
<jdub> can't do images as poll items :(
<jdub> as soon as we can though, i'm up for it
<G0SUB> jdub: wiki?
<jdub> G0SUB: ?
<G0SUB> jdub: can't we use a wiki for the poll?
<jdub> i'm looking for a new poll for the fridge
<G0SUB> i see
<G0SUB> how about ``Edgy Elk'' ?
<G0SUB> Elk is a large Deer btw
<robitaille> brown or blue for your theme?  (or maybe we have done that one already....)
<HrdwrBoB> enraged elephant
<G0SUB> HrdwrBoB: edgy is fixed
<HrdwrBoB> ah
<G0SUB> Edgy Elk sounds good IMO
<mroth> Edgy Emu
<robitaille> jdub: what was your prefered OS before Ubuntu?
<HrdwrBoB> no-name-yet
<HrdwrBoB> :)
<Burgundavia> robitaille: is that a question or a poll?
<Burgundavia> I would like to know the answer though
<G0SUB> Debian?
<robitaille> Burgundavia:  poll...we would need to add the usual suspects for choices
<Burgundavia> I like it
<robitaille> tells us how many people are switcher (from windows, etc) vs switcher from other linux, etc etc
<_ion> eagle, earthworm, eel, elephant, elk, emu, ewe 
<robitaille> in my case, I came from FC1
<Burgundavia> rh8 for me
<Burgundavia> windows for my brother
<G0SUB> I came from Debian
<G0SUB> [for the desktop] 
<_ion> I switched from AmigaOS to Debian when i got a PC.
<Burgundavia> interestingly, I was diggging through popcon on debian
<_ion> Now i use Ubuntu for the desktop.
<Burgundavia> it appears that gnome and kde are about neck and neck for installations, with gnome slightly ahead
<robitaille> That's why I wanted a Ubuntu vs Kubuntu poll :)
<joelbryan> do you think ekiga should be run on startup in dapper?
<hendry> isn't there something like popularity contest for ubuntu?
<robitaille> we had a visitor at work today, with a Kubuntu laptop.  Being the resident ubuntu fanboy, people pointed that to me very quickly
<hendry> joelbryan: ekiga shouldn't be in startup
<joelbryan> hendry: why?
<hendry> joelbryan: takes up valuable resources
<joelbryan> ok
<HrdwrBoB> should my X40 stall while 'loading hardware drivers' until I break it ?
<hendry> i don't think ekiga works through a firewall, does it?
<Burgundavia> hendry: you mean default install?
<Burgundavia> yes, it works through most firewalls
<hendry> Burgundavia: pardon?
<joelbryan> hendry: yes, through STUN
<hendry> why does it have this odd NAT dectection phase?
<Burgundavia> ekiga should be in the default install because we want to encourage free codecs for speech
<joelbryan> I have a strict NAT setup
<joelbryan> and it works
<joelbryan> yes
<hendry> in order for ekiga to work. do you have to sign up to ekiga service??
<Burgundavia> no
<joelbryan> yes
<_ion> hendry: You can use any SIP provider/server.
<Burgundavia> all you need is to call any other sip account
<joelbryan> ah, ok, you use your IP
<joelbryan> h323
<Burgundavia> sip is an open protocol, unlike skype
<Burgundavia> h323 is an older standard for video conferencing
<Burgundavia> h323 != sip
<_ion> h323 < sip :-)
<joelbryan> yup
<hendry> what do win32 users have to install to talk to you?
<joelbryan> but you can call an ip using h323
<Burgundavia> openwengo
<Burgundavia> any video conferencing program that speaks sip
<hendry> why doesn't ubuntu provide SIP addresses?
<joelbryan> google talk?
<hendry> can I use my google account with Ekiga?
<Burgundavia> hendry: http://en.wikipedia.org/wiki/List_of_SIP_software
<Burgundavia> hendry: that is jabber and that is a different protocol entirely
<hendry> Burgundavia: so that's a no?
<Burgundavia> https://wiki.ubuntu.com/UbuntuMac
<Burgundavia> no
<Lathiat> ekiga provides its own sip address server
<Burgundavia> ideally we should one "talking to people" client that does all this
<Lathiat> you get @ekiga.nets
<hendry> so with Ekiga I can't talk to GoogleTalk peeps. Oh gawd
<Lathiat> no, googletalk is a totally separate protocol 
<joelbryan> I think google is upto sip support
<Burgundavia> nothing but googletalk currently does the video stuff from there
<G0SUB> hendry: GTalk is XMPP
<Burgundavia> Google Talk supports XMPP with the beta release. We plan to support SIP in a future release. Additionally, we will evaluate other protocols as appropriate, to continue to deliver on our commitment to open communications
<hendry> i remember writing a SIP review paper. I remember it sucking
<hendry> http://www.cs.helsinki.fi/u/kraatika/Courses/MobInt/Essay2/Hendry.pdf
<joelbryan> Burgundavia: your from google! cool.
<Burgundavia> joelbryan: uh, I wish
<joelbryan> misinterpreted your post, looks like your from Google
<hendry> wish to be another corporate Google drone? ;)
<_ion> He probably pasted it.
<Burgundavia> joelbryan: I copied that from the googletalk faq
<Burgundavia> sorry, should have quoted it
<joelbryan> yeah, I understand now.
<fabbione> sladen: have you decided to take over X?
<Burgundavia> fabbione: he touched it, his now!
<fabbione> sladen: i don't mind if you want to work on X, but we need to coordinate the work.
<sladen> fabbione: oh, don't worry, I left the Maintainer field along so you'll get all the bugs :)
<_ion> :-)
<fabbione> sladen: eheh i didn't touch it either.. sucks to be Daniel Stone
<sladen> fabbione: yeah, I'm only  interested in i810 stuff that I can test here and that's not too intrusive
<joelbryan> do you think there should be a welcome screen for Dapper, just like fresh install XP's?
<fabbione> sladen: what has agpgart to do with the resolution issue?
<Burgundavia> joelbryan: only in the OEM mode
<fabbione> sladen: that guy had 1MB of shared ram allocated from the BIOS.. X did the detection correctly
<joelbryan> Burgundavia: really, are there screenshots?
<sladen> fabbione: what's your opinion on fixing the Xv stuff---that's a bug that has been bugging for ages
<fabbione> sladen: what bug is that?
<sladen> fabbione: doesn't the agpgart support allow the available memory window to be dynamically altered?
<Burgundavia> joelbryan: OEM currently is text only. It would be nice if it had a pygtk interface. Want to write one?
<fabbione> sladen: i did a round of fixes to get rid of stupid bugs in the libs.. i still need to get to drivers
<fabbione> sladen: not if the BIOS forces the shared mem to N Mb
<joelbryan> Burgundavia: yeah, I'm currently writing a GTK+ version
<fabbione> sladen: this is one of these card that doesn't have its own RAM.
<fabbione> sladen: so the BIOS rules you
<fabbione> sladen: have seen it many many many times
<sladen> fabbione: bug #28326  for the Xv
<Ubugtu> Malone bug 28326 in xserver-xorg-driver-i810 "crashes after long-use -> infinite resprawn (Xv trigger?)" [Major,Confirmed]  http://launchpad.net/bugs/28326
<joelbryan> Burgundavia: I want to know what OEM mode asks to the user?
<Burgundavia> joelbryan: name, password, timezone, dob, mothers maiden name, dogs birthday, what you ate for dinner last night :)
<Burgundavia> joelbryan: seriously, only the first three are what you need
<sladen> fabbione: most cards are shared memory now (eg. i810) and the allocated RAM goes up and down based on what X asks for  (IIRC, E&OE)
<joelbryan> Should it asks to register a Ekiga.net SIP name?
<Burgundavia> joelbryan: and you migth be able to reuse on of the espresso parts (the one that creates users)
<Burgundavia> joelbryan: nope
<joelbryan> Should it asks to run Ekiga on startup?
<hendry> does anyone here use Gmail and still doesn't have Talk integrated?
<Burgundavia> joelbryan: just checking, do you know what the OEM installer is?
<fabbione> sladen: do we have a patch for 28326? otherwise i am not sure i can fix it...
<joelbryan> I've seen it, but not use it, it doesn't have an explanation of what OEM mode is, so I use normal install instead
<sladen> fabbione: AlanH pointed me to some stuff of his, but it needs pulling out from bigger commit
<Burgundavia> joelbryan: OEM installer is when someone is installing the box for somebody else. Such as Dell, who preinstall Windows
<fabbione> sladen: i have never seen this dynamic mem allocation happening.. i *think* the only way to force the request it to set VideoRAM but we can't do it by default
<Burgundavia> joelbryan: the questions that are relevant to the user (their name and where they live) are left until the end. The machine is shipped at the state when you turn it on, you get those questions asked
<fabbione> sladen: bigger commit for the i810 or all over the X tree?
<Burgundavia> joelbryan: currently that is a text mode, but it would be much nicer if it was a pygtk interface
<fabbione> sladen: i am dealing to ask UVF breakage if there are good reaons
<fabbione> reasons even
<joelbryan> Burgundavia: should it be called, "Personalize Installation (OEM Mode)"
<sladen> fabbione: only instead i810.  I think the only other thing in that bundle might be rotation support (which would be nice to have aswell to support the various tablets)
<Burgundavia> joelbryan: OEM installation is really only good for those who are doing lots of installs on machine they themselves are not going to be doing
<sladen> fabbione: ^^only inside i810
<infinity> joelbryan: More to the point, it's everything BUT personal.  You're installing a system, but not doing inital user setup, etc.
<infinity> joelbryan: So, when the customer boots it the first time, it gets setup up for them.
<fabbione> sladen: ok.. i think it is doable.. 
<sladen> joelbryan: OEM is designed for people like Dell or HP.  They "install" ubuntu once.  Image the disk XXX thousand times and then when each user turns on their machine for the first time it's already installed but still asks the username/password...
<infinity> joelbryan: If you've ever bought a machine with a Windows OEM install on it, you'd know what I mean (except theirs is graphical and ours isn't quite yet)
<Burgundavia> joelbryan: http://ubuntu.wordpress.com/2005/10/11/ubuntu-oem-mode/
<Burgundavia> infinity: can we use the espresso user-setup bit?
<sladen> fabbione: maybe I'll look at it when awake.  the Xv is a bug-fix for something that's been around for a long time;  xrandr would be a UVF feature request (it's been in Xorg CVS for about 12weeks now)
<infinity> Burgundavia: Probably.  I don't know how much developer time there is to go around to fix up OEM mode AND finish espresso.
<fabbione> sladen: did they release a new driver with this stuff?
<fabbione> sladen: or are we talking only CVS...
<infinity> Burgundavia: But espresso could well be used as the graphical stage2 for OEM, yeah...
<Burgundavia> infinity: OEM works, that is all i care about
<infinity> Burgundavia: (Well, bits of it)
<joelbryan> Burgundavia: should it be pygtk?, why not C?
<Burgundavia> joelbryan: because pygtk is easier and faster to write in
<Burgundavia> not that I write code...
<joelbryan> Burgundavia: ok, uhmm... don't know much about python, but I can write it entirely in GTK+
<joelbryan> Burgundavia: I mean C
<joelbryan> Burgundavia: or I use Glade and generate it in libglade
<infinity> It's just faster to prototype in a scripting language, that's all.  If you're comfortable and quick with C, no one's suggesting you not use it.
* _ion thought that python rules until he learned ruby. :-)
<joelbryan> infinity: ok, hehehe, just trying to comform with ubuntu standards, maybe I'll break something if I use this and that.
<joelbryan> clearly Ruby isn't installed default, so I should not use it.
<infinity> joelbryan: If you want to have other people be able to make very rapid changes/bugfixes to it, python's a better choice than C  (I say this, despite not really liking python at all, and rather quite liking C)
<infinity> joelbryan: But if you don't know python at all, and aren't in the mood to learn (or just plain prefer C), then go with C.  Most anyone who will want to hack on your stuff will know C anyway.
<Mez> hey infinity, everyone else
<joelbryan> Is there a problem with Glade generated source?, future compatibility issues? security holes?
<joelbryan> I think Glade generated source is neat, it has modular source codes, much easier to understand.
<Burgundavia> fabbione: why is timezone data stored in glibc?
<infinity> Burgundavia: It's not anymore.
<infinity> Burgundavia: It's in "locales" now.
<Burgundavia> infinity: but why does upstream do it that way?
<Burgundavia> it seems very "kitchen sink"ish
<infinity> Burgundavia: Upstream doesn't dictate how we split it up.
<infinity> Burgundavia: glibc can't really do its job (well, all of its jobs) without timezone and locale info, so upstream ships that too.
<Burgundavia> ah
<infinity> We happen to know (from experience), that on a cut down system, you can live without that stuff.
<infinity> So we now ship them seperately.
<jdub> glibc is our rock
<infinity> But most people probably still want the kitchen sink.
<Mithrandir> I like kitchen sinks.  Hard to make food without one.
<infinity> 99.9% of installations are "broken" without locales and zoneinfo, IMO.
<infinity> The other 0.1%... Well.. I happen to be one of those users. :)
<Burgundavia> ok. I just seemed so odd to have two seemingly non-relating things in one package
<Burgundavia> package being glibc, not in the debian sense
<Mez> Mithrandir, why is it hard to make food without the kitchen sink? surely you dont really need that much water
<Mez> infinity, that's cause you're weird ;)
<Mithrandir> Mez: I wash the stuff I make food with quite a lot.  Like, the semi-large knife I use for meat and vegetables, for instance.
<Mithrandir> Mez: as well as all the plates and stuff I use in between
<Mez> Mithrandir, surely you could wash those in the bathroom sink though? or under the tap outside?
<Mez> Mithrandir, why does it specifically have to be a "kitchen" sink] 
<Mithrandir> Mez: tap outside?  In -10C and one floor down?
<Mithrandir> because I tend to make food in the kitchen and having the tools I need to make food elsewhere is not helpful?
<Mez> Mithrandir, *shrugs* I've had to deal with worse (-10 inside )
<Mez> Mithrandir, it's helpful to have a kitchen sink  but not essential
<Mez> (anyway - I'm just rambling)
<pitti> Good morning
<fabbione> who has an opinion on #35758 ?
<fabbione> it looks like a dumb bug
* infinity taps his foot, waiting for Herr Vogt to show up.
<fabbione> Ubugtu: malone #35758
<Ubugtu> Malone bug 35758 in xinit "startx leaks .serverauth.???? files" [Normal,Unconfirmed]  http://launchpad.net/bugs/35758
<infinity> Looks like a "Don't Do That, Then" bug to me.
<fabbione> yeah exactly
<hendry> can ubuntu resize ntfs?
<infinity> Yes, but I'm not sure I'd recommend it.
<hendry> infinity: from the installer eh?
<infinity> It might be disabled in the install out of paranoia.  I'm not sure.
<infinity> Kamion / Mithrandir : --^
<infinity> mdz: Around?
<mdz> infinity: yep
<Burgundavia> pitti: have you seen this? https://wiki.ubuntu.com/RootSudo?action=diff&rev2=28&rev1=27
<infinity> mdz: How do you feel about a UVF exception for ttf-freefont?
<mdz> infinity: nervous
<Seveas> Burgundavia, I already reverted the latest edit
<infinity> mdz: It's currently FTBFS (and has been since January, go us!), Christian Perrier has taken it over in Debian and is giving it much love.
<mdz> new upstream versions of freefont always seem to have unpleasant side effects
<mdz> changed glyphs, adding new ones which override other fonts in unexpected ways, etc.
<infinity> mdz: Yes, but at least this time it's being maintained by someone who's close to both the installer and the translators.
<mdz> takes a while to shake out
<mdz> what's the nature of the FTBFS?  this version built at one point
<Burgundavia> Seveas: thanks, I saw that
<infinity> mdz: Alternately, I could just fix the FTBFS... But that would, ironically, bring us a new upstream too, since we never got the new upstream built.
<infinity> mdz: Ever since it was synced, it hasn't built.  No one bothered to check.
<Seveas> Burgundavia, episode 999 in the story of John Richard Moser - more to follow soon I'm afraid...
<infinity> mdz: I'm going through every FTBFS in main right now (only a couple left) and found this.  <sigh>
<Burgundavia> Seveas: we seem to have a few. George Farris is another
<Seveas> that's the downside of being popular
<infinity> mdz: We have 20051102-2 built, 20051206-2 synced (but FTBFS), and current upstream is 20060126b-2
<mdz> infinity: gah
<pitti> Burgundavia: heh, classic trojan horse :)
<infinity> mdz: That's what I thought. :/
<Seveas> Burgundavia, there was a troll yesterday that followed me everywhere and even called me on the phone (which means he can google, takes ~3 seconds to find it) - just symptoms of a growing community
<Burgundavia> Seveas: ah, the warty days 
<infinity> mdz: Alternate option at this stage would be to reupload the old version with a hideous version number, since we know it works for us.
<Seveas> Burgundavia, how I long for those sometimes...
<infinity> mdz: Perhaps I should discuss this with Kamion instead, since this has a pretty high impact on the installer?
<mdz> infinity: it does?
<infinity> mdz: At least, I believe this is the scary font that gets used in the installer, right?
<infinity> Or am I thinking of another scary font...
<infinity> Maybe I'm on crack. :)
<mdz> I think the installer uses default fonts
<infinity> The installer uses some scary all-in-one font for a few screens (though that may be obsolete now with gfxboot)
<Burgundavia> Seveas: I sort of do, but then think of the cool projects that are happening because Ubuntu is big
<Seveas> true, true
<Burgundavia> and the NM work by _ion and others
<Seveas> ah well, let's not behave like old men and look forward instead of looking back 
<Burgundavia> Seveas: incidentally, how old are you?
<Seveas> If I get the wxwidgets problem sorted, then maybe I can have Xara ready in time
<Seveas> Burgundavia, 23.5 minus 8days
<Burgundavia> Seveas: ah, my age then
<Seveas> and certainly not the age yet to keep dreaming about the past ;)
<mdke> youngsters
<Seveas> Burgundavia, did you see what was going on in #ubuntu between now and 8 hours ago?
<Seveas> I heard some rumours arnieboy 'paid us a visit' and started swearing at everyone
<Burgundavia> Seveas: happily, my time constraints mean I can no longer follow #ubuntu
<Seveas> hehe, lucky fellow :0
<Seveas> it's increasingly hellish there at time
<Seveas> s
<Seveas> OMG, when did karma explode at launchpad?
<Seveas> I was at 1267 yesterday, checking regularly since I wanted a screenshot of Karma: 1337 but now my karma is 42617
<infinity> I need to write some karma bits into all the buildd administration actions, so I look like less of slacker...
<Seveas> hehe
<Seveas> apparently bug triaging is very high vaued now
<Seveas> so shall I file some bugs against a few of your packages? >:)
<infinity> I have enough bugs, thanks. :P
<robitaille> yeah, some of us have had very good karma increases in the last 24 hours
<Burgundavia> it appears that specs are good karma boosters too
<Seveas> robitaille, your karma must be close to infinity (no pun intended0 now
* Burgundavia goes to write some useless specs
<Seveas> robitaille, btw: next CC meeting is april 3, 09:00 UTC. Could you please add that to the fridge?
<robitaille> Seveas:  done already
<Seveas> you rock 
<infinity> pitti: If I yell at you, can you pass the chastisement on to mvo when he shows up (since I've fixed this bug several times now, and you both did it more than once)? :)
* infinity clears his throat.
* Seveas plugs his ears
<pitti> infinity: erm, erm, for which bug?
<infinity> pitti: INTLTOOL-UPDATE IS IN INTLTOOL, ARGH!  *cough*
<infinity> There, all done.
<pitti> ah, that one *blush*
<infinity> doko_: Are you alive, or just suffering client bounce?
<doko_> infinity: both
<infinity> doko: Do you recall what your rationale was for switching libidl to mcpp from cpp?
<infinity> doko: It's FTBFS with mcpp, works great with cpp.
<doko> infinity: have only one cpp used on the CD, all of gnome uses mcpp
<infinity> doko: Because of xrdb, I assume...
<infinity> (At least, it's the only thing that directly depends on mcpp)
<infinity> We could just switch xrdb to using cpp...
<infinity> Unless that breaks the world.
<infinity> Otherwise, feel free to investigate the libidl FTBFS.
<Mithrandir> infinity: I thought we switched to mcpp since it's way quicker?
<infinity> I have no idea, hence why I was asking. :)
<doko> yes, the speed was mcpp's advantage
<infinity> doko: Kay, can you kindly make libidl actually work with mcpp, then? :)
<infinity> I suspect it's just a broken autoconf test or something equally silly, but haven't poke it.
<fabbione> if you are fixing mcpp there is also another annoying bug about predefined macros not being there that it would be very nice to get rid of
<doko> infinity: hmm, doesn't fail here ...
<infinity> doko: ...
<infinity> doko: It failed on every buildd, some several times...
* infinity tries it locally.
<mdke> is there a good reason the exim4 metapackage is in universe?
<mdke> its dependencies are both in main, i think
<infinity> mdke: No, I keep meaning to seed the metapackage.
<doko> Predefined macro file '/usr/lib/gcc/i486-linux-gnu/4.0.3/include/mcpp_gcc40_predef_old.h' is not found
<infinity> mdke: Thanks for the reminder.
<mdke> infinity, ah cool. nice
<doko> that's the only warning I get
<fabbione> doko: yes.. that one
<fabbione> there are 2
<fabbione> old and std
<infinity> configure: error: C preprocessor "mcpp" fails sanity check
<infinity> doko: my local attempt --^
<infinity> Oh, haha..
<infinity> /home/adconrad/libidl/libidl-0.8.6/./configure: line 4208: mcpp: command not found
<infinity> That would be much more useful if you didn't hide it in a log, dear autoconf!
<Keybuk> "Microsoft delays launch of Vista"
<Keybuk> *blink*
<Keybuk> ...by 6 weeks?
<infinity> doko: You just forgot the build-dep, that's all.  Feh.
<Seveas> Keybuk, something like that
<pitti> Keybuk: 'World delays launch of April - by six weeks'
<infinity> doko: I'll upload right now.
<pitti> Keybuk: that would be much more helpful to both M$ and us, wouldn't it? :)
<Keybuk> yes
<Keybuk> we could add an extra 42-day month after March
<Keybuk> we could call it Stroll
<pitti> Keybuk: Polishuary
<doko> infinity: ohh, would be better ;)
<Seveas> pitti, Bugfixtember
<pitti> Seveas++
<Keybuk> "Sliptember"
<pitti> hey mvo 
<Treenaks> Hugtember?
<Kamion> 05:57 < Burgundavia> joelbryan: OEM currently is text only. It would be nice if it had a pygtk interface. Want to write one?
<pitti> mvo: protect your ears, infinity will yell at you
<mvo> hey pitti
<Kamion> Burgundavia: Oi, check your facts before saying that. ;-)
<mvo> pitti: what did I do?
<Kamion> infinity: installer and gfxboot both use unifont
<infinity> pitti: No, no, you were supposed to pass it along for me.
<infinity> Kamion: Ahh, I misremembered, then.
<Keybuk> Kamion: could you process a NEW for me?
<pitti> mvo: <infinity> pitti: INTLTOOL-UPDATE IS IN INTLTOOL, ARGH!  *cough*
<infinity> mdz: Right, ball's back in your court, then, unless you want to delegate this one to the desktop guys. :)
<pitti> infinity: I didn't know whether just yelling at me vented enough of your frustration already :)
<Kamion> Keybuk: sure, I was halfway through morning NEW processing when Kirsten chucked me off the laptop for her morning website browsing
<infinity> mdz: We can either upload the old package with a wonky version number, fix the currently FTBFS (and untested) one, or upload the newer onr from Debian.
<Keybuk> Kamion: libitwouldbeniceifsomeonetestedthisoni386
<mvo> heh :) I suppose we are talking about hwdb-client?
<Keybuk> uh, I mean, libnl ;)
<Keybuk> and stick a "!" in there
<Keybuk> *ahem*
* Keybuk drinks his coffee
<infinity> mvo: I think you may have done one or two, I know pitti did a couple. :)
<Seveas> Keybuk, that's the thing used by NM, right?
<Keybuk> Seveas: yes
<Burgundavia> Kamion: by text I meant ala d-i text
<Seveas> what do you need tested - I'm on i386
<Keybuk> it only worked on i386
<Keybuk> it didn't even compile on amd64
* Keybuk gets those nice shivers
<Kamion> Burgundavia: well sorry, you're still wrong :)
<mdz> infinity: I suppose we bite the bullet; if we need to take a new upstream we might as well get the latest from Debian
<Kamion> Burgundavia: oem-config is and has always been pygtk
<infinity> mdz: Alright, I'll sync it right now, then.
<Burgundavia> Kamion: I have not played with oem for a long time (breezy beta). I stand corrected
<Kamion> you do a regular install first, but the "OEM installer" bit of it is pygtk
<Kamion> breezy beta oem-config was pygtk too
<infinity> mdz: At least I know the current maintainer is reasonably sane...
<Burgundavia> I think I tried breezy at the time when OEM installer was borked, so hmm...
<Kamion> it's borked in dapper now at the moment too - blocked on me having time to chase down the buglets
<mdz> infinity: does soyuz not give you appropriate notifications/reports for FTBFS yet?
<Kamion> also, FYI, it already uses user-setup
<Kamion> (the backend)
<infinity> mdz: Nope!  I'm using britney's out-of-date reports to tear through everything that's currently broken in main, then will quinn-diff universe to file bugs for the MOTUs.
<Burgundavia> Kamion: hey, you get to wave the retroactive feature wand today :)
<Kamion> Keybuk: do you need this in main straight away?
<Kamion> mind you, that'd need an inclusion report ...
<Keybuk> just to universe for now, then I'll get pitti to look at it
<Kamion> ok
<Kamion> accepted
* Keybuk idly wonders which of the three accepted versions will make it into the archive
<Kamion> the last
<Kamion> well, either that or all three, but the last will be the one that gets built :)
<infinity> (as of yesterday, the last will be the only one that gets built)
<infinity> Yay for that bug being fixed.
<Keybuk> I  Soyuz
<doko> infinity, mdz: you may use your https://launchpad.net/people/<user>/+packages page to get this kind of information
<infinity> doko: Individuals can, I sure as heck can't. :)
<infinity> doko: Not unless someone decides I own all the source packages in the archive.
<doko> infinity: just open some tabs in your browser ;-P
<mdz> sabdfl: morning
<mdz> sabdfl: are you near SteveA? he seems to have called my phone about an hour ago
<infinity> Oh, FFS... ttf-freefont was converted to cdbs, but our cdbs produces broken udebs.
<infinity> \o/
<_ion> Working packages are overrated.
* infinity hacks around it for now.
<siretart> hi _ion 
<_ion> Hi siretart
<siretart> _ion: now my test is over. what's the status about your nm packages?
<_ion> siretart: There's still stuff to be done. Mostly polishing.
<mvo> infinity: for the intltool stuff (and one liners like this) I would prefer a quick ping/mail. I maintain all my stuff in bzr so I have to integrate the changes into that anyway
<siretart> _ion: do you have a repository for source package you work on?
<_ion> siretart: Nope, but setting one up wouldn't be a bad idea.
<infinity> mvo: Duely noted for the future.  I'm just trying to kill every FTBFS in main right now. :)
<siretart> _ion: do you coordinate with the debian utopia ppl?
<siretart> _ion: they are the guys you have sent me the wpasupplicant patch for nm after all
<_ion> siretart: Not exactly coordinate, but i have looked at their packages.
<mvo> infinity: yeah, thanks for this :)
<siretart> ok
<siretart> _ion: I assume I need a patched l-r-m for madwifi, no? is there one available for current kernels?
<_ion> siretart: Their packages are going to somewhat different direction  they support VPN and use cdbs, whereas i switched back to the old build system from cdbs (which i was using originally) because i was told that changing the build system from 0.5.1 would decrease the chance of the package being accepted.
<siretart> _ion: ok, I see
<_ion> siretart: Hmm, i don't think there are patched l-r-m packages available for the current kernel image yet.
<siretart> _ion: oh. ok, then I need to patch them myself.
<_ion> siretart: But using n-m with madwifi-old is problematic as long as madwifi-old doesn't support background scanning.
<_ion> siretart: IIRC Pygi is going to look whether it's feasible to backport it form madwifi-ng.
<_ion> from
<siretart> _ion: thats no real regresseion. but afaik, you can disable scanning in nm while having a connection
<_ion> Ok.
<infinity> _ion: I intend to include that small madwifi patch (the WPA one) in my next LRM upload, so we can stop building custom test packages.
<_ion> infinity: Nice.
<infinity> _ion: Reading over the code it touches, it seems harmless to me.
<Keybuk> infinity: do we have madwifi-ng yet?
<infinity> _ion: As for backporting the scanning thing, that would be awesome, but would require some heavy review and testing.
<_ion> keybuk: Dapper will not get madwifi-ng AFAIK.
<Keybuk> _ion: that wasn't the plan
<infinity> Keybuk: Dirty hacks to include both?  mjg59 and I have tossed around a few scary ways to do it that involve sed and a screwdriver, but we've not gotten to it yet.
<siretart> that would be really awesome
<siretart> I mean there is already nvidia and nvidia-legacy. whats the conceptual difference in madwifi-old vs madwifi-ng?
<mvo> Kamion: thanks for processing ttf-sil-doulos, ttf-sil-charis. ttf-gentium has the same license, but is in multiverse right now, what needs to be done to get it into universe? is a new upload required for this?
<infinity> siretart: The biggest differece is that nvidia is only one kernel module, madwifi is a whole set of them (with dependencies).
<infinity> siretart: So, the hack gets a bit dirtier, in that one set (ideally the old ones, since we want to switch to -ng eventually) will need internal renaming, not just a filename change.
<_ion> Btw., why is l-r-m a single, monolithic source package?
<infinity> siretart: Anyone willing to step up and do said renaming is welcome to do so.  Then we need to get some PCI ID lists ASAP for machines that MUST use -ng (they'll skip on trying to load -old at all in the new world order, stuff like new Thinkpads), everyone else gets -old by default, and you can switch if you feel the urge.
<infinity> siretart: Ish.
<infinity> _ion: So it's not a royal pain in the ass to update on every kernel ABI bump.  It's intentional.
<siretart> infinity: i see. thanks for explanation
<Treenaks> hmm.. http://www.securityfocus.com/bid/17178/info
<Kamion> mvo: no need for a new upload - I'll move it once this publisher run has finished
* infinity calls it quits for the day.
<infinity> Happy hacking, kids.
<mvo> Kamion: thanks, I'll ask for it to enter main later, it one of the missing fonts that we want in fontconfig
<mvo> pitti: could you add ttf-lao as a dependency for language-support-lo please?
<Pygi> infinity: you there perhaps?
<pitti> mvo: shouldn't fonts go to *-desktop rather?
<mvo> pitti: if we still have room on the cd, sure
<pitti> mvo: well, we don't, but it's our current policy...
<pitti> mvo: and 50 kB isn't too bad
<mvo> pitti: ok, it's not a big package
<mvo> I'll add it
* mvo will also add ttf-gentium
<Mithrandir> mvo: language-selector-common needs a versioned replaces on language-selector for /usr/share/language-selector/data/countries
<mvo> Mithrandir: hm, I'm thought I added one, let me check
<Mithrandir> mvo: you added one for <<, not for =<
<mvo> Mithrandir: yeah, damm. thanks!
<carlos> pitti: hi, do you have a couple of minutes?
<pitti> actually not, but if it's urgent?
<pitti> carlos: the blender POT thingy?
<carlos> pitti: not really, openoffice
<carlos> but it can wait
<seb128> Mithrandir: https://launchpad.net/distros/ubuntu/+source/xkeyboard-config/+bug/35845
<Kamion> Kinnison: awake?
<Ubugtu> Malone bug 35845 in xkeyboard-config "compose:ralt option broken with 0.8 update" [Normal,Unconfirmed]  
<carlos> pitti: just ping me when you are less busy, please
<seb128> Mithrandir: any opinion on the suggest change?
<Kamion> Kinnison: your fix for binary accepts last night left out a (presumably) cowboy fix that cprov did for me on change-override.py
<Kamion> Kinnison: bug 35889
<Ubugtu> Malone bug 35889 in launchpad-upload-and-queue "change-override.py broken by 20060321 rollout" [Normal,In progress]  http://launchpad.net/bugs/35889
<pitti> carlos: will do; OO.o? that isn't for doko rather?
<carlos> pitti: not really, it's related with the es-ES.po -> es.po mapping
<Mithrandir> seb128: he's upstream, isn't he? :-)
<seb128> Mithrandir: he is ;)
<Mithrandir> seb128: could you apply it and see if it fixes it for you?  If so, I say we just run with that
<seb128> Mithrandir: k, will do that
<pitti> carlos: what about it? YM the po files that OO.o generates during build?
<Kinnison> infinity: how're the binaries?
<carlos> pitti: yes, I think we talked about mapping them at pkgstriptranslations but I don't remember the details or even if we reach an agreement on it...
<carlos> pitti: same with abiword
<pitti> carlos: oh, did we? I can't remember
<carlos> pitti: same here
<carlos> ;-)
<siretart> _ion: where can I see your latest nm 0.6 source package?
<Kinnison> Kamion: impressive considering I cp'd the current tree to change
<Kamion> Kinnison: boggle
<hunger> Is it a known issue that the buttons on a thinkpad T43p do no longer work?
<Kinnison> Kamion: ask cprov?
<hunger> Oh, false alarm, the buttons work, it is just the kde popup windows that went missing.
* Kinnison goes to do the usual "I just got up" things, my dedication to my job supersedes my need to pee
<Kamion> ogra: help re gnome-screensaver?
<Kamion> ogra: 'sudo gnome-screensaver-command --poke' can't talk to the session bus
<Kamion> ogra: which makes it hard to use from within espresso, which is invoked via sudo
<Kinnison> either whatever invokes espresso needs to preserve DBUS_SESSION_BUS (envvar) or you're going to have to find some way around it
<Kamion> YM DBUS_SESSION_BUS_ADDRESS?
<Kamion> and sudo does preserve that
<Kamion> I don't have DBUS_SESSION_BUS set
<Kinnison> sorry, yes _ADDRESS
<Kinnison> I forgot it changed
* Kinnison is on breezy on his desktop
<Kinnison> not got to laptop yet
* Kinnison needs coffee/tea before his brain implodes
<stewski> is it worth creating a bug/wishlist that the gnome trash would store a restore path (cope with duplicates)
<dholbach> hello
<Treenaks> morning
<pitti> hi dholbach 
<Pygi> when will finally croatian keyboard layout start workin' properly in xorg by default? ;)
<infinity> Kinnison: My binaries are fine, thanks. :)
<infinity> Pygi: You rang?  I'm only around for a few minutes.
<Pygi> infinity: o, hello ;)
<Pygi> infinity: yup, I did...can you please  build patched l-r-m on new kernel build?
<Kinnison> infinity: cool, thanks
<infinity> Pygi: As I told _ion, I'll be including that patch in my next LRM upload to the archive, so we can stop with the forked build.
<infinity> Pygi: It seems safe and correct enough to me to do so.
<pitti> does anyone know 'join'? I'm currently desperating on it
<Pygi> infinity: hm, ok, thanks ^_^ any ideas when will that be?
<Pygi> some people are rampaging :-/
<infinity> Pygi: We'll also get wider testing that way and know if we have to back it out. :)
<infinity> Pygi: Tomorrow, probably.
<Pygi> kk, thanks infinity ;)
<infinity> Pygi: (My tomorrow, which is in ~12 hours)
<Pygi> same here
<Pygi> 13 hours here tho
<pitti> Kamion: you have used join, right? do you have a minute to help me?
<infinity> Well, "tomorrow" is in 3 hours for me, technically, but I'm planning on sleeping at some point.
<Pygi> infinity: yes, I know ^_^ you are in australia...
<Seveas> infinity: sleep, schmeep :)
<Pygi> Seveas: that patch I showed you yesterday makes the package unbuildable
<Pygi> ;)
<Seveas> Pygi, then don't hang around here - fix it for crying out loud!
<Pygi> Seveas: heh ^_^
<Kamion> pitti: sure
<Kamion> Kinnison: any idea what else it might be, given that DBUS_SESSION_BUS_ADDRESS is preserved?
<Kamion> Kinnison: strace shows that it's sending AUTH EXTERNAL claiming uid of 0 (fair enough)
<Kamion> which is about where it fails
<Kinnison> aah
<Kinnison> hmm
<Kinnison> maybe it needs to sudo -u personname gnome-screensaver-command --poke
<Kamion> sudo -u $SUDO_USER? ugh, but would work I guess
<Kamion> yeah, "sudo sh -c 'sudo -u $SUDO_USER gnome-screensaver-command --poke'" DTRT
<Kamion> how horrible
<Kamion> thanks
* Kinnison hugs
<Kinnison> you'll wash the dirty feeling off eventually
<ogra> Kamion, hey, it prevents you from depending on dbus at least :)
<Mithrandir> seb128: doesn't evince antialias graphics?
<seb128> Mithrandir: if poppler is built with cairo probably, but we build it with splash
<Mithrandir> seb128: ok
<lifeless> anyone else having gnome-screensaver routinely blank-cause-it-wants-to ?
<dholbach> whiprush, jdub: could somebody of you please remove the bugsquad meeting from the calendar - we need to postpone it, I'll send an announcement later
<jdub> dholbach: ok
<dholbach> jdub: thank you very much
<Kamion> Mithrandir: ok, uploaded your espresso changes now, thanks as ever
<Mithrandir> Kamion: thanks
<Riddell> ogra: you don't like the flame xscreensaver?
<mvo> I would like to add ttf-thai-tlwg, ttf-lao, ttf-gentium to ubuntu-desktop. any objections? otherwise I'll commit it in a bit
<ogra> Riddell, why ?
<Mithrandir> seb128: do you have any idea what the submitter in https://launchpad.net/distros/ubuntu/+source/xkeyboard-config/+bug/33565 is talking about?
<Ubugtu> Malone bug 33565 in xkeyboard-config "xkeyboard use pc105 instead of macintosh" [Major,Unconfirmed]  
<Riddell> ogra: kscreensaver happens to use that one for its test to see if xscreensaver exists
<Riddell> I'll change it to something else
<ogra> Riddell, its in xscreensaver-data (it should be at least)
<Kamion> mvo: how big are they combined?
<seb128> Mithrandir: https://bugs.freedesktop.org/show_bug.cgi?id=2870
<infinity> Kamion: Oh, we now have end-to-end %source support for seeds, right?  It's safe to use it?
<Kamion> infinity: yes
<mvo> Kamion: ~1,5mb
<Riddell> ogra: it's in xscreensaver-data-extra
* infinity does some cleanup.
<Kamion> mvo: oof, more than I'd hoped
<seb128> Mithrandir: I think that should be fixed with xkeyboard-config 0.8
<mvo> well, we could ship them as part of the language-support packs
<seb128> 2005-10-11 svu
<seb128>         * symbols/macintosh_vndr/fr: update French Macintosh keyboard, closed
<seb128>         https://bugs.freedesktop.org/show_bug.cgi?id=2870
<ogra> Riddell, oh, then it wasnt in the default selection in wart~breezy ...
<mvo> at least for some
<seb128> Mithrandir: the changelog has that mention
<Mithrandir> seb128: excellent, I'll close the bug, then
<Kamion> pitti's right, we have traditionally put fonts in desktop
<infinity> Anyone have any objections to "eximon4" (the exim monitor) heading to supported as a result of changing the exim4 seeds to a source seed?
<Mithrandir> infinity: I've never seen it as useful, but I don't have an active objection.
<Kamion> infinity: not me
<infinity> Mithrandir: I don't use it either, but it reduces 5 lines of messy seeds to a 1 line source seed that seems more sane.
<ogra> Keybuk, bzrk doesnt work with the recent bzr and bzrtools ...
<mvo> Kamion: so 1,5mb is a problem ?
<Keybuk> ogra: ddaa maintains bzrk now
<ogra> ah,k
<Mithrandir> is bzrk pronounced "berzerk"?
<Mithrandir> possibly berserker.
<ogra> heh
<Seveas> bzrkr
<Seveas> bzr-kr - bzr written in K&R C
<Kamion> mvo: we do have room though, so go ahead; we can revisit later if need be
<Keybuk> Mithrandir: yes
<mvo> thanks
<Mithrandir> Keybuk: so bzr should be pronounced like bursar.
<Keybuk> "buzzer"
<Mithrandir> bzzt
<Keybuk> it could be "bursar" if dried frog pills were involved
<Mithrandir> does bzr exist in that universe?
<mvo> lol
<ajmitch> so that's why launchpad has the librarian
<infinity> Kamion: And if I do a " * %source" in support and a " * binary" in ship, germinate will do the expected thing, I assume?
<Mithrandir> also, I claim my luggage of sapient pearwood.
<fabbione> Kamion: could you be so kind to NEW xserver-xorg-driver-v4l ?
<infinity> pitti: Another oddity.  All of postgresql-8.1 lands in main except for -server-dev ... Intentional, or should be fixed?
<Kamion> Mithrandir: so should bug 34332 be fixed now?
<Ubugtu> Malone bug 34332 in espresso "crashes right after timezone selection" [Normal,Confirmed]  http://launchpad.net/bugs/34332
<Kamion> infinity: yes
<pitti> infinity: we don't really need it in main, but it's completely harmless
<Mithrandir> Kamion: yes
<Kamion> Mithrandir: will you say that in the bug or should I?
<pitti> infinity: I'm just hesitant to explicitly seed it, since we don't want to add library-like stuff to the seeds any more, right?
<infinity> pitti: Do we get anything out of not having it in supported (since we support the source)?
<infinity> pitti: I was going to convert the 6 pgsql seeds to 1 source seed, actually. :)
<pitti> infinity: no, just seed cruft
<infinity> pitti: Hence the question.
<pitti> infinity: oh, wow, then go ahead :)
<Mithrandir> Kamion: I can close the bug, just a sec
<Kamion> infinity: any idea why https://launchpad.net/+builds/+build/178965 says "Dependencies: libxosd-dev"?
<infinity> Kamion: Because somehting has a bit of a (harmless, it seems) bug that cprov and I need to find.
<infinity> Kamion: Ignore it for anything but Dep-Wait packages (where it's actually sane and correct)
<Mithrandir> ooh, shiny.  LP no longer lists fixed bugs by default.
<fabbione> Mithrandir: i had to make kiko an offer he couldn't refuse...
<Mithrandir> fabbione: fix bug or concrete shoes? ;-)
<Kamion> fabbione: for main?
<Kinnison> infinity: thanks for clashing with my half-prepared g-p-m upload, but never mind
* Kinnison sighs and rolls your changelog into his
<fabbione> Mithrandir: concrete shoes :)
<fabbione> Kamion: hmm yes... that have to be main.. otherwise we will have regressions from breezy
<infinity> Kinnison: I didn't know you were in the process of one.
<Kinnison> infinity: aye, hence I asked fabbione to file the bug rather than upload a fix
<Kinnison> :-)
<Kinnison> infinity: s'okay, won't cause any hassle
<Kamion> fabbione: accepted; please either seed it or make something depend on it (IIRC, we generally make xserver-xorg-driver-all depend on stuff)
<fabbione> Kamion: yes.. in the next upload...
<Diziet> fabbione: Well done for fixing that scroll back/forward bug at last.  Thank you very much.
<infinity> Kamion / pitt: Okay, the only other one I want to touch for binary->source seed changes is db4.X, which currently doesn't seed a couple of bindings packages (neother of which pull in extra deps into main)
<Kamion> that one's pitti's call AFAIAC, I don't mind the extra bindings
<infinity> pitti: ^^^
<pitti> yep, saw it; as I said, I'm fine with seeding -server-dev
<pitti> s/seeding/putting it into main/
<pitti> I just want to avoid explicitly seeding it
<infinity> pitti: We've moved past that to BDB. :)
<pitti> infinity: *sniff* :)
<infinity> pitti: Any objections to db4.x bindings (tcl and java) moving to supported?
<infinity> That's my last proposed seed change for the day. :)
<pitti> infinity: I generally appreciate moving binaries to main whose source is in main already
<pitti> infinity: since we need to provide security udpates for them anyway
<infinity> I've just been looking forward to saying "our default db version is FOO", seeding the source, and not having to worry about -utils, -doc, etc. :)
<infinity> pitti: Kay, cool.  I'm with you on that wavelength (as long as they don't pull in extra deps from universe, of course)
<pitti> right, that should considerably clean up the seeds
<fabbione> Diziet: assuming that's the right fix..
<Diziet> So can someone explain to me what Pango is and why we want to use it ? :-)
<tseng> Diziet: its a font renderer that can handle all sorts of strange i18n needs
<mvo> Diziet: it's a text rendering engine and it is used by gtk
<tseng> like right to left
<Diziet> So the reason we need to use it is for i18n ?
<Kamion> Kinnison: bug 35078 sheds more light on the disappearing gparted dialog; will you have time to look at it soon, or should I have a go?
<Ubugtu> Malone bug 35078 in gparted ""Apply operations to harddisk" dialog is in background" [Normal,Unconfirmed]  http://launchpad.net/bugs/35078
<mvo> Diziet: apparently. and because gtk is using it. why? do you want to get rid of it?
<Diziet> (pango.org seems vaguely informative ...)
<Kamion> also consistent rendering across all desktop applications, AIUI
<Kinnison> Kamion: I have a patch I should have uploaded yesterday
<Diziet> It seems that our firefox is slow according to many people, and setting MOZ_DISABLE_PANGO makes it faster.
<Kinnison> Kamion: I'll get that done ASAP
<pitti> infinity: does germinate figure that out automatically? (implicitly seed binaries from  main sources whose deps are all in main)?
<Diziet> It could be that that disables use of Cairo.
<Kamion> Kinnison: thanks
<Kamion> pitti: no
<pitti> so we just check with anastacia
<Diziet> I haven't looked at the code yet to see what exactly setting that variable does.
<Kamion> pitti: the extra seed lists extra binaries from main sources that aren't otherwise seeded, and if you use a %source seed (e.g. %postgresql) then all binaries from that source get seeded and any extra dependencies get pulled in
<mvo> Diziet: I wouldn't be supprised if it would also break loads of international websites
<Diziet> If there's some reason why we _have_ to use Pango and Cairo then I should just reject the report.
<pitti> Kamion: alright; thanks for the heads-up
<jdub> fabbione: yay xorg v4l :)
<Mithrandir> Diziet: does it render CJVKK pages correctly without it?
<Mithrandir> CJVK, even
<Kamion> and Thai
<Mithrandir> that too
<Diziet> mith: I don't know.  I probably couldn't tell if it didn't.  If we have someone that could try it then that would be a quick way of dealing with the issue.
<Kamion> oh, worth checking Hebrew and Arabic too for right-to-left-ness
<Diziet> It's a shame it's slow.
<Kinnison> can you have pango enabled and cairo disabled?
<infinity> Alright, I'll check in all these changes tomorrow when I have all the seeds checked out and can merge between all the branches.
<infinity> Thanks for the input guys.
<Diziet> kinnison: I don't know.
<Kinnison> Diziet: cairo is dog slow
<Diziet> So I should try to have pango but not cairo ?
<jsgotangco> sladen: ping?
<Kinnison> It'll still link cairo because of gdk2.8 but if moz can get by without calling it, it should be faster
<Diziet> There are some configuration options in this area, and I think yes, it can probably do it.
<Diziet> I don't know how well-tested a code path it is.
<infinity> I did notice that Tbird got a tiny bit slower with pango/cairo enabled, but it also seemed to get a bit prettier, so I'm of two minds.
<Kinnison> cairo rendering is better than gdk
<Kinnison> but it's slower because everything is a trapezoid
* infinity nods.
<ogra> isnt cairo used for svg rendering ? we'll loose that without cairo i think
<infinity> I'm inclined to just take the performance hit and wait for cairo to improve.
<Mithrandir> there's nothing inherent in cairo which makes it slow, it's just that it's not optimised, AIUI.
<Diziet> I suppose I could profile it.  But the thought of profiling Mozilla doesn't fill me with optimism and good cheer.
<Kinnison> do we compile cairo with all of gcc4's funky vectorising turned on?
<infinity> You mean the fnuky stuff that would render it unable to run on certain CPUs, or other funky stuff? :)
<Kinnison> I imagine there're some optimisations which would break some cpus
<Kinnison> we could have libcairo-686 for that
<lifeless> Kinnison: prod
<Kinnison> lifeless: looks fucked
<Diziet> I think extra optimisations for faster more modern CPUs is rather missing the point.
<lifeless> Kinnison: stdout and sterr races AFAICT
<infinity> Kinnison: No need for two packages, we can just double up and dump one in /usr/lib/i686/cmov, but someone should see if it's worth the effort.
<Kinnison> rjek is currently trying on amd64
<infinity> Diziet: Well, I won't debate one way or the other for cairo, but it certainly makes sense for libssl (one of the few multi-target optimised libraries on the system)
<sladen> jsgotangco: yo
<sladen> jsgotangco: ask the question, rather than pinging :)
<lifeless> Kinnison: still the question is - is it sufficient
<jsgotangco> sladen: do you happen to know what might cause a toshiba not to reboot at all since Flight 3?
<Kinnison> lifeless: fix the race
<jsgotangco> sladen: modules not unloaded perhaps?
<Kinnison> lifeless: making stdout and stderr present separately on the page, or else go down the same pipe would probably do
<lifeless> Kinnison: later.
<lifeless> Kinnison: I will tweak it a little now the hard part is done
<Kinnison> lifeless: once it's more readable, you qualify for cashing in the token
<lifeless> heh
<sladen> cairo:  for when --OMG-faster makes crap libraries better
<lifeless> also it would be a lot less sucky if make check_merge cooperated
<Kinnison> infinity: it seems, asking dapper's gcc on amd64 to tree-vectorize cairo causes an ICE
<jsgotangco> sladen: i've did reinstalls and upgrades and it still doesn't work
<sladen> jsgotangco: the reboot methods have changed.
<sladen> jsgotangco: /me *gone*
* jsgotangco updates bug report
<Mithrandir> seb128: are you working on xkb stuff today?
<seb128> Mithrandir: I just built xkeyboard-config with that ralt patch and I was going to reboot to try it
<seb128> Mithrandir: out of that, nothing plan on it no, I still have a lot of desktop bugs catchup to do
<Mithrandir> seb128: 'k, please do.  I am writing a definition for my desktop keyboard, so we should merge at some point
<seb128> brb, rebooting
<lifeless> bug 35241 is _really_ hurting
<Ubugtu> Malone bug 35241 in gnome-screensaver "screen blanks randomly whilst I am typing" [Major,Unconfirmed]  http://launchpad.net/bugs/35241
<doko> Seveas: for #31231 you have still not the /sbin and /usr/sbin in your path?
<Mithrandir> Ubugtu: kill and restart gss and you should be fine.
<Mithrandir> s/Ubugtu/lifeless/
<seb128> Mithrandir: the patch doesn't fix the issue, I'll comment for svu on the bug
<Seveas> doko, can't tell now - I'm at work behind a fedora machine, will poke you later today
<Mithrandir> seb128: thanks
* Mithrandir really wants all packages in bzr soon..
<seb128> hum
<seb128> I forgot a part of the patch in fact, brb
<doko> Seveas: thanks
* StevenK kicks himself.
<ajmitch> hi doko 
<ajmitch> StevenK: why? :)
<StevenK> I just managed to accidently upload Linda 0.3.19 to upload.u.c, not ftp-master.d.o
<ajmitch> ah well
<ajmitch> if it's a binary upload it should get rejected, and it was uploaded to unstable :)
<lifeless> Mithrandir: it happens across login after login
<lifeless> Mithrandir: are you saying I need to kill gss after every login ?
<Mithrandir> lifeless: uh, weird.  I thought it was the same bug as I'm seeing, but then it's not.
<lifeless> I've just killed and spawned it
<lifeless> if it stops it for this session I will note that in the bug.
<seb128> Mithrandir: grumpf, no, doesn't work
<Mithrandir> seb128: should KPDL give you KP_Decimal or KP_Separator?
<Mithrandir> (in a french locale)
<Mithrandir> seb128: I'm wondering if bug 30211 is an X bug or a gnumeric bug, or maybe both.
<Ubugtu> Malone bug 30211 in xkeyboard-config "in french locale, KPDL returns period instead of KP_SEPARATOR" [Normal,Unconfirmed]  http://launchpad.net/bugs/30211
<seb128> KP_Decimal I would say
<Mithrandir> Ubugtu is too bloody quick.  I swear it answered at the same time I pressed enter.
<Mithrandir> seb128: I get KP_Separator with a norwegian layout, fwiw.
<seb128> hum
<Mithrandir> seb128: (and so does br, cs, de, dk, fi, gr, hu, mk, no, pl, ro, ru and se)  (at least)
<seb128> the issue is that french use a ","
<seb128> but the keyboards have a "." printed on the numeric pad key
<seb128> cf /etc/X11/xkb/symbols/fr
<Mithrandir> so either way, we make some people unhappy?
<seb128> "    // French uses a comma as decimal separator, but keyboards are labeled with a period
<seb128>     // Will take effect when KP_Decimal is mapped to the locale decimal separator
<seb128>     key <KPDL>  { [       KP_Delete,          period,           KP_Delete,           KP_Decimal ]  };"
<Mithrandir> yeah, I saw.
<seb128> Mithrandir: you have a "," with your locale? Do you have it with every GTK app or only gnumeric?
<Mithrandir> seb128: I don't have the bug, it's apparently only a bug in the french setup (we have , as decimal separator and get it when pressing KPDL)
<seb128> you get it for every single GTK widget?
<seb128> or that's a gnumeric feature?
<Mithrandir> I don't think gnumeric is relevant here
<Mithrandir> I get , everywhere, as I should
<seb128> I get a "," when pressing KPDL in a spreasheet
<seb128> and I get "." elsewhere
<Mithrandir> and that's how it should be, or?
<seb128> that's what the submitter is asking I think
<seb128> the use of that key is controversial
<seb128> let me comment on the bug
<Mithrandir> thanks
<seb128> np
<infinity> mdz: How do you feel about a UVF exception for samba (3.0.21b to 3.0.21c), appears to be entirely bugfixes, passed from sid->etch without a word on debbugs.
<infinity> mdz: Appears to fix some issues with NT4 clients.
<lifeless> Kinnison: fixed, soon as the queue clears it'll come good
<Kinnison> lifeless: prod me again when I can look
* Kinnison screams blue murder at c++
<lifeless> whats wrong ?
<Kinnison> Well, I get:
<Kinnison> Win_GParted.cc:1383: error: no match for ternary operator?: in (((GParted::Win_GParted*)this)->GParted::Win_GParted::installer_mode != 0) ? *((GParted::Win_GParted*)this)->GParted::Win_GParted::plug : *(GParted::Win_GParted*)this
<Kinnison> I should never have decided to make this neater
<Kinnison> I could have uploaded already
<Robot101> hnahrgahr
<Kinnison> #define TRANSIENT_TARGET ((installer_mode)?(*(this ->plug)):(*this))
<lifeless> WTF are you using fully qualified paths there
<Kinnison> I am not
<Kinnison> the compiler reports the error as such
<lifeless> oh, I see complier barf
* Kinnison changes the stars around a bit
<Kinnison> #define TRANSIENT_TARGET (*((installer_mode)?(this ->plug):(this)))
<Kinnison> let's see if that helps
<Kamion> Kinnison: heh, I tried to do exactly the same thing a while ago and ran into the same issue
<Kinnison> Kamion: grah!
<Kinnison> Kamion: I cleaned up so many if statements
<Kinnison> and now it b0rken
<Kamion> Kinnison: I gave up and added a transient_target member to Win_GParted I think
* Kinnison sobs
<Kamion> Kinnison: which works fine
<Kamion> (you realise it's not actually transience that's breaking here, but whether the window is brought to the front - but don't let me stop you cleaning up the transience too)
<Kinnison> it's metacity being odd about the bring-to-front yes
<Kinnison> but I wanted to tidy the transience too
* Kamion nods
<Kinnison> I'm hoping that the raise issue is fixed by judicious application of an ->raise() just before showing the confirmation dialog
<Kinnison> :-)
<Kinnison> since it never pops under in my tests
<Kinnison> bwuahaha I have tamed the compiler beast
* Kinnison feels dirty
<Kinnison> #define TRANSIENT_TARGET (*((installer_mode)?((Gtk::Window*)(this ->plug)):((Gtk::Window*)this)))
<Keybuk> Kinnison: does gpm, to your knowledge, deliberately save the session before the power goes out?
<Kinnison> Keybuk: it sends a signal to the session manager to shutdown
<Kinnison> Keybuk: the session manager saves the session
<Keybuk> does it say to save in that?
<Kinnison> I believe so
<dholbach> Kinnison: you could try on #c++ or #gparted in irc.gimp.net, maybe they can make you happy in a different way :)
<Keybuk> could it not, then?
<Keybuk> because something saved my session when the battery ran flat
<Keybuk> so now every time I login, I get those apps
<Kinnison> Keybuk: is this related to 35961?
<mjg59> Keybuk: What's your critical battery action set to?
<Keybuk> ubuntu 35961
<Keybuk>  Bug #35961 in gksu (Ubuntu): "-u option is being ignored"
<Ubugtu> Malone bug 35961 in gksu "-u option is being ignored" [Normal,Unconfirmed]  http://launchpad.net/bugs/35961
<Keybuk> ?
<Keybuk> I don't think it's related to that, no
<Keybuk> mjg59: Shutdown
<mjg59> Keybuk: Right. Then that's unsurprising.
<Keybuk> mjg59: no, it is surprising; because I have "Save Session at Logout" turned *off*
<Keybuk> and there's no way to clear what it saved now
<mjg59> Keybuk: Hm. Sounds like a session manager bug.
<Keybuk> (other than removing files in ~/.*)
<Kinnison> Keybuk: must have made a note wrong
<Kinnison> one sec
<Kinnison> Keybuk: bug 35691 even
<Ubugtu> Malone bug 35691 in gnome-power-manager "Session is saved at critical battery shutdown" [Normal,Unconfirmed]  http://launchpad.net/bugs/35691
<mjg59> If the session manager is doing two different things depending on how the shutdown is requested, something sounds broken
<sabdfl> Keybuk, mjg59: could that explain why gnome terminal is launching itself when i log in?
<Keybuk> sounds like exactly my bug
<Keybuk> sabdfl: yes
<mjg59> sabdfl: Probably, yes
<Kinnison> I think g-p-m explicitly requests a session save
<sabdfl> ah. Confirmed then :-)
<Keybuk> I get 30 of the buggers, plus three copies of firefox (two of which just display dialogs) and four evinces
<Keybuk> it's quite annoying
<sabdfl> mjg59: another thing, do you have a documented policy on gpm shutdown/hibernate policy defaults?
<mjg59> Given that we don't actually make any pretence to support session management, we should probably just rip all of it out
<mjg59> sabdfl: We default to enabling hibernate, I believe
<Keybuk> aye, if session management *worked*, I wouldn't mind
<sabdfl> my laptop used to sleep when it was on battery and i closed the lid, but no longer
<Lathiat> session management really tends to be more hassly than time saving :)
<sabdfl> mjg59: +1 on stripping out session management
<Keybuk> but all the windows are blank, and nothing like what it saved
<sabdfl> leave it in main for the brave
<Kinnison> sabdfl: can you dump that on that bug?
* Kinnison is updating the package to 2.14.0 + CVS_stuff currently
<mjg59> sabdfl: Preferences/power management/Running on battery/Sleep on lid cloes?
<sabdfl> Kinnison: the gpm hibernation, or the terminal issue?
<Kinnison> sabdfl: bug 35691
<Ubugtu> Malone bug 35691 in gnome-power-manager "Session is saved at critical battery shutdown" [Normal,Confirmed]  http://launchpad.net/bugs/35691
<sabdfl> mjg59: i looked there, and it was set to blank screen until the battery was critical, then hibernate
<sabdfl> i didn't change the pref
<sabdfl> so i suspect our default prefs have moved
<mjg59> sabdfl: It should be ok for breezy->current dapper upgrades, but may have been broken if you upgraded in the intervening period
<mjg59> But "Sleep on lid close" was never a supported option, really
<sabdfl> mjg59: ok, thanks, at least i know this is expected behaviour
<mjg59> sabdfl: Tangentially, Intel Mac support is now only lacking installer support
<sabdfl> mjg59: those installer slackers
<mjg59> Yeah, it's disgraceful
<mjg59> Anyway, Colin's going to take a look when he's got time
<Seveas> mjg59, you know that that sort-of equals never ;)
<mjg59> But it should be practical for dapper, even if we don't decide to ship it as the default iso
<sabdfl> be wonderful to have it as a download option, even
<Kinnison> Kamion: yay, this call to raise() causes a segv
* Kinnison does so love GTK
<Treenaks> mjg59: Could you tell me again what the 'interesting' values in my Radeon registers were? (bug 20283)
<Ubugtu> Malone bug 20283 in xserver-xorg-driver-ati "[fgl v5000]  really bad sync" [Normal,Unconfirmed]  http://launchpad.net/bugs/20283
<Kinnison> Kamion: but in other news, it's started popping under
<Kinnison> Kamion: so I actually have something to debug
<mjg59> Treenaks: Anything starting CRTC, possibly also the ones starting FP
<mjg59> (Would be my suspicion)
<Treenaks> mjg59: ok, thanks
<Kamion> mjg59: actually, I think I now have all the udeb support we need; I'm just looking at how to make the CD images work (see my question about blessing files)
<Kinnison> Kamion: In fact, reading the code and the gtk docs, the transient stuff being correct should cause metacity to put the window on top of the gparted window
<Kamion> Seveas: nah, this is actually high enough up my interest list to get done
<Kinnison> Kamion: so I'm inclined to say this iz metacity boog
<Kamion> it never used to pop under
<mjg59> Kamion: Ah, cool
<Kamion> it was only after your gparted change that that started, AFAI
<Kamion> K
* Kinnison notes that apart from changing the transience from the window to the plug, the installer-mode patch makes no changes to that particular bit of the code
<Mithrandir> sladen: any idea how to fix 35080?  (Thanks for the analysis, though)
<Kamion> sabdfl: http://sourceforge.net/mailarchive/forum.php?thread_id=9984881&forum_id=47882 suggests and approach that might even be safe to use by default, although it has the disadvantage of using up a wodge more space on the CD (because we'd have to duplicate the kernel)
<Kamion> the hybrid option is probably more space-efficient but isn't as safe
<sabdfl> Kamion: i don't think we have the luxury of the space, unfortunately
<mjg59> Kamion: We might as well give the hybrid option a shot
<sabdfl> mactel is very much a nice-to-have for this round
<sabdfl> mjg59: +1
<sabdfl> in a pre-beta flight
<Mithrandir> Riddell: it'd be nice if you could shave a bit off the size of the ppc live image.
<sabdfl> get mdz's byu-in though
<Kamion> sabdfl: yeah, my feeling too
<Mithrandir> mjg59: if you can have it ready this week, I can chuck it in next week's flight.
<mjg59> Their refusal to boot off ISO9660 is very tiresome
<Kamion> though you never know, i386 has more free space on powerpc so it might actually be doable
<Kamion> more free space than powerpc
<mjg59> sabdfl: Oh, Linus emailed me asking for help on getting Linux on his new Mac
* Kamion laughs
<sabdfl> DOIT!
<sabdfl> :-)
<mjg59> I said it would be painful until the installer was sorted, but I'd let him know then
<sabdfl> tell him to file a support request like everyone else... nah.
<sabdfl> you guys are going to love the launchpad by dapper+1
<sabdfl> promise
<sabdfl> sprint is going very well
<tseng> sabdfl: rock!
<sabdfl> and the next ui phase will, i hope, address many of the issues we've had
<tseng> i was a big fan of some of bradb's recent mockups
<Riddell> Mithrandir: yes, I'll do that, hopefully today
<Mithrandir> Riddell: thanks.
<Mithrandir> Riddell: I'm aiming for a flight in a week, is that fine with you?
<Mithrandir> ogra: ^^ and with you?
<ogra> sure
<Riddell> Mithrandir: yeah, that's good
<ogra> gah, ENOSEB
<Mithrandir> great
<dholbach> ogra, Mithrandir: new gnome is due on april 10th, so next week should be fine
<dholbach> 10th-12th
* ogra just needs that gdm fix in before ...
<Mithrandir> dholbach: that's almost three weeks away so shouldn't be any kind of problem
<dholbach> yeah
<dholbach> Mithrandir: I was just referring to ogra's "gah, ENOSEB"
<Mithrandir> dholbach: ah, ok.
<ogra> dholbach, yes, that was about gdm 
<ogra> :)
<Mithrandir> uh, what should I do about missing translation bugs?  Yes, sure, the translation is missing, because there is no translation.
<Kinnison> Kamion: afaict metacity is ignoring the transience for the dialog and popping it under to stop it stealing focus
<Kinnison> Kamion: because the plug it's a top level window
<Kinnison> Kamion: I'm trying to verify this
<Kinnison> Kamion: if I'm correct, then it very much iz metacity boog
<maswan> So, for stupid dapper tricks, I have stored a bit over 5000 copiers of flight-4 dapper-install-amd64.iso on tape.
<zul> heylo
<MrFaber> hi all
<MrFaber> Where can I make bug repots for dapper kernel?
<MrFaber> I haven't found the 686 package in launchpad
<dholbach> MrFaber: try linux-sourfce-2.6.15
<dholbach> MrFaber: ummm linux-source-2.6.15
<MrFaber> But it happens only with 686
<MrFaber> not with 386
<dholbach> you can mention that in the bug report
<MrFaber> ok, I am going to try to manage it in launchpad if I am lucky :-D
<dholbach> ok, cool :)
<MrFaber> No packages matching 'linux-source-2.6.15' are published in Ubuntu.
<MrFaber> I hate launchpad
<MrFaber> there are only 12 kernels
<MrFaber> there are only 2.6.12 kernels
<dholbach> naaaaah, you don't hate it, how does this one look: http://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+filebug
<MrFaber> How do you find it
<maswan> Btw, is that place the correct place to submit unsupported hardware to, or is that a support request or whatever?
<mjg59> maswan: launchpad is probably the right place
<mjg59> Wishlist if you wouldn't expect it to work, normal if it ought to be supported but isn't
* maswan nods
<maswan> on linux-source-2.6.15?
<mjg59> Yeah
<dholbach> launchpad.net -> the ubuntu distribution -> enter 'linux-source' in source package text box, click on 2.6.15 in the list -> report a bug
<dholbach> MrFaber: but to be honest, i know how the links are made up, so I 'assembled' the url on my own :)
<MrFaber> ok :)
<MrFaber> I used the search function
<MrFaber> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/36014
<Ubugtu> Malone bug 36014 in linux-source-2.6.15 "kernel 686 can't scale cpu frequency" [Normal,Unconfirmed]  
<MrFaber> please fix it :)
<MrFaber> and I have another bug but I am not sure
<MrFaber> And there is another bug in latest kernel. I can change some values like scaling_governor or sony_brightness with root but not with sudo. Same syntax but if I do this with sudo I got a permission denieded.
<MrFaber> Wrong sudo permissions?
<dholbach> check if it'S filed already, if not file it
<dholbach> launchpad is the best place
<MrFaber> launchpad is ingored :)
<dholbach> it's not
<MrFaber> my loop-aes but is still unconfirmed
<MrFaber> after two monthes
<jono> hey
<MrFaber> and I have posted it here several times
<MrFaber> after one month
<MrFaber> hi joelbryan 
<MrFaber> sorry
<MrFaber> hi jono 
<jono> hey MrFaber
<Mithrandir> MrFaber: how are you trying to change the governor using sudo?
<dholbach> there are 35000 bugs and there are 15 to 50 developers, depending how you count
<Mithrandir> 'morning jono
<jono> hey Mithrandir :)
<jono> anyone have some odd problems with the keyboard settings tool where it changes the theme?
<Treenaks> jono: that's when it crashes gnome-settings-daemon (which gets restarted immediately)
<Treenaks> (afaik)(
<jono> Treenaks, ahhh
<Mithrandir> gnome-settings-daemon shouldn't crash, though.
<Mithrandir> jono: when you select what keymap?
<MrFaber> https://launchpad.net/distros/ubuntu/+source/sudo/+bug/36018
<Ubugtu> Malone bug 36018 in sudo "can't access proc or sys with sudo" [Normal,Unconfirmed]  
<Mithrandir> MrFaber: do you know how sudo and you shell works?
<Mithrandir> MrFaber: you need to do echo ondemand | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
<MrFaber> dholbach, I understand it but two monthes and I have posted an easy fix
<MrFaber> for now I am useing loop-aes from debian sid
<MrFaber> that works under dapper
<jono> Mithrandir, yep
<MrFaber> Mithrandir, in past I always used echo 6 > ...
<MrFaber> with sudo and it works
<jono> it only happened for my on a small Sony Vaio - I will dig into it tonight and try to reproduce it
<Mithrandir> MrFaber: then you need to be root _first_
<MrFaber> I thought sudo executes it as root?
<Mithrandir> jono: please do; I'm attacking the xkb problems at the moment and it would be nice to get them all nailed.
<jono> Mithrandir, no worries :)
<MrFaber> Mithrandir, then remove the bug if I am wrong
<Mithrandir> MrFaber: the redirection is done by your shell.
<Kamion> MrFaber: > redirections are processed by the shell *before* sudo takes effect
<Kamion> (it's always been that way)
<MrFaber> but I am pretty sure that this works under Breezy
<Kamion> I'm pretty sure it doesn't
<Treenaks> (and can't really be changed easily)
<MrFaber> ok, sorry
<Mithrandir> MrFaber: no problem; I rejected the bug.
<MrFaber> but changing brightness doesn't work with the new kernel
<MrFaber> from today update
<MrFaber> and with the kernel before it works with my keys
<MrFaber> there is an sony_brightness acpi script
<MrFaber> So I have no influence
<MrFaber> But I haven't checked it in detail
<MrFaber> So maybe it is only a temporary bug
<MrFaber> thx btw
<MrFaber> bbl
<Kinnison> Kamion: It's definitely a metacity misbehaviour (in my opinion) -- currently filing upstream bugs to garner opinions of metacity's authors
* Kinnison has written a metacity patch to fix it
<jono> is there a boot time feature for fixing a grub partition ?
<jono> sorry, a broken grub
<mdke> i don't think so
<mdke> i've heard it suggested as a good feature
<zul> broken as in how?
<Kamion> jono: not boot time, but use an install CD, boot into rescue mode, follow the menus, select your root partition, select "Reinstall GRUB boot loader"
<trappist> has something been changed in karma on malone?  mine went from ~250 to ~50,000 in a couple of days, and I haven't been that great
<Kamion> mjg59: I think adding an -hfs-bless-file option to mkisofs is going to be the cleanest answer here; doing that now
<Kamion> Zomb: (I'll send you the patch once I've got it tested)
<jono> Kamion, cool :)
<mvo> Zomb: oh, I forgot that python-apt upload, sorry for this
<mjg59> Kamion: Rock, thanks
<mvo> Kamion: do you know if promotion work in breezy-updates? I would like to get python-vte from universe to main in it
<jono> mjg59, are you busy tonight?
<Kinnison> Kamion: Right, I think that popunder bug you listed earlier can be marked fix-released by the new metacity upload I just did
<mjg59> jono: Probably not, though my throat is fucked
<Kinnison> Kamion: do you agree?
<jono> mjg59, so the rumours are true then :P
<jono> mjg59, next show, want that belated interview?
<mjg59> jono: Sounds good
<jono> mjg59, cool, I guarentee it this time :)
<Kamion> mvo: I haven't tried yet, let me just try it now and see what happens ...
<mvo> Kamion: cool, thanks
<Kamion> actually
<Kamion> Kinnison: do pockets have independent overrides from their parent distrorelease?
<Kinnison> Kamion: yes
<Kinnison> Kamion: whether or not change-override obeys this is another question
<Kinnison> Kamion: I'd do it --dry-run first to be sure
<Kinnison> Kamion: and/or ask cprov to check
<Kamion>   File "../../canonical/launchpad/database/distribution.py", line 244, in getRelease
<Kamion> canonical.launchpad.interfaces.launchpad.NotFoundError: 'breezy-updates'
<pitti> sivang: ping
<Kamion> maybe it needs an option for pockets
<Kamion> Kinnison: popunder> if it works for you, go ahead and close the bug
<Kinnison> Kamion: looks like it should be using a different function yes :-)
<Kamion> I'll file a bug
<Kinnison> cool
<Kamion> mvo: blocked by bug 36022
<Ubugtu> Malone bug 36022 in launchpad-upload-and-queue "change-override can't handle pockets" [Normal,Unconfirmed]  http://launchpad.net/bugs/36022
<Keybuk> . o O { what's in its pocketses? }
<Kinnison> Kamion: closed the two related bugs in gparted
<Kamion> ta
* Kinnison phews
<Kinnison> lunch and then back to g-p-m
<Kinnison> Kamion: I assume the agreement we had about g-p-m being under the gnome UVF exception still stands? (I'm updating it to 2.14.0 + a few CVS patches)
<Kamion> Kinnison: if g-p-m is still following GNOME release scheduling policies upstream, then yes
<Kinnison> Kamion: I believe it is. However he never made a 2.14.0.news so I'll have to extract that one I've eaten lunch for you to take a quick peek at
* Kinnison -> lunch
<Kamion> Kinnison: FWIW #29474 was probably originally because ubuntu-express did set_keep_above(True)
<Kamion> I took that out a while back
<Kamion> mjg59: I need to bless elilo.efi, right?
<mjg59> Kamion: Yup
<mjg59> Then elilo.conf just wants to point at the kernel and initrd, and have the usual boot options
<Kamion> that part should be done, just uploading debian-installer with that now
<Kamion> I have a suspicion that elilo-installer won't be quite right
<Kamion> but we can deal with that once the CDs boot
<mjg59> Sure
<Kinnison> Kamion: Do you have any changes to the glade file not pushed to p.u.c?
<Kinnison> Kamion: (espresso)
<Kamion> Kinnison: nope
<Kamion> I'm pushing anyway just in case
<Kinnison> Kamion: okay, I'm taking out a minilock so I can make the UI changes for the N-of-M stage ui fix
<Kamion> go for it
<Kinnison> have you finished pushing?
<Kamion> yes
<Kinnison> cool
<Kamion> (there was nothing to push as it happened)
<Kinnison> hehe
<fabbione> Keybuk: what did you break with udev/initramfs this time?
<fabbione> Begin: Waiting for root file system... ...
<fabbione> and it ends there..
<Kamion> mjg59: do we still need the legacy-free option in elilo.conf?
<fabbione> [    7.008720]   sdb: sdb1 sdb2 sdb3
<fabbione> root is there...
<Kamion> mjg59: and will chooser=textmenu work? the mactel-linux.com live CD has chooser=simple
<Kinnison> Kamion: any preferences on where the step N-of-M goes?
<Kinnison> Kamion: My current preference is bottom-left of the page
<Kamion> Kinnison: bottom-left, yes
<Kinnison> cool
<Keybuk> fabbione: that's strange
<Keybuk> it looks until /dev/sd* turns up
<Keybuk> which clearly it isn't
<Kinnison> Kamion: Do you know how to insert a vbox around an element?
<Kamion> Kinnison: if the element's already in a box, use Insert Before, put a vbox there, cut/paste the element into the vbox, decrease the size of the containing box again
<fabbione> Keybuk: it was.. and it's booting.. it just took a while.... weird.. i will give you console access to that box...
<Kinnison> Kamion: and that won't eat containment, names etc?
<Keybuk> fabbione: it just took a while
<Keybuk> slow scsi warm-up then
<Amaranth> whoa, when you run out of memory the kernel starts killing random things?
<Kamion> Kinnison: it may eat packing
<Kinnison> Kamion: umm, argh
<Kamion> I think the rest should be ok
<Keybuk> if you didn't touch it, and didn't hit ^C, and nothing
<fabbione> Keybuk: i will check it again.. got distracted by the phone
<Keybuk> your hardware needed a run-up
<Kamion> packing is small enough to remember
<fabbione> Keybuk: no nothing..
<Keybuk> ok
<Keybuk> this the new shiny?
<Kagou> hi
<JaneW> Yes, Dennis Daniels has done loads
<Kinnison> Kamion: Erm, I need to reparent the steps widget
<JaneW> ECHAN
<Kamion> Kinnison: it'll only eat the packing of steps itself, not stuff inside it
<Kinnison> Kamion: aah right
<Kinnison> okay
<Kinnison> thanks
<Kamion> (at worst)
<Kinnison> cool
<Keybuk> fabbione: once it's said "Waiting for root filesystem" it's literally just in a while/sleep loop waiting for the hardware to get out of bed and brush its teeth
<fabbione> Keybuk: ok..
<Keybuk> that doesn't rule out BenC-bugs of course ;)
<fabbione> no.. it was working with -19 and old udev :)
<fabbione> but i will check it again
<Keybuk> nothing's particularly changed in the scsi case
<fabbione> ncpus probed    : 24
<fabbione> ncpus active    : 24
<Kamion> mjg59: hmm, how about automatically turning on ia32_gconf.legacy_free_boot in apple_fudge()? would that be crack?
<Kamion> (and #ifdef CONFIG_ia32)
<Keybuk> fabbione: I'm assuming you have plain root=/dev/sd* and not lvm, dmraid, evms, or anything I might not have heard of?
<fabbione> Keybuk: hmmm i don't remember.. let me check.. 
<fabbione> Keybuk: LVM on pure scsi..
<fabbione> Keybuk: again don't worry.. i will look at it again..
<mjg59> Kamion: Would probably be reasonable
<fabbione> if i can't figure it out, i will give you console access
<Keybuk> ok
<Keybuk> that would be ideal, thankyou
<Kamion> mjg59: shall I do that and upload then? not that I can test, but it seems easy enough ...
<fabbione> i have been distracted and lost count of seconds..
<Kamion> (famous last words)
<mjg59> Kamion: Sure
<Keybuk> evms, lvm and md are massively undertested in dapper still
<Keybuk> I'm not even sure they work :(
<hunger> Keybuk: They work-for-me(TM)
<mjg59> Kamion: (As long as you're sure CONFIG_ia32 is defined there)
<Keybuk> hunger: do they work after today's update
<hunger> Keybuk: I am using lvm on all my boxes (4 of them, all on dapper).
<hunger> Keybuk: LVM on MB on one box (dapper as well).
<fabbione> Keybuk: yes they do work...
<fabbione> Keybuk: i use them a lot as test cases
<Keybuk> ok
<hunger> Keybuk: Do I need to reboot to get updates activated?
<Keybuk> hunger: yes
<hunger> Keybuk: I have all boxes updated, but I did not yet reboot.
<Keybuk> you need to reboot to test the "mounting of root filesystem at boot time" :)
<hunger> Keybuk: Oh, I did not get that;-)
<hunger> Keybuk: It did work this morning after the -19- kernel upgrade if that helps.
<Keybuk> the udev update is what I was interested in
<Keybuk> to ubuntu20
<hunger> Keybuk: Hmmm.... donno whether that was installed at that time. Probably not.
<Kinnison> Kamion: can espresso be started from within the dev tree, for testing the UI appearance?
<hunger> Keybuk: I'll reboot asap (after finishing install of this crap).
<hunger> Keybuk: BBL.
<Kamion> mjg59: should be, Make.defaults sticks it in CPPFLAGS
<mjg59> Kamion: Excellent
<Kamion> Kinnison: err, possibly but I'm not sure
<Kamion> you can always try sudo ./installer and fix whatever breaks ...
<Surak> Hello.
<Kinnison> Kamion: heh
<Surak> people, the xserver-xorg src package has some packages marked to not be created in some architectures. (for instance, xserver-xorg-via-driver in amd64 and powerpc).
<fabbione> Surak: yes.. that is correct..
<Surak> fabbione: can I request some help from you?
<fabbione> Surak: help -> #ubuntu
<Surak> fabbione: I'm intended to provide a backport for it. The help is in generating the package.
<fabbione> Surak: you can't backport it
<hunger> Keybuk: Does *NOT* work.
<Keybuk> hunger: waits three minutes?
<hunger> Keybuk: With the normal kernel I get no output at all.
<Keybuk> "no output at all" ?
<Keybuk> black screen?
<hunger> Keybuk: With the "safe mode" kernel it writes something about "waiting for root" or similar.
<Keybuk> ok
<hunger> Keybuk: blank after grub is done with its text.
<Surak> fabbione: why? There are patches on via driver on Xorg's cvs. Not intended to backport the whole 7.0 driver, but only those patches required for some hardware to work.
<Keybuk> and then if you wait three minutes, it carries on?
<hunger> Keybuk: I have not waited 3min yet.
<Kinnison> Kamion: I'm just rsyncing the liveCD down for testing
<hunger> Keybuk: Lets just sit around and wait a bit:-)
<fabbione> Surak: if you want to backport patches is one thing. doing a backport means pushing the via driver from a release to another
<hunger> Keybuk: It continued to boot now...
<hunger> Keybuk: 3min seems to be pretty close to what I am seenig;-)
<Keybuk> okies
<Keybuk> http://people.ubuntu.com/~scott/udev
<fabbione> Keybuk: it did wait exactly 3 minutes and then kept going.. even if root was there...
<Keybuk> ^ build and install that, then reboot again
<Surak> fabbione: specifically, the build-tree/xc/programs/Xserver/hw/xfree86/drivers/via/via_mode.c needs to be patched. But yet I don't know how to change the debian structure so I can enable some package to be created in some architecture.
<fabbione> Keybuk: gonna setup access for you
<Keybuk> fabbione: can you try the same source, build and install that
<fabbione> Surak: i don't understand why you want to enable via on amd64/powerpc
<hunger> Keybuk: You got a deb?
<fabbione> Keybuk: sure... in a few tho...
<Keybuk> hunger: which architecture?
<hunger> Keybuk: Sorry, I do not have build tools on my box.
<hunger> Keybuk: x86.
<Keybuk> moment
<hunger> Keybuk: oh, wait, I'll just build it here and push it over.
<Surak> fabbione: the driver works on amd64, but gets stucked at 640x480. This patched file corrects that. I would like to compile the amd64 the ubuntu way.
<fabbione> Surak: do you have a url for via graphic drivers on amd64 machines?
<Surak> fabbione: I have a binary one, I don't remember anymore where I got it.
<fabbione> Surak: i mean.. URL to the hw
<fabbione> i have never seen via with amd64
<hunger> Keybuk: Aehm... how do I extract the files I downloaded from your site? There must be a debian way to do this...
<fabbione> Keybuk: it's building..
<hunger> Ah... dpkg-source does the trick;-)
<Keybuk> hunger: dpkg-source -x _.dsc
<hunger> I am spoiled by apt-get source;-) Sorry for that simple question.
<Surak> fabbione: http://www.surak.eti.br/linux/ubuntu/via_drv.o works on breezy-amd64
<fabbione> Surak: i didn't ask for a driver.. but for hw link 
<fabbione> Surak: link to a vendor that does via with amd64
<Surak> oh, sorry. msi does
<hunger> Keybuk: rebooting with udev version 21
<Surak> fabbione: they sell em64t and amd64 using via boards. we sell about 2000 from those per month.
<fabbione> Surak: ok... please file a bug on malone against xserver-xorg-driver-via
<hunger> Keybuk: That version works better: No 3min break.
<fabbione> Surak: including the URL's to the patches.
<fabbione> Surak: it looks important enough to make it going properly
<Surak> fabbione: this is valid for breezy? dapper come with it and it works.
<hunger> Keybuk: System comes up fine.
<fabbione> Surak: oh breezy!
<fabbione> Surak: nope.. 
<fabbione> Surak: only dapper...
<fabbione> Surak: i see where you are going now..
<fabbione> Surak: you need to edit debian/control, search for the driver and change the line for the architecture
<Surak> fabbione: that's why I've asked for help on compiling it. We ship ubuntu on those machines. And customers are not happy with 640x480...
<fabbione> Surak: but breezy won't get an update
<fabbione> it's something you are doing on your own
<Surak> fabbione: oh I can't believe is that simple. I've been looking areound the whole x tree - duh
<fabbione> Surak: that's the Debian part.. you will need to make sure via recongnized as valid driver on amd64 into the Xorg tree as well
<fabbione> Surak: it's in an Imakefile
<fabbione> if you grep for stuff like mga or sis
<fabbione> you will find it easily
<Surak> fabbione: and I have to put the patch on debian/patches, of course.
<fabbione> yes
<Surak> fabbione: I can make and provide this patch from myself. 2000 machines/month is a good test case.
<fabbione> Surak: yes, but it's an update we can't push into dapper
<fabbione> i mean breezy
<Surak> fabbione: sure. But does it qualify for breezy-backports?
<fabbione> Surak: nope..
<fabbione> Surak: backports are unmodified sources from release X+1 rebuilded without modification in release X
<Surak> fabbione: which would require backporting the whole X tree, I presume.
<fabbione> that won't work
<fabbione> because new X requires too much
<Surak> fabbione: yes, I understand.
* fabbione takes a 2 minutes break
<Surak> fabbione: thanks for your attention. time to lunch now.
<fabbione> Surak: welcome
* xhaker wonders why scribus is so slow
<mdz> infinity: samba changelog?
<Kinnison> Kamion: grrreat, current daily hangs at the waiting for root filesystem message
* Keybuk whistles and slinks off into the corner
<Kinnison> Kamion: aah no, it just takes aaaaages before it gets on with it
* Kinnison kicks vmware for being apparently uberslow
<Keybuk> if fabbione's server wasn't so damned slow ...
<hunger> Kinnison: keybuks new udev (21) fixes this for me.
* fabbione hands a couple of extra > to Keybuk 
<Keybuk> I mean, 24 cpus and it takes more time to build udev than my p200
<Kinnison> hunger: cool, so tomorrow's daily should be cleaner
<fabbione> Keybuk: break and redirect.. really
<Keybuk> Kinnison: to be fair, I *did* say it was probably broken on u-d-a
<Kinnison> Keybuk: aye
<Keybuk> though why are you using evms/lvm/md/dmraid?
<Keybuk> they are evil and the spawn of satan
<Kinnison> Keybuk: me?
<hunger> Keybuk: lvm rocks!
<Keybuk> Kinnison: that is the only bug I'm aware of
<hunger> Keybuk: as for md: I prefer SW to HW raid.
<hunger> Keybuk: Roasted a raid controller once and had *huge* trouble getting the disks going again.
<Keybuk> it's not the theory I hate, just the implementation
<fabbione> Keybuk: that's because it clashes with your implementation :)
<fabbione> Keybuk: please stop that build and pipe it...
* Keybuk points at mjg59 -- blame him!
<fabbione> we are going to get old at this speed
<Keybuk> fabbione: bah, it's nearly finished now <g>
<fabbione> reasonably old that we won't be able to reproduce anylonger
<johannesen> so why isn't sablecc-3.x in dapper?
<Keybuk> I have no plans to reproduce anyway; though David claims he's "eating for two"
<Kinnison> Keybuk: well, I imagine the livecd is using devicemapper?
<Keybuk> Kinnison: squashfs and unionfs?
<Keybuk> though that may mean extra initramfs goo, yes
<Kinnison> Keybuk: dunno, but either way it got stuck
<Keybuk> *nods*
<Keybuk> probably another symptom of the same bug
* Kinnison quits evo and firefox to free up some ram for vmware
<Keybuk> I've fixed it by doing it the way we should have done it in the first place
<Kinnison> :-)
<Kinnison> Kamion: so far so good, I have the label in place and being set when you change pages
<fabbione> SILENCE!!
<fabbione> ahhh
<fabbione> NOISE again...
<fabbione> :/
* Keybuk sneaks a crontab for 3am
<fabbione> Keybuk: this better be good :)
<fabbione> Keybuk: no no.. i am going to remove even the powercords from this thing
<Keybuk> what's the point of having it if you're not going to leave it on?
<Kamion> Kinnison: cool
<fabbione> Keybuk: collection? :)
<fabbione> Keybuk: i won't have it forever anyway
<Keybuk> can I have it?  I could do with a way of getting my heating bill down
<hunger> Keybuk: Having one would be enough for me:-)
<fabbione> Keybuk: it's a 6 months loan.. it will go back 9/11/2006
<fabbione> and i am not kidding.. 9/11
<Keybuk> fabbione: that's almost enough time to boot it
<fabbione> Keybuk: hehe
<Kinnison> Kamion: Now all I need to do, is to turn the self.current_page into a N of M
<Keybuk> "one cpu ... two cpus ... three cpus ... four cpus ..."
<fabbione> so let see...
<fabbione> twentythree cpu
<fabbione> 48000 Nogo
<fabbione> Bogo
<fabbione> there.. it works
<fabbione> Keybuk: good job..
<Keybuk> I'm a genius
<fabbione> Keybuk: that qualifies you as (the only) X maintainer
<Keybuk> excellent
<Keybuk> Kamion: please remove X from the archive, love the maintainer
<fabbione> Keybuk: ehehe
<fabbione> Keybuk: i am powering off this thing
<Keybuk> aww
* Keybuk wonders which button powers it on again
<fabbione> or do you need it more?
<Keybuk> then I can power it on and make you jump
<Keybuk> nope
<Keybuk> it books
<Keybuk> I'm happy
<Keybuk> boots too
<fabbione> ok logout or your session will hang in a sec :)
<Kamion> Keybuk: thppt
<xhaker> mjg59: you around?
<Keybuk> Kamion: if we didn't have X, we wouldn't need OpenOffice, dbus, HAL, network manager, firefox, and all the other things that make our life hell
<Keybuk> :p
<Kamion> that would certainly reduce our bug count, I guess
<Keybuk> of course, we couldn't use launchpad either
* Kinnison is fairly sure w3m would *do* for launchpad
<ogra> hostmaster@grawert.net
<ogra> Timezone: Europe/Berlin
<ogra> Ubuntero: Yes
<ogra> Karma: 84256
<Kinnison> and you can build w3m-img for framebuffer
<ogra> err, wow 
<Kinnison> karma has been re-scaled for balancing
<Keybuk> Kinnison: I guess it wouldn't be any more painful than Launchpad is under Firefox
* Kamion promotes vast swathes of xubuntu stuff to main
<ogra> Kinnison, ahh 
<Kinnison> Keybuk: not much
<Keybuk> after all, pain plateaus after a certain point
<Kamion> though I keep forgetting about it until just before the publisher's due to run, so it's taking a while
<Surak> ogra: your karma is so high you are nearby becoming buda.
<ogra> hehe
<Surak> nearly
<ogra> i think my body is still to much in shape for being a buddha
<ogra> but i'm working on it ;)
<dholbach> ogra: look at seb128's karma :)
<ogra> wow
<dholbach> yeah ;)
<jono> ok I am off
<jono> bye all
<Surak> ogra: looking at seb128's karm you're not becoming buddha soon. sorry.
<ogra> heh
<ogra> i wasnt planning to switch to enlightenment anyway :)
<mjg59> xhaker: Hi
<xhaker> mjg59: my Fn keys are acting up
<xhaker> mjg59: do you want to hear?
<mjg59> xhaker: How so?
<xhaker> mjg59: in example.. the multimedia keys sometimes register 0x03 or something.. and sometimes Xf86AudioPlay
<xhaker> and similar
<mjg59> xhaker: That's not a terribly helpful report, I'm afraid
<mjg59> Firstly, is this under gnome or KDE? Secondly, register under what?
<xhaker> mjg59: sorry, i'm trying to explain that the same key spawns two diferent key codes? in gnome, at the keyboard shortcut applet
<mjg59> Something is causing the keycode to be bound to the keysym. I've no idea why.
<mjg59> It shouldn't be a problem
<Kinnison> Kamion: N-of-M patch in http://people.ubuntu.com/~dsilvers/bzr/espresso/ui-fixes
<xhaker> mjg59: i haven't tryed assigning the keys before
<xhaker> in dapper
<mjg59> xhaker: You shouldn't have to assign them
<xhaker> oh, it's an acer laptop. it has those  and $ keys next to the cursor keys.. they also don't work.. don't bother
<xhaker> those keys are stupid
<Kamion> Kinnison: you have a duplicate self.set_current_page in on_steps_switch_page now
<Kamion> Kinnison: we should make lblStepNofM translatable; I'd change its name to step_progress_label or something, then add espresso/text/step_progress_label to debian/espresso.templates with "_Description: Step ${STEP} of ${TOTAL}" and run debconf-updatepo
<Kamion> although we might have to wibble the i18n framework a bit to get that properly retranslated on the fly when selecting a different language
<Kamion> Kinnison: do you want to do those now, or shall I merge and fixup?
<Kinnison> Kamion: You may as well merge and fixup
* Kinnison is knackered and just killed vmware so would take a while to get the test platform back
<Kinnison> :-)
<janimo> Kamion, thanks for the promotions
<Kinnison> So how big is dapper/main these days?
<janimo> dholbach: your blog entry just made me close most of xubuntu bugs which were left unclosed for some reason
<janimo> so we're down to 4 I think
<dholbach> every call for help on bug triage/bugs seems to result in more bugs... so don't count your chickens before they hatch ;)
<janimo> Kinnison is there a way in LP to link subscribe a team so certain packages 
<dholbach> yeah
<janimo> so xfce stuff gets automatically assigned to xubuntu-team even if mainatiners says debian-xfce
<dholbach> http://launchpad.net/distros/ubuntu/+source/<package> -> bugmail settings
<janimo> dholbach: thanks I'll check that out
<janimo> how existent/good is LP's mail interface
<janimo> for something like for packages in a,b,c; subscribe mail address;kthxbye
<Kamion> Kinnison: ok, no problem, thanks for that!
<mvo> Kamion: I dropped of the net earlier and I think I missed the result of your try to promote python-vte in breezy-updates :) ?
<janimo> Kamion, xffm4 does not currently install (old 4.2 version new not packaged yet) if this is a problem you can postpone promoting it
<doko> Kamion: openoffice.org-l10n-br is in NEW, please promote to main, pitti: please adjust the language packs
<Kamion> mvo: 14:55 < Kamion> mvo: blocked by bug 36022
<Ubugtu> Malone bug 36022 in launchpad-upload-and-queue "change-override can't handle pockets" [Normal,Unconfirmed]  http://launchpad.net/bugs/36022
<Kamion> janimo: xffm4 isn't listed in http://people.ubuntu.com/~cjwatson/anastacia.txt anyway; presumably not seeded and nothing depends on it
<janimo> Kamion, ok then I thought you were going through the wiki page
<janimo> indeed it's not seeded
<janimo> OTOH there are packages which are seeded but not yet approved
<janimo> shall I remove them from the seed until they are approved so they do not block CD build?
<Surak> fabbione: there?
<mvo> Kamion: thanks!
<janimo> mvo, had a chance to look at the update-manager no-gconf thing?
<mvo> janimo: not yet, what was the subject of the mail again?
<janimo> hmm I have to look it probably had update manager and gconf in it :)
<janimo> and/or
<janimo> the only mail you got from me in tha past month if that helps searching
<janimo> mvo, right it is 'update-manager and gconf'
<Kamion> janimo: to unblock the CD build, I'd recommend waiting until everything you absolutely need has been promoted to main, and then rebuilding xubuntu-meta pointing only to main and restricted, not universe or multiverse
<janimo> Kamion, right I'll wait
<Kamion> janimo: then it's OK for other things to remain seeded pending approvals
<Kamion> xfce4-terminal needs an approval for libxml-perl, and I'll do xfdesktop after this publisher run
<mvo> janimo: thanks, found it
<Kamion> and there's a load of plugins still to do
<Kamion> ... to be approve
<janimo> Kamion, hmm libxml-perl let me see I think many xfec packages use a package which is very similarly called
<Kamion> d
<janimo> xml-perl-parser maybe that would siffice
<janimo> suffice
<Kamion> there's libxml-libxml-perl as well, I forget the difference
<janimo> it should
<dholbach> libxml-parser-perl?
<janimo> ah libxml-parser-perl is not in main
<dholbach> hu?
<janimo> then I'll have to add that to the wiki I though it was standard gtk-doc requirement
<Kamion> libxml-parser-perl is in main
<Kamion> libxml-parser-perl |     2.34-3 |         warty | source, amd64, i386, powerpc
<Kamion> libxml-parser-perl |     2.34-4 |         hoary | source, amd64, i386, ia64, powerpc, sparc
<Kamion> libxml-parser-perl |     2.34-4 |        breezy | source, amd64, hppa, i386, ia64, powerpc, sparc
<janimo> Kamion, ok I'll check terminal probably only needs that only not libxml-perl
<Kamion> libxml-parser-perl |     2.34-4 |        dapper | source, amd64, hppa, i386, ia64, powerpc, sparc
<Kamion> since ever
<dholbach> it definitely is, without, there wouldn't be much translation love :)
<kmon> Keybuk, Hi. I've just upgraded udev and it has broken my amd64
<Kamion> right, thanks
<janimo> I missed a question mark there, was actually wondering how come it's not in main :)
<Keybuk> kmon: to 20 or 21?
<kmon> mmmm
<Kamion> janimo: which source package are we supposed to be using now, xfdesktop or xfdesktop4?
<kmon> I've upgraded an hour or so
<Keybuk> dpkg-query -W udev
<janimo> Kamion, the one that provides 4.37
<kmon> I don't really know :(
<janimo> 4.3.7svn
<Keybuk> kmon: likely 20, it's fixed in 21
<janimo> I always forget which 
<Kamion> xfdesktop4 then; that explains some weirdness
<Kamion> janimo: shall I remove xfdesktop?
<Keybuk> it's not frozen, it'll timeout after three minutes and carry on
<janimo> Kamion, yes please
<janimo> and I have a llist of xfce packages to remove if you're doing that
<kmon> Keybuk, my bug: https://launchpad.net/distros/ubuntu/+source/udev/+bug/36038
<Ubugtu> Malone bug 36038 in udev "New Udev package has broken my system and it can't boot." [Normal,Unconfirmed]  
<Kamion> janimo: sure, let me know and I can do them in about twenty minutes
<Kamion> preferably with a reason for each removal
<kmon> I haven't waited 3 minutes though....
<kmon> I'll try now
<stewski> is there a known issue with tvtime showing green screen on dapper
<janimo> Kamion, the reason is the same for all. xfce4.2 packages which were supreseded/replaced (in both normal and dpkg way) by new ones
* kmon goes to reboot
<stewski> tuning is fine and so is sound but video and menu overlay dont show
<stewski> oh and do you know the command to run the gstreamer config tool?
<zyga> hey guys
<Kamion> janimo: ok, it's useful in each case to have the package it was superseded by, for our records
<Kamion> that way the removal log is more useful
<janimo> Kamion, xfdesktop, xfce4-toys, xfce4-taskbar-plugin, xfce4-systray, xfce4-iconbox (replaced by xfdesktop4, xfce4-utils, xfce4-panel for the last three)
<Surak> Keybuk: how can I make breezy's xorg try to compile a driver it will originally not? I mean, a driver is enabled for i386 but it's not for amd64. How can I try to change that? It is in some Imakefile, it seems. But no success up to now.
<sivang> hey janimo 
<Kamion> ok, thanks, I'll kill those
<janimo> Kamion, thanks
<janimo> sivang, hey
<zyga> dholbach: ping
<dholbach> zyga: pong
<zyga> dholbach: I lost track of ontv 1.8.8 inclusion, is there anyone makin the UVF exception?
<zyga> if no then I'll file a bug about it and start reading thru the diff
<dholbach> zyga: bug 33441
<Ubugtu> Malone bug 33441 in ontv "UVF exception 1.6.2 -> 1.8.6" [Normal,Unconfirmed]  http://launchpad.net/bugs/33441
<zyga> k
<zyga> will that include my fixes that have been submitted into gnome cvs yesterday?
<dholbach> zyga: i suppose not, it's talking about 1.8.8
<dholbach> zyga: ask johan to make another release, I'll CC oyu on the bug
<zyga> great, I'll mail him right away
<dholbach> zyga: I asked him on the bug report - he's CCed too
<dholbach> zyga: so no need for the mail
<zyga> okay
<stewski> should the multimedia selector come up with
<zyga> I still need to mail the maintainer of the polish translation to approve my improvements, johan has asked for that
<stewski> failed to construct test pipeline for ALSA on the test in the multimedia selector?
<stewski> on default input plug in
<zyga> done
<stewski> well its like being at the bar in my local :-)
<Kamion> janimo: xfce4-utils doesn't conflict/replace xfce4-toys?
<Surak> someone? help me to compile BREEZY via driver in amd64's ubuntu package?
<Kamion> janimo: and xfce4-panel doesn't conflict/replace xfce4-taskbar-plugin either
<Kamion> janimo: anyway, xfdesktop, xfce4-toys, xfce4-taskbar-plugin, xfce4-systray, xfce4-iconbox all removed
<KaiL> hmm, one of the last days updated seams to produce lockups in gtk apps (and maybe somewhere else too..)
<Robot101> uh
<Robot101> the "reboot required" dialog
<Robot101> has the "instantly reboot my computer now without confirmation" as the bottom right button
<Robot101> I don't consider this safe
<Robot101> it's usually the "this file has been changed, save?" save as the bottom right action
<Robot101> I don't think rebooting my computer is very... affirmative
<janimo> Kamion, ah sorry actually xfce4-session is that Replaces xfce4-toys
<zyga> Robot101: ask mvo to change this then
<janimo> and conflicts too
<Robot101> bah
<Robot101> I suppose it's correct and I'm just a moron for clicking it.
<zyga> Robot101: check the gnome HIG
<zyga> it might be wrong, you might be wrong
<zyga> don't guess, just checek
<zyga> check
<Robot101> I think it says the affirmative action is always in the bottom right
<Robot101> the wording is along the lines of "you should reboot now" "rebooting is required to save the world and stuff might not work unless you do it" <later> <now>
<Robot101> so yeah
<Kamion> janimo: ok
<highvoltage> does the ubuntu community council have an irc channel?
<tseng> #ubuntu-meeting is the home of all meetings including CC
<tseng> most members are here in between
<ogra> highvoltage, you mean a channel where Kamion, elmo, mako and sabdfl idle all day ? 
<highvoltage> ogra: something like that :)
<ogra> :)
<ogra> most likely this one then :)
<Surak> it's #nerd-heaven :-)
<highvoltage> ogra: i wanted to ask about adding something to the CC agenda, but i'll just add it anyway.
<ogra> you'll get comments on the wikipage usually ...
<Kamion> highvoltage: no, we don't
<highvoltage> ogra: hehe :)
<LaserJock> anybody know of a list of admins/moderators (I'm not sure what they are called) for #ubuntu ?
<sabdfl> hardly
<Treenaks> LaserJock: chanserv can tell you
<mdke> LaserJock, i think there is one on the wiki. But yeah, /msg chanserv access #ubuntu list I think
<LaserJock> Treenaks, mdke thanks
<bluefoxicy> can someone explain something to me about debian packages?
<Seveas> doko, ping
<bluefoxicy> Debian packages are more than simply archives of files; you need to account for files changing ownership between packages, diversions, actions of maintainer scripts, etc.
<bluefoxicy> Believe me, there is more to this than finding copies of the files which came from the .deb, and even that isn't straightforward.
<bluefoxicy> ^^^ specifically that, re taking a package vs a root at which it was installed and locating the files from the package
<mdke> bluefoxicy, mdz wrote that, you can ask him. or follow that thread on the mailing list
<Seveas> bluefoxicy, the postinst script can do arbitrary things, including creating, deleting and moving files.
<bluefoxicy> mdke:  I'm aware, but he's never gone into much detail with things.  My experience with mdz is his arguments are largely "Look, you can't do that, there's reasons for it, it just doesn't work because things aren't that simple"
<bluefoxicy> Seveas:  I'm aware of that, I just don't see it as something extremely common
<bluefoxicy> I hardly think packages are majorly scripts that take a tarball that was created from a tree of files and shuffle it around for no real reason
<Seveas> bluefoxicy, then you're terribly wrong I'm afraid
<mdz> bluefoxicy: I've gone into more detail in the past; this is hardly the first time someone has proposed this
<mdz> if you didn't follow the previous discussions, please read the list archives
<bluefoxicy> Seveas:  so you mean if I like, unpack an xorg-server tarball, i'll get a blob of files in ./xorg/files/ that are all in one directory; and some script will actually build the directory tree from scratch?
<bluefoxicy> mdz:  "you need to account for files changing ownership between packages"  <-- well at least that is straight false, which leads me to question.
<mdz> bluefoxicy: I'm afraid it isn't
<Seveas> bluefoxicy, search malone for Replaces: and Conflicts: to find keybugs rant about people abusing them
<Seveas> it contains a very thorough explanation about it
<mdz> install package foo, which contains /usr/bin/foo.  package foo2 Replaces: foo, installs a different version of /usr/bin/foo
<mdz> the version of /usr/bin/foo you need to reproduce the .deb is no longer available
<bluefoxicy> mdz and?
<mdz> and you lose
<bluefoxicy> this proposal is not "let's create a reusable .deb file that's stripped down"
<mdz> it's "add a hacked up backend to dpkg which tries to gather the necessary bits from a filesystem"
<mdz> I understand what you're proposing and it's not something that I think is worthwhile
<mdz> but if you want to try it, that's none of my business
<doko> Seveas: pong
<bluefoxicy> mdz yes; however, you seem to be missing the fact that the actual deb that needs the bits and the filesystem supplying them are both immutable and interdependent.
<bluefoxicy> in other words the deb would be specifically stripped to match with a file system as it exists at that specific time, kind of like when you have a spanning zip archive to fit across 3-4 floppies and if you change the content of it you can't just update one of the floppies and hope it's okay.  They're all one big unit.
<Seveas> doko, re: the path issue: it has improved from being /usr/bin:/bin to /usr/bin:/bin:/usr/local/bin:/usr/X11R6/bin:/usr/games - still no /usr/sbin:/sbin though
<mdz> bluefoxicy: all I can say is, good luck
<bluefoxicy> mdz I could try it, though i'd have to find the unpacking routine in dpkg, probably have to wait until I have more time though because I'm writing a paper and jobhunting and about to go to a cyberdefense competition
<mdz> don't expect anyone else to do this work
<bluefoxicy> mdz I understand how debian works; if they don't think it's worthwhile, you can write something the size of the codebase in OpenOffice.org and they'll shrug and ignore it without a second look
<bluefoxicy> and I understand how ubuntu works; if it doesn't get into debian, it doesn't get into ubuntu.
<mjg59> bluefoxicy: That's quite obviously untrue
<mjg59> The livecd is a good example of this
<Kamion> gfxboot is another
<bluefoxicy> mjg59:  It's quite obviously fuzzy.  I've seen the exact debian-ubuntu argument used to kick a few things back such as certain gcc compiler patches.
<bluefoxicy> "We'll do that when debian does that"
<doko> Seveas: ok, asking Mithrandir (he did the PATH magic)
<mjg59> bluefoxicy: Individual maintainers have different policies. 
<Kamion> bluefoxicy: that's obviously a matter of resources
<bluefoxicy> mjg59:  fair.
<mjg59> With basic infrastructure like gcc, there's an incentive to stay close to Debian. It means there's more people looking at problems that come up.
<Kamion> bluefoxicy: Ubuntu has finite resources, and it's important to make use of the (often) bigger development/testing community in Debian where possible/sensible
<bluefoxicy> mjg59:  although I'm quite sure an entire distro isn't going to use a modified version of apt/dpkg that has no chance of making it into mainline debian
<bluefoxicy> at any rate
<Kamion> that's true
<bluefoxicy> this discussion has gone far off into tangent
<Kamion> although you're certainly welcome to prototype ideas that can then be looked at with a little more experience
<doko> bluefoxicy: even staying close to upstream. gcc very rarely sees patches which are not integrated upstream
<bluefoxicy> heh.
<Seveas> doko, btw: root path includes the /sbin's and missed /usr/games - that seems correct
<bluefoxicy> "there's nothing wrong about an executable stack though. It's been part of Linux ever since."  o_o
<bluefoxicy> anyway I have things to do.
* lamont points at bld-4.mmjgroup.com/~wb/buildLogs/stats/dapper.stats.png and friends
<wasabi> Any movement on an Ubuntu port to arm?
<sivang> pitti: ping
<sivang> pitti: any idea why hal's property capacity returns different values depends on the CD ? I have one CD which it reports 200MB for
<sivang> pitti: any idea how to get the real capacity?
<sivang> sjoerd: ^^
<Burgwork> wasabi, most of the pieces are there, due to it being mostly debian and there was an effort. see EmbeddedUbuntu on the wiki
<wasabi> k
<sjoerd> sivang: dunno, is it a blank cd or a written one with 200mb's of data ?
<sivang> sjoerd: one of the is a written one with 200MB of data :)
<sivang> sjoerd: but capacity should be the theortical available space ,, not how much was consumed :)
<sjoerd> dunno what the exact definition is 
<fabbione> sivang: for ro media it's sligtly different..
<fabbione> sivang: 200MB is correct becuase the session is closed and can't be reopened.. 
<fabbione> i guess xfce4 made it in main...
<sivang> fabbione: I see, so instead of reporting the capacity it says how much was occupied?
<fabbione> sivang: the capacity at that point is 200MB
<fabbione> it's a corner case where the capacity becomes the same as used space
<sivang> fabbione: okay, thanks, this helps alot :)
<fabbione> think it as shrinking a partition that you can't grow anylonger
<sivang> right
* sivang suddenly can't reproduce that :-)
<sivang> fabbione: how can I find out how much room is left on an multisession, not finalized CD?
<fabbione> sivang: no idea.. i don't have such luxury like empty/multisession CD's
* fabbione is burning about 25 DVD's per day to backup data around
<sivang> fabbione: k, thanks a lot!
* mjg59 reduces ALPS-pad suckage
<dieman_> heh
<dieman_> the gnome cups printer wizard for windows printing sucks when it comes up with 20-30 'please login for blah workgroup'
<dieman_> as it annoys every laptop on the subnet
* Burgwork hugs mjg59 
<dieman> ive had my synaptics pad flip out twice in the last week but no good logs from it
<dholbach> jdub: rocket powered cheerios... hahahaha :-)
<j^> is it possible to change all those * in password dialogs to ?
<j^> or all  to *
<j^> right now its 50/50
<mjg59> j^:  is probably correct
<mjg59> But was difficult in the pre-unicode world
<j^> just tried with NetworkManager, its set in the .glade file <property name="invisible_char">
<j^> setting that to  does not work, i get an invalid unicode error
<Amaranth>  is better
<j^> Invalid UTF-8 string passed to pango_layout_set_text()
<dholbach> have a nice evening
<Pygi> evenin' dholbach
<_ion> Good morning.
<Pygi> night _ion ;)
<Pygi> _ion: I think we can drop l-r-m from our repo now...
<Pygi> thoughts?
<_ion> pygi: As the patch gets to the official package, sure.
<Pygi> _ion: yup, agreed
<_ion> pygi: Btw., i have made some changes to the n-m package. I'll email them to you and tonio, i'll let you decide whether a certain thing i did is teh evil, or should it be uploaded to the repo. :-)
<Pygi> _ion: btw. perhaps we should look on a way to make n-m scan, as long as no network cable is plugged in
<Pygi> _ion: lol, ok ^_^
<Pygi> will check right away...
<_ion> I didn't send the email just yet.
<Pygi> yup, I know...
<j^> is there any solution for the orinoco regression wrt WEP keys?
<seb128> j^: bug #3300
<Ubugtu> Malone bug 3300 in gksu "gksudo does not follow GNOME password hiding style" [Normal,Confirmed]  http://launchpad.net/bugs/3300
<seb128> https://bugzilla.ubuntu.com/show_bug.cgi?id=7714 too
<Ubugtu> Ubuntu bug 7714 in gtk+2.0 "Change default invisible character for GtkEntry" [Normal,New]  
<j^> seb128 i reported 7714 some releases ago
<pitti> Kamion: (not urgent) can you please NEW postgresql-common for the new split off postgresql-client-common package?
<pitti> good night everyone
<j^> seb128 what about switching to 0x25cf in ubuntu gtk?
<j^> afaik ubuntu does not use any fonts that do not provide  by default
<seb128> j^: I didn't do it the cycle we got the bug because it was not best time for that cycle
<seb128> j^: I'll try that tomorrow
<mroth> the new xserver-xorg appears to have fixed bug 35172 , however no direct rendering / acceleration.   Should I file a new bug against xserver-xorg-driver-i810 for that?
<Ubugtu> Malone bug 35172 in xserver-xorg "X.org with i810 Driver Cannot Detect i945GM chipset" [Normal,Needs info]  http://launchpad.net/bugs/35172
<mjg59> mroth: Are you sure you're running with i810 rather than vesa?
<mroth> mjg59: the Xorg.log appears to be loading i810, so I would think so.  Easy way to absolutely confirm?
<mjg59> mroth: No, that should be it
<mroth> also, looks like bug 35739 is a duplicate of my 35172, or vice versa
<Ubugtu> Malone bug 35739 in xserver-xorg-driver-i810 "Missing support for 945GM chipset" [Normal,Unconfirmed]  http://launchpad.net/bugs/35739
<mjg59> When you say no direct rendering/acceleration, do you mean no 3D acceleration?
<mroth> mjg59: no 3d acceleration (glxgears is actually slower than with vesa, less than 1fps), but also glxinfo reports "Direct rendering: no" 
<wasabi> I have this strange desire to try to install Ubuntu on my n770.
<HrdwrBoB> haha
<wasabi> Wonder what the driver status is like in the kernel and X.
<HrdwrBoB> in it's own way, the 770 has a touch of ubuntu
<HrdwrBoB> ;)
<mjg59> mroth: Ok. Is i915 (the kernel module) loaded?
<HrdwrBoB> (daniels is working on it)
<jdub> 770 shares the same wonderful roots with ubuntu :)
<mjg59> sladen: Around?
<sivang> wasabi: what's n770 ?
<wasabi> the nokia handheld.
<zyga> sivang: nokia linux based handheld
<Riddell> mjg59: he's not
<zyga> with the open source maemo platform
<zyga> rather not sucessfull due to limited memory and lack of extensibility
<wasabi> Yeah. Not too happy with it. I mean, it's pretty neat.
<jdub> zyga: ... it has been very successful, moreso than expected
<wasabi> But I can't use it for anything.
<jdub> certainly it's a 1.0 product, but it's doing nicely
<wasabi> The software that is ported is simple stuff, Gaim, etc.
<wasabi> Not even a usable email client.
<jdub> (the new firmware is going to rock)
<wasabi> What about it?
<wasabi> jdub: know something I don't? :)
<jdub> everything
<jdub> speedier, cool new apps
<zyga> jdub: the software is but the hardware had rather bad reviews and I tend to agree looking at the specs
<wasabi> I'm disappointed that it doesn't jujst work like normal linux.
<wasabi> This /var/lib/install stuff is stupid.
<sivang> zyga: ah, kiko has one like this
<mroth> mjg59: i915 is not loaded.
<jdub> zyga: it's a tiny bit slow, but work is being done on that
<wasabi> I'd just assume have a normal distro base, and Maemo to be nothing more than a desktop environment.
<sivang> he played Dome or something on it when I set next to him
<zyga> jdub: if it had 256M the it'd be really awsome
<zyga> no memory == really useless in 12+ months
<zyga> cpu speed is not that much of an issue but with no swap space you are pretty limited
<wasabi> At least, I think I'll make Hildon packages for Ubuntu.
<wasabi> If possible.
<mroth> mjg59: modprobe i915 and restarting X does not produce DRI, however
<jdub> that's really not true - look at the playstation, xbox, etc. not much memory, but the apps get better and better because the developers learn how to get the best out of it
<mjg59> mroth: Anything in dmesg when i815 is loaded?
<jdub> s/it$/the platform/
<wasabi> I'm actually kinda excited about teh UMPCs
<zyga> jdub: true but those are very vertical applications, not gereric 'office' apps like email and web browser
<mroth> mjg59: only "[drm]  initialized drm 1.0.0"
<zyga> jdub: do you think that 64M is enough? seriously?
<jdub> absolutely
<zyga> I work on embedded stuff daily
<zyga> our boxes have 32 megs and do awsome stuff
<mroth> mjg59: this is a 945GM chipset with a GMA950 card, perhaps i915 is not the proper driver (or it needs a more recent upstream?)
<mjg59> mroth: Ok. So the kernel module doesn't support it
<zyga> but that's not open source software with genericness,
<j^> gates 640k is enugh, jdub 64M is enough...
<zyga> and besides... we'll never put firefox there
<mjg59> i915 is the right driver, though
<zyga> nor will maemo
<Amaranth> mjg59: does the xserver-xgl package contain a full xorg source tree?
<mjg59> Amaranth: The source package contains a full xserver/xorg tree, yes
<HrdwrBoB> zyga: firefox needs 100+, esp with it's worthless X pixmap handling
<Drac[Server] > I know you don't like support questions, but I have an interesting problem and a worthy cause. I'm trying to set up a small example of how my school can use Linux as its pirmary OS, even with networking and such. I will then present my finalized, tweaked and networked ubuntu machines to the tech department. I hope to convince them to switch. Will somebody here be willing to help me?
<mjg59> minimo needs much less than that
<zyga> HrdwrBoB: we don't run X, does maemo?
<mjg59> It's easily usable in 64MB
<jdub> zyga: it's very early on in the product lifecycle - the software was actually developed quite late in the process. the next firmware improves in this respect.
<jdub> and opera is used in devices with less than 64MB RAM
<zyga> jdub: then I'll look forward to this
<zyga> I wanted to buy n770 last week actually but I learned that it lacks a phone support and was mildly dissapointed
<zyga> maybe 2.0 hardware with phone, better apps and more memory will be interesting
<mjg59> zyga: There's a specific desire not to make it a phone. It's way too big to be used as one.
<zyga> jdub: opera is nice for embedded stuff, yes! :)
<zyga> mjg59: even so a GPRS web browser is usefull
<mjg59> zyga: So you have to carry a phone /anyway/
<zyga> a wifi-only device is limited  uness you live in a major capital city with free wifi (And I don't)
<jdub> i thought it would fail based on the lack of mobile hardware
<mjg59> So it might as well just do bluetooth to that
<jdub> but now i understand - phones are phones, browsers are browsers
<Drac[Server] > Apparently not. I remain ignored. 
<jdub> devices that try to do both *suck rocks*
<wasabi> Yeah, I agree with that wholeheartidly.
<jdub> Drac[Server] : #ubuntu for support foo
<wasabi> I do not want my n770 to be a phone.
<zyga> mjg59: two devices, two batteries, I prefer one GPRS but that's just my personal opinion
<zyga> jdub: windows smartphones are quite nice, a friend of mine has one
<Drac[Server] > jdub, I'm quite aware of that. Do you know how useless that channel is when it comes to remotely complicated problems? 
<wasabi> Drac[Server] : well, read the topic here, then.
<zyga> (every time I think of changing my current phone I'm turned down by the lack of ssh to that smartphone though ;-)
<mjg59> zyga: I like to be able to phone people without either having a silly device attached to my head or holding something the size of a small brick to it
<jdub> Drac[Server] : yeah, but this channel is equally useless for different reasons 8) you might want to ask about it on the edubuntu mailing list
<mjg59> Drac[Server] : Emailing the sounders list may be your best bet
<jdub> Drac[Server] : they have particular interest in schools, thin clients, etc.
<mjg59> Or edubuntu, as Jeff says
<zyga> mjg59: actually my friend always uses a pocket headset 
<wasabi> Splitting out the part of Maemo that is hte unix desktop environment, to me, is a good idea.
<mjg59> zyga: Yeah, but the majority of people don't
<wasabi> So I can apt-get install it on Ubunut, for instance.
<zyga> mjg59: that probably depends on the sample :-)
<zyga> most drivers do
<jdub> wasabi: their developer livecd is based on ubuntu, and ships with maemo
<mjg59> Coming from a GTK development background, Maemo is lovely to develop for
<wasabi> jdub: But it doesn't run Maemo as part of the live cd.
<mjg59> I ported dasher in less than a day
<wasabi> jdub: It uses scratchbox.
<jdub> so you can run it in an appropriately sized xnest
<wasabi> Which is quite different from actually having Maemo/Hildon be a viable Normal Unix UI.
<zyga> I'd like a device like that with flash disk (CF internal) and more more ram
<zyga> then I'd trade my PSP for it and have a nice browser :)
<mroth> mjg59: should I file something against kernel-source re: the i915? or..
<mjg59> mroth: Yeah
#ubuntu-devel 2006-03-28
<sivang> fabbione: still here?
<wasabi> I wonder what about Ubuntu and our system, udev, hal, etc, is unsuitable for the n770. I suspect the memory footprint is going to be higher.
<wasabi> Probaby something that should be fixed anyways though.
<sivang> anybody has an idea if when giving -o device_node to mkisofs it acts as cdrecord and "burns" the image directly to a CD?
<sivang> it's described that way on the man page, but seems rather odd
<HrdwrBoB> I highly doubt it
<_ion> Unless mkisofs contains some magic for burning a CD instead of just cat'ing the image to a device, my guess would be "no".
<wasabi> it might be possible if the driver for the drive supports burning.
<wasabi> Which I dunno.
<sivang> what why is it mentioend to you can give -o device_node where device_node = "correspond directly to the device name of the optical disc writer.."
<mjg59> wasabi: Burning is slightly more complicated than that, I'm afraid
<mjg59> Otherwise we could just use dd
<sivang> yes, that what I Had in mind
<sivang> mjg59: so I guess I do need to create backup images on the HD, and then use cdrecord to toss them to a CDR/CDRW
<sivang> :)
<Chipzz> hrrrm :)
<_ion> sivang: http://johan.kiviniemi.name/tmp/backup-to-cdrw
* Chipzz just installed plesk :P
<Chipzz> must say, from all isv software I have seen yet, at least they understand what "dpkg" and "apt-get" are
<Chipzz> not entirely, but at least a bit :)
<sivang> Chipzz: is it a some kind of a web serveR?
<tepsipakki> would it make sense to provide support for ISV:s to help make native deb-packages?
<sivang> _ion: right, so cdrecord is the "driver" :)
<Chipzz> sivang: plesk is a control panel
<tepsipakki> I've just tried to package Matlab...
<Chipzz> something like cpanel
<Chipzz> tepsipakki: they actually do support debian sarge and ubuntu 5.04
<sivang> Chipzz: why use an ISV software for that then?
<Chipzz> but they have certain custom packages
<mroth> mjg59: hrm, bug 35741 seems to be a duplicate of what I was about to file, but its filed against mesa for some reason
<Ubugtu> Malone bug 35741 in mesa "Missing support for 945GM chipset" [Normal,Unconfirmed]  http://launchpad.net/bugs/35741
<tepsipakki> Chipzz: yes, they do. Matlab builds on sarge, but they still ship 3CD:s full of stuff =)
<Chipzz> sivang: because $dumb_user_wanting_a_webpage doesn't know shit about configuring apache and shouldn't know
<Chipzz> sivang: this is for the company I work for, we offer webspace with php/mail/etc against bottom prices ;)
<Chipzz> amongst several things
<HrdwrBoB> Chipzz: I used to sysadmin for a webhost.. we wrote our own
<Chipzz> HrdwrBoB: and how much time and money did you have for it? ;)
<Chipzz> we actually have a front-end for plesk to do the actual creation of the domains, and then offer plesk to the users to give them a certain amount of control over their domains
<Chipzz> currently installed on rh, but going to migrate to debian/sarge
<HrdwrBoB> well you have to pay for plesk
<Chipzz> we do have a license allready :)
<HrdwrBoB> and I was working for them fulltime.. so the economics were on our side
<mroth> mjg59: should I just mark that one as confirmed instead of opening a new one in kernel-source?
<mjg59> mroth: What's it currently assigned to?
<mroth> mjg59: no one.  status unconfirmed.  https://launchpad.net/distros/ubuntu/+source/mesa/+bug/35741
<Ubugtu> Malone bug 35741 in mesa "Missing support for 945GM chipset" [Normal,Unconfirmed]  
<mjg59> mroth: No, what package
<mjg59> Or just ubuntu in general?
<mroth> yeah, its under "mesa (Ubuntu)"
<mjg59> Can you reassign it to linux-source-2.6.15?
<mroth> mjg59: sure.  keep as unconfirmed, or change status?
<mjg59> unconfirmed for now
<mjg59> Have you attached lspci? If not, could you?
<mroth> mjg59: I'll link to my lspci page for that machine on the LaptopTestingTeam wiki
<mroth> since it has both normal, -v and -n
<mroth> ok, bug 35741 should be in linux-source now, right Ubugtu?
<Ubugtu> Malone bug 35741 in linux-source-2.6.15 "Missing support for 945GM chipset" [Normal,Unconfirmed]  http://launchpad.net/bugs/35741
<sladen> mjg59: yup
<mjg59> sladen: Do you still have an IBM restore and recovery partition?
<sladen> mjg59: yes, but not the boot sector
<mjg59> sladen: Can you mount it and stick up an ls -R somewhere?
<sladen> mjg59: I can still boot the recovery partition (I think)
<sabdfl> night all, sladen, mjg59 
<mjg59> sladen: I'm just fixing up os-prober so it can autodetect the correct type of partition
<_ion> Quite an interesting plugin for Gimp, "Resynthesizer". http://software.newsforge.com/article.pl?sid=06/03/15/1722200
<_ion> http://www.logarithmic.net/pfh/resynthesizer
<sladen> mjg59: http://www.paul.sladen.org/ubuntu/recovery/ibm-thinkpad-r52-rescue-recovery.ls-lR.txt.gz   and I've scp'ed up a lot of the small files like 'version.id' for you to `strings`
<mjg59> Ta
<infinity> mdz: http://us4.samba.org/samba/history/samba-3.0.21c.html <-- Samba changelog... Sorry for not providing it last night in my ping payload.
<mdz> infinity:     * Update dhcp.conf files in Debian packaging <-- what's that about?
<mdz> why does samba have a dhcp.conf in the packaging?
<infinity> mdz: Upstream maintains a debian/ directory which is seperate from the one we (Debian/Ubuntu) maintain in SVN.  Can be (and is often) completely ignored.
<mdz> infinity: looks fine, go ahead
<infinity> mdz: But it's some trickery for allowing netbios-name-server from DHCP to trickle into samba's wins server setting.
<hendry> i am getting an md5 mismatch on Universe. Anyone else?
<infinity> mdz: Thanks.
<infinity> Oh, hey, lookit that.  Leave it overnight, and eventually bzr will finish checking out all the seeds.
<hendry> is there some reason ubuntu doesn't autoupdate like RH's up2date?
<tseng> it has a red icon that pops up and tells you when to update
<tseng> very similar to the up2date applet
<LaserJock> but much better, IMHO
<Burgwork> LaserJock, like it is actually up2date? :)
<sivang> it's not up2ate for sure :)
<sivang> it's update-manager no?
<LaserJock> Burgwork: exactly
<LaserJock> Burgwork: up2date had a lot to do with my advisor moving from Linux to OSX :(
<infinity> mdz: Same question, mod_perl2 2.0.1 -> 2.0.2.  Very minor bugfix release, plus one added feature (exposes three new proxy constants) -- http://perl.apache.org/dist/mod_perl-2.0-current/Changes
<mdz> infinity: OK
* infinity tries to get over the shock of hppa being caught up, and prepares new chroots for all arches before a mass-give-back.
* Kinnison tickles infinity
<Kinnison> mdz: I'll get on those vim and aspell bugs tomorrow morning
<hendry> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358071 # i've exp this bug in Dapper too
<Ubugtu> Debian bug 358071 in evolution "Subject: SIGABRT error after libc6 update" [Grave,Open]  
<hendry> glibc seems b0rked
<mjg59> You're sure it's not glib?
<hendry> mjg59: ok, perhaps glib. is there an Ubuntu bug open for this too?
<crimsun> no, it's glib
<mjg59> hendry: It's already being dealt with
<mjg59> glib's memory allocator changed and broke some false assumptions 
<hendry> mjg59: i want to know when this is fixed. or how i can work around with it. it's already screwed up a days work for me
<j^> http://stratusandtheswirl.blogspot.com/2006/03/for-those-who-care-about-gnomew-glib.html
<mjg59> hendry: I recommend not depending on a development distribution
<Amaranth> mjg59: found something weird in one of my xorg logs when i was messing with xgl
<Amaranth> mjg59: for some reason it was trying to use the vga driver
<Amaranth> i'll try to make it happen in a loggable way again
<mjg59> Amaranth: Weird
<Amaranth> yeah, the vga driver doesn't work on ppc
<Amaranth> at least not on this one
<Amaranth> bbiab
<hendry> mjg59: you're right. :/
<Lathiat> ooh, launchpad has as exy new little dropdown for changing status info
<nictuku> where is the channel for discussing possible bugs? (ati driver)
<nictuku> *what
<Amaranth> mjg59: would an strace between aiglx glxinfo and xorg glxinfo help with anything? (no direct or indirect acceleration with aiglx)
<Amaranth> err, diff of straces between the two
<minghua> I need a core developer to review and sponsor an upload for scim
<minghua> the debdiff is at http://www.mems.rice.edu/~minghua/ubuntu/scim_1.4.4-1ubuntu5_to_1.4.4-1ubuntu6.debdiff
<minghua> it fixes bug #35852
<Ubugtu> Malone bug 35852 in scim "scim xinput.d file causes login failure" [Normal,Confirmed]  http://launchpad.net/bugs/35852
<minghua> #debian-l10n seems silent now (I posted half an hour ago), anyone willing to help here?
<fabbione> minghua: looks sane...
<minghua> fabbione: thanks, can you upload it for me?
<fabbione> minghua: in a bit.. i want more coffee first
<minghua> fabbione: sure, no pressure :-)
<fabbione> done
<minghua> thanks!
<fabbione> minghua: i will send you a bill to your bank.. welcome to pay in 2/3 rates.. 
<minghua> fabbione: Hmm... pay to you or to Canonical? :-)
<fabbione> minghua: me :)
<infinity> minghua: I'll email you fabbione's Australian bank account details.
* infinity coughs.
<fabbione> ehheh
<minghua> :-)
<jkakar> infinity: According to the release notes there are "major ABI/API changes". :)
<infinity> jkakar: Then that's almost certainly a "no", unless there are amazingly compelling reasons to upgrade, which you'd then need to discuss with pitti, seb128, and mdz (the first two would be responsible for implementing all the changes required, probably, and the latter would most likely veto it anyway without some really good arguments)
<infinity> jkakar: DBUS upgrades are typically very (VERY) painful.
<jkakar> infinity: Shucks.  Thanks, I'll see if I can come up with a compelling argument.  Right now there are bugs in the python bindings that make it basically useless...
<jkakar> infinity: I suppose there's always monkey patching.
<fabbione> jkakar: are the bugs only python related?
<fabbione> or there is more than that?
<infinity> jkakar: Can the bugs not be fixed in the python bingdings without upgrading the whole mess?
<infinity> bindings, even.
<jkakar> fabbione: I suspect only python-related... "successful" is spelt "sucessful" in three places in service.py:_method_lookup()
<infinity> jkakar: Yeah, those are some pretty minor bugfixes, then.  Pretty please, prepare patches and file bugs (or poke me directly), and we'll get the fixes uploaded.
<jkakar> Fixing the spelling in the python files directly fixes my problem.
<jkakar> infinity: Awesome!  Thanks, will do.
<jkakar> infinity: I'd like to wait to provide the patches until I've made it a bit further into what I'm doing... just in case there are other dumb things like that.  Is there any rush on this, or can I harrass you about sometime in the next week or two?
<infinity> jkakar: Small and obviously correct bugfixes are appropriate anytime (before release).
<jkakar> infinity: Cool, thanks.
<fabbione> ogra: are you still around?
<childe> Hi, if I don't line the default recycle bin icon, where should I report the bug?
<childe> Or, to which team should I report the bug?
<infinity> You're not alone, and I'm not sure that filing another bug will help.
<childe> It looks too much like a pistol bullet shell.
<infinity> Most people say "battery", but bullet works too. :)
<childe> It's sweet to know that I'm not alone on this issue
<whiprush> the ubuntu-art list probably.
<childe> Thanks
<Burgundavia> there is already a bug filed for it
<childe> Burgundavia: Could you tell me the bug number?
<childe> I want to see what other people say about this
<infinity> Most of the complaining has been on IRC and on mailing lists and such.
<infinity> But the artists are definitely aware of the dislike for the icon.
<infinity> Not sure what they plan to do about it. :)
<whiprush> infinity: are you on the server team?
<infinity> whiprush: Aye.
<childe> Maybe when Dapper release most of the icons will be changed to the orange color ones
<Burgundavia> childe: sorry, not off hand. I am not worried, it will be dealt with
<childe> Like the "Home Folder" icon.
<childe> Burgundavia: It's OK :-)
<whiprush> infinity: Kerberos support is much better in dapper than breezy, you guys should mention that in some release notes somewhere.
<infinity> whiprush: Feel free to start some ubuntu-server release notes on the wiki for me.  I won't object.
<whiprush> It's almost damn near trivial.
<infinity> whiprush: If there's anything anyone knows about server-type people, it's that we hate creating documentation. ;)
<whiprush> heh
* infinity looks at his TODO list for the day, notes that he's already worked 8 hours or so, counts another 4 or 5 to go, and sighs.
<childe> Synaptics feels much faster than before. I don't know why.
<whiprush> infinity: has anyone shown up with any interest in LDAP server stuff? 
<whiprush> It'd be neat to have someone working on the fedora directory stuff...
<infinity> whiprush: Someone (like you?) really should try to make it a priority at the beginning of a release cycle, so someone else (like me?) might get assigned to work on it. :)
<robitaille> childe: https://launchpad.net/distros/ubuntu/+source/ubuntu-artwork/+bug/35811
<Ubugtu> Malone bug 35811 in ubuntu-artwork "Wastebacket and Battery icon look too similar" [Normal,Confirmed]  
<childe> Thank you so much. Only I think this bug should be marked as critical, not normal.
<childe> Brend: If you have tried xchat-gnome...
<childe> Sorry, wrong channel
* lamont grumbles at libgtk2-perl
<lamont> but at least it's ftbfs everywhere...
<pitti> Good morning
<G0SUB> pitti: hello!
<pitti> Hi G0SUB 
<_ion> Good time of day
<pitti> fabbione: btw, will our ssl-cert changes go to Debian eventually? or is that deemed ubuntu specific?
<fabbione> pitti: -> infinity 
<infinity> pitti: No. it's not ubuntu-specific, and I need to upload ssl-cert to Debian before I can upload the new apache2.
<infinity> pitti: I've just been somewhere between busy and lazy.
<pitti> infinity: oh, it's not urgent for me, I was just curious :)
<pitti> bzr merge does a wonderful job for me
<pitti> Karma:  117884  <- WTH? Yesterday I had some 4000... the last LP update must have changed something...
<Burgundavia> pitti: bug work now earns you more
<infinity> A LOT more.
<Burgundavia> pitti: as does spec work
<pitti> whoa, did they just multiply everything by 100? :)
* pitti doesn't dare to look at seb128's now, to not produce an integer overflow in LP
<infinity> Oh, that's not that high... I wonder if anyone's over a million yet.
<Burgundavia> he is now 4th. mpt has more, with about 1/2 million
<pitti> so, that's not a cockroach any more, but closer to a guinea pig? :)
<pitti> jdub: ping
<Mez> hmm anyone here who wants to answer a question regarding library versioning?
<Mez> basically - if I change backwards compatibility - I should increase the major...
<Mez> and if not the minor
<Mez> but whats the other part for
<dholbach> good morning
<Mez> morning dholbach
<Mez> dholbach- know about best practice for library versioning?
<dholbach> hey Mez
<dholbach> hey seb128
<pitti> hey dholbach, hey seb128 
<dholbach> hey pitti
<dholbach> Mez: what do you mean? versioning as in packaging?
<seb128> hey dholbach pitti
<Mez> dholbach: well with my app - we've renamed a function
<Mez> so we need to bump the version of the so.
<Mez> but I dont know whats the best way to bump it
<Mez> see - most things talk about major and minor 
<Mez> but there's 3 parts of the version
<Mez> x.y.z
<dholbach> Mez: http://www.openismus.com/documents/linux/using_libraries/using_libraries.shtml and http://www.openismus.com/documents/linux/building_libraries/building_libraries.shtml might be good reads
<pitti> ogra: can you please retroactively add CVE-2006-1335 to the gnome-screensaver changelog for 2.14.0-0ubuntu1?
<Treenaks> I'm having kerning problems with my fonts in firefox.. stuff like 'fix' looks distorted, and some other things as well
<infinity> Mez: ABI changes change the minor (and the SOVER), API additions (that don't affect the ABI's compat) bump the minor, bugfixes bump the pachlevel.
<infinity> Mez: In a nutshell, anyway.
<Mez> infinity, well we changed from using keyReleaseEvent to keyPressEvent.
<Mez> (changed the name of a function) b
<Mez> so I have the choice to either add to the soname
<infinity> Mez: Changed the name of the function without providing a wrapper for it?
<seb128> Mez: http://www.gnu.org/software/libtool/manual.html#Libtool-versioning
<infinity> Mez: If you didn't provide a wrapper (for ABI compat), then you're in SOVER bump land.
<Mez> infinity, see - we didnt think of that until now ... but I'm planning on adding a wrapper ;)
<Mez> though that might be not worth it
<Mez> infinity, SOVER = major right ?
<seb128> is anything using your lib?
<Mez> seb128, only stuff within the application itself
<Mez> nothing outside of it
<seb128> you don't have to bother about the SOVER
<infinity> Mez: Traditionally, SOVER is major, yes.  (but not necessarily)
<seb128> you just update libtool versions and it makes the job for you
<infinity> Mez: If it's a static library, then all bets are off.
<Mez> seb128, each plugin is a library that links into the main library
<Mez> infinity, .so and .la :D
<seb128> plugins are not versionned usually
<infinity> Mez: Well, s/static/private/ then for the same results.
<seb128> they are not a shared lib
<infinity> Mez: Shared objects are only truly "shared" if something other than your app will use them.
<Mez> seb128, yet the things they link to in the main app ARE
<Mez> infinity, well - they may :D
<Mez> noone does yet - but we want to let them
<seb128> if that's reserved to the app you don't care
<Mez> seb128, i care when people get compile errors
<lifeless> Mithrandir: killing gss stopped it until I rebooted
<Mez>   /opt/kde3/lib64/libkatapult.so.0: undefined reference to `KatapultDisplay::keyReleaseEvent(QKeyEvent*)'
<seb128> usually the app is in sync with its own source :p
<infinity> seb128: Not if it's KDE...
* infinity coughs.
<seb128> lol
<seb128> right :)
<Mez> seb128, well - people are building external plugins - that arent part of the app "proper" but are seperate packages
<seb128> they should build plugins adapted to the app version
<seb128> changing the soname will not change that fact
<seb128> if the plugin uses a wrong API, soname changed or not it'll not build
<fabbione> Makefile.am:24: BUILD_LINUXDOC does not appear in AM_CONDITIONAL
<Mez> seb128, true ;) but we want people to be able to use old plugins with newer versions
<fabbione> so does anybody remember what provides that to aclocal?
<seb128> Mez: so don't rename a function :p
<infinity> Mez: Then you need to make the library ABI compatible.
<infinity> Mez: Nothing else you can do to "fix" that, really.
<Mez> infinity, i know - which is why i'm adding the wrapper as we speak
<siretart> hi
<Mez> infinity, though now I've done that - I should increase minor - yes?
<Mez> or should I increase major just because I made a release without that wrapper
<seb128> increment the age and the revision numbers if you added a new function
<seb128> hum
<Mez> again though - there has been a release without the wrapper ...
<seb128> you can declare that one was a bug and ignore it :)
<Mez> seb128, lol
<Mez> now I just need to make sure it all compiles nicely and stuff
<Mez> seb128, the age AND revision numbers?
<seb128> you have a new function?
<seb128> increment current,revision,age I think
<seb128> cf http://www.gnu.org/software/libtool/manual.html#Updating-version-info
<seb128> grumpf no
<seb128> increment current and age and set revision to 0
* pitti sighs on the gaping emptyness of http://cdimage.ubuntu.com/daily/current/
<pitti> (daily-live as well)
<seb128> pitti: if you are borred I can give you some patches to review or bugs or stuff to do :p
<pitti> seb128: oh, yes please, give me ALL your gnome bugs!
* pitti hugs seb128 
<seb128> oh, really? :)
* seb128 hugs pitti
<pitti> hi carlos 
<carlos> pitti: hi
<carlos> pitti: don't worry, I had to fix a couple of bugs on imports and I already have some export fixes to do
<Mez> pitti: o_O are you sure of that ? I'm sure there'sa lot
<carlos> pitti: take the time you need
<carlos> pitti: I'm generating daily exports now
<carlos> on the usual URL
<pitti> Mez: ... and what shall I do in the afternoon? :-P
<pitti> carlos: cool
<Mez> pitti: go to the pub?
<pitti> Mez: now, that's a brilliant idea
<Mez> pitti: of course - I always have them
<jdub> pitti: pong
<pitti> jdub: what's the plan wrt. the EOL announcement for warty?
<pitti> jdub: I read sth about that on a ML recently, it should be done soon
<lifeless> Mithrandir: are you still lookin at that gnome-screensaver bug ?
<Mithrandir> lifeless: not as much looking as knowing that it exists.
<Mithrandir> lifeless: gss is ogra-land
<lifeless> Mithrandir: ok. well it still does :)
<dholbach> Diziet: hello! Could we please get a firefox-dbg package? What do you think about it?
<Kagou> hi
<carlos> is there any backport of cyrus22 for breezy?
<dholbach> hey sabdfl
<Kagou> seems that the daily iso build process have failed today 
<seb128> Kagou: we have noticed but thank you :)
<sabdfl> hiya dholbach!
<Kagou> seb128, :) always here to help you
<Kagou> ;)
<seb128> hi sabdfl
<sabdfl> so, the drake is shaping up nicely
* Treenaks still sees new bugs from time to time :(
* dholbach sees new bug reports all the time
<Treenaks> dholbach: new bug reports doesn't mean new bugs :)
<dholbach> Treenaks: i'm perfectly well aware of the difference :-)
<dholbach> Treenaks: 1500-2000 desktop bugs mails per week teach you quite well
<Treenaks> :)
<siretart> infinity: do you still intend to upload a patched l-r-m package (madwifi) or have you already uploaded it?
<Kamion> pitti,Kagou,etc.: fixing the CD breakage now
<sebest--> dholbach: hello, so around 250 new bug repots per day?!
<Lathiat> mails, not necesarily new reports?
<dholbach> seb128: is sebest--'s estimation accurate?
<seb128> dholbach: somebody told yesterday than launchpad gets a bug every 10 min or something like that
<Lathiat> launchpad guys might be able to give us a better idea of new bug nos?
<Lathiat> would be interesting
<Lathiat> so 144/day ?
<Kagou> ok Kamion 
<Lathiat> 1000 a week??
<infinity> siretart: Still intend to, before I head to bed.
<seb128> Lathiat: good math :p
<sebest--> would be nice to have a graph to see the trend
<Burgundavia> seb128: that was my very rough estimate. I suspect it might be less
<siretart> ok
<sebest--> the number of open bugs is growing/shrinking or stable?
<Lathiat> seb128: thanks, need to put high school to work somewhere ;p
<Lathiat> sebest--: i'd bet growing
<Burgundavia> I would got with Lathiat on that
<fabbione> Kamion: i need a UVF exception for util-macros. It's a pkg in universe that is required to bootstrap some drivers from CVS. We forgot to update it from breezy and it is quite important for me now to pull fixes from CVS.
<Kamion> fabbione: mail please with changelog
<fabbione> Kamion: we are going from 0.99 to 1.0.1 and the pkg contain only .m4 definitions
<sebest--> but maybe a lot of these bug report are not valid any more, but people forget to close them when it's solved for them
* Mez taps his foot and waits for keybuk to turn up
<jdub> pitti: it's on silbs announcement agenda - perhaps ask her about it?
<fabbione> Kamion: you have (an extra) mail from me ;)
<Mithrandir> do we support SATA dvd/cd devices?
<ajmitch> Mithrandir: afaik, yes, since quite a few laptops have drives which appear as SATA
<Mithrandir> 'k, thanks
<sladen> Mithrandir: it's weird, even things like the Intelimac have SATA HDD's and PATA optical drives
<Treenaks> sladen: yeah, why would you waste a perfectly good SATA port on slow drives? :)
<Mithrandir> Treenaks: because you want better air flow and/or longer cables?
<ploum> Hello 
<Treenaks> Mithrandir: naaah!
<Treenaks> ploum: Goeiemorgen :)
<Mithrandir> Treenaks: also, most of my machines use one or maybe two of the eight or so SATA ports.
<Treenaks> Mithrandir: None of my machines has SATA ports anymore..
<ogra> pitti, will do, thanks for the heads up 
<ploum> sabdfl: isn't http://daniel.holba.ch/ubuntu/ic/#network-wireless-encrypted and http://librarian.launchpad.net/1818438/nm_sshot.png the same icon ?
<ploum> (I replied in the comment *above* your question I think ;-) )
<ploum> bug #36017
<Ubugtu> Malone bug 36017 in ubuntu-artwork "Network-Manager WEP icon not really useful" [Normal,Unconfirmed]  http://launchpad.net/bugs/36017
<fabbione> ati users the next driver upgrade will bring TONS of fixes
<seb128> ploum: what version of n-m do you use?
<ploum> seb128: the 0.6 test 
<seb128> k
<ploum> https://wiki.ubuntu.com/DapperNetworkManager
<sabdfl> ploum: ah, yes it is. Interesting, because NM has its own vpn icons, but it uses tango for that
<Mithrandir> seb128: did you find out anything more about the xkb-c thing you tested yesterday or can I upload?
<ploum> Indeed, I've seen that on dholbach page (great work this page, really fine !)
<ploum> So it's a tango bug..
<ploum> I will report it upstream
<seb128> Mithrandir: the patch I pointed on the bug fixes some issue according to svu, if you want to ship it with your upload feel free
<Mithrandir> seb128: sure, I can do that, then
<seb128> Mithrandir: remaining issue is an xkbcomp or xorg issue according to him, he's working on it
<Mithrandir> seb128: what do you want me to put in the changelog?
<seb128> Mithrandir: I had that
<seb128>    * symbols/level3, types/pc:
<seb128>      - CVS patch to fix the issue with "compose:ralt" (Ubuntu: #35845)
<sabdfl> ploum: i don't know if its a bug or a feature
<seb128> Mithrandir: maybe changing it by "some issue"
<Mithrandir> seb128: yup, thanks
<sabdfl> i will promote those icons anyway, so we get good ones done.
<sabdfl> ploum: good catch!
<seb128> Mithrandir: or something pointing there is something to fix :)
<seb128> Mithrandir: np, thank you
<ploum> sabdfl: thanks. I will report it upstream and they will close it if it is a feature..
<Kamion> doko: openoffice.org-l10n accepted, sorry for the delay
<Mithrandir> seb128: it's lovely that svu actually uses malone, though
<seb128> yeah, that's nice when upstreams do that
<seb128> there is an xchat-gnome upstream subscribed to the package, he reply on bugs, forwarded them, etc ... really handy :)
<Kamion> pitti: postgresql-client-common accepted
<pitti> Kamion: thank you
<pitti> yay, fresh live isos - another espresso testing time today :)
<jdub> BenC: ping
<jdub> BenC: ping (sata_promise stuff)
<doko> Kamion: thanks. no problem, if it gets onto Flight6 :)
<pvanhoof> hey guys
<pvanhoof> yesterdays kernel upgrade seems to have broken my boot
<pvanhoof> you want me to help you investigate this, or are you guys already aware ?
<Kamion> mjg59: have time to test a stripped-down i386+mac CD in a minute?
<pvanhoof> I managed to boot by booting a live cd and changing the default to 2 in menu.lst
<pvanhoof> which is of course the previous kernel (if you count the recovery kernel)
<ogra> Kamion, no cdimages last night ? 
<pvanhoof> it also looks like grub's ESC menu is broken too
<Kamion> ogra: scroll up
* ogra scrolls up
<pvanhoof> anyway, if you have questions about what might have happened ... let me know, I'll assist you and will launch your funny commands and paste the output
<ogra> Kamion, thanks
<mjg59> Kamion: Should do
<pvanhoof> anyway, I've been trying to boot my dapper since this morning, and this is in messages:
<pvanhoof> Mar 22 17:31:28 localhost exiting on signal 15
<pvanhoof> Mar 23 11:15:04 localhost syslogd 1.4.1#17ubuntu4: restart.
<pvanhoof> so basically .. syslogd didn't yet start
<pvanhoof> it hung at the second line in the boot-splash screen (Mounting the LV /dev/Ubuntu/root)
<pvanhoof> the restart line is this session, my first that actually succeeded (after revering the kernel upgrade)
<Kamion> mjg59: http://people.ubuntu.com/~cjwatson/tmp/dapper-install-i386+mac.iso
<Kamion> mjg59: I've taken out dists and pool so it won't actually do anything useful, but I'd like to know if it boots
<pvanhoof> title           Ubuntu, kernel 2.6.15-19-686
<mjg59> Kamion: Ok
<pvanhoof> is the latest in my menu.lst (the one which I didn't boot for this session)
<mjg59> May take a little while to download
<Kamion> hence taking out dists/ and pool/ :)
<doko> Kamion: the eclipse-pydev sources in NEW are reviewed from my side, don't contain any non buildable/non-free jars anymore.
<Kamion> doko: thanks, accepted
<Seveas> infinity, ping
<mjg59> Kamion: Nope, not recognised as bootable
<mjg59> Kamion: Did I need to burn it with any special options?
<Kamion> ogra: you have updated images now
<Kamion> mjg59: hmph, bugger
<Kamion> no, shouldn't have needed any special options
<Kamion> maybe it just doesn't like the hybridness or something
<Kamion> or maybe I screwed up with -hfs-bless-file
<ogra> Kamion, thanks 
<mjg59> I should check whether the install DVDs are hybrid
<Kamion> could be a byte-swapping issue
<ogra> they'll be oversized anyway i guess :)
<Kamion> ogra: install CDs are, live CDs seem OK
<ogra> yep, which is astoiushing ... :)
<ogra> *astonishing
<mjg59> Kamion: Given a known bootable DVD, is there anything useful I can give you?
<mjg59> Hm. The install DVDs are pure HFS.
<mjg59> Pure hfsplus, that is.
<mjg59> I wonder if that matters...
<mjg59> (the hfsplusness)
<Kamion> yeah, I noticed that
<Kamion> mjg59: I've got a CD image here from mactel-linux.org - I'll start comparing notes
<mjg59> Kamion: Ta
<Kamion> it certainly could be that it only takes HFS+
<Kamion> which would be painfully awkward
<Kamion> I'd have to go for the second ElTorito image approach if that's the case, I think
<mjg59> The source to mfs.hfsplus is available, I believe, but under APSL...
<mjg59> (mkfs)
<Kamion> we have hpformat
<Kamion> er, no we don't
<j^> but udf dvds should work too
<mjg59> Yeah :(
<mjg59> j^: No
<mjg59> The firmware appears to understand HFS and FAT
<Kamion> how can we have hpfsck but not hpformat? bah
<mjg59> Kamion: Hang on, I'll go and check whether I can actually read the CD in the firmware
<mjg59> Kamion: Hm. Seemingly not.
<Kamion> I'll go look up the HFS+ specs and see if I can reconcile them
<Kamion> (with bless, and with mkisofs, and with the mactel-linux CD image)
<Kamion> ah, http://developer.apple.com/technotes/tn/tn1150.html lists a startup file as an HFS+ extension
<Kamion> but it's talking about something different from what bless seems to do ...
<mjg59> Kamion: Ah. I can ls the install DVD from the firmware, but not this CD
<mjg59> Which implies a fair degree of unhappiness
<mjg59> (Wonder if it needs a partition table?)
<Kamion> it should have one, I think
<Kamion> dapper-install-i386+mac.raw1     Apple_partition_map Apple                    2 @ 1       (  1.0k)  Partition map
<Kamion> dapper-install-i386+mac.raw2               Apple_HFS Ubuntu 6.06 i386     30732 @ 16      ( 15.0M)  HFS
<Kamion> although mac-fdisk goes on to witter a great deal
<Kamion> so it could be that stuff is a bit corrupted
<mjg59> Hang on, I'll dump the one from the install disc
<Kamion> Desktop/ubuntu-base-20060306.cdr1     Apple_partition_map Apple                   63 @ 1       ( 31.5k)  Partition map
<Kamion> Desktop/ubuntu-base-20060306.cdr2               Apple_HFS disk image          819120 @ 64      (400.0M)  HFS
<Kamion> Desktop/ubuntu-base-20060306.cdr3              Apple_Free                         16 @ 819184  (  8.0k)  Free space
<Kamion> (mactel-linux)
<infinity> Seveas: Pong?
<mjg59> Kamion: http://ubuntu.pastebin.ca/46694
<Kamion> ok, looks normal enough
<mjg59> Hm. Both the working ones have bigger partition maps.
<mjg59> Wonder why.
<Kamion> 31.5k probably won't fit in the room that hybridisation uses in ISO9660
<Mithrandir> fabbione: do you have an xorg pending?
<Kamion> mjg59: do you have an Ubuntu powerpc ISO lying around?
<Mithrandir> xorg upload, even
<Kamion> mjg59: if so, it would be interesting to know whether you could ls that
<mjg59> Kamion: Hm, good point.
<mjg59> Hang on
<fabbione> Mithrandir: i think so.. i need to check
<fabbione> gimme 2 minutes please
<mjg59> (I have a nasty feeling that the answer is "no")
<mjg59> Hmm. Yes, in fact the answer does appear to be "no"
<mjg59> I can download one, but it'll take a few hours
<mjg59> Kamion: Of course, at this point you're entirely welcome to the imac for a while :)
<Kamion> I have a sick child to take care of today, but I might come over tomorrow if that's possible
<Mithrandir> fabbione: arewethereyet or do you want a patch?
<fabbione> Mithrandir: i have no pending changes.. my last upload was ubuntu22 yesterday
<Mithrandir> fabbione: cool, thanks.
<mjg59> Kamion: Sure
<heno> Mithrandir: any news on the seeding of the accessibility stuff? (did you get my email with package names?)
<Mithrandir> heno: I got the mail, but I have neglected to take any action on it.
<Mithrandir> heno: iirc, Kamion was wondering about festival vs flite
<heno> Mithrandir: so flite is slightly smal;er, but festival is much better technically and sound-quality wise
<heno> and supports multiple languages, fwiw
<mjg59> Kamion: Ok, the OS X disk utility recognises it as partitioned media, and claims that it's HFS extended (journaled)
<mjg59> Which doesn't sound right
<Mithrandir> heno: -> Kamion; can you two battle it out? :-)
<Kamion> the problem is that both of them are too damned huge
<Kamion> libflite1 is 8MB
<heno> Kamion: are we really in a sqeeze for space still?
<Kamion> we can probably fit this lot in, but you're not the only one wanting the space
<heno> Kamion: No, I can imagine
<Kamion> we might have to make it amd64/i386 only (they're much better off for space on the live CD)
<heno> I guess many more languages will have support this time
<Kamion> Mithrandir: incidentally, if you can look at why the powerpc live CD is 60MB bigger than amd64, that would be good ...
<Kamion> heno: s/more/fewer/
<TheMuso> Kamion: Thats probably ok, as most people using the a11y tools are on thoe systems anyway.
<Kamion> stuff has got bigger
<heno> Kamion: that sounds fine
<Mithrandir> Kamion: sure, I can take a look
<Kamion> if we can figure out why powerpc live is so huge, it could go in there
<Kamion> Mithrandir: the squashfs itself is much bigger
<Mithrandir> Kamion: that's.. odd.
<Kamion> Mithrandir: oh, never mind ...
<Kamion> it's because we have many more languages seeded on powerpc ;-)
<Kamion> might as well stay that way, we know we have room for expansion by taking those out
<Kamion> in fact I might add those languages to the other architectures now
<Mithrandir> Kamion: heh, ok. :-)
<Kamion> Mithrandir: can you make a copy of the dapper seeds, add the stuff that heno wants to them, and use germinate on that copy to get a size report? we can then make a decision
<Mithrandir> Kamion: I'll look at that, sure.
<Seveas> infinity, according to the changelog you applied _ion/Pygi's madwifi patch to l-r-m -- it seems not to work though since NM won't recognize my atheros card as WPA capable although the madwifi driver in the l-r-m package from _ion/Pygi does
<infinity> Seveas: Erm, which package from them are you referring to?
<infinity> Seveas: URL?
<Seveas> their l-r-m package -- which is no longer available since the patch is supposed to be in the official l-r-m
<infinity> Seveas: Well, the -18- packages they were distributing were built by me...
<infinity> Seveas: With the same patch...
<Seveas> hmm, odd
<infinity> Seveas: Like, identical.  The only difference between those packages and these are control file changes.
<Seveas> that means I'll have to apt-get source and poke around 
<infinity> (Well, and being built against the -19- kernels)
<Seveas> thanks for the information - I'll get back to you if their really is something wrong
<infinity> Please do.
<infinity> I wanted that patch in the mainline LRM specifically so it could get more widespread testing.
<infinity> (It seems pretty obviously harmless, even if it doesn't work, it can't really hurt anything...)
<Seveas> indeed
<infinity> Seveas: Do you know if the NM 0.6.0 kids are seriously looking at backporting background scanning to madwifi-old?
<infinity> (I suspect it would require too many architectural changes to the code, but maybe it's simpler than that..)
<Seveas> infinity, they are seriously thinking about it but I have serious doubt about the doability of it...
<infinity> Yeah, me too.  It'll still be pretty nice.
<Seveas> indeed
<infinity> Other than support for new devices (which is going to require madwifi-ng in some hacked-up fashion, *sigh*), background scanning is the only complaint about madwifi-old.
<Seveas> madwifi-ng is on serious crack
<Seveas> I have serious doubts about it being in a good enough shape for dapper soon
<Mithrandir> heno: you just want the packages onto the live cd, right?
<infinity> It's starting to look like a much better codebase, technically, but it's got a long way to go to shake the bugs out that come from a major code reorg.
<infinity> Seveas: It'll never be in good enough shape for dapper, but for some new devices, we have no choice.  We ship a half-broken driver, or no driver.  \o/
<Kamion> mjg59: can you put an 'od -Ax -tx1 -N65536' of your working install DVD somewhere for me?
<Seveas> infinity, go us :/
<heno> Mithrandir: yes, but it would be good if they would then also get installed
<sladen> fabbione: I'm going to do an upload of mesa for the i945GM if you're blocking
<Kamion> Mithrandir: it's a lot easier to have them in the desktop seed
<sladen> fabbione: ...*not* blocking
<heno> Mithrandir: otherwise we cannot really claim an accessible install procedure
<DVSoftware> hello
* heno agrees with Kamion
<mjg59> Kamion: http://www.codon.org.uk/~mjg59/tmp/macosx_dump
<DVSoftware> hello
<Kamion> although it does kind of bloat up the installation rather a lot for people who don't need it, so I don't know
<infinity> Riddell: Around?
<DVSoftware> i got one question, and i hope someone is willing to help me
<Kamion> perhaps it should go only in the live seed and we should make espresso keep it installed only if you specify the relevant a11y options
<DVSoftware> it's regarding ubuntu's hardware detection method on livecd
<TheMuso> Kamion: Is that trivial?
<Kamion> TheMuso: relatively, yes
<Kamion> it would then go in the ship seed too so that the regular install CD can install it
<heno> Kamion: in that case that seems ideal
<DVSoftware> actally, i'm developing my custom livedvd for learning and demonstration purposes filled with all kind of software
<heno> cool!
<Kamion> DVSoftware: the hardware detection on the live CD is pretty much just the same as that in the regular system
<Kamion> i.e. udev
<DVSoftware> and i need some help with hardware autodetection
<DVSoftware> mostly graphics card
<infinity> Riddell: kdenetwork is FTBFS on all arches (despite having at one point built on a few of them) with the following:
<heno> Kamion: Could it be installed directly during the install procedure (in Experft mode, say)?
<infinity> dh_install -pktalkd  
<infinity> cp: cannot stat `./debian/tmp/etc/kde3/ktalkdrc': No such file or directory
<infinity> dh_install: command returned error code 256
<Kamion> heno: on the install CD, sure
<infinity> Riddell: ^^^^
<infinity> Riddell: Pls fix, kthxbye.
<sladen> DVSoftware: if you find anything that doesn't work, please file bugs with the PCI IDs and drivers that didn't work
<Kamion> heno: I see no reason for it to be expert-mode-specific; we could key off the a11y boot options in gfxboot
<DVSoftware> sladen: no, everything is alright with ubuntu
<DVSoftware> that's the reason i come here
<DVSoftware> :)
<heno> Kamion: even better :)
<Kamion> we basically just do dpkg-reconfigure -fnoninteractive xserver-xorg in the live filesystem
<Kamion> DVSoftware: ^--
<DVSoftware> hmmmm
<DVSoftware> what that command do exactly?
* heno forgot that the install CD now uses gfxboot
<Kamion> 'apt-get source casper' for more details
<Kamion> DVSoftware: tells X to reconfigure itself for the current system
<DVSoftware> ehm.....
<Kamion> using its debconf maintainer scripts
<DVSoftware> but how it tells it to X... when i try to use X's autodetection it fails
<DVSoftware> problem is that my livedvd is not debian based :(
<Kamion> it's not X's native autodetection, it's the Debian/Ubuntu maintainer scripts
<Kamion> DVSoftware: oh, we can't help you then
<DVSoftware> hmmmm
<sladen> DVSoftware: X's install scripts use discover1 to select the driver and then build a xorg.conf based on that
<Kamion> the graphics card detection on our live CDs is intrinsically based on using the Debian/Ubuntu maintainer scripts, which are a couple of thousand lines of code
<Riddell> infinity: ok, thanks
<DVSoftware> can you point me to that script so i can (hopefuly) customize it for my needs?
<Kamion> sladen: but if it's not Debian-based he won't have our discover1/discover1-data patches
<fabbione> sladen: is that to add the support for it?
<Kamion> DVSoftware: apt-get source xserver-xorg, see debian/xserver-xorg.*
<sladen> DVSoftware: apt-get source xserver-xorg
<Kamion> er, 'apt-get source xorg' on breezy
<Kamion> but it's really too much to ask to help you reimplement it from scratch, I think
<pitti> fabbione: did you see my msg wrt. git-core's main inclusion report from the other day?
<sladen> fabbione: yes, it's about a 10 line delta, aliasing i945GM to the i945G code-path in most places
<fabbione> sladen: ok.. go ahead
<Kamion> it's not a standalone script and relies on a lot of our infrastructure
<fabbione> pitti: no i think i missed it?
<DVSoftware> Kamion: i'm not going to reimplement it from scratch :)
<TheMuso> Mithrandir: I should have a majorly trimmed down accessibility startup script for casper some time later tomorrow my time, as I will be finalizing the move of most package-specific settings into the packages themselves.
<Kamion> DVSoftware: trying to customise it on a non-Debian-based system would be nearly equivalent
<Mithrandir> TheMuso: excellent.
<Kamion> you can try if you like, but expect it to be a good deal of hard work
<pitti> fabbione: https://wiki.ubuntu.com/MainInclusionReportGitCore -> it needs a security update before I'll approve it
<sivang> hi all
<sivang> do I need something special to be able to build kernel modules from source other then linux-source ?
<fabbione> pitti: ok.. works for me
<pitti> fabbione: http://lwn.net/Articles/169623/, btw
<sivang> (trying to build cisco vpn client which needs to build CiscoVPN kernel module)
<fabbione> sivang: you only need the headers
<Aegir> sivang, Make sure you have gcc-3.4 and the kernel headers, that's about it, really. Do an export GCC=gcc-3.4 before compiling, and your set. Atleast that's the method working for me.
<fabbione> pitti: ahahha "please practice safe merge ;-)."
<sivang> fabbione: k, thanks. weird thing, the cisco installer tries to run 'modules' target from the include/linux tree, and can't find this target and fails.
<fabbione> pitti: ok.. is the new source already in debian?
<Kamion> mjg59: interesting that they've stopped doing the HFS wrapper thing; according to http://developer.apple.com/technotes/tn/tn1150.html#HFSWrapper "Apple software currently initializes all HFS Plus volumes with an HFS wrapper"
<sivang> Aegir: thanks, why 3.4 specifically ?
<Kamion> mjg59: so I suspect that they've just ripped plain HFS support out of the firmware - sigh
<pitti> fabbione: save merge> :)
<infinity> sivang: Because in breezy, that's what we built the kernel with.  If you're running dapper, his advice is stale, we use gcc-4.0 :)
<pitti> fabbione: I think so, we can just sync if mdz approves the new version
<pitti> fabbione: 1.1.4->1.1.5 is safe, no idea about 1.1.3->1.1.4
<Kamion> mjg59: which means either we need to add format support to hfsplus (APSL isn't free enough for main, right? wrong?), or we need to add an -hfsplus option to mkisofs, or both
<fabbione> pitti: usually git is safe.. tons of eyes on it
<sivang> infinity: cool, I'm using dapper then :)
<pitti> fabbione: as long as our kernel maintainers use 1.1.5, I had no objection anyway, since it's just for them :)
<sivang> infinity: linux-kernel-headers is a meta package against the haders suitable for the current running kernel for me?
<infinity> sivang: No, linux-kernel-headers are for userspace.
<Aegir> infinity, It's gcc-4 now? Oh goody, I've been using 3.4 for kernels for a while now... Woops...
<infinity> sivang: You want linux-headers-`uname -r`
<sivang> infinity: k, thanks.
<Aegir> Sorry for the bogus advice then folks
<Kamion> hppa's still on 3.4, I think - but you probably don't care
<infinity> Yeah, it is.
<sivang> hmm, it can't find a kernel headers suitable for me kernel
<sivang> (2.6.15-17-386)
* sivang dist-upgrades
<Seveas> infinity, hmm, in linux/wireless.h: #define WIRELESS_EXT 17 
<Seveas> that may very well explain the lack of WPA support in NM (needs 18/19)
<Seveas> odd that it worked before...
<sivang> infinity: any idea why we seem not to have the headers of 2.6.15-17-386 
<sivang> ?
<Mithrandir> -17 is obsolete
<infinity> sivang: Because you're severl kernel versions behind, and that's gone from the archive?
<Mithrandir> -19 is the newest
<infinity> Seveas: Hrm, but madwifi (both old and ng) don't support WEXT 18/19, afaik...
<infinity> Seveas: And I certainly never changed that define in the previous builds.
<infinity> Seveas: Does rebuilding LRM with that one define changes make the world different for you?
<Seveas> infinity, no, but NM checks that #define before even attempting WPA iirc
<infinity> s/changes/changed/
<Seveas> which makes it all really weird
<Seveas> anyway, I'll have to get my facts straight here
<infinity> Seveas: I expect that if that IS true, we're going to have to patch NM to skip that check on ath_pci, cause I refuse to fake the WEXT version in the driver.
<infinity> Seveas: That way lies madness will all sorts of other tools.
<Seveas> indeed
<Seveas> but I'm trying to dig some more into this horrible mess
<Mithrandir> seb128: 35845 ; what's you initial keyboard setup?  It works fine for me.
<doko> Kamion: please remove the swt-gtk source, now built from the eclipse package
<azeem> did the changelog links on packages.u.o stopped to get updated at some point?  Most of the ones I tried are 404 and only older ones are available
<infinity> azeem: They haven't worked for ages.  After clicking on one, do s/packages/changelogs/ in the URL bar.
<azeem> infinity: oh, thanks
<infinity> azeem: changelogs.ubuntu.com is a service we control, packages.ubuntu.com is provided by djpig, so we have no control over its brokenness.
<azeem> I thought so
<infinity> azeem: If you could ask him so s/packages/changelogs/ in his HTML generation code, though.. :)
<azeem> infinity: I hope I remember next time I'll see him
<sivang> Mithrandir, infinity : yes, thanks, I'm upgrading now
<ogra> infinity, azeem, they only have changelogs for the stable release ... (always had) 
<ogra> changelogs.ubuntu.com is what you look for ;)
* jdub links JaneW's soup on the fridge.
<mvo> does anyone mind if I do a ubuntu-meta upload now? Kamion, is that ok with you?
<infinity> mvo: I have no objections.  I have a bunch of seed changes/tweaks to commit, but they're all in supported, so won't affect -meta anyway.
<JaneW> jdub: :)
<ogra> mvo, any changes that require a edubuntu-meta update ?
<mvo> ogra: some fonts from me ... not sure if you take those too (they take ~1,5mb space)
<ogra> mvo, then not :)
* ogra doesnt have 1.5MB
<ogra> oh, btw
<mvo> ogra: lovely thai and lao gylphs
<ogra> seb128, do you mind if i do a gdm upload with the added edubuntu-artwork dependency ? 
<j^> hm, the volume keys on my X30 now also trigger a software volume change of Master. they are hardware volume keys.
<ogra> mvo, suuure ... but amd64 and ppc are ~9MB oversized :)
<ogra> no chance for 1.5MB :/
<Mithrandir> Kamion: would you mind if I did ran cron.daily on little?
<sladen> j^: yes.  Now, forgetting that you happen to know that ;-)  Does it do what you expect?
<j^> no
<j^> mute does not work
<sladen> j^: pressing hardware-mute and then unmuting from the software mixer does not sync it back.  correct, that is the one corner case
<j^> i never change Master volume, only PCM, changing Master volume i get distortion
<j^> sladen right the mute key is in a corner case since its on the right side :)
<sladen> j^: disortion while changing it?  disortition at/near 100% on most laptops is normal.  about 90% tends to work out best
<sladen> j^: :)
<j^> sladen anything above ~80% is bad, fixing Master at ~75% and changing PCM from 0-100 sound is ok
<Mithrandir> Kamion: also, installing the stuff heno asked about on the live cd seems to need 46.9MB (unpacked), according to apt.
<sladen> j^: one thing can you check for me;  when you press volume-up, is the jump the same amount as volume-down?
<desrt> j^; i don't suppose you're talking about powerbooks?
<Mithrandir> seb128: 13:49 < Mithrandir> seb128: 35845 ; what's you initial keyboard setup?  It works fine for me.
<sladen> j^: here I'm now seeing that volume moves it about 1/3rd as much as volume-down (bigger steps)
<Mithrandir> s/you/your/, obviously.
<Mithrandir> sladen: bug 35080 ; do you have any suggestions on how to fix it too?
<Ubugtu> Malone bug 35080 in xkeyboard-config "Numlock key doesn't work on IBM t42" [Major,Confirmed]  http://launchpad.net/bugs/35080
<j^> sladen down is bigger, up is 1/3rd
<j^> desrt no about thinkpads
<infinity> Do we still need/want gst-plugins0.8 in main?
<infinity> seb128: ^^^
<desrt> sound gets really bad on the PB too above like 80% vol on either master or pcm
<j^> sladen the mute button works, but the icon that is shown is not mute, other than that seams ok
<infinity> seb128: Oh, nevermind, it's not in main.  soyuz bug (which Celso has fixed, but not in production yet)
<infinity> seb128: Ignore me. :)
<sladen> j^: it sould the same icon, but without the o/~ musical notes coming out of it
<sladen> Mithrandir: disable Shift-NumLock => Pointer_EnableKeys by default in all key-maps?
<j^> sladen a right, its confusing that it still shows the volume bar at the bottom
<Mithrandir> sladen: how will people enable Pointer_EnableKeys then?
<j^> sladen something like a striked out speaker would be better.
<sladen> heno: does Accessibility Support have a way to enable Pointer Mouse Emulation on the Numerica Pad?
<heno> sladen: that's standard in gnome
<sladen> j^: can you file a wish-list against  gnome-settings-daemon
<Mithrandir> heno: from the keyboard?  How?
<sladen> heno: so would dropping the  shift-numlock  to turn on pointer-emulation be bad/good/ugly
<heno> Mithrandir: Cleverly hidden Under System -> Pref -> Keyboard -> Accessibilty -> Mouse
<Mithrandir> heno: and you're going to enable that how if you can't use a mouse? :-)
<Mithrandir> heno: or is that a silly question to ask?
<heno> Mithrandir: no, I think the whole way these things are managed should be reworked
<heno> It should be collected in one place
<heno> I've been thinking of making a SoC project of it
<Mithrandir> is SoC going to exist this year too?
<sladen> Mithrandir: thing is.  If we do an xmodmap fix just for ThinkPads, mouse-emulation would be disabled on an external keyboard anyway
<heno> You would be able to enable it with the keyboard if key navigation workeed everywhere
<Mithrandir> sladen: yes, which sucks.  I would at least think some people use it.
<sladen> Mithrandir: or some Evilness at the input layer so that on_numlock, send shift-up, numlock down, numlock up, shift-down
<heno> On the live CD we should be good because we enable sticky keys with F4-option 4
<heno> otherwise you cannot get to the application or system menu
<heno> (Alt-F1)
<mhz> TheMuso: ping
<sladen> Mithrandir: to me, the shift-numlock => mapping by default is wrong as it's an X policy decision;  nobody's keyboard has little blue writing that says 'mouse emulation'
<heno> sladen: because it's not a very common use case
<heno> but important if you need it
<Mithrandir> sladen: no Norwegian keyboards have the m marked in a way that suggests that  should come when you press lvl3 shift + m either.  Should X stop doing that?
<heno> sladen: so does this conflict with input methods?
<Kamion> doko: swt-gtk removed
<sladen> Mithrandir: bah your ee keyboard
<Kamion> mvo: seed changes> go ahead
<Kamion> mvo: (er, ubuntu-meta upload, I mean)
<Kamion> Mithrandir: feel free to run cron.daily
<Mithrandir> Kamion: already done. :-P
<Kamion> Mithrandir: 46.9MB> how about .deb size? that's more important
<heno> sladen: normally these features would be enabled by pressing NumLock five times in a row for mouse keys
<Mithrandir> Kamion: 10.8
<sladen> heno: if people expect it to work, I guess it would
<Kamion> 10.8 is just about doable
<heno> and Shift 5 times for StickyKeys
<Kamion> what is the figure with flite?
<Mithrandir> Kamion: (what apt-get install wants to download, which is sensible)
<sladen> heno: the five times thing I'd expect from having hit it so many times on windows
<heno> that should notmally not get in other people's way
<Kamion> Mithrandir: that's why I suggested germinate, which will let you get a definite figure
<Mithrandir> Kamion: well, germinate didn't want to play with me, so I reverted to the ways I know.
<Mithrandir> uh, flite is bigger?
<Kamion> really? huh, go figure
<Mithrandir> something's pulling in festival too
<Mithrandir> festival vs flite is 7.1 vs 8.3
<DVSoftware> i got discover1 running, now i need to look at the script
<sladen> Mithrandir/heno: oooh, if you go into System->Settings->Keyboard->Accessibility->Mouse  and then press  Shift-Scrlock, it nicely toggles the mouse-keys
<Mithrandir> sladen: which you can't do if you can't use a mouse.
<heno> Mithrandir: you can if sticky keys are truned on already
<heno> I would still like the Applicaton menu be be available with the Windows/Apple key though
<heno> You can navigate to those menus with the keyboard
<heno> you just cannot start the menu opening
<heno> if at leadt one of those features isn't already on
<heno> On Windows it's not a problem because the Windows key will take you to the Control panel where you can switch on the rest
<heno> all with one finger
<sladen> Mithrandir: the other option is to remap numlock to Something Completely Different in hotkey-setup on ThinkPads
<seb128> Mithrandir: re
<Mithrandir> sladen: I guess I'll punt it to upstream.
<sladen> heno: you could put in for Ctrl-Esc too, that's the windows key-stroke that I would expect to work (it might even work on OS X too)
<heno> sladen: you should try this https://wiki.ubuntu.com/HandsFreeEmailing if you haven't already
<Mithrandir> seb128: hiya
<seb128> Mithrandir: $ setxkbmap -rules xorg -layout us -model pc105 -option '' -option 'compose:ralt' -option 'grp:alts_toggle' -print | xkbcomp - :0.0
<seb128> Mithrandir: does that work for you?
<sladen> Mithrandir: there isn't a solution as the bug is in the thinkpad hardware---they never expected shift-numlock to ever be used, so it wasn't something that was considered
<heno> sladen: how does that help if you cannot press ctrl and esc at once?
<Mithrandir> seb128: hm, no.
<seb128> Mithrandir: that's the bug :p
<sladen> heno: it helps in other cases (no mouse, but I happen to expect it to work)
<seb128> Mithrandir: but if you -print it, use xkbcomp -xkb and use the xkb it works fine
<Mithrandir> seb128: so it's not an xkeyboard-config bug, as you noted in the bug.  Ack.
<seb128> Mithrandir: the xkeyboard-config part is fixed by the patch from the bug
<seb128> Mithrandir: there is xkbcomp or xorg issue still
<Mithrandir> heno: are you allowed to use your foot instead?
<Mithrandir> (for the hands-free emailing)
<pitti> Mithrandir: hmm, espresso still crashes after keyboard layout selection on ppc on today's live CD
<Mithrandir> pitti: is espresso-kbd-chooser or espresso-keyboard-selector on the cd?
<pitti> Mithrandir: did the live image not yet catch the latest kbd-chooser version? or is the bug not yet fixed?
<heno> Mithrandir: sure, cheating is alowed :)
<heno> I think using just your feet will give a realistic impression of the issues
<pitti> Mithrandir: kbd-chooser
<heno> Mithrandir: let's say just one foot :)
<Mithrandir> pitti: hmm, can you put the backtrace somewhere?
<heno> The point is to try and think a bit about it
<Mithrandir> heno: I believe using multiple feet on the mouse might be counter-productive.
<pitti> Mithrandir: you mean s/selector/setup/?
<Mithrandir> pitti: indeed.  and espresso-kbd-chooser is correct.
<pitti> Mithrandir: sure, I can file a bug with ESPRESSO_DEBUG=1, will that suffice?
<Mithrandir> pitti: if you have the time, I would prefer to have you help me track it down.
<pitti> Mithrandir: I have to go in 20 minutes, but I'm fine to take the time for that
<Mithrandir> pitti: if you have the backtrace from /v/l/i/espresso, that'd be a good start.
<heno> Mithrandir: true, but multiple feet on the keyboard can be useful
<pitti> Mithrandir: it's a python exception: DebconfError: (10, "kbd-chooser/do_select doesn't exist")
<pitti> Mithrandir: yep, second
<Mithrandir> heno: true.
<siretart> doko: re bug 12471 which you just closed
<Ubugtu> Malone bug 12471 in subversion "missing javahl library" [Normal,Fix released]  http://launchpad.net/bugs/12471
<Mithrandir> pitti: hmm, ok, I'll take a look at that.
<siretart> doko: the bug is that this binary package libsvn-javahl is built in debian, but not in ubuntu
<siretart> doko: the buildlog says this: dpkg-genchanges: warning: package libsvn-javahl in control file but not in files list
<pitti> Mithrandir: http://people.ubuntu.com/~pitti/tmp/espresso
<pitti> Mithrandir: let me know if you need a more verbose log
* heno once rode in a car driven by someone using a joystick with his foot (in traffic). Interesting ride.
<pitti> wow
<Mithrandir> pitti: uh, that's really, really weird, given that it's shipped in the deb
<Mithrandir> pitti: does grep do_select /var/lib/dpkg/info/espresso-kbd-chooser.templates
<Mithrandir> give you something sensible?
<pitti> Mithrandir: I guess so; Template:, Type: and Description: look sensible
<doko> siretart: ok, I'll look
<Mithrandir> pitti: does it exist in /var/cache/debconf/templates.dat and /var/cache/debconf/config.dat ?
<pitti> Mithrandir: not in /var/cache/debconf/templates.dat
<pitti> Mithrandir: neither in config.dat
<Seveas> doko, dennis@mirage:~$ echo $PATH
<Seveas>  /bin:/usr/bin
<Seveas> aargghh 
<Mithrandir> Seveas: what does grep PATH /etc/environment say?
<Mithrandir> pitti: can you try apt-get --reinstall install espresso-kbd-chooser and tell me if it says "Extracting templates from packages"?
<pitti> Mithrandir: 'kbd-chooser/do_select' vs. 'debian-installer/kbd-chooser/title' is correct?
<Mithrandir> pitti: as in, whether it should exist in both namespaces?  Yes, that's right
<pitti> Mithrandir: no sign of extracting templates with reinstall
<Mithrandir> oh, it only prints that if you install 30 debs or more.
<pitti> mvo: is there some debug option? ^
<Mithrandir> pitti: can you strace -f -e execve it and see if it calls apt-extracttemplates ?
<Mithrandir> pitti: it's debconf, not apt.
<mvo> pitti: for what?
<pitti> mvo: whether debconf extracts templates from adeb
<Mithrandir> pitti: it's all controlled from debconf using apt hooks.
<sladen> heno: press control-five times, then press escape?  :)
<mvo> pitti: sorry, I don't know.
<pitti> Mithrandir: yep, execve /usr/bin/apt-extracttemplates is called and succeeds
<pitti> Mithrandir: it's called with 35 vars though, so I can't see all of them
<Mithrandir> pitti: -s 512 ?
<seb128> is "gettext" on the CD?
<pitti> Mithrandir: no, that doesn't help
<seb128> do we have an easy way to know what is on the CD or not? :)
<pitti> FWIW, pacakge 'gettext' is not in the live session - does it have to?
<ogra> seb128, grep the manifest ? 
<seb128> pitti: pygtk upstream asking
<seb128> ogra: what is "the manifest"?
<pitti> ah, sorry, I thought it was related to Tollef's question
<ogra> seb128, err, it was called mainfest earlier i think, look at the .list files in the cdimage folders
<Seveas> Mithrandir, nothing
<pitti> Mithrandir: I'll try with -v
<seb128> ogra: k, thank you
<Mithrandir> pitti: it seems like I need to make espresso-kbd-chooser depend on debconf to have it extract the templates.
<Mithrandir> Seveas: uh, is this a clean dapper install, or?
<Seveas> not exactly
<j^> would be nice if Ubugtu would know whats on the CD
<infinity> So, uhh, doing "bzr push" over sftp is a stupid idea, isn't it?
<Mithrandir> infinity: no, just a slow one.
<pitti> Mithrandir: I have the full execve() call here now, do you need it?
<mvo> infinity: well, it seems to be a bit slow
<Mithrandir> pitti: not really, no, I found the bug.
<pitti> Mithrandir: cool, you rock :)
<infinity> mvo: Yeah, I'm doing it for all 4 seed branches right now.  I think I may pass out before it finishes.
<pitti> Mithrandir: any workaround for me to try here?
<ogra> infinity, depends ... if you want to do your dishes between two pushes, its very helpful 
<infinity> Yeah, well, I had this silly idea that if I was only pushing a single commit, it might be fast.
<Seveas> Mithrandir, in my fresh dapper install a few weeks ago it wasn't in that file either. I added a path myself, which I removed yesterday. After that my path was normal except for not including /sbin:/usr/sbin
<infinity> Ha ha ha ha.
<Mithrandir> pitti: debconf-loadtemplate debian-installer /var/lib/dpkg/info/espresso-kbd-chooser.templates
<Mithrandir> Seveas: it _should_ be in /etc/environment, though.
<pitti> Mithrandir: debconf-loadtemplate doesn't exist here
<Mithrandir> infinity: if you're pushing to something where only you have write access, use rsync
<Mithrandir> pitti: install debconf-utils
<infinity> Mithrandir: I'm not, I'm pushing to the main seed branches.  Which was dumb, in retrospect.
<infinity> Mithrandir: For LP code, I push with rsync, then do all my merging on chinstrap, which seems much saner.
<pitti> Mithrandir: cool, thanks
<Seveas> Mithrandir, ok, riddle me this: in a VC my path is different than the one I get in gnome...
<siretart> _ion: ping
<Mithrandir> Seveas: compiled-in defaults.  Shouldn't be if you do the supported thing and just set PATH in /etc/environment
<Seveas> ok
<Mithrandir> infinity: yeah, sounds saner.
<Seveas> i'm 100% sure though that it wasn't there right after install (flight 4), but tha could be solved already
<pitti> Mithrandir: heh, now I see the keyboard window for 2 seconds, then it automatically advances to the next screen :)
<Mithrandir> pitti: heh, ok.  I think I should try this on a live install myself.
<Mithrandir> pitti: this isn't ppc specific.
<Mithrandir> (I hope)
<pitti> it so much doesn't sound arch specific...
<pitti> but it just worked on amd64 for me
<Mithrandir> hmm
<Mithrandir> I'll see if I can reproduce it.
<sladen> seb128: if you've been following above, what do you think of a   -option "mousekeys:shiftnumlock"   in all cases that it's not a thinkpad?
<Treenaks> Whoa! ubuntu-announce isn't moderated?!
<dholbach> Treenaks: it is
<seb128> sladen: I don't know enough of xkb stuff to have an option on that, dunno what the option does in fact :p
<Treenaks> dholbach: then why did I get that mail from Simon Jardine?
<Treenaks> dholbach: which obviously isn't ubuntu-announce material
<dholbach> Treenaks: there was one spam message which accidentally slipped through jdub's hands
<dholbach> Treenaks: and he excused himself for that already
* Treenaks gets the pitchforks & torches
<Treenaks> oh
* Treenaks drops the pitchforks again
<sladen> seb128: the option doesn't exist at the moment.  I would add one
<Mithrandir> sladen: I don't think we want to have that.
* Mithrandir does today's second Korean installation
<Kamion> Mithrandir: I bet you just forgot to add a postinst to espresso-kbd-chooser
<Mithrandir> Kamion: indeed, it doesn't have a postinst.
<Kamion> Mithrandir: you need a postinst that just does . /usr/share/debconf/confmodule, or else debconf won't load up the templates
<Kamion> it's related to the hacky way that debconf hooks into package installation
<Kamion> you do need to depend on debconf as well, certainly
<Kamion> and yeah, it's not arch-specific, I can reproduce it here
<Kamion> Mithrandir: want me to fix it now?
<Mithrandir> Kamion: if you'd like to, please.  I'm in the middle of testing that korean actually works so kinda occupied.
<Kamion> will do
<Kamion> Mithrandir: can I remove some of the big pile of debugging code?
<Mithrandir> Kamion: please do.
<Kamion> or do you still want it in there?
<maswan> BenC, mjg59: coordinate. :)
<Mithrandir> Kamion: no, I tend to just add it when I need it, then forget to remove it afterwards. :-/
<dholbach> Diziet: Hello... what do you think about building a firefox-dbg binary package?
<slomo> fabbione: thanks for updating the ati driver :) fixes all the problems i had including the ppc 24bit display problems
<dholbach> slomo: seems like we can set a lot of bugs needinfo :)
* Treenaks needs to test that driver as well
<Treenaks> it might well save me from having to poke Radeon registers :)
<slomo> dholbach: probably :)
* hunger uses the ati driver and still has his display freeze occassionally.
<Treenaks> hunger: did you update today?
<dholbach> slomo: or to fix-released-please-reopen-if-things-are-still-b0rked
<hunger> Treenaks: Yeap, even restarted X after reading the changelog of the ati driver:-)
<glatzor> Chipzz: mvo: hi
<dholbach> Diziet: i had the idea, when i had to rebuild firefox again, because yelp explodes on amd64 (http://daniel.holba.ch/ubuntu/yelp.bt)
<hunger> Treenaks: I suspect it is the kernel starving some task or another... Desktop switching freezes for secounds, but the IRC window is still updated.
<glatzor> mvo: Chipzz: I think that because many people mistake the "add" dialog for the "edit" dialog, doesn't make the "add" dialogs to a good "edit" dialog. The separation between both dialogs should be ratherer made clearer.
<glatzor> shoudl be rather made clearer
<ogra> dholbach, just remove the ff dependency :P
<ogra> the i could switch edubuntu to epiphany if you remove that dep as well ... :/#
<dholbach> ogra: narf!
<glatzor> Chipzz: mvo: I don't know how deep ui changes should be made at this time. If we want to fix this issue, I would vote for the design, that I have suggested on the ubuntu-desktop list some time ago.
<ogra> whats the reason everything depends on firefox now ... its very annoying ...
<sladen> fscking slowkeys pop-under brokeness
<glatzor> Chipzz: mvo: I could port the corresponding changes to the dapper branch at the weekend.
<sladen> heno: slow-keys requires a mouse to raise and activate the dialogue, do you know of that bug already?
<infinity> ogra: Because everything uses the firefox renderer?
<dholbach> ogra: they embed firefox
<infinity> ogra: epiphany is kinda useless without firefox embedded.
<ogra> infinity, yes, but it was better when we had libnspr ... 
<seb128> we still have libsnpr
<dholbach> libnspr is only the tiniest part
<ogra> i didnt need to kepp firefox and 100MB of translations around 
<Chipzz> hrrrm, lemme catch up
<ogra> seb128, yes, but we dont build epy against it ...
<heno> sladen: how does that require a mouse more than anything else (I just did it without)
<ogra> we discussed switching edubuntu to epy, but thats a no go if i still need ff on the CD ... then the switch is pretty pointless
<seb128> ogra: 
<seb128> $ ldd /usr/bin/epiphany | grep nspr
<seb128>         libnspr4.so => /usr/lib/libnspr4.so (0xb7ea7000)
<seb128> we do
<Chipzz> glatzor: I think changing the UI too much would not be a good thing at this point
<Chipzz> glatzor: my patch just reuses the existing UI, and is small and contained
<seb128> ogra: but that's not enough to get randering, epiphany uses gtkmozembed
<ogra> hmm, then i dont understand the principle of nspr
<heno> One problem with gnome though is that you cannot tab backwards (shift-tab)
<Chipzz> glatzor: http://chipzz.studentenweb.org/um.patch
<ogra> i thought that was the gecko engine
<dholbach> ok guys, I'm off
<Kamion> Kinnison: hmm. I think the "Step N of M" could do with being moved down a bit so that it's at the same level as the cancel/back/forward buttons
<ogra> dholbach, enjoy the weather :)
<seb128> ogra: no, gtkmozembed is the gecko stuff
<heno> I guess that's a bug. what should I file it under
<dholbach> merci
<ogra> seb128, ah ...
<Kamion> (have only just actually seen it)
<seb128> ogra: apt-cache show libnspr4
<Chipzz> glatzor: it is by no means finished though
<seb128> ogra: it doesn't do any rendering, just communication stuff
<ogra> seb128, so if we have everything in external libs, what for do we need ff in there ? 
<ogra> ah, k
<seb128> ogra: because firefox does the rendering
<ogra> yep, understood now ...
<glatzor> Chipzz:  I am amware of the prototype nature of your path.
<seb128> ogra: we will probably switch to xulrunned next cycle though
<ogra> cool
<seb128> xulrunner
<glatzor> Chipzz: But your path also is a change in the UI. So I ask myself why not to fix the whole situation
<ogra> i'd really love to be edubuntu the guinea pig for 100% epiphany
<ogra> and drop the huuge firefox ...
<Chipzz> glatzor: becaus my path, as it reuses existing code, is much more tested
<Chipzz> glatzor: and it's not *really* a UI change
<Chipzz> glatzor: big UI changes would probably not be accepted at this point anyway
<glatzor> I would suggest to merge the "add" and "add custom" dialog, skip the the components from the "add" dialog at all.
<infinity> ogra: xulrunner still won't be TINY (though smaller than firefox)... Keep in mind that firefox's original goal was to be a "less bloated mozilla" :)
<jdub> and it is indeed a less bloated mozilla
<infinity> Much so, yes.
<danimo> BenC: ping?
* jsgotangco seconds epi for edubuntu
<ogra> infinity, i dont care... i care about the translations that eat my space, not about the 8MB ff binary :)
<jdub> it just depends on how you define the completely meaningless word "bloat"
<glatzor> Chipzz: I would not call this a big change. And of course your path includes definitely a change of the UI
<Chipzz> glatzor: the idea, as I discussed it with mvo, is to make it easier to add components to existing channels, without being to invasive, for dapper, and then do a major UI overhaul for dapper+1
<BenC> danimo: pong
<jsgotangco> yelp depends on ff though right?
<seb128> hate hate hate firefox translations system
<ogra> yeah 
<ogra> seb128++++++++++
<seb128> jsgotangco: as everything else needing gtkmozembed atm
<jsgotangco> gee
<jdub> jsgotangco: could be switched to xulrunner
<ogra> jsgotangco, it could use xulrunner as well at some point
<danimo> BenC: hi, can I annoy you with some intel HDA driver fun?
<seb128> I expect switch for next cycle
<glatzor> Chipzz: on the underlaying code side we could use your math fenction. I don't want to include the whole child/parent stuff that I propsed earlier on ubuntu-devel, too.
<seb128> Debian has switched for GNOME
<danimo> BenC: your last changes in -19 broke them for me, in that I can no longer hear any sound
<glatzor> match function
<ogra> yay ...
<danimo> BenC: I want to debug it as far as I can, I just need a point to start from
<ogra> sad we didnt already ...
<jsgotangco> hmmm
<BenC> danimo: I believe those are fixed in current git
<glatzor> Chipzz: my concern is that we mix up the two dialogs even more.
<Chipzz> glatzor: that function needs changing anyway; it doesn't recognize deb-src channels atm
<jsgotangco> ogra: epi default in edubuntu is not possible though for now right?
<danimo> BenC: when will you create updated packages?
<ogra> jsgotangco, we dont gain *anything* by it now
<jsgotangco> gee
<danimo> BenC: I appended my whinings to 35098
<ogra> my only target is to free up CD space at this point :)
<Chipzz> glatzor: but that would involve changing SourceEntryTemplate to have a types field instead of the type field
<glatzor> Chipzz: you would also have to add a new option to change the channel type binary/source to the add dialog
<Chipzz> glatzor: one sec
<Chipzz> glatzor: will put my discussion with mvo online in a bit
<danimo> BenC: not really related, but audio jack sensing didn't work for me either up to -18, and now I can't really test
<jdub> BenC: what are the chances of pulling in an updated sata_promise driver?
<ogra> if the edubuntu cookbook gets ready for dapper we need a lot of extra space i dont know where toi take yet
<jdub> BenC: or a patch for a particular card to support
<glatzor> Chipzz: ok
<jsgotangco> ogra: release a dvd heh
<jdub> BenC: http://lwn.net/Articles/176208/ (search for TX4300)
<ogra> jsgotangco, we *have* a DVD for edubuntu 
<ogra> :)
<jsgotangco> release disc 2
* jsgotangco hides
<ogra> its just not our main media
<ogra> we'll be fine once i replaced kdeedu with gnome apps ...
<ogra> but thats dapper+1 :+
<ogra> :)
<jsgotangco> yuo're not doing that now
<ogra> nope
<ogra> no big changes for dapper applies to edubuntu as well :)
<ogra> i want a new app selection for dapper+1 ... without kdelibs and their unbelivable huge translation packages
<ogra> (either that or a separate language CD)
<Chipzz> glatzor: http://chipzz.studentenweb.org/mvo-um
<seb128> mvo, doko: https://launchpad.net/distros/ubuntu/+source/fontconfig/+bug/35472
<Ubugtu> Malone bug 35472 in fontconfig "Propose to set default font to Bitstream Vera instead of DejaVu" [Normal,Unconfirmed]  
<BenC> jdub: I'll look into it
<jdub> BenC: thanks!
<glatzor> Chipzz: why do you want to extend the template by type?
<glatzor> Chipzz: the type could be used from selected
<glatzor> Chipzz: do you want to show the type combo/radio in the add dialog, too?
<danimo> BenC: what git branch are you looking at?
<danimo> (talking about alsa)
<BenC> danimo: I'm looking at the ubuntu-2.6 git
<danimo> BenC: oh, ok, I didn't know ubuntu was using git, too
<danimo> BenC: where is it?
<BenC> danimo: https://wiki.ubuntu.com/KernelGitGuide
<danimo> tnx
<glatzor> Chipzz: another problem that I see are mirrors.
* netjoined: irc.freenode.net -> brown.freenode.net
<glatzor> So since we are hackish people we could  use "if uri in 'ubuntu.com/ubuntu'" instead of the baseuri of the template
<glatzor> that would be fine for dapper
<Chipzz> glatzor: just try the patch; it works for deb repo's, but not for deb-src repo's (the templates only include deb as type)
<Chipzz> the idea is to not extend the UI at all wrt deb/deb-src
<Chipzz> glatzor: mirrors are a problem in the current UI anyway
<glatzor> Chipzz: changing the mirror is not supported, but I would not call this a problem
<glatzor> Chipzz: the mirrors are/should be detected in the sources treeview
<Chipzz> glatzor: yes, but that is not a regression in my patch ;)
<jdub> http://lwn.net/Articles/176825/
<jdub> ^ ha ha ha
<glatzor> Chipzz: oh, you pathed against your installed python files?
<Chipzz> yes
<Chipzz> I can put a fixed patch online too if you want
<Chipzz> lemme do that
<glatzor> it is "patch -p4 < /home/dapper/Desktop/um.patch", right?
<glatzor> no. it worked so, too
<Chipzz> glatzor: just reget the patch ;)
<Chipzz> ah ok
<Keybuk> ya know, I think I finally understand what WPA does/is now
<jdub> Keybuk: kitten-strangling device?
<sladen> Keybuk: "broken"?
<rcaskey_> any thoughts on straightening out RestrictedFormatsAssistant, RestrictedFormatsOnDemandAssistant, Restricted Formats Solutions, Restricted Formats Solutions, and EasyCodecInstallat?
<Kinnison> Kamion: do you want me to move it, or will you?
<j^> Keybuk what did you think it is before?
<Keybuk> j^: I had no idea
<Keybuk> "scary evil kitten-strangling device"
<Keybuk> now I think it's a garrotte for kittens
<glatzor> Chipzz: I was worong. Thought that you used the templates of the info file. The mirrors are not an issue. 
<Chipzz> glatzor: if you can get your branch in, all the better, but I dunnow if its finnished, and I doubt it would egt in anyway
<Chipzz> and basically the situation as it is now sucks
<Chipzz> so as a little pollish for dapper, I think my patch would be the best (short term, ie dapper) solution
<Chipzz> we've been with the current UI for several releases; doing big changes at this point would not be a good idea I guess
<Chipzz> like I said to mvo:
<glatzor> Chipzz: doing something wrong for monthes doesn't make it right. take a look at malone, how many people mistae the add and edit dialog
<glatzor> mistake
<doko> seb128: ENOCLUE ... I thought that jdub did change fontconfig again to default to Bitstream?
<Chipzz> 14:21 <Chipzz> the point of the patch is to make it very easy to enable multiverse etc
<Chipzz> 14:21 <Chipzz> which is something a lot of users will want to do
<Chipzz> 14:22 <Chipzz> and I think it would be a significant improvement to make that easier and more polished
<Kamion> Kinnison: I won't have time until tomorrow or so, so if you're not too busy, please do
<glatzor> Chipzz: and as I said before, I don't see the support for getting my branch in. There was only one reply on this topic.
<Kinnison> Kamion: I'll do it now then, I can take a break from g-p-m for a bit
* Kamion is attempting to fix the keyboard chooser, which isn't being driven quite right
<seb128> doko: no such upload according to my dapper-changes mailbox
<Chipzz> glatzor: so if your branch can't get in, can'ty we use my patch as a solution for dapper and get your branch in for dapper+1?
<glatzor> Chipzz: I also see the need. I justed waited if my branch would be accepted. 
<pips1_> Kamion, ping
<Chipzz> glatzor: I'm not even sure if my patch will be accepted ;)
<Kinnison> Kamion: where exactly do you mean by "by the buttons" ?
<danimo> BenC: indeed. great stuff
<doko> mvo: I did hear you are the new font specialist?
<danimo> BenC: seem like the issues with dell laptops are fixed
<Kamion> Kinnison: there are "Cancel", "Back", and "Forward" buttons at the bottom of the screen
<Kamion> Kinnison: the breadcrumbs should be vertically aligned with those
<BenC> danimo: great, thanks for checking it
<pips1_> Kamion,  found a wierd localisation bug: the installer ask me if I want to download language support - this question is in english, rather than german, like all the dialog questions before... I downloaded the debian-installer language file (po) from launchpad, but I could find those english strings in the po file at all...
<Kamion> Kinnison: they're in hbuttonbox5 right now
<danimo> BenC: well, I'd still have to compile the kernel myself to actually test it
<Chipzz> glatzor: maybe we should wait for mvo to join the discussion ;)
<Kamion> pips1_: I have to go out just now, but will you still be around in about 45 minutes or so? I can talk with you about it then
<pips1_> ok
<danimo> BenC: is there an instruction how to build ubuntu packages from the source?
<glatzor> seb128: hi. at the moment it is not possible to add "universe" or other components in the softwareproperties by a single click. furthermore many people mix up the "add" and "edit" dialog.
<Kinnison> Kamion: so top-right of the text aligned near the top left of the left-hand button?
<Kamion> Kinnison: no, it should be at the left of that box, probably yalign=0.5 in it
<seb128> glatzor: hey. Better to ping mvo about that :)
<BenC> danimo: fakeroot debian/rules binary-debs flavours=686
<danimo> ok
<BenC> change 686 to whatever you actually need
<BenC> debs will end up in debian/build/
<Kinnison> Kamion: so, same horizontal position as before, vertically aligned center-to-center with the buttons?
<Kamion> Kinnison: so like this:
<Kamion> +-----------------------------------------------------+
<Kamion> + Step 1 of 7               | Cancel | Back | Forward |
<Kamion> +-----------------------------------------------------+
<danimo> BenC: 686 is alright
<Kamion> Kinnison: yeah
<Kinnison> Kamion: okay, it'll need a good shuffle around because of the possibility of pictures
<Kinnison> Kamion: I'll get on it right away
<Kamion> thanks
<glatzor> Chipzz: the add functions is a problem. if you change the channel in the edit dialog, a new channel entry will be generated by the add dialog
<glatzor> Chipzz: how do you want to handle this exception?
<mdke> scary stuff: opening a bookmark from my gnome places menu opens konqueror
<ogra> thats the new ubuntu/kubuntu migration ...
<ogra> wait until edubuntu joined in and tuxpaint opens for jpegs ;)
<mdke> kde is taking over huh?
<Chipzz> glatzor: hrrrm need to take a look at that
<ogra> (multibuntu)
<glatzor> Chipzz: the mirrors are an issue: the edit dialog can only add "new" components of the default archive and doesn't respect the mirrors used
<glatzor> Chipzz: this issue will be very drastic fo cdrom users disabling and reenabling a component
<glatzor> I thinkt that this approach is too much a kind of a hack.
<glatzor> Chipzz: I hope that novice users will use gnome-app-install to install new apps, so they won't see the s-p at all
<Kinnison> Kamion: pushed, take a peek
<Keybuk> dholbach: ping
<Chipzz> glatzor: anyway, I'm working atm, will look at it later
<danimo> BenC: bad luck, compilation fails in the hda directory. investigating
<danimo> BenC: sound/pci/hda/patch_analog.o fails to build
<danimo> BenC: sound/pci/hda/patch_analog.c:630: error: syntax error before 'ad1986a_laptop_eapd_mixers'
<BenC> ok
<danimo> BenC: my C knowledge is a bit rusty, plus I don't know alsa too well. would be great if you had a look
<BenC> I will, thanks
<mjg59> BenC: That bcm compile fix looks bogus
<mjg59> It's supposed to be checking the revision of the phy, not the core
<danimo> BenC: just ping me by the time you sorted things out, and I will git pull the update
<danimo> BenC: being without sound sucks ;)
<mjg59> BenC: Probably ought to be bcm43xx_current_phy(bcm)->rev == 8
<BenC> mjg59: I didn't see any other references to the same thing
<mjg59> BenC: No, there aren't any
<mjg59> Hm. Let me just recheck that to make sure.
<mjg59> BenC: Nope, definitely supposed to be checking the phy revision, not the core revision
<BenC> ok, changed
<mjg59> Thanks
<mjg59> BenC: dce0ca36f2ae348f005735e9acd400d2c0954421 - it seems to have got 945 support in the same diff 
<mjg59> (It's labelled as the powernow-k8 fix)
<BenC> weird, goof on my part then
<Kamion> Kinnison: much better, thanks! merging and pushing
<dholbach> Keybuk: pong
<Keybuk> dholbach: on Palm Pilots
<Keybuk> does my comment make sense?
<dholbach> Keybuk: didn't read it yet - which bug number was that (just if you have it)
<dholbach> got it
<Keybuk> basically I'm suggesting that instead of having the current system
<Keybuk> the ideal UI is pretty much Serpentine/SJ on CD writers
<Keybuk> use HAL to look for USB-connected pilots
<Keybuk> then give them a drop-down like:
<Keybuk> Device: [ Palm Pilot 9000 on USB           ] 
<Keybuk>         : Palm Pilot 8200 on USB           :
<Keybuk>         : Pilot plugged into Serial Port 1 :
<Keybuk>         : Pilot plugged into Serial Port 2 :
<Keybuk> where the first two were "detected" automatically, and the other two just hard-code /dev/ttyS0, /dev/ttyS1 for stuff we can't detect
<Keybuk> that way we don't need /dev/pilot, and I can get rid of it
<dholbach> hrmmmmm, since upstream is not very active, this is the "ideal" case
<Keybuk> (I'm likely to get rid of /dev/pilot anyway, as it doesn't work)
<Kinnison> Kamion: you're welcome
<Kinnison> Kamion: anything else I can do for you UI-wise?
<Kamion> Kinnison: pretty much anything in the "braindump from UI sprint" section of UbuntuExpress/ToDo is fair game
<Kamion> some of those should be reasonably accessible, some are harder - should be fairly obvious which, I think
<Kinnison> Kamion: I'd like to get this g-p-m upload finished since I've been working on it for nearly four days (with interruptions :-)
<Kinnison> Kamion: once I've got this done, I'll go look at the ToDo
<dholbach> thanks Keybuk, i just thought we might apply some udev magic and make palm devices happy again
<Kamion> Kinnison: sure, fortunately I'm actually beginning to run out of HYPER-URGENT things
<Keybuk> dholbach: sadly there is no udev magic
<Keybuk> ignoring not-on-USB pilots for a moment, which don't get the symlink
<Keybuk> it seems that USB pilots contain two serial port interfaces
<Keybuk> only one of which is useful for gnome-pilot
<Kamion> from a functionality point of view, the timezone->country->locale logic, apt-setup, and network configuration are the missing pieces I know of
<dholbach> Keybuk: ok, thanks
<Keybuk> because of the way these things work, the events for each serial port device get processed by a separate udevd process
<Keybuk> so without having some kind of "BIG UDEV LOCK" there's no way to provide "enumeration" of them
<Keybuk> (which is why we can't just have /dev/pilot, /dev/pilot1, etc.)
<Keybuk> and helpfully, there's no difference in identification between the two interfaces
<Keybuk> they're just both identified as a serial interface
<Keybuk> so there's nothing we can put in the udev rule to select the right one
<Keybuk> and even better, it's usually the second one
<Keybuk> so we could just do "only make the symlink for odd-numbered interfaces"
<Keybuk> but that obviously breaks if you have a USB serial converter plugged in first <g>
<Keybuk> as then the pilot would have ttyUSB1 and ttyUSB2
<Keybuk> the icing on the cake is that old pilots have just one serial interface
<Keybuk> *breathe*
<Keybuk> so yeah, that's why /dev/pilot is broken, and why I don't think it can be fixed
<Keybuk> (it's also why /dev/cdrom, /dev/dvd, etc. are broken if you have multiple drives)
<dholbach> poor palm users :/
<Keybuk> and I'm more inclined to suggest the software is fixed in the first place
<mjg59> The applications should just be fixed to try all available pilot devices
<mjg59> Palms have names, IIRC
<Keybuk> mjg59: not only do palms have names, but they have unique vendor and device ids for each model
<Keybuk> so the software could even intelligently offer features if it bothered to use HAL
<mjg59> Never mind. I'm sure opensync will make everything ok.
<xhaker> if there was a "we need a hero" song, it would suit this exact moment
<mjg59> http://gregdek.livejournal.com/4008.html is cool
<xhaker> mjg59: i don't find it cool, except the ubuntu love in the comments
<xhaker> mjg59: you mean that or the OIN?
<mjg59> The OIN stuff
<mjg59> It'll be interesting to see what else they're willing to go for
<xhaker> somehow, i feel they're playing the "silly-patent-game", but yeah.. aslong as they protect
<Keybuk> until we (the Dental community) play the silly patent game, and excel at it, we can't expect to influence the rules
<xhaker> Keybuk: cool laying down of things. I guess it's the option we have. Ohh, Sony is part of OIN :S
<dholbach> hum, how can I tell gdb to write output to a file?
<xhaker> redirect it? gdb .... > file.. sorry if this sounds silly, not used to console debugging
<Keybuk> which kind of output?
<Keybuk> output of the process?
<dholbach> backtrace
<Keybuk> output of debugging session?
<Keybuk> set logging file FILENAME
<dholbach> i tried to feed it something like    --command="/usr/share/bug-buddy/gdb-cmd"
<dholbach> ahhhh
<Keybuk> set logging on too
<Keybuk> (my favourite gdb trick for debugging curses apps is setting the process output to a different tty :p)
<Chipzz> Keybuk: how do you do that?
<Keybuk> tty TTYNAME
<Keybuk> oddly enough
<dholbach> Keybuk: thanks a lot
<Keybuk> handiest with screen
<Chipzz> Keybuk: or with dual head ;)
<Keybuk> indeed
<Chipzz> ie 'tty /dev/tty2' in gdb?
<Keybuk> yup
<Keybuk> with screen it's handiest because you can create a shell-less tty
<xhaker> Keybuk: what if you set logging filename to /dev/tty2 ?
<Keybuk> xhaker: that works too -- except then you can't interact with gdb *and* your debugged app
<xhaker> Keybuk: thanks
<Keybuk> (assuming curses)
<Keybuk> if not curses, then logging to another tty is quite acceptable
<danimo> BenC: I think I can see what went wrong
* xhaker bbl
<danimo> BenC: first of all, there's a "struct" missing in line 630, that one was easy
<Keybuk> meh, I have too many "Personal Projects" to start, and too little time or motivation for any of them
<danimo> BenC: but that doesn't seem to be everything
<sladen> kinnison/mdz: Can I have a UVF for powernowd (0.96 in Ubuntu, 0.97 in Debian) to fix power-saving on SMP systems (eg. all the new dual cores)
<danimo> BenC: ah_ *t_* vs *.t:630
<Kamion> sladen: send mail to me/mdz
<Kamion> er, me+mdz
<Kamion> with changelog
<danimo> oh, strike the struct, just reverse the _t mistake :)
<BenC> danimo: s/t_new/new_t/
<danimo> BenC: yes, exactly
<danimo> BenC: I just realized that the struct is superflous because the definition was turned into a typedef
<danimo> BenC: compiles now, please apply the change
<BenC> done, pushing
<danimo> tnx
<BenC> thanks for tracking it down
<danimo> no problem
<danimo> BenC: it's just funny to see how upstream likes to mess with datastructures just inbetween minor releases
<danimo> that said, their new way of doing it is of course cleaner
<danimo> <- is a C++ whimp anyway
<marseillai> hi! i've report this bug https://launchpad.net/distros/ubuntu/+source/network-manager/+bug/36086 and i want to know if i can do something more to help ...........
<Ubugtu> Malone bug 36086 in network-manager "network manager can't activate eth1 interface" [Normal,Unconfirmed]  
<Kamion> pips1: sorry, forgot to get back to you earlier
<Kamion> pips1: which installer - the traditional text-mode installer on the install CD?
<ogra> Kamion, edubuntu
<ogra> the traditional one ...
<Seveas> marseillai, just wait for a developer to spot your bug and place a reaction...
<Kamion> pips1: OK, this is my fault - I forgot to include pkgsel in the list of packages I included in the merged debian-installer translation files
<Kamion> pips1: I'll get that corrected straight away. Thanks for the heads-up!
<marseillai> oki Seveas thanks
<pips1> Kamion, ah, ok, cheers
<mdke> is it known that OOo writer crashes whenever you scroll with the mouse or sidebar?
<giftnudel> mdke: not for me
<mdke> hrph
<mdke> it's hard to remember not to scroll
<giftnudel> what do you do? just scroll?
<ogra> get a bigger display ? 
<Burgwork> mdke, there is a bug filed
<mdke> lol
<mdke> Burgwork, ah good
<mdke> got the number handy?
<Burgwork> just a sec
<mdke> i'll search, np
<Burgwork> https://launchpad.net/distros/ubuntu/+source/openoffice.org/+bug/36121
<Ubugtu> Malone bug 36121 in openoffice.org "crashes on more than one page" [Normal,Needs info]  
<Diziet> dholbach: ping
<dholbach> Diziet: pong
<Diziet> dholbach: You were asking for a firefox-dbg package.
<dholbach> yes
<dholbach> It'd make the world a happier place.
<Diziet> There are basically two ways of doing that that aren't mad.
<Diziet> Firstly, make the existing build system build everything twice.
<Diziet> Secondly, make a script which transforms a firefox source package into a firefox-dbg source package.
<dholbach> what about   dh_strip --dbg-package=firefox-dbg  ?
<Diziet> Neither of these are very nice :-).
<Diziet> To debug it properly you want to compile it with -O0.
<Diziet> And against debug/static versions of the other libs.
<Diziet> But I could do the --dbg-package thing fairly easily I suppose.
<dholbach> I'm not quite sure I understand the technicalities behind that, but wouldn't be the dh_strip-version a good first step? before building a noopt version?
<Diziet> Right.
<Diziet> (Is --dbg-package new ?  I remember us talking about this kind of thing in Docklands.  I didn't realise it had been put into debhelper.)
<dholbach> I can't remember it not being there, but that doesn't say anything :))))))
<mdke> thanks Burgwork 
<Diziet> Well, thanks for pointing it out :-).
<Kamion> Diziet: older than the Docklands sprint, but relatively new
<Burgwork> mdke, np
<Kamion> hmm, October 2003. shows what my notion of "relatively new" is I guess ...
<Diziet> :-)
<dholbach> Kamion: that's why I can't remember a state of the world without it ;-)
<danimo> BenC: works now as advertised
<BenC> nice
<dholbach> Diziet: thanks for looking into it
<danimo> BenC: incl. audio jack sensing
<Diziet> Anyone here have an ia64 box ?
* bddebian wishes
<dholbach> bddebian: it's nice if your heating is broken :)
<Diziet> OK, failing that, I'll get the admins to install it on halley for me.
<bddebian> dholbach: :-)
<slomo> infinity, Keybuk: what's that? two uploads with the same version and different changes? ;) which one will be used now? (initramfs-tools)
<Kamion> that would be ... a Soyuz bug!
<Keybuk> slomo: We  Soyuz!
<Keybuk>  _  ___           _              _
<Keybuk> | |/ (_)_ _  _ _ (_)___ ___ _ _ | |
<Keybuk> | ' <| | ' \| ' \| (_-</ _ \ ' \|_|
<Keybuk> |_|\_\_|_||_|_||_|_/__/\___/_||_(_)
<Kamion> in fact, it's bug 31038
<Ubugtu> Malone bug 31038 in launchpad-upload-and-queue "two accept messages for different udev 079-0ubuntu9 uploads" [Normal,Unconfirmed]  http://launchpad.net/bugs/31038
<Keybuk> (bet that doesn't trigger his notify)
* Kinnison spanks keybuk
<dholbach> hahahaha
<infinity> Wow, where do I get hilight-on-figlet technology for my IRC client?
* ogra holds his ears
<Kinnison> infinity: hire a lackey to watch channels for you and tell you when someone figlets
<Treenaks> http://www.audiorelief.co.uk/shop/product_info.php?products_id=31
<Kinnison> Keybuk: known bug, blahblahblah, probably the latter, no way to know until the archive cycles mumblemumblemumble, sorry
<ogra> Treenaks, thanks
* ogra orders
<Keybuk> Kinnison: heh
<infinity> Kinnison: S'ok, there was apparently an ubuntu27 uploaded shortly after the clashing ubuntu26s, so we know what will win this time. :)
* Treenaks goes away to try the 'ati' X driver with all the pwetty bugfixes
<Keybuk> infinity: I'm not sure we do actually know that <g>
* infinity decides to upload a few ubuntu27s for fun.
<infinity> Keybuk: Yours just hit -changes...
* Kinnison shrugs. If you guys go and break the archive, just remember that cprov is on a plane
* infinity puzzles over the changelog.
<infinity> Keybuk: You did the same thing... Twice? :)
<infinity> Keybuk: Oh, 26 was doing prereqs...
<Keybuk> right, 26 I modified the lvm and md scripts in the package
<Keybuk> which I realised meant initramfs-tools had to depend on udev again
<Keybuk> because of the PREREQ bug
<Keybuk> so I decided it was time to purge them
<infinity> Heh.
<Keybuk> thus 27, which moved the scripts to the right packages and dropped them (and a boatload of deps) from initramfs-tools
<infinity> Keybuk: Want to send me the -27 .dsc and .diff.gz, so I can do -28 and upload it before the archive cycle?
<Keybuk> infinity: I already did
<Keybuk> infinity: see #ubuntu-kernel
<Keybuk> (and it's a .tar.gz, because initramfs-tools is native, no? :p)
<infinity> Ah, rock.
<infinity> Err, yeah.  tar, diff, whatever.
<infinity> Brain not all here.
<infinity> Been up for 22 hours or so.
<Keybuk> Kamion: may have just come across a bug caused by the installer not recognising certain ethernet/wifi cards
<Kamion> Keybuk: similarly, I trust you've checked which of your two libnjb uploads actually hit the archive?
<Kamion> Keybuk: any idea why?
<Keybuk> Kamion: I didn't think we'd hit a daily cycle since then yet
* ogra glares at his inbox
<ogra> Von: 	Doug <899sergio@fcta.com>
<ogra> An: 	daniel.holbach@ubuntu.com
<ogra> Betreff: 	Hello, new job for you
<ogra> Datum: 	Thu, 23 Mar 2006 14:56:19 +0300  (12:56 CET)
<ogra> Mailer: 	Microsoft Office Outlook, Build 11.0.5510
<Keybuk> Kamion: not sure yet; need some details.
<Kamion> Keybuk: we certainly have, that was hours ago
<ogra> dholbach, hey, i'm getting your spam !
<dholbach> tssssss
<dholbach> ogra: what will my new job be like?
<ogra> but if you want to channel several billions from a african bank through your account i can forward it ;)
<ogra> Requirements:
<ogra> - basic knowledge of computer (email),
<ogra> - free time (approx 1 hour per day),
<ogra> - good communication skills
<ogra> :)
<ogra> - bank account to withdraw/receive funds,
<ogra> - ability to cash money orders and certified checks (only for USA, UK and DE),
<ogra> *giggle*
<dholbach> ogra: :)
<Keybuk> Kamion: the bug seems a little strange
<Keybuk> the user had an /etc/iftab line that caused udev to hang, because they had two devices that matched the rule
<Keybuk> I thought I'd explicitly checked for that in netcfg
<Keybuk> Kamion: is there a way I can get the user to run that bit of netcfg from an installed system?
<Kamion> no, sorry
<mjg59> I note that nobody is subscribed nvidia-glx bugs by default...
* ogra scratches head about the text of bug 36296
<Ubugtu> Malone bug 36296 in gnome-power-manager "Problem with the systray and gnome-power-manager" [Normal,Unconfirmed]  http://launchpad.net/bugs/36296
<ogra> somehow it stops making sense to me very precisely in the middle ...
<infinity> mjg59: I thought I got all LRM bugs..?
<mjg59> infinity: Hm. I just assigned something to nvidia-glx, but it didn't seem to add you
<Pygi> infinity: seems that new patched L-R-M don't work??
<infinity> Meh, oh well.  I can't actually FIX nvidia-glx bugs anyway. :)
<mjg59> infinity: Some time, we should really get in touch with nvidia and "suggest" that we get a direct route to their development people
<infinity> Pygi: That's what Seveas was saying... But it's the exact same patch I applied when I built the other packages for you, so I'm at a loss.
<Pygi> infinity: perhaps something in kernel makes it stop workin'? :-/
<infinity> Pygi: It's concievable.
<infinity> We'll have to look deeper when it's not 6am. :)
<Keybuk> nvidia-glx scares me
<Pygi> infinity: k, great ... please ping me once you have time, ok ? ^_^
<Keybuk> mostly because I have to use it, because the default X drivers won't even detect my gfx card
<mjg59> (Rather than nvidia responding to my bug reports with a job offer)
<KaiL> uhm,. who (re)added xscreensaver to ubuntu-desktop? ;)
* infinity grumbles at the libmysqlclient15 ABI change upstream.
<mjg59> ogra: I /think/ it means "When I boot on battery, the systray icon doesn't appear"
<ogra> KaiL, nobody
<KaiL> ogra, at least ubuntu-desktop depends on both, gnome-screensaver (running) and xscreensaver
<ogra> mjg59, yeah, it was the combination with the next sentence that totally confused me
<infinity> KaiL: No it doesn't...
<KaiL> uh, wait..
<ogra> KaiL, that would be news to me
<Keybuk> KaiL: doesn't here
<KaiL> it's only the data - sorry :)
<Keybuk> are you sure you're not getting confused by the fact it depends on the xscreensaver *hacks*, not the daemon itself
<Amaranth> mjg59: They offered you a job? :)
<ogra> unless mvo secretly added it today ;)
<mjg59> Amaranth: They sent me an email titled "Resume", but meant "Resum"
<Burgwork> mjg59, ogra I think that is my rant on g-p-m on hiding the icon when battery is full and plugged in
<infinity> mdz: ping
<mjg59> Burgwork: No
<sivang> mjg59: joining canonical ? :)
<Kamion> janimo: hmm, can you do the same libxml-perl -> libxml-parser-perl change to xfmedia, if possible?
<mjg59> Burgwork: And that's an option in the preferences
<mjg59> sivang: Nope
<Kamion> sivang: 18:54 < mjg59> (Rather than nvidia responding to my bug reports with a job offer)
<ogra> Burgwork, "To see it, you have to plug and unplug your ubuntu box to the sector." 
<janimo> Kamion,sure
<Kamion> ta
<ogra> Burgwork, did you write that ? 
<sivang> Kamion: :-)
<sivang> mjg59: wow! 
<Burgwork> ogra, umm. I spaek Engrish beetter than that
<Keybuk> mjg59: did you give them the same "I'd rather create an army of fruit flies to do my bidding than work for you" speech?
<ogra> Burgwork, right ...
<mjg59> Keybuk: Not quite...
<Kamion> sivang: not to run mjg59 down or anything, but it's not too uncommon - I've had job offers from two companies I've worked with on Ubuntu stuff since joining Canonical
<Keybuk> Kamion: and how many of those were search engines? :p
<Kamion> *cough*
<mjg59> Haha
<Kamion> (that would be one)
* Kinnison ponders some food before the meeting
<mjg59> Google were attempting to hire the entire world at LCA
<Keybuk> again?
<Keybuk> they were trying to do that in Canberra too
<mjg59> There were four of them there this year
<Treenaks> Guess they're doing it everywhere then
<mjg59> They bought beer for everyone at the conference one evening
<mjg59> All night
<Kamion> mjg59: jesus
<mjg59> Only worked out at about 4000NZD, so...
<Kamion> so thruppence or so?
<Amaranth> o_O
<Amaranth> dude, i need to go to these conferences
<Amaranth> free beer from google!
<mjg59> I think I managed free beer every night
<Treenaks> Amaranth: in exchange for your most intimate details for them to search through :P
<mjg59> And a helicopter ride
<Keybuk> siretart: ping
<Amaranth> that's why you do things for people throughout the year, so everyone owns you a beer
<Treenaks> mjg59: Yeah but you're kind of a well-know guy...
<sivang> Kamion: Well, that's because you guys are of this caliber :)
<mjg59> Kamion: Pretty much
<sivang> Kamion: what were you working with nvidia on regarding ubuntu? 
<mjg59> So, uh, who moderates ubuntu-announce?
<Treenaks> jdub
<infinity> Okay, can someone tell me why the world is trying to hax0r my sshd all of a sudden?
<dholbach> Treenaks: i realized what you meant an hour ago... sorry :)
<dholbach> Treenaks: i mean the other spam mail 1-2-3 weeks ago
<dholbach> s/other//
<Treenaks> dholbach: oh :)
<Pygi> infinity: bah, probably some random scripts....
<Kamion> sivang: I wasn't; nvidia never offered me a job
<KaiL> hmm, shouldn't gnome-screensaver allow at least a _few_ configurations for the screensaver? ;)
<Kamion> mjg59: apparently jdub on not remotely enough coffee, repeatedly
<mjg59> sivang: Me? I just sent them a couple of bug reports...
<infinity> Pygi: Oh, I'm sure hitting /my/ IP is random, but it's usually not random when I hear no activity for weeks, then thousands of attempts in a day.
<sivang> mjg59, Kamion : okay, sorry for the noise, going back to my hacking now :)
<Pygi> infinity: just make sure you change the port to some "not normal", for example 1022 or somethin'
<infinity> Pygi: <shrug>.. I'm just firewalling it off completely for now.
<Pygi> infinity: ah, changing port makes it good enough...
<sivang> Kamion: hmm, acutally thinking of it one search engine does have a branhc over ireland somewhere :)
<Kamion> sivang: that would be more useful if I lived in Ireland though ...
<Keybuk> Kamion: pcmciautils missing dep on lsb-base
<Keybuk> not that I guess it's necessary these days ... given an Essential package depends on it
<Keybuk> but still
<Kamion> not really, given that it has compatibility code for the installer
<Kamion> I can put the dependency in if you *really* want, but it's a bit false
<Keybuk> right
<Keybuk> I just noticed it because I was looking for whatever versioned-dep we need this week :p
<Keybuk> and I picked on that because it was reasonably recent and I trusted you to get it right <g>
<Kamion> if it needs a versioned dep, I can add that with more justification, I guess
<Keybuk> you use log_action_begin_msg which was added in 3.0-6 or wherever
<Kamion> oh, heh, that's quite different in Debian, I guess Per rearranged that
<Kamion> yeah, 3.0-6, will add the dep
<Riddell> Kamion: how come the powerpc live CD has a bunch of extra language packs the other arches don't?
<ogra> Riddell, look at your seeds :)
<pitti> Riddell: the seeds support per-arch selection
<Riddell> ogra: that's what I'm querying
<Kamion> Riddell: because at one point that made sense for size reasons
<pitti> Riddell: when we released breezy, we just filled all CDs up to the rim
<Kamion> it probably doesn't any more
<ogra> i reverted it for edubuntu, made ppc behave way more sane
<pitti> Riddell: I have a script which calculates kubuntu and ubuntu cumulative size for language packs, which can be used to figure out the seeds
<pitti> in case you need it
<pitti> (it also respects our 'priority' langauges)
<ogra> pitti, i'd be intrested ...
<Riddell> I'm also wondering why Bengali seems to be a priority langauge, do we have a lot of Bengali speaking users I don't know about?
<Kamion> it's by count of speakers
<pitti> ogra: http://people.ubuntu.com/~pitti/bzr/langpack-o-matic/langpacksize
<ogra> pitti, TA !
<Keybuk> pitti: when you're done with libnl, https://wiki.ubuntu.com/MainInclusionReportWpaSupplicant
<pitti> oh, sorry for dragging that, will do now
<pitti> Keybuk: you are fine with wpa-supplicant's quality? last time I tried it it just fell apart
<Diziet> Gah, debugging the `clean' target in the firefox build system is really unpleasant.  Everything takes aaaages.
<Kamion> Riddell: according to ethnologue there are about 70 million Bengali speakers, which is roughly on a par with German
<Kamion> although actually the d-i languages.xml file has a different figure, it says 189 million
<Kamion> I'm inclined to trust d-i on this, I know a lot of work has gone into that file
<pitti> ISTR that it were way more, too
<Riddell> wikipaedia says 196 million native,
<pitti> Kamion: but it probably depends on the source
<Keybuk> pitti: meh, I don't *like* it ... but it's a dependency of n-m 0.6
<Kamion> German is at 101 million, for comparison
<Kamion> pitti: that's a "corrected" figure
<Keybuk> and it does work better than xsupplicant in my experience
<pitti> Keybuk: can't tell, neither worked for me at debconf 5 :)
<Riddell> Keybuk: what's the status of n-m 0.6?
<pitti> Keybuk: they broke differently
<Keybuk> wpasupplicant was the one that worked for me at debconf
<KaiL_> Riddell, afaik nobody really know, how many they are..
<janimo> wikipedia says 270 millionranked as the 4th most spoken
<Kamion> and the number of native English speakers is listed at around 309 million
<Keybuk> and with NM providing the configuration, it has worked perfectly here today in all my testing
<KaiL_> but aren't that mostly very poor people?
<pitti> Keybuk: I guess it just doesn't at powerpc then
<KaiL_> I miss spanish a bit on that list...
<Keybuk> it may be that it doesn't work with linux-wlan-ng of course
<pitti> Keybuk: but that would be fine for me, if it works on i386
<Keybuk> there's no specific mention of wlan-ng in the source
<Kamion> KaiL_: on principle we're not discriminating against language support just because the speakers happen to be poor
<KaiL_> oh, there es _is_ prioritized - only not let landed on the live-CD..
<pitti> Keybuk: if WPA is driver specific, that might be, too
<Kamion> es is the next one down after fr
<Keybuk> pitti: it has to be supported by the driver, fwict.  see the patch to madwifi
<Kamion> we'll probably add it and a few others in too
<KaiL_> Kamion, the question is only about how big is the chance, that this lang is searched for..
<pitti> Keybuk: could you test libnl on any !i386 arch?
<Keybuk> pitti: I can give it a go on powerpc this evening
<pitti> would be interesting
<Kamion> KaiL_: consider that Canonical and related organisations have put a fair bit of effort into getting free software and Ubuntu into areas not traditionally known as high-tech; look at the Freedom Toaster and the Xhosa translation work
<Lure> pitti, Keybuk: will wpasupplicant also include patches required for n-m (in test repository)
<Keybuk> is with a linksys orinoco pcmcia card, would be a fun test
<Keybuk> Lure: see -changes
<Keybuk> (yes)
<Keybuk> Kamion: *three* dailies today?  what broke? <g>
<pitti> Keybuk: the world will *love* you for that :)
<Kamion> Keybuk: the third was Mithrandir's, I think - no idea
<Kamion> Keybuk: the first was broken code on cdimage, my fault
<KaiL_> Kamion, right, but what is more usefull: a lang with 50Mio speakers, of which 805 have a PC or a lang with 100Mio speekers, of which maybe 5% have a PC..?
<Keybuk> Kamion: uhhh, what versioned dep on module-init-tools did you just add? :p
<pitti> Keybuk: ok, I trust you for the QA assessment; libnl is fine
<Keybuk> ah, just >= 3.2.2 that's ok then
<Kamion> KaiL_: how about a language with 100 million speakers, of which not many have a PC yet, but when they do, guess who shows up with full support for them
<Kamion> look to the future! :)
<Evaso2> hi guys there is islsm driver packaged in ubuntu?
<pitti> janimo: evince-gtk? yay source code duplication.. :/
<siretart> Keybuk: pong
<Keybuk> Evaso2: not that I'm aware; what is it?
<janimo> pitti, yes unfortunately
<janimo> there;s more of that kind
<KaiL_> Kamion, good idea, if there'a chance, that this happenes in a to to far future..
<Keybuk> siretart: ETOOLATE :p
<siretart> hehe
<Kamion> plus I don't think we can objectively measure number of speakers with PCs; you mentioned Spanish, of which there are a large number of poor speakers in Latin America
<janimo> pitti, we talked about this about two weeks ago
<Kamion> and yet Brazil is one of the centres of Canonical development
<Keybuk> siretart: I just uploaded wpasupplicant with your ctrl_ap patch, a prettyfied init script and wpagui split out
<Evaso2> Keybuk: is the prism54 driver for the softmac cards
<Kamion> so go figure
<siretart> was it about wpasupplicant? I'm currently preparing the next upload to debian
<Keybuk> Evaso2: yes.
<pitti> janimo: no chance for multi-building the evince package with a different patch set or so?
<pitti> janimo: or, rather, configure options?
<Keybuk> siretart: wanted to check there was nothing I missed, and it was all ok
<siretart> Keybuk: wpagui is split out for some time in debian. I thought that slomo already fakesynced that work some time ago
<janimo> pitti, seb did not want that
<janimo> and also cdbs does not cope with multibuild
<Evaso2> Keybuk: so there isn't support for it in ubuntu?
<janimo> AFAIK
<Keybuk> siretart: not that I could tell, the latest source from ubuntu just had it in the main thing
<Keybuk> Evaso2: prism54 is in Ubuntu
<crimsun> siretart: no, he asked me to, but I didn't due to the bugs in BTS
<pitti> janimo: not very well, true
<slomo> siretart: no... crimsun wanted to do it
<siretart> oh
<siretart> I see
<Evaso2> Keybuk: i'm talking about softmac
<janimo> pitti, otherwise I'd try the same source package approach with gcalctool for example
<crimsun> (0.4.7-4 is not ready for our main, so I didn't)
<Keybuk> Evaso2: I don't know what that is, sorry
<Evaso2> Keybuk: http://jbnote.free.fr/prism54usb/
<siretart> well, I spent now about an hour fixing some debian bugs about wpasupplicant
<Keybuk> siretart: Debian's package seemed somewhat different from Ubuntu's?
<slomo> siretart: i asked him to do it as there were greater changes in packaging and you and crimsun were noted in the changelog. so i thought it would be far easier for one of you to merge the changes
<siretart> Keybuk: we worked on getting it merged, so that ubuntu's package doesn't need to be diverged anymore
<siretart> slomo: no problem. I wasn't aware that this hasn't happened yet
<janimo> pitti, similar situation with xubuntu-system-tools which is very close to gnome-system-tools
<janimo> on the plus side is still better than duplication by rewriting from scratch
<siretart> Keybuk: I'll look at your upload in a minute and merge it with debian's svn
<mjg59> Evaso2: Last time I checked, the prism54 softmac code didn't work. Has that changed?
<sivang> janimo: who's the upstream authors?
<siretart> Keybuk: I wanted to have 0.4.8 in ubuntu anyway, but havn't yet prepared a UVF exception request
<KaiL_> wpa going into main? maybe even on the final dapper-CD? ;)
<janimo> sivang, gnome devels genarlly I dunno
<Kamion> er, Brazil => Portuguese of course, not Spanish. sigh, obviously not quite awake ...
<Evaso2> mjg59: yes it is quite usable without encryption
<Pygi> Kail_: hehe ;)
<Keybuk> siretart: other than the prettyfying, I don't think there's anything interesting in the upload
<siretart> Keybuk: you suggested that wpasupplicant should only run via pre-up.d scripts
<Keybuk> I copied the patch from the DNM repository, and the control file snippet for wpa_gui
<Keybuk> the rules changes were "minimal"
<Keybuk> right, that was already done in Ubuntu
<siretart> Keybuk: this doesn't cover all use cases for wpasupplicant
<mjg59> Evaso2: Ok. If you can point me at the source for the working version, I'll see what I can do
<Kamion> janimo: you might want to bump evince-gtk to 0.5.2, BTW
<Keybuk> why not?
<janimo> Kamion, yep planning that
<siretart> Keybuk: there are people who want to use wpasupplicant as roaming daemon, waiting for the interface to come up
<Keybuk> siretart: why is that a valid usecase though? :p
<siretart> Keybuk: I've prepared a new package where there is a switch to choose what mode to use for wpasupplicant
<siretart> Keybuk: as a replacement for waproamd
<Keybuk> that's like saying dhclient3 should be running all the time waiting for the interface to come up <g>
<Keybuk> ahh, I think we don't have to care about that in Ubuntu
<Keybuk> "one true way to run it" is fine
<Keybuk> and actually makes it a damned sight easier to integrate with other things
<siretart> Keybuk: well. therefore I built a switch in /etc/default/wpasupplicant where the user can choose what mode he wants to use
<siretart> Keybuk: it is NOT enabled by default. 
<Keybuk> yeah, the trouble with that switch is it makes it harder for things like NM to start and stop wpa_supplicant and modify its configuration :)
<Keybuk> and makes it harder for us to support it
<Keybuk> as it means we have to find out how the user is running it
<siretart> Keybuk: hm. how is nm actually starting nm?
<siretart> argl
<Keybuk> if we know that it's only run on a running interface, and only takes care of that single interface, like dhclient3, then it's easier to support
<siretart> Keybuk: hm. how is nm actually starting wpasupplicant? via init script?!
<Keybuk> directly I think
<siretart> Keybuk: then thats no problem anyway
<Evaso2> mjg59:  http://jbnote.free.fr/prism54usb/data/code/tarballs/islsm-workbench-latest.tar.bz2
<pitti> Keybuk: wpasupplicant needs LSBified init scripts
<Lure> siretart: n-m calls it directly
<pitti> Keybuk: s/s$//
<Keybuk> pitti: it does :p
<Keybuk> pitti: wait for the next cron.daily
<siretart> Keybuk: just leave the init scripts alone, they are disabled by default
<pitti> Keybuk: ah, cool
<Keybuk> siretart: well, I was going to take the init script and default file out
<Keybuk> and then change the pre-up and post-down scripts to invoke and kill wpa_supplicant directly
<Keybuk> depending on how that interacts with network-manager
<pitti> Keybuk: ok, pacakging looks good, I'll do a quick source code review before I approve it (but after meeting...)
<Evaso2> mjg59: firmware http://daemonizer.de/prism54/prism54-fw/
<siretart> Keybuk: have you had a look at our integration in the experimental tree?
<crimsun> Keybuk: that sounds sane enough.
<Keybuk> siretart: has it changed from what's in Ubuntu?
<Evaso2> mjg59: or here for an explanation of firmware http://jbnote.free.fr/prism54usb/PrismFirmwares.html
<siretart> Keybuk: well, we support 3 modes there
<Keybuk> the current stuff in Ubuntu is kinda buggy <g>
<siretart> Keybuk: with the default being 'do not start it at all'
<Keybuk> I'm not disagreeing that it's good in Debian to do that
<Keybuk> however in Ubuntu I've been systematically purging all multi-mode operation from everything
<siretart> Keybuk: one mode is as waproamd replacement, as ever in debian. the second is like you suggest
<Keybuk> and making things only work one way
<Evaso2> mjg59: do u need somthing else?
<mjg59> Evaso2: No, that should be ok
<mjg59> Oh, argh, another copy of the madwifi tree
<siretart> Keybuk: the third is with direct integration to /etc/network/interfaces like wireless-tools
<mjg59> WHY MUST PEOPLE BE SO MEAN?
<Keybuk> siretart: isn't that just a pre-up/post-down script?
<Keybuk> that's how wireless-tools intergrates with ifupdown
<Pygi> mjg59: ask people? ;)
<siretart> Keybuk: http://svn.debian.org/wsvn/pkg-wpa/branches/wpasupplicant-0.5/debian/README.modes?op=file&rev=0&sc=0
<Keybuk> it just has if-up scripts that get environment variables
<siretart> that file describes the planned state
<siretart> mom phon
<Keybuk> siretart: ok, I like the first one
<Keybuk> I'd probably take that, and strip the other two from the package in Ubuntu
<crimsun> well, seeing how I made the crufty if-p{re-up,ost-down}.d script, cut away
<crimsun> (at the time I wanted to make the least invasive change to get it working)
<mjg59> Keybuk: Ok, here's a fun one for you
<mjg59> Keybuk: prism54 softmac and fullmac cards are identical except for the amount of RAM in them
<mjg59> Keybuk: The softmac driver will drive both, but the fullmac driver is more functional
<Keybuk> siretart: do you not think that just supporting one true mode is better?
<Keybuk> even from a "I have to maintain this" point of view, it'd make your bug-triaging life much easier
<siretart> Keybuk: mom, I'm on phon. just a sek
<mjg59> Keybuk: The fullmac driver should refuse to load on softmac cards (since there's not enough ram for the firmware)
<Keybuk> mjg59: heh, why is the driver different?
<mjg59> Keybuk: softmac cards do host-ieee80211
<mjg59> fullmac ones do it on the card
<mjg59> Oh, no, hang on - the fullmac driver only loads firmware on ifup
<mjg59> Hnngh
<Keybuk> <g>
<Keybuk> was going to mention that
* Keybuk hates prism54
<mjg59> (Why does it not load firmware on modprobe? Why? Why? WHY?)
<KaiL_> Network-Manager looks really nice...
<Keybuk> mjg59: we have the source for that?  might be worth fixing
<Keybuk> that causes no end of pain
<mjg59> Keybuk: We have the source, yes
<Keybuk> iirc. it has no MAC address until the firmware has been loaded
<Keybuk> which is cute
<Evaso2> mjg59: what kind of prism card do u havE=
<siretart> ok. back
<mjg59> Evaso2: None
<siretart> Keybuk: I don't think that there is really 'one true mode'
<mjg59> Oh horrid horrid driver
<Keybuk> siretart: what does the always-running daemon give them?
<siretart> Keybuk: I do agree that wpasupplicant should not be started via the init script by default
<Keybuk> that the ifup/down mode doesn't?
<siretart> Keybuk: roaming support. you don't need to care about where you are.
<Keybuk> how does it give them that?
<siretart> Keybuk: you just specify all your networks, and it just associates. thats neat
<Keybuk> even when the interfaces are down? :p
<siretart> Keybuk: when the interfaces are down, it waits for them to come up
<Keybuk> right
<Fawzib> hello, I'm trying to make a deb for a python application, but all the samples are for compiled apps not interpreted ones. Is there a skeleton debian/rules for python programs or a site with samples?
<Keybuk> so if you put all the networks in a configuration file, and referenced that in /etc/network/interfaces using wpa-conf ... doesn't that give you the same behaviour?
<siretart> Keybuk: the first mode in that README.modes does not give you roaming. thats only in the second mode
<Keybuk> right
<Keybuk> so what does the third mode give you that the first two don't
<Keybuk> ?
<siretart> Keybuk: the first one is intended for making it easier for gnome-system-admin to provide an interface to wpa
<Keybuk> one question about the experimental package, btw
<Keybuk> why does the svn include doc/ examples/ wpa_gui/ and wpa_gui-qt4 directories?
<Keybuk> should those be in the diff.gz verbatim?
<siretart> they come from the orig tarball
<mjg59> Keybuk: Ok, I think I can manage this (so that the fullmac driver will fail on probe for softmac cards)
<mjg59> Keybuk: So, can you then ensure that the fullmac driver is always loaded before the softmac one?
<mjg59> (Will fail in the case of multiple cards, but, well)
<Keybuk> siretart: hmm?  so I don't need to check those out?
<Keybuk> mjg59: no, I have no way of forcing driver order at this time
<mjg59> Keybuk: Well, we're going to need that
<mjg59> (For the ahci case as well)
<Keybuk> mjg59: like I said; I'd rather we fixed the modules <g>
<siretart> Keybuk: you just check the svn out and build it with svn-buildpackage
<Keybuk> assume I don't have that
<mjg59> Keybuk: In this case, loading the softmac driver on a fullmac card is a perfectly reasonable thing to do
<mjg59> It's just not what we /want/ to happen by default
<Keybuk> I'm trying to understand the shape of the svn
<Keybuk> the blah/blah/debian/ I'm used to, I just export the debian
<Keybuk> but why are there the other trees next to it?
<siretart> err, but this was a by hand upgrade, perhaps there has been some mistake while upgrade
<siretart> I focused on the 0.4.8-1 upload. the experimental was kel's work from yesterday. need to catch up there
<Keybuk> ok
<Keybuk> cause I rather like the shape of that experimental one
<Keybuk> and am gonna try for a UVF for it :)
<siretart> well, we are not sure how many systems that is gonna break
<siretart> therefore we are uploading that crack to debian/experimental and poke ppl to test that :)
<Keybuk> no supported Ubuntu systems, wpa isn't in main yet <g>
<siretart> glad that you like that work :)
<mjg59> Keybuk: So what we want is for prism54 to be preferred over prism54_softmac, which would appear to be entirely a load order decision
<fabbione> pitti: it is more complicate than that
<fabbione> pitti: what i need is: query for bugs with conditions X/Y/Z -> get the list -> change status -> add comment
<fabbione> pitti: there i no way to do that in LP for more than one bug
<Keybuk> mjg59: but we can't guarantee the load order for people with one device of one type, and another of the other type
<Keybuk> and trust me, SOMEONE will do this
<mjg59> Keybuk: Yes. What do you propose instead?
<siretart> Keybuk: whats the status with nm? can I look at your nm 0.6 branch?
<mjg59> Keybuk: We can either make it work for most people, or we can leave it broken for everyone
<pitti> fabbione: right, debbugs can search for way more properties than lp ATM
<siretart> I'd love to see how I can help on the wpasupplicant side for integration
<fabbione> pitti: only till a few hours back :)
<pitti> fabbione: but it depends on what 'conditions' are
<fabbione> pitti: my grep sk1ll5 are on it :)
<Keybuk> siretart: I don't have a "branch", I just have a bunch of code on my disk
<siretart> Keybuk: another option would be to integrate whats outlined in README.modes in an wpasupplicant_0.4.8-0ubuntu1 package 
<fabbione> pitti: in about 100 lines of shell i have LP caching and local search in bugs headers :)
<Keybuk> mjg59: like I said, I'd rather we fixed the modules to work whichever order they're loaded
<siretart> but I'd rather see some more testing for that
<Keybuk> siretart: given that the config changes are the bulk of the UVF request, I think that's probably defeating the spririt
<siretart> I tried that today, its horrible to debug
<pitti> fabbione: heh, I do that in my ubuntu-bugs maildir, easier :)
<Keybuk> the upstream bit looks mostly like "fixed some stuff and added supprot for this algorithm"
<siretart> nearly all options are case sensitive, and you won't get any assistance in debugging :/
<mjg59> Keybuk: Which, in this case, would be how?
<fabbione> pitti: assuming you have all of them.. yes..
<fabbione> pitti: but not if you need to adopt something
<mjg59> Keybuk: I mean, yes, ideally, the softmac driver should have all the functionality of the fullmac one. But it doesn't, and it won't in time for dapper
<pitti> fabbione: ubuntu-bugs@ has them all, yes
<Evaso2> pitti: i think that the dmraid udeb is available for debian. do u plan to backport it to ubuntu?
<siretart> Keybuk: right. but the upgrade from 0.4.7 to 0.4.8 should be done anyway. quite focused bugfix release from upstream. the packaging and integration changes are disputable, sure
<Keybuk> siretart: the packaging and integration changes are great though!  they make my life much easier <g>
<Keybuk> mjg59: right
<siretart> :)
<pitti> Evaso2: I think you want to talk to Kamion for installer issues
<infinity> Actually, me.
<Keybuk> the trouble is I'm not sure we have time to patch and debug modprobe before dapper either <g>
<pitti> or that ;)
<infinity> That particular bug has been assigned to me (for now) for the initramfs integration stuff.
<infinity> The installer stuff will come nearly for free (but not quite)
<Evaso2> pitti: are u maintaining the user space tool?
<mjg59> Keybuk: So we can either cripple the softmac driver so it can't load on fullmac hardware (which would be less than ideal, because it does have a couple of features the fullmac one doesn't), or we can ensure a specific load order
<Keybuk> modprobe patch would need
<Keybuk> 1) config entries
<Keybuk> 2) sorting of alias expansion
<pitti> Evaso2: I don't think so, but which tool? 
<mjg59> Keybuk: Does the device ID get passed to the environment when modprobe.d commands are executed?
<siretart> Keybuk: ok. let me propose this: I look at your upload now and see what can and should be merged to debians svn here: http://svn.debian.org/wsvn/pkg-wpa/trunk/?rev=0&sc=0
<infinity> dmraid.  It's all in the same package.
<infinity> (same source package, that is)
<siretart> and report back. this package should do it in dapper as well
<Keybuk> siretart: there's not much to integrate back
<Keybuk> just the init script change
<Keybuk> and that's just s/echo/log_action_*_msg/
<siretart> ok
<Keybuk> why am I only getting 8KB/s from cdimage?
<Keybuk> ah
<Keybuk> because my boyfriend left bittorrent running
<Keybuk> *kills*
<Keybuk> oh look, 200KB/s
<LaserJock> Keybuk: because everybody loves Dapper?
<mjg59> Keybuk: We could just have something in modprobe.d that modprobes the other module if certain criteria are met?
<Evaso2> pitti: the dmraid package
<siretart> crimsun: care to test my wpasupplicant_0.4.8-1 package? (pkg-wpa/trunk)
<Keybuk> mjg59: that'd work too
<siretart> crimsun: I've introduced a new variable INTERFACE in /etc/default/wpasuplicant and like to hear a second opinion
<Keybuk> mjg59: have "install prism54_softmac" and "install prism54_fullmac" config options that both just load the right one
<mjg59> Keybuk: Yeah
<Evaso2> mjg59: there is another issue some netgear prism54 card (wg511 made in china) have the wrong fullmac pci id
<mjg59> Evaso2: ?
<Evaso2> mjg59: the chinese assemblers have missed to set the right id on the pci id memory :)
<siretart> btw, are these log_action_{begin,end}_msg commands in init scripts supposed to work in debian as well out of the box?
<mjg59> Evaso2: What's it set to?
<jdthood> siretart: Yes
<crimsun> siretart: I'd love to, but I'm occupied until 2300 GMT
<Keybuk> siretart: yes
<Evaso2> mjg59: 0000:01:00.0 0280: 1260:3890 (rev 01)
<mjg59> Evaso2: And what's the problem with that?
<siretart> great. thanks
<siretart> crimsun: thats okay. I'll polish further then
<Evaso2> mjg59: ubuntu actually try to load the wrong prism54 module associated to this id
<mjg59> Evaso2: I don't understand.
<Diziet> Damn, it's still stripping firefox-bin.
<mjg59> Evaso2: Do you mean there's a softmac card with the same PCI ID as a fullmac one? If so, that's the problem we've just been discussing
<Evaso2> mjg59: ah ok, but the problem is it has the wrong PCI id, it is only an hardware assembly problem
<sivang> pitti: so, are the db2 debs already testable (thinking of the certification test suite)
<sivang> pitti: ?
<mjg59> Evaso2: I still don't understand what the problem is here (other than what we've already discussed)
<Evaso2> mjg59: on the pragmatical software side nothing 
<Pygi> keybuk, poke ...
<Keybuk> Pygi: 'sup?
<Pygi> Keybuk: I heard that you plan to get N-M "in" by next monday...we should rather postpone that period
<Pygi> Keybuk: There is one major issue that we need to solve
<Keybuk> what issue is that?
<Pygi> Because N-M does constant background-scanning, and madwifi-old doesn't support it (-ng does, but we don't want to support that) disconnects happen
<Pygi> this is not good, and should be fixed
<Keybuk> that's not a regression from the current situtation though
<Pygi> there are also some minor issues, like bad icons :-/
<Keybuk> so I don't see how that should block the update
<Pygi> Keybuk: yes, true, but we should really solve that first
<Lure> Keybuk: I agree
<lifeless> mjg59: is the hibernate button still considered known-non-functional ?
<Keybuk> I don't see the need for a "first"
<Lure> we will just get more testers
<Keybuk> uploading 0.6 to main doesn't mean we can't continue to fix bugs afterwards
<Pygi> Keybuk: ah, ok, your call after all, but I just don't think it's ready for inclusion
<Kamion> better to get 0.6 in early if we're going to get it in at all
<Keybuk> we have 10 weeks until release to do that
<mjg59> lifeless: No, should work now
<Pygi> Kamion: ah, ok
<lifeless> mjg59: should I file a bug then ?
<Keybuk> "get it in, then worry about whether it's comfortable"
<Keybuk> *ahem*
<Kamion> postponing it for one piece of hardware makes it more likely that we won't be able to include it after all
<mjg59> lifeless: What are you running, and what does it show up in xev as?
<Keybuk> anyway, the disconnection issue isn't that bad
<Keybuk> you don't notice it unless you're running wavemon or something
<lifeless> dell X1 still
<lifeless> KeyPress event, serial 26, synthetic NO, window 0x4600001,
<lifeless>     root 0x4c, subw 0x0, time 685560661, (627,207), root:(633,305),
<lifeless>     state 0x0, keycode 165 (keysym 0x0, NoSymbol), same_screen YES,
<Pygi> Keybuk: a lot of people reported that...but ok..
<Pygi> Kamion: agreed, but still .. perfection is what counts ^_^
<Keybuk> Pygi: sure; but then that situation exists with the current 0.5 packages too
<mjg59> lifeless: Running gnome-power-manager?
<Keybuk> and is only fixable by shipping madwifi-ng from what I understand it
<Keybuk> or stopping n-m scanning on atheros
<lifeless> yes, suspend w button works.
<Pygi> Keybuk: not really...we can stop scanning if we have connection...
<lifeless> erm, : yes, suspend button works.
<Pygi> and once it dc/s, start scanning again
<mjg59> lifeless: That's not actually strong evidence for that
<Keybuk> there are better bugs to try and fix
<mjg59> lifeless: Can you check?
<lifeless> thats why I added the comma.
<Keybuk> like that fact N-M doesn't report state for interfaces it's not controlling
<Pygi> Keybuk: ah, ok
<lifeless> there is a gnome-power-manager process, AND the suspend button works.
<mjg59> lifeless: Ok. hald-addon-keyboard ?
<mjg59> (Running?)
<Pygi> Keybuk: hm, well, we can't just take over all the interfaces
<lifeless> mjg59: no.
<Keybuk> Pygi: reporting state != taking over
<mjg59> lifeless: That would be your problem, then
<Pygi> Keybuk: yes, understandable
<lifeless> doesn't seem to be in the path
<mjg59> lifeless: No, it needs to be launched by hal
<pitti> Mithrandir: at that time I still was under the impression that the only thing that was left was xmms, which we could demote easily
<pitti> seb128: alright, maybe we can get rid of it then, I'd much appreciate
<Pygi> Keybuk: ok, so we'll fix bugs after inclusion
<seb128> pitti: I'll have a look on some of those stuff if I get borred by bug triage :p
<seb128> pitti: the list is not that long, so maybe it's easy ... depending of the app
<pitti> yes, I didn't check the particular apps
<pitti> imlib should probably go with gtk+1.2 anyway
<Pygi> Keybuk: as to what I know, we are to ship madwifi-ng for dapper+1 anyway, along with new n-m
<lifeless> mjg59: how do I make that happen ?
<_ion> siretart: Pong.
<_ion> Hi Pygi
<mjg59> lifeless: It ought to happen automatically. Sounds like something is broken for you.
<Pygi> _ion: hey, what's up?
<mjg59> lifeless: Running latest hal?
<Keybuk> Pygi: the main problem with that is that madwifi-ng has regressions from madwifi
<Keybuk> like not actually working on amd64
<lifeless> 0.5.7-1ubuntu7
<janimo> pitti, is putting xfce translations in langpack-base still the plan?
<Pygi> Keybuk: yup, I know ... :-/ 
<mjg59> lifeless: Do you have /usr/share/hal/fdi/policy/10osvendor/10-keyboard-policy.fdi ?
<Keybuk> so assuming upstream get their act in gear by dapper+1, yes, otherwise maybe
<pitti> Riddell: kdegraphics is the only package needing imlib; any chance to migrate to something else?
<lifeless> yes
<Keybuk> depends how enthusiastic infinity and/or mjg59 get about shipping both :)
<lifeless> 470 bytes
<Mithrandir> mgalvin: hiya, I'm planning on releasing flight-6 on Wednesday.  Any chance you could do your magic and whip up a "what's new and shiny in flight 6" page for me? :-)
<Kamion> Pygi: the perfect is the enemy of the good
<pitti> Riddell: like the much more modern imlib2?
<mjg59> Keybuk: We need to ship madwifi-ng for dapper anyway
<Pygi> Kamion: heh ;)
<Keybuk> mjg59: we do?
<ogra> janimo, but please in separate langpack-xubuntu packages or something 
<mjg59> Keybuk: Yes
<pitti> janimo: yes, it'll happen automatically now that they are in main
<Keybuk> mjg59: infinity was getting cold feet about it yesterday
<Kamion> (language-pack-xfce-*)
<mjg59> Keybuk: Since it's insane for us to ship without support for modern hardware when there's a working driver
<Kamion> (I imagine)
<pitti> Kamion: oh?
<ogra> Kamion, or that indeed
<Riddell> pitti: I'm not sure, I'll take a look sometime
<_ion> pygi: Hm, have you and tonio looked at the updated package i sent?
<Kamion> pitti: or not. where were you planning on putting them?
<pitti> Kamion: no, they are small enough for the base ones, as we figured out recently
<Pygi> mjg59: but -ng is likely to be in universe or?
<mjg59> Pygi: No
<Pygi> _ion: hm, yes, I did..
<ogra> pitti, edubuntu is currently 9M oversized ... and i only ship english
<Kamion> pitti: oh, ok
<pitti> Kamion: some 100 kB or so
<mjg59> But it won't be used by default except on cards that are only supported by it
<janimo> maybe 200K
<mgalvin> Mithrandir: as in 20060329?
<janimo> I'll recalculate
<Mithrandir> mgalvin: yes
<Pygi> mjg59: huh :-/ so we are including -ng in main as well?
<Kamion> could be 2MB on Ubuntu CDs then
<ogra> oh, ok, if its in the kb area ...
<mjg59> Pygi: No, restricted
<janimo> too bad abiword and other apps are translated part of gnome-langpack so cannot get those separately
<Kamion> *probably* doable but be prepared to reconsider that, if you could
<mgalvin> Mithrandir: yea sure I can get it done by then
<Mithrandir> mgalvin: thanks :-)
<Pygi> mjg59: hm, ok... can we then make madwifi suggested package for network-manager?
<mjg59> Pygi: No
<_ion> pygi: Well, is the change totally evil? :-)
<Mithrandir> mgalvin: I assume you'll coordinate with heno about a page on www.u.c instead of the wiki and such.
<lifeless> mjg59: any other thoughts ?
<mjg59> lifeless: Can you put up a lshal somewhere?
<Pygi> _ion: not totally evil ;)
<janimo> Kamion, I'm fine with langpack-xubuntu too if not too much hassle for pitti/the archive whatever
<lifeless> mjg59: anything in that that I should censor ?
<Pygi> mjg59: ah, ok then ^_^
<mjg59> lifeless: No
<mjg59> Oh, possibly your serial number if you're paranoid
<janimo> if it turns out too much overhea
<janimo> d
<mgalvin> Mithrandir: np :)... yea, i have access to it, i will move it there when its ready
<pitti> Kamion: I'd be fine with either way, it's not difficult to build an extra set
<Pygi> _ion: come to #kubuntu-devel, we have to discuss some more things
<Kamion> janimo: I'm not overly keen on another seven million packages, but if it's what it takes - we'll see
<Mithrandir> mgalvin: thanks again.
<lifeless> mjg59: so grep -v serial is ok ?
<mjg59> lifeless: Best to eyeball it
<mgalvin> Mithrandir: np, I will let you know when its all set :)
<pitti> Kamion: me neither, and most of the translations are around 50 kB or so (just the most popular ones were 200 kB), so my gut feeling is that it's not really worth the package overhead
<janimo> pitti, anything not explicitely put in gnome or kde langpack and is in main goes to base-langpack?
<pitti> janimo: yes
<pitti> well, right now, that is; easy enough to tweak
<pitti> but it wouldn't fit into either gnome or kde
<janimo> if so there are apps which I did not count last time because not xfce proper (graveman, evince-gtk etc)
<lifeless> mjg59: people.ubuntu.com/~robertc/lshal.txt
<pitti> janimo: evince-gtk doesn't reuse evince.mo? that's evil
<janimo> pitti, well I can make it so
<janimo> it will reuse it :)
<lifeless> mjg59: we're at the restraunt, I will catch up tomorrow and see if there was useful data in there as I imagine ints not a trivial thing to check at this point
<pitti> janimo: please do, otherwise all translations need to be done twice
<pitti> janimo: so, the pots of both should just be merged (if there are any different strings at all)
<janimo> so we'll probably have gnoem langapcks too on xubuntu CD for abiword/evince-gtk whatebver else we may have in common
<lifeless> mjg59: ok ?
<mjg59> lifeless: Ok
<janimo> pitti, ok
<mjg59> lifeless: From that, hald-addon-keyboard should have been started. Is evdev loaded?
<Pygi> Keybuk: also, new patched L-R-M packages seem to fail for Madwifi...
<fabbione> night guys
<Pygi> night fabbione
<Keybuk> "fail" ?
<Keybuk> works ok here
<pitti> night fabbione 
<Pygi> Keybuk: not work that is...
<ogra> ciao fabbione 
<janimo> night all
<pitti> oh, my main network seems to be back, brb
<Keybuk> "fail" and "doesn't work" are both banned terms here
<Pygi> Keybuk: hm...perhaps...but it still doesn't work...old L-R-M we have in our repo seem to work with older kernel build, but new ones that are in official repo don't work with new kernel build
<Pygi> altought the ones that are in official repo are patched with the same patch we used to patch the older ones...
<Keybuk> define "don't work"
* Pygi defines "don't work"
<Keybuk> I'm running today's kernel and lrm, and I'm on the network
<Keybuk> "my network card doesn't work" can be anything from module won't compile, won't load, isn't loaded automatically, won't ifconfig, ifconfigs but won't dhcp, no traffic sent/received, etc.
<Pygi> the issue can be seen with WPA
<Pygi> the N-M reports that the card cannot do the WPA, while it can
<Lure> Keybuk: I suspect madwifi WPA
<Pygi> problem is seen with athereos cards aka Madwifi
<mjg59> Evaso2: What do the firmware files need to be called?
<pitti> Keybuk: wpasupplicant code looks reasonable, I didn't find anything obvious (but I'm too tired already to really dig deep)
<pitti> Keybuk: I'm not sure whether it's a piece of sw that we can support for three years, though
<pitti> but if you think it's sane, it'll have my blessing
<Keybuk> I think it's sane enough
<Keybuk> it's as sane as WPA :p
<Pygi> Keybuk: thoughts on not working L-R-M?
<Keybuk> Pygi: not sure, just setting up my test WPA environment again
<pitti> Keybuk: don't scare me off :)
<Pygi> Keybuk: ok, thanks ^_^
<Keybuk> uh
<Keybuk> why isn't write-to-cd working today?
<Keybuk> "because Keybuk put the CD in upside down"
<Amaranth> Nice.
<Kinnison> Keybuk: tit
<Amaranth> I can honestly say I've never done that one. :P
<Keybuk> though there's a bug here
<Keybuk> I put the CD in my second writer
<Keybuk> and it popped up, I clicked Write Data CD, copied the ISO, it asked me whether I wanted to write from image, I did
<Keybuk> and the dialog box had my *first* writer selected
<Amaranth> it should poke hal to find out which one has a CD in?
<Keybuk> it should somehow pass from the "g-v-m sponsored dialog" which writer is being used
<Amaranth> wow, dpkg must be killing my HD, i've never had my fan spin up to full speed before
<Amaranth> sounds like a small blow dryer
<joelbryan> how large is the GNOME Desktop? without any applications just nautilus and metacity?
<tseng> how large in what way
<_ion> The diameter, in meters.
<tseng> yeah.
<tseng> its 6 hands high
<tseng> joelbryan: a full install of an ubuntu desktop (gnome, firefox, OOo mainly) is a bit under 2gb
<torkel> oh, thought it was one foot :-)
<milli> darn it all...  ATI chipset in new ThinkPad T60p is unrecognized by radeon/ati driver in xorg...  PCI dev id 1002:71c4
* milli is testing Flight 5
<joelbryan> tseng: no apps, just gnome-panel, metacity, nautilus, and human icons
<tseng> milli: file a bug, it may be fixable
<tseng> joelbryan: i still dont know what indicator of size you are talking about
<Amaranth> MB?
<tseng> installed on disk?
<tseng> in ram?
<tseng> on the install cd?
<Burgwork> joelbryan, larger than a breadbox :)
<joelbryan> flash disk
<tseng> i am sticking to "just under two gigs"
<tseng> if you want an exact figure you'll need to do your own research
<Burgwork> 1.8 was what the hoary and breezy cd cases said
<Burgwork> GB that is
<Amaranth> yeah
<Amaranth> you'll need at least 1.5GB, i think
<joelbryan> if I compiled it with --enable-static
<Amaranth> um
<tseng> static is bigger
<Amaranth> that would be a waste
<joelbryan> how do you make it under 1 cd?
<Amaranth> compression
<Burgwork> voodoo
* Burgwork doesn't think he is helping
<Amaranth> gz and bz2 for the packages on the install cd, squashfs for the live cd
<joelbryan> ok hehehe
<Amaranth> squashfs-lzma, that is
<tseng> you might be able to find a way to copy the livecd image onto a flash disk
<tseng> and make it boot
<tseng> or similar tactic
<joelbryan> tseng: yeah, that was I'm trying to do
<Amaranth> i don't think that'd be hard, do flash drives have mbrs?
<tseng> Mithrandir might be able to give you a tip or two
<tseng> point you in a direction to hack on it
<tseng> Amaranth: i dont think so, but modern BIOS has some kind of method of booting off it
<joelbryan> I'm trying to make a super small dapper
<tseng> there is a Gentoo/Gnome live-usb image
<tseng> that might give you some good ideas
<milli> tseng: ok
<joelbryan> is the live cd uses bz2 compressions too?
<tseng> some debs are bz2'd maybe
<tseng> the cd uses squashfs
<joelbryan> so it's on the fly uncompress when a program is called.
<tseng> actually, the livecd shouldnt have deb's on it
<tseng> i think part of it might be uncompressed into ram
<tseng> you are talking to the wrong people for specific details
<joelbryan> ok,
<joelbryan> I just want to figure out how to fit dapper under 50MB
<tseng> eh
<tseng> I am pretty confident that isnt going to happen with GNOME
<joelbryan> maybe strip all apps, and just the core, and create a script that has on-the-fly apt-get install clicked-app
<tseng> i am telling you, you can only strip so much
<joelbryan> so gnome can't compile without those apps?
<tseng> the livecd is around 600mb compressed
<tseng> if you remove firefox and open office
<tseng> you arent getting anywhere close to 50mb
<tseng> and one could question what you want with a desktop without a browser or a word processor
<joelbryan> they can make it 50MB, if they use the installer cd for on-the-fly "apt-get install clicked-apps"
<tseng> who is they
<joelbryan> the installer cd would be the main repos
<tseng> you cant get a base system with gnome on top in 50mb
<joelbryan> how about xfce?
<Pygi> just use blackbox ;)
<tseng> i think you are really overestimating what fits into 50mb of space
<tseng> and need to give it a try to prove it to yourself, I guess
* Pygi agrees with tseng
<tseng> Installed-Size: 60696
<tseng> the linux-image-2.6.15-18-686 is 50mb
<tseng> 60*
<joelbryan> I think it's possible to make the live cd smaller than 600MB, using the installer cd as the main repos
<tseng> thats installed and uncompressed
<tseng> but you have to have some manner of kernel and initrd outside the compressed loopback
<tseng> "using the installer cd as the main repos" you will have to rephrase
<tseng> i have one cd rom drive, I do not understand your idea
<joelbryan> tseng: on-the-fly apt-get install clicked-app
<tseng> that makes the cd totally useless for people without a network
<tseng> or 2 cd drives
<joelbryan> in background and just a prompt dialog that says "Please Insert Ubuntu Disk 1"
<tseng> you seem to be forgetting that you system is running of the cd in the tray
<joelbryan> i have ejected a live cd while running it.
<joelbryan> probably because all is loaded in memory
<tseng> its past 5pm here, time to head home
<tseng> good luck with your project.
<joelbryan> thanks, it's 5am here
<joelbryan> do you think it's necessary to copy everything to disk? why not apt-get install when needed, that way the installation time for ubuntu is much shorter.
<joelbryan> there should be a "Just Desktop" install method, aside from OEM install
<Pygi> hm, is it only me, or does it seem we have an outdated madwifi support?
<Pygi> me and Tonio_ were just looking, and we are lacking large portions of code
<Keybuk> it hasn't been updated in a while, no
<Pygi> Keybuk: this is not good :-/
<Pygi> Can we do a diff, and apply it?
<Keybuk> Pygi: where did you diff from?
<Pygi> Nowhere yet ... but we were just looking at one patch, and noticed that we are missing large portions of code :-/
<Keybuk> bear in mind that upstream "trunk" is -ng
<Pygi> yup, understandable
<Tonio_> hi
<Keybuk> it's certainly been updated within Dapper
<Keybuk> in fact, last update was 1 Dec
<Keybuk> so it's not that out of date
<joelbryan> deskbar-applet is now included on default
<Keybuk> in fact:
<Keybuk> r1417 | kelmo | 2006-01-27 13:42:11 +0000 (Fri, 27 Jan 2006) | 5 lines
<Keybuk> Fix a compile-time type-warning message in madwifi/ath/if_ath_pci.c on linux
<Keybuk> >=2.6.15. Backported from madwifi-ng.
<Keybuk> is the only commit to madwifi-old since then
<Keybuk> which hardly seems serious
<Pygi> Keybuk: ok, thanks
<Pygi> we'll have a lot of problems generated by madwifi :-//
<Seveas> Keybuk, madwifi devs are crazy, development has stalled on what they call stable and the unstable branch is still quite crackful...
<Amaranth> mjg59: you have an intel mini, right? how is the graphics support on that?
* Keybuk sings the "I Hate Network Manager" song
<mjg59> Amaranth: Unaccelerated linear framebuffer
<Amaranth> ouch
<Amaranth> i thought drivers already existed for it
<Amaranth> or is it an EFI issue?
<mjg59> No, the existing i945 drivers require a video BIOS
<Amaranth> ick
<siretart> Keybuk: I see you assigned the wpasupplicant UVF exception request to yourself
<Keybuk> siretart: why not? :)
<siretart> Keybuk: I think what wie currently have in debians svn/trunk is suitable for both debian and ubuntu
<siretart> but I don't have a wpa secured network here to test
<Keybuk> I've gone with experimental :)
<Keybuk> I like it
<siretart> Keybuk: the package in trunk does install an init script, but doesn't start wpasupplicant by default
<siretart> should be fine for integration with nm
<siretart> Keybuk: ah, so you merge the ifupdown integration to 0.4.8-1?
<Keybuk> (on phone, hang on)
<siretart> ok
<Keybuk> but yup, basically
<Burgwork> anybody else getting duplicated emails for dapper-changes?
<seb128> no
<seb128> but you might be subscribed to the launchpad package and get the mail from launchpad?
<siretart> Keybuk: if you can test this and it works for you, that'll speed up my confidence that it do okay in debian/unstable :)
<Seveas> siretart, I am using your 0.4.8 wpa_supplicant here and it works like a charm
<siretart> Seveas: thanks :)
<Seveas> if there's something newer you want me to test, just poke 
<siretart> Seveas: how do you use wpasupplicant? via nm only?
<siretart> Seveas: or via init script?
<Seveas> currently initscript as there is something broken between madwifi and NM, but it worked a few days ago with NM and madwifi
<Seveas> so: no complaints, excellent job with the supplicant
<siretart> Seveas: I've cleaned up the initscript massively, this needs testing
<Seveas> aight, did you deb-ify it already?
<siretart> well, not that massive, but quite a bit. 
<siretart> Seveas: it on my latop right now. I'll upload that
<Seveas> ok, just poke me when ready
<siretart> Seveas: ok, package in place
<siretart> not that I didn't change the version number, it is still wpasupplicant_0.4.8-1_i386.deb
<Seveas> where can I download it?
<siretart> http://siretart.tauware.de/wpasupplicant/wpasupplicant_0.4.8-1_i386.deb
<Seveas> ok, my connection may drop during wpa_supplicant restart - so brb
<siretart> the directory holds the sources, they come out from here http://svn.debian.org/wsvn/pkg-wpa/trunk/?rev=0&sc=0
<Lure> siretart: I am using your 0.4.8 and it works great (WPA2-PSK)
<siretart> Lure: via nm or via init script?
<Lure> nm 0.6
<siretart> ok
<Seveas> siretart, "daemon" is run from /etc/rc*.d and "link" from if-pre-up.d?
<Seveas> (dpkg prompted for a config file change)
#ubuntu-devel 2006-03-29
<siretart> Seveas: right. thats the bit that needs further testing
<Seveas> ok, so I'll be offline a bit longer to test both (I'll reboot)
<Lure> siretart: tried new package - NM 0.6.1 still works with it ;-)
<siretart> Lure: that would have surprised me, because the only changes where in the startup script, which nm doesn't use anyway :)
<Keybuk> siretart: what's the wpa-conf thing supposed to *do*
<seb128> $  nm -D --demangle /usr/lib/firefox/libxpcom_core.so | grep 'nsAString_internal()'
<seb128> 00087522 T nsAString_internal::~nsAString_internal()
<seb128> 000874ea T nsAString_internal::~nsAString_internal()
<Lure> siretart: where is new TYPE= field documented?
<seb128> does anybody knows if that's normal?
<siretart> Keybuk: it basically chooses which of the 3 modes is going to be used
<seb128> how can the same symbol be defined twice?
<Keybuk> siretart: except it only switches between two of them, no?
<siretart> seb128: perhaps a versioned symbol?
<siretart> Keybuk: yes, mode 3 is independent from ifupdown
<seb128> why would versionning make it defined twice?
<siretart> Keybuk: for nm, I think you wouldn't want to touch any wpasupplicant configuration at all. mode 1 is nice if you want to hack up gnome-system-admin or something.
<siretart> well, okay, the user could shoot himself in the foot by activating the supplicant there and trying to use nm
<siretart> in this case you would have 2 supplicants running compating after the interface. but hey..
<Seveas> siretart, it's very broken 
<siretart> fuck 
<Seveas> link mode doesn't work at all due to syntax errors, and the stop action makes lsb_logging complain about integer argument required
<HrdwrBoB> the whole thing is utterly broken :/
<Seveas>  * Stopping wpa_supplicant...
<Seveas> /etc/lsb-base-logging.sh: line 96: [: done.: integer expression expected
<Seveas> /etc/lsb-base-logging.sh: line 116: [: done.: integer expression expected
<Seveas>    ...fail!
<Seveas> /etc/lsb-base-logging.sh: line 122: return: done.: numeric argument required
<Seveas> invoke-rc.d: initscript wpasupplicant, action "stop" failed.
<siretart> argl, I didn't upload my latest deb
<siretart> sorry
<seb128> doko: around?
<siretart> will upgrade my wlan here to wpa tomorrow and to extensively testing
<doko> seb128: for you?
<seb128> doko: no, just for a question :p
<seb128> doko: 
<doko> ;)
<Seveas> siretart, could you please upload the latest so it won't break ^_^
<seb128> $  nm -D --demangle /usr/lib/firefox/libxpcom_core.so | grep 'nsAString_internal()'
<seb128> 00087522 T nsAString_internal::~nsAString_internal()
<seb128> 000874ea T nsAString_internal::~nsAString_internal()
<seb128> doko: is that something normal or buggish?
<siretart> Seveas: on my way
<seb128> doko: same symbol defined twice
<doko> seb128: in the same object file?
<seb128> doko: cf the command
<seb128> doko: that's a nm -D --demangle on /usr/lib/firefox/libxpcom_core.so
<doko> hmm, can't see these in the mozilla libs 
<doko> nm -D --demangle /usr/lib/firefox/libxpcom.so|grep  nsAString_internal doesn't show anything
<doko> which architecture is this?
<seb128> i386
<siretart> Seveas: ok, the syntax foo should be fixed now
<Seveas> dennis@mirage:~$ nm -D --demangle /usr/lib/firefox/libxpcom.so | grep  ns
<Seveas> 0000168c T NS_GetFrozenFunctions
<seb128> doko: you made a typoe
<Seveas> siretart, gracias
<seb128> doko: _core.so
<seb128> doko: wrong file
<seb128> Seveas: same
<Seveas> gotcha
<Seveas> seb128, there are more doubles 
<Seveas> Installing new version of config file /etc/init.d/wpasupplicant ...
<seb128> Seveas: the question is if that's normal to get dups, the number is an another one :p
<Seveas> since when is an init script a config file?
<Seveas> (I might go offline, testing siretarts madness :))
<siretart> Seveas: everything below /etc/ is a conffile by default in recent debhelper versions
* siretart giggles
<seb128> Seveas: why shouldn't your init changes be respected? :)
<doko> hmm, strange, and none is a weak symbol
<doko> and mozilla-dev doesn't have this symbol at all
<Seveaz> siretart, other than my network (either router or card) going bananas if I do the ifupdown dance to often too fast (which sadly is normal) it works like a charm in both link and daemon mode
<Keybuk> hmm
<Keybuk> wpa still working with madwifi for me
<siretart> Seveas: right, I noticed that as well
<siretart> ok. so didn't have that much crack. thanks for testing
<Seveas> siretart, but this has always been the case so it's not new to this version
<Seveas> somehow the GROUP_HANDSHAKE is failing
<siretart> Seveas: at the testplace, I noticed that authentication took a veeery long time :/
<seb128> doko: that's a --demangle 
<seb128> doko: thanks to jbailey which made me try without it :p
<Seveas> siretart, actually, it seemed to be much quicker here 
<seb128> doko: that's a --demangle bug I mean
<siretart> well, one independent tester says its okay. Keybuk: shall I upload to dapper to get broader testing?
<Keybuk> siretart: I've uploaded already
<siretart> oh. ok
<Keybuk> will probably upset the universe users, of course
<Keybuk> but it's "fit for main" now imo
<siretart> :)
<siretart> so gmane seems to have a significant lag for dapper-changes. good to know
<Keybuk> not realluy
<siretart> ah, there it is
<Keybuk> I don't know when mails go to the -changes list
<siretart> wpasupplicant in /sbin?!
<Keybuk> sure
<Keybuk> otherwise how you going to mount your NFS /usr over a WPA network? :p
<siretart> why not directly in early userspace :p 
<Keybuk> more pointedly, wpa_supplicant is started by ifup, which is started by udev
<Keybuk> all of which are before /usr is available
<Keybuk> so our policy is that anything related must be in /sbin
<HrdwrBoB> anyone using NFS /usr on a wireless machine is inviting danger anyway
<siretart> so you could nfsroot it via wpasecured network :)
<HrdwrBoB> but still a fair point
<Keybuk> HrdwrBoB: actually, that's a reasonably far-out use case
<Keybuk> the real problem would be anyone with /usr on a different filesystem wouldn't get their network device brought up :p
<siretart> Keybuk: do you think it would be reasonable for debian as well to have them in /sbin rather than /usr/sbin?
<Keybuk> yes; your experimental packages already had that change, btw
<Keybuk> I just double-honoured it
<siretart> right, but it isn't uploaded yet, after all
<Keybuk> though the Debian boot sequence is rather different from ours
<siretart> ok
<Keybuk> I also changed the pre-up script slightly; wpa-conf didn't make much sense to me, so I made it just start wpa_supplicant if *any* wpa-* option was given
<Keybuk> as that kinda implies the mode
<siretart> ok
<Keybuk> I foresaw a hundred "you forgot to also put 'wpa-conf managed' in there too" bugs
<Keybuk> or "I put 'wpa-conf Managed' and it didn't work" bugs
<siretart> hm. I see
<Keybuk> will see how it goes
<siretart> lets see how our users react on this. 
<Keybuk> aye
<Keybuk> I like it anyway, it's exactly how I'd've written it
<siretart> :)
<Keybuk> and it does feel natural
<Keybuk> auto eth1
<Keybuk> iface eth1 inet dhcp
<Keybuk>     wpa-driver madwifi
<Keybuk>     wpa-ssid linksys
<Keybuk>     wpa-psk blahblahblah
<siretart> what I don't like about the current solution is that everything is horribly case sensitive and you got NO debugging aid at all
<siretart> but well, we'll see how much that will bite future bug submitters
<Keybuk> I would hope most people editing config files are aware that UNIX is generally case sensitive
<Keybuk> ie. you can't put "IFACE" in that file for a start <g>
<siretart> for my internet cafe, this is a real world example:
<siretart> iface ath0 inet dhcp
<siretart>   wpa-key-mgmt WPA-EAP
<siretart>   wpa-eap PEAP
<siretart>   wpa-identity rt
<siretart>   wpa-password foobar
<siretart> (plus the obvious wpa-driver and essid stuff) - especially that part with key-mgmt and eap having to be UPPERCASE has bitten me
<Keybuk> I don't really understand wpa enough to know the difference between psk and password
<Keybuk> what is it?
<siretart> there are over a dozen variants of doing wpa. the easy ones are called wpa-psk. you can do that with TKIP (wpa1) or RSN(using aes, sometimes called wpa2)
<siretart> the more interesting ones are called nowadays 'wpa-enterprise' this involves authentication agains radius servers
<siretart> in that setup, we have a freeradius server authenticating against a mysql database
<xhaker> siretart, the ones you got a user/password to get in?
<siretart> xhaker: sorry?
<Keybuk> ah, and thus the identity/password pair?
<xhaker> wpa-enterprise.. uses certs and user/password authentication
<xhaker> right?
<siretart> Keybuk: right. these credentials are presented to the radius server, which itself consults something else
<siretart> xhaker: right
<siretart> Keybuk: more advanced setups use a PKI infrastructure and x509 certificates
<j^> will this madness be wired to network-admin?
<siretart> again using freeradius, which happens to hand out crypto/key material suitable for commen nas implementations around
<xhaker> tried that at my university today.. it wouldn't allow me to login though.. the AP's are there.. but i guess they haven't that connected to something yet
<siretart> j^: well, it shouldn't be hard, now that we have wpasupplicant with ifupdown integration in dapper :)
<siretart> j^: but we are after feature freeze after all
<j^> siretart it took a year to get WEP right in network-admin so i guess by that time NetworkAdmin should be all you need
<siretart> j^: wep and this one look quite similar. when I find some time, perhaps I can hack on a patch for that
* Keybuk wonders what nm-crash-logger is supposed to do
* j^ tries to find out why NM 0.6 breakes orinoco_pci/hostap_pci
* siretart gets some sleep. cu tomorrow!
<Robot101> hnnrgh
<Robot101> who is responsible for CUPS in dapper?
<Keybuk> pitti
<Robot101> yay for a) adding manufacturer autodetection from the USB info
<Robot101> and b) moving half the useful HP printer drivers into a pseudo-manufacturer called HP (HPLIP)
<Robot101> meaning that it detects that I have a HP Deskjet 5740 and forwards me straight to a list where my printer does not appear
<Robot101> *sigh*
<Robot101> Excellent communicateur  l'humour ravageur, les confrences de Jeff Waugh sont clbres pour la quantit d'interjections que l'on peut y trouver :  Rock 'n' roll ,  Awesome! Awesome! .
<Robot101> awesome.
<Robot101> now it's cone into an infinite loop
<Robot101> select(1024, [0 1 6 7 8 9] , [7] , NULL, {1, 0}) = 1 (out [7] , left {1, 0})
<Robot101> time(NULL)                              = 1143159140
* Robot101 cries
<Seveas> Robot101, ranting won't help - filing a bug will
<Robot101> I will look at it more closely tomorrow, but I'm too tired now to file a useful one... I just wanted to print something
<Robot101> https://launchpad.net/distros/ubuntu/+source/cupsys/+bug/33545
<Ubugtu> Malone bug 33545 in cupsys "cupsd hangs when HP printer is added with web interface" [Normal,Unconfirmed]  
<Robot101> it seems to be that
<raphink> anyone with a powerbook having problem to suspend to ram ?
<hyperactivecrond> can we _not_ make ubotu join #debian-bots?
<hyperactivecrond> idk it seems that we're too conforming if we make him /join #debian... ubugtu and ubuntulog dont
<wasabi_> Is ubuntu not supposed ot mount usbfs?
<desrt> wasabi_; see /dev/bus/usb/...
<wasabi_> Oh it's just in a different location.
<wasabi_> Hmm.
<wasabi_> Hmm. Possibilty of mounting it in both places for legacy apps, perhaps?
<wasabi_> /proc/bus/usb, etc.
<Keybuk> legacy apps won't work because the permissions will be wrong
<Keybuk> so no real point mounting it
<Keybuk> better to get the apps fixed
<wasabi_> hmm.
<wasabi_> Sure, if all those apps are open source. ;)
<wasabi_> no biggy to do it manually, thx. ;)
<Gwynn> mako: are you available for a talk?
<Keybuk> /dev/bus/usb != /proc/bus/usb
<Keybuk> /dev/bus/usb contains device nodes created and managed by udev using events from the usb_device subsystem
<Keybuk> /proc/bus/usb is a hacky kernel pseudo-filesystem
<Keybuk> you can always mount it if you need it, but you'll need to chmod/chown things
<Keybuk> siretart: ping?
<Keybuk> _ion: ping?
<_ion> keybuk: pong
<Keybuk> _ion: I may be just being stupid here ... but how does nm-applet request a WPA key? :)
<Keybuk> it says in the log that "NO valid key exists New key needed" and just sits there for a bit before giving up
<_ion> I haven't looked at how n-m does WPA stuff _at all_. :-) I don't have a WPA network.
<_ion> My machine is connected only via a wired network.
<ajmitch> for me, it just came up with a dialog to enter the key
<ajmitch> & then it just worked :)
<Keybuk> weird
<Keybuk> it came up with a dialog on the 11th attempt
<Keybuk> and now always does
<Keybuk> freeeeaky
<Keybuk> oh
<Keybuk> no
<Keybuk> "took too long"
<Keybuk> HAH
<j^> Keybuk there is some issue with old passwords saved in the keyring
<Keybuk> I do dislike how there's no way for gnome-keyring to have a "yeah, always let nm-applet have access"
<Keybuk> libnotify-WARNING **: Received unknown action default
<Keybuk> NOBODY EXPECTS THE DEFAULT ACTION!
<j^> Keybuk absolutly there should be a keyring that is opened than logging in
<j^> gnome bug 326925
<Ubugtu> Gnome bug 326925 in general "need for a keyring that is unlocked than logging in" [Normal,Unconfirmed]  http://bugs.gnome.org/show_bug.cgi?id=326925
<Keybuk> clearly I am Mr Stupid
<Keybuk> because I cannot get NM and WPA to play nice
<Keybuk> I put in my WPA key, it associates and disassociates for a while
<Keybuk> then gives up
<j^> which driver?
<Keybuk> madwifi
<j^> hm, latest kernel + the patch that is in the unofficial NM should work
<j^> dont have one though
<Keybuk> indeed
<Keybuk> it works if I run wpa_supplicant myself
<Keybuk> it's just NM's WPA puppetry
<tseng> hm, is radeon oss broken for everyone?
<j^> https://www.redhat.com/archives/fedora-test-list/2006-March/msg00555.html
<j^> Are you using madwifi drivers, of the madwifi-ng drivers?
<j^> wpa_supplicant must be compiled for one or the other, and right now its
<j^> compiled for madwifi-ng.
<Keybuk> madwifi drivers
* Keybuk tries without the "community" workarounds patch
<Keybuk> WEP works at least
<Keybuk> Mar 24 02:19:52 quest cupsd: Unable to open log file "/var/log/cups/error_log" - Permission denied
<Keybuk> my gods, cups is having a spasm
<wasabi_> I like how you say "gods."
<_ion> Battlestar Galactica. :-)
<Keybuk> too much Terry Pratchett, I suspect
<Burgundavia> ok _ion, Pygi, you are gods among men. I salut you for your NM work
<desrt> Keybuk; did you say wpa nm?
<Keybuk> desrt: I said wpa-doesn't-work-for-me nm
<Keybuk> but yesx
<Keybuk> is in the archive
* desrt waits pateiently
<desrt> patiently too
<Keybuk> ok, so I have Chicken, Asparagus, Sweetcorn and Pasta
<Keybuk> maybe I shouldn't cook at 3am
* Amaranth tries to think of something you could make out of that
<desrt> uh
<desrt> if you have some alfrado sauce then that's one hell of a meal
<Amaranth> do you have any cream of chicken?
<Amaranth> or that
<Amaranth> i was going for the ghetto version :)
<desrt> pasta+whitesauce+asparagus+chicken is practically meant to be
<Keybuk> I'm avoiding the sauce for experimental purposes
<Keybuk> and I-don't-have-any-in purposes
<Keybuk> Amaranth: that's what I'm having; added herbs and oil to make a meal
<Keybuk> actually tastes rather scrummy
<Amaranth> Keybuk: cream of chicken?
<desrt> ok.  so seriously
<desrt> what's nfs that's not nfs?
<desrt> all of these lustre/afs/whatever filesystems are way overkill
<mjg59> desrt: The only simple, transparent Unix networking file system is nfs
<desrt> damnit
<desrt> this is really an area that needs improvement!
<mjg59> If you don't like nfs, then what you choose depends on what you're trying to do
<mjg59> Firstly, what's up with nfs?
<desrt> i want to mount a bunch of user homedirectories on a bunch of machines in a reasonably trusted environment
<mjg59> Easiest alternative is cifs
<desrt> samba?
<mjg59> Per-user auth, unix semantics
<mjg59> Yeah
<desrt> per-user auth is out of the question
<mjg59> Why?
<desrt> i want it to always be there
<desrt> not just when people log in
<mjg59> Ah.
<mjg59> Then nfs is the answer
<desrt> blah
<mjg59> (seriously)
<mjg59> What's inadequate about nfs?
<desrt> i guess i'd better figure out how to effectively firewall it then
<desrt> the nfs server is semi-outward-facing
<mjg59> If all else fails, do nfs over VPN
<mjg59> Or move to nfs4
<desrt> mjg59; all the machines share ethernet
<mjg59> Yeah. You can do a VPN over that, surely?
<mjg59> If you're mounting stuff, you have to trust each of those machines
<desrt> oh.  i see what you're saying
<desrt> i don't need this much security
<mjg59> But you don't have to trust the ethernet
<mjg59> Just firewall out access to the portmapper and mountd
<desrt> i'm really just worried about effectively firewalling the 1000 (occasionally semi-randomly assigned) ports it opens
<mjg59> Though nfs (in theory) can turn up on any port, in practice it's always the same one
<desrt> portmapper is infuriating
<desrt> it has this -i open that totally fails to work in a useful way
<desrt> -i 127.0.0.1 -i 172.20.1.1
<desrt> you might expect this to do something sane... but it actually just binds to the last interface you give
<desrt> making it impossible to have it bound to 127.0.0.1 (required for services to register) and a specific external interface at the same time without binding to INADDR_ANY
<mjg59> iptables -A INPUT -s 0.0.0.0/0 --dport 111 -j DENY
<desrt> i've already done this
<mjg59> Or just use tcpwrappers
<mjg59> (Since if you can't trust that, we're all doomed anyway)
<desrt> i have listeners also on tcp/2049, 965, 3306, 953, 41115, 924, udp/2049, 32772, 32784, 918, 921, 1194, 962, 67
<mjg59> That's fun
<desrt> and i think that some of these are from portmap/nfs/whatever
<desrt> :p
<mjg59> What's bound to them?
<mjg59> (lsof -i FTW)
<desrt> netstat -p :)
<mjg59> Well, or that
<mjg59> You should have rpc.mountd and rpc.statd (possibly rpc.lockd)
<desrt> mostly rpc.mountd and rpc.statd
<mjg59> Again, easiest is just to tcpwrappers them out
<desrt> i've already done that too
* desrt has a vague distrust for tcpwrappers
<mjg59> Sounds pretty secure, then
<desrt> muh.  guess i'm fine
<mjg59> Seriously, if tcpwrappers is broken, so is so much of the internet that they won't be hitting you first
<desrt> i imagine it'd be pretty hard to exploit tcpwrappers
<mjg59> Yeah
<mjg59> It's pretty simple code, and it's been checked a lot
<desrt> not to mention it doesn't listen to them at all
<desrt> it's just like "you?  hmm. no."
<mjg59> Wow. Aspirin is, like, the best thing ever
<desrt> ah.  interesting.  the kernel is listening on 0.0.0.0:2049 tcp and udp.  this is what bothers me most :)
<desrt> this seems to be static though.. it's listed in /etc/services as 'nfs'
* desrt adds to firewall
<mjg59> I generally forget that these things actually work
* mjg59 revels in his newfound ability to swallow
<mjg59> Oh, wait. That sounds quite bad.
<desrt> don't worry.  we know you're just a pill swallower
<Amaranth> real aspirin is worthless
<Amaranth> you need 2000 mg of ibuprofen
<Keybuk> Amaranth: some people don't react to ibuprofen
<Keybuk> some do
<Keybuk> depends whether the complaint is due to inflammation as well
<Amaranth> hydracodone (sp?) then? :)
<LaserJock> hmm, for my wife asprin works but ibuprofen doesn't do anything
<mhz> TheMuso: ping
<mhz> TheMuso: thx for the email
<LaserJock> is there some recommendation about using "dfsg" in either the package name or version for package that have non-free parts removed?
<fabbione> morning guys
<G0SUB> LaserJock: it's mostly appended to the version IIRC
<nictuku> fabbione, hi
<fabbione> hi
<minghua> G0SUB: make would be an exception (the source package is make-dfsg)
<G0SUB> minghua: the gfdl issue?
<G0SUB> minghua: has the make package been updated yet? IIRC no
<minghua> G0SUB: you are right.  but it's make-dfsg in debian already
<G0SUB> okay, great
<greebo> Can some canonical person please tell warthogs that Jeff (jdub) has been offline since 3am, and the fault has been logged with Telstra (very few Canonical people in Sydney at the moment so he couldn't call them)
<fabbione> greebo: thanks
<fabbione> <-will do
<greebo> fabbione, thankyou
<fabbione> greebo: done
<fabbione> he can go back to sleep now ;)
<greebo> fabbione, heh, he will have dinner in a few hours, no sleeping just yet ;)
<fabbione> greebo: afternoon nap? :)
<greebo> heh :) siesta is always an option!
<fabbione> seee...
<janimo> Lathiat: ping
<sladen> mjg59: ACPI on HP/Compaqs seem to have broken.  This should be handled internally in the DSDT---did a interpreter change or similar?
<pitti> Good morning
<Lathiat> janimo: pong
<janimo> Lathiat: what is the status of avahi in dapper?
<janimo> I see zeroconf spec was deferred
<Lathiat> janimo: spec delayed, avahi was put in main, not installed by default
<Lathiat> no gui for configuring it
<Lathiat> that'l be done as part of zeroconf in dapper+1
<janimo> Lathiat: so how can one try it out now?
<Lathiat> janimo: apt-get install avahi-daemon
<janimo> can nautilus use it to discover samba shares for example?
<janimo> Lathiat: I have it installed just wondering how to test it best
<janimo> since I am entirely new to it
<janimo> gnome app seem to all link to avahi
<janimo> so I suppose even if there's no gui one can use it somehow
<janimo> is the reason for spec delay incompleteness of avahi in some way?
<janimo> Lathiat: so I am interested mostly in the client part now
<mdke> what's the correct way to enable flash in firefox on dapper? We refer to an absent package in the documentation at the moment
<mdke> (flashplayer-mozilla, which seems to have disappeared from multiverse)
<Lathiat> i can see it
<Lathiat> ?
<mdke> hmm
<mdke> Lathiat, http://article.gmane.org/gmane.linux.ubuntu.doc/5220
<Seveas> mdke, flashplugin-nonfree?
<mdke> Seveas, right, that's what the poster says in that post, except he says it doesn't work
<Seveas> wffm - but it downloads things from an external server which of course is unreliable
<mdke> Seveas, it works for you?
<Seveas> worked a few weeks ago - didn't try since
<mdke> I'll have a go
<mdke> doesn't work
<mdke> if anyone knows how to get flash support, please highlight me, and we'll add it to the documentation
<robitaille> mdke: download the tar file from macromedia web site, untar it, copy the two files to your plugins directory in .mozilla.  Not really user friendly, and use the CLI, but it works :)
<mdke> we'll fall back to that if there isn't a package, I guess
<robitaille> someone could probably write a small script, including scraping from the macromedia web site the link to the latest tar file available.
<jsgotangco> its already a script
<jsgotangco> its not even a complicated script
<infinity> Or we could get explicit permission from Macromedia to redistribute in multiverse.
<jsgotangco> yeah
<infinity> (which we used to do without permission)
<mdke> ah, hence the package disappearing
<infinity> Having installer packages that break a few months after release is always teh suck.
<robitaille> or someone could resync with the latest DEbian package.  I thought there was request on the motu list about this
<mdke> so what does the flashplugin-nonfree package do?
<infinity> robitaille: Yes, but that doesn't solve anything in the long term, just for now.
<mdke> that's in the archive
<robitaille> would solve the security issue with the older flash we try to ship in all the ubuntu version since Warty
<infinity> mdke: flashplugin-nonfree is an "installer package" that downloads from macromedia and installs.
<robitaille> infinity:  long term is to hope that a free solution will work correctly for joe user
<infinity> mdke: flashplayer-mozilla was a package that actually shipped the biaries from our archive (so didn't rely on their website not breaking)
<mdke> ok
<infinity> robitaille: That's longer term.  I'm talking "for the dapper cycle", since we're not going to go slipping new Flash player (free or not) into dapper after it releases.
<mdke> i tried installing it from within firefox, that failed too
<mdke> lots of people will try that, because you only notice its absence when you get those "Missing Plugin" boxes
<robitaille> mdke:  that should work...it worked for me a few weeks back.
<infinity> How does it fail when you install it from firefox?
<jsgotangco> it downloads but doesn't install
<infinity> Fun.
<mdke> infinity, i don't know. It downloads for a while, gives me a license agreement, then says "Installation failed"
<robitaille> infinity:  for dapper, what's wrong with the latest DEbian package?
<infinity> robitaille: That it will stop working a month after we release?
<robitaille> then put the next version in dapper-update
<mdke> it only lasts a month?
<infinity> mdke: No, that's a hypothetical.  As in "they could move the files on their website in a month"
<infinity> Installer packages are notoriously unreliable and unsuitable for stable releases, IMO.
<mdke> oh, that's an installer thing too
<robitaille> 6.0.25 worked for quite a while...it's only semi recently that things started to break.
<mdke> infinity, i think the website uses a generic filename though, rather than a version number in the filename, so it might not break
<infinity> And Macromedia /does/ hand out redistribution licenses like they're candy, so I'm not sure why no one's emailed them for one (which we could then apply to put flashplayer-mozilla back in multiverse)
<mdke> but still, the website itself might break
<Pygi> _ion: around?
<mdke> infinity, do you fancy pinging someone official to mail them?
<robitaille> on the other side, we are talking about a multiverse package.  it breaks, it breaks; nobody is promising anything to anyone.  But it would be nice if it worked for at least JUne 2006 :)
<infinity> Well, I still have breezy's flashplayer-mozilla installed.  Didn't even notice it had been removed. :)
<infinity> That works fine.
<mdke> me too
<infinity> Oddly enough, my name's the last one on the changelog too.
<infinity> Hrm.
<infinity> Could explain why I have it installed. :)
<mdke> then you get to fix it!
<minghua> hehe
<mdke> i saw that rule somewhere
<infinity> Anyhow, I could mail them as an Ubuntu community representative, and if getting a license on behalf of Ubuntu doesn't cut it for them, can see if they're interested in granting a distribution license to Canonical instead.
<mdke> sounds great
<infinity> mdke: Yeah, I'm exempt from the rule, since I upload EVERYONE's packages. :)
<mdke> infinity, no, that just means you get to fix everything
<infinity> If I suffered from touched-it-last maintenance, I'd maintain the whole dist by now.
<mdke> :)
<Mithrandir> infinity: you don't?
<infinity> Mithrandir: Shh.  I'm trying to put a happy spin on things and pretend for a moment that my life doesn't suck.
* infinity wishes he could shake the TILM from Thunderbird and LRM.
<infinity> sladen: Around?
<Pygi> Keybuk: here?
<sladen> infinity: yup
<JaneW> sladen: ping
<sladen> JaneW: pong
<JaneW> sladen: did you receive my laptop testing team mail? 9I think you were one of the ones that got mail-bombed with the message - sorry about that)
<JaneW> sladen: I have to check in with all testers to make sure that they are still actively testing and on track
<sladen> JaneW: yup, I queried you on IRC about the multiple copies.  I'll just answer the first one if you want:)
<JaneW> sladen: again I am sorry, the messages refused to send, and I was creating a new one and then everything suddenly went - it was stupid
<sladen> JaneW: I got one, and then there was a second one CC'ed to me, mjg59, corey
<JaneW> sladen: yes one response with suffice ;)
<JaneW> unless you want to get me back ;)
<sladen> :)
<JaneW> with=will
<JaneW> siretart: ping
<siretart> JaneW: pong
<JaneW> Lathiat: ping
<infinity> sladen: https://launchpad.net/distros/ubuntu/+source/xserver-xorg-driver-i810/+bug/31499
<JaneW> siretart: what I said to sladen...did you receive my laptop testing team mail? (sorry if you got mail-bombed with the message)
<siretart> JaneW: yes, I received your message
<Ubugtu> Malone bug 31499 in xserver-xorg-driver-i810 "no dri with xorg 7.0 on Dapper" [Normal,Needs info]  
<infinity> sladen: The last comment on that bug is pretty convinced you just broke DRI for him with your mesa upload.
<Lathiat> JaneW: pong
<siretart> JaneW: I'm still testing the laptop, but my wiki is at flight-4, due to my last exam this week. I'll get it updated to flight-5 asap. 
<sladen> Ubugtu: why are you not providing clickable URLs anymore
<JaneW> Lathiat: did you receive my laptop testing team mail? (sorry if you got mail-bombed with the message)
<JaneW> siretart: ok great thanks
<Mithrandir> siretart: flight-6 is on Wednesday, you know, so you better get rolling. ;-)
<siretart> JaneW: the laptop is in general fine, there are issues with suspend to ram, and some hotkeys, but nothing serious
<Lathiat> nope sorry
<JaneW> siretart: we were just concerned that some people might have stoped testing altogether
* Lathiat looks
<simira> Mithrandir: don't work so fast! I can't keep up!
<JaneW> siretart: I'll list you as compliant
<infinity> sladen: It was responding to a clickable URL I pasted two lines up. :)
<siretart> JaneW: no, I didn't stop at all. I needed to pause for some weeks for my exam
<Lathiat> JaneW: i havent actually
<Lathiat> JaneW: whered you send it?
<siretart> Mithrandir: thanks for notice :)
<JaneW> Lathiat: I will check and resend...
<Lathiat> also yeh i havent been updating the wiki, i do test it tho :)
<Lathiat> if thats what your wondering
<Lathiat> i should update it
<JaneW> Lathiat: It went to lathiat@bur.st
<sladen> infinity: funky, ta.  That set (kernel, mesa, -driver-i810, discover1-data) were basically adding additional PCI IDs
<Lathiat> from?
* StevenK wonders about the about-ubuntu spec.
<Lathiat> resend?
<JaneW> Lathiat: done - you may have spam filtered it... ;)
<Lathiat> i got that one
<Lathiat> JaneW: i'll do a wiki update this weekend
<JaneW> Lathiat: ty :)
<Lathiat> no real issues with my laptop a-t-m tho, other than the bug reports im already participating in
<Lathiat> e.g. the synaptics/alps bug
<JaneW> does anyone know Niall Sheridan ?
<JaneW> him and kokey are the only 2 unaccounted for now.
<JaneW> koke I mean (kokey is another guy)
<sladen> JaneW: don't you have their details on file from when you posted the machines out?
<JaneW> sladen: well I didn;t post the machines out...
<JaneW> sladen: I dstarted with the wiki table and now I have Claire's list
<JaneW> sladen: so I do have an e-mail address for him, but he hasn't responded
<dholbach> good morning
<hunger> Do we really need ifrename in the resume scripts now that udev does that anyway?
<Pygi> mornin' dholbach
<dholbach> heya Pygi
<seb128> fabbione: do you have a patch of that change you did to glib? Debian could use the same change probably?
<fabbione> seb128: uh no.. it's just a change in debian/rules
<seb128> hum, k, I'll debdiff both so
<seb128> or diff both rather :)
<fabbione> just diff debian/rules
<fabbione> it's a 3/4 lines changes
<seb128> k
<seb128> do you know if -mcpu=v9 should be used on Debian sparc too?
<fabbione> seb128: it's an optimizations for sparc64 processors
<seb128> that package used to have no diff and be syncable, I would like to keep it that way if possible :p
<fabbione> afaik it breaks on sparc32
<fabbione> that debian does support
<seb128> :(
<dholbach> seb128: couldn't you do a test on   lsb_release -is   in debian/rules?
<Pygi> infinity: around?
<seb128> dholbach: Debian has no lsb installed by default, but we could Build-Depends on it maybe
<dholbach> yeah
<seb128> dholbach: I would rather have a try on the arch than on lsb
<dholbach> seb128: sure.. that'd be better
<Pygi> who can tell me why is n-m missing libn-dev atleast for ppc (we didn't had amd64 builds) when in our test repo we have that package? :-/
<Pygi> https://launchpad.net/distros/ubuntu/+builds?build_state=depwait
* fabbione gets back to the rack
<fabbione> later
<simira> morning fabbione 
<fabbione> hi simira
<simira> How's your better half?
<fabbione> simira: she is getting better...
<fabbione> and you?
<simira> fabbione: fine, enjoying the spring approaching.
<fabbione> eheeh good
<fabbione> ok i am back to the rack
<fabbione> for real
* fabbione &
<simira> enjoy
<slomo_> Pygi: libnl is not in main yet
<Pygi> slomo_: hm, ok, thanks for taking time to answer ^_^
<infinity> seb128: I used lsb_release for a few packages to keep them syncable.  Works well.
<slomo_> Pygi: but it's approved... so talk to Kamion about it maybe :)
<seb128> infinity: yeah, that's an idea :)
* Pygi pokes Kamion
<infinity> seb128: And we definitely don't want to build with -mcpu=v9 on Debian/sparc
<seb128> slomo_: do you have an idea why some people still have that totem-xine issue?
<slomo_> seb128: the crash, the mem usage or the slow logo?
<seb128> slomo_: the xerror, which is the same issue that the slow logo afaik
<seb128> seems to be "ask for too much ressource and trigger an xerror due to that" crash
<slomo_> seb128: hmm... would be useful to have the complete output of totem-xine in that case
<infinity> fabbione: If you wanted to build with world with v9, why didn't you have doko change the GCC default to v9 instead of v8?
<infinity> fabbione: I can also override it in gcc-opt, or a varienty of other things to prevent seb from having an ugly diff in his package. :)
<fabbione> infinity: becayse we don't want that for dapper
<fabbione> infinity: dapper is v8 by default and that's good enough
<fabbione> infinity: some pkgs require extra tuning.. and to avoid to introduce a global regressions point, we just change the few we need
<seb128> does that tuning makes a real difference?
<fabbione> seb128: yes
<fabbione> like changing from v7 to v8 in gcc made gcc about 25% faster
<fabbione> but we know there are no regression from v7 to v8
<fabbione> we don't know the same to v9
<fabbione> so isolated changes are easy to spot than changing the default
<fabbione> seb128: you will be able to drop the change in dapper+1 if we get enough testing on v9 by default
<seb128> k, I guess I'll be near to 0 GNOME packages syncable on Debian without change soon :p
<seb128> Kamion, mdz: could any of you approve or refuse the libcairo UVF exception? There is a CVE on cairo fixed by that version, so either way we need to patch or update
<fabbione> bbl
<infinity> fabbione: Yeah, but I still could have overridden just the one package in gcc-opt, that's all I'm saying. :)
<Kamion> Pygi: I'm doing my morning archive maintenance now, so main promotions are next on the list
<Kamion> seb128: ... and UVF exceptions are after that, being harder ;)
<Kamion> have to do these things in order of coffee intake
<Pygi> Kamion: thanks ^_^
* Mithrandir chuckles
<seb128> Kamion: hehe :)
<seb128> Mithrandir: hi.  you working on some xkeyboard-config changes atm? Just to know if I can upload an another fix for the ralt stuff
<Pygi> Kamion: will we get wpasupplicant in main as well?
<Mithrandir> seb128: I have no changes pending now.
<Mithrandir> seb128: I uploaded the fix from svu on lp yesterday, is it more than that?
<seb128> Mithrandir: ok, I'll upload it so. FYI the change is http://webcvs.freedesktop.org/xlibs/xkbdesc/symbols/group?r1=1.7&r2=1.8
<Kamion> Pygi: it's in the queue, but not reviewed yet
<Kamion> and it pulls in qt4, which seems to have gone unnoticed
<Kamion> Pygi: I don't actually really make the review decision, pitti does that
<Kamion> I just act on decisions he makes (and make a few "obvious" ones myself)
<Mithrandir> seb128: go ahead.
<seb128> Mithrandir: that fixes the issue on my box and my altgr is still working as modifier on normal config so seems to work fine :)
<seb128> Mithrandir: ok, doing that now
<lifeless> mjg59: there is no process called evdev 
<slomo_> Kamion: hm, the libnl inclusion report says that it's approved by pitti
<dholbach> lifeless: a loaded module called evdev?
<Kamion> slomo_: that would be why I promoted it five minutes ago :-P
<Kamion> slomo_: Pygi asked me about wpasupplicant, not libnl
<lifeless> dholbach: is evdev a kernel module ?
<Pygi> Kamion: yes, I know...we removed that dependency in our test repo I believe... ok, I'll poke pitti
<Kamion> well, most recently
<slomo_> Kamion: oh... ok, sorry for the noise ;)
<Pygi> Kamion: nah, I about libnl and libnl-dev ;)
<seb128> $ sudo lsmod | grep evdev
<seb128> evdev                  10432  1
<seb128> but that's an xorg.conf option too
<Kamion> Pygi: might have changed actually, the anastacia report I was looking at predates the NEW processing I did on the most recent wpasupplicant binaries 20 minutes ago
<lifeless> ah yes
* seb128 not sure about what is the discussion
<lifeless> mjg59:  - yes, evdev 10176 2
<Pygi> Kamion: ah,kk
<seb128> but I know using evdev with xorg makes gnome-settings-daemon go away
<lifeless> interesting
<Kamion> seb128: since mdz was already talking with you about cairo, I'd prefer to leave that to him
<Kamion> usually works best if we don't both pile in on something
<lifeless> I didn't explicitly ask for it ever
<seb128> Kamion: yeah, do you know if he's likely to be around today?
<seb128> he was not to the distro team meeting yesterday neither replied to the mail so ...
<Kamion> seb128: oh, actually, StaffCalendar says he's on holiday now; ok, I'll look at it
<seb128> Kamion: thank you
<pitti> Pygi: I accepted wpasupplicant yesterdsy
<Pygi> pitti: k, great
<pitti> Pygi: oh, can you make wpasupplicant optional in nm
<pitti> Pygi: ?
<pitti> Pygi: i. e. detect it at runtime?
<Kamion> pitti: it was still in the not-ready section of the inclusion queue
<pitti> Kamion: yes, because it wasn't seeded/germinated yesterday night
<Pygi> Kamion: yes, that's why I told that...
<pitti> Pygi: I'm not 100% happy about having it in main, but if we can't avoid it...
<pitti> it seems sane enough at least
<Kamion> pitti: no, it wasn't even in that section, it was in "reviewed packages that need work before approval"
<Kamion> still is
<pitti> Kamion: oops, my fault then
<Pygi> pitti: we can't really avoid it when N-M needs it for WPA jobs
<Kamion> pitti: I routinely look in the "reviewed and approved, but not ready to promote" section anyway
<pitti> Pygi: I meant, will n-m work without wpasupplicant?
<Pygi> pitti: yes, ofcourse ...
<Kamion> pitti: I wonder if it's still worth keeping that separate from "ready to promote"
<Kamion> because the ftpmaster has to sanity-check against anastacia *anyway*
<pitti> Kamion: if you don't need it, then let's just merge them
<Pygi> pitti: it'll work, but no WPA will be available
<pitti> Pygi: that sounds indeed good
<pitti> Pygi: so what about Recommends: or Suggests: instead of Depends:?
<Kamion> pitti: mdz might have liked it I guess, but it seems like excess paper-shuffling to me
<slomo_> Pygi: and no WEP afaik? doesn't it use wpa_supplicant for WEP?
<Kamion> I've never found it valuable
<Pygi> slomo_: yes, no wep as well ;)
<pitti> Kamion: fine for me
<Pygi> pitti: I would go for recommended ...
<Pygi> pitti: what do you say?
<pitti> Pygi: the definition of 'Suggests' seems to match more closely IMHO, but I don't know how many people actually need WPA
<slomo_> pitti: i would say that nm is almost useless without wpa_supplicant... no sane wireless network has no encryption at all (it's required also for WEP)
<pitti> slomo_: hm?
<Pygi> pitti: wpasupplicant is also needed for WEP
<pitti> slomo_: I'm in a city-wide WLAN that has no encryption at all - what for?
<pitti> slomo_: the only thing that WEP/WPA provides is access control to the WLAN, AFAICS
<hunger> pitti: Lucky you... I never ever was able to use an unencrypted WLAN.
<pitti> slomo_: but in big networks that seems to work poorly, that's why they use something different here
<Pygi> pitti: yes, but do we really want it to make *that irrelevant* to put in 'Suggests'
<infinity> Pygi: Err, why would it be required for WEP?... it never was before.
<slomo_> pitti: ok, but i for one was never in a wlan that had no encryption ;) and i think every private wlan has (or should have) encryption...
<pitti> slomo_: why?
<Pygi> infinity: uh, k , sorry :-/
<Pygi> it isn't required for WEP, just WPA
<Pygi> pitti: hm, I guess we can go with 'Suggests' then
<pitti> Pygi: http://www.de.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
<infinity> I's recommend Recommends, personally.
<infinity> Since WPA is a pretty big feature of NM.
<pitti> infinity: well, WFM, but for Recommends we need it in main
<slomo_> pitti: do you want your neighbour or somebody else use your network? :) but anyway, i'm fine with recommends
<hunger> Pygi: Are you sure NM does not use wpasupplicant for both? It would be natural to do so IMHO.
<slomo_> pitti: we have many packages in main that recommend something outside of main afaik
<pitti> slomo_: alright
<infinity> pitti: Is it too sketchy/broken for supported?
<Pygi> hunger: as infinity sad, WEP can be used without wpasupplicant
<Pygi> infinity: not really, but the question is do we want to support it for 3 years in its current state
<pitti> infinity: it seems sane now, but given that wlan change their encryption method like people change their socks, I have a dizzy feeling about supporting it for 3 years
* Pygi agrees with pitti
<hunger> Pygi: Hmmm... gnome developers seem to like redundant code:-)
<Pygi> pitti: and what about "Enhances" ?
<Treenaks> pitti: WLAN encryption is stnadardized now
<pitti> Pygi: that's not yet really supported, and Enahnces is just a reverse Suggests
<Treenaks> pitti: (WPA2 is an implementation of 802.11i afaik)
<infinity> Pygi: You can put Enchances in the control file if you want, but no tools actually support it.
<Treenaks> pitti: (which is a standard)
<Pygi> infinity: oh, joy ...
<pitti> infinity: 'Enchants:'? :)
<infinity> pitti: Erm, yeah. I can type.  Really.
<Pygi> pitti, infinity: so the real question is do we really want wpasupplicant in main ... given that it's not so good as it should be, do we really think we can/want to support it for 3 years? :-/
<hunger> pitti: Even if there is a new WLAN encryption in 3 years time, then the situation will probably be like WEP/WPA at the moment. I doubt that WPA will change in itself.
<pitti> hunger: I agree, it'll just be obsolete
<hunger> pitti: Yes, like WEP is nowadays. Still you want to support that?
<pitti> I think the most important question is: is there an upstream behind it which is likely to stay around for a while?
<Kagou> hi
<Pygi> pitti: behind wpasupplicant 0.4.8? hardly...they are now working on new 0.5 brach, which is labeled as experimental development build
<infinity> That is the real question, yes, since WPA should eventually get rolled into wireless-tools, I expect.
<hunger> Maybe someone "offical" could ask them?
<infinity> No need to be official to ask such questions.
<infinity> Oh boy, another banshee upload.
<hunger> infinity: Well, the answer might differ depending on whether it is asked by famous-distribution-head-honcho or by joe-random-user;-)
* infinity waits for /dev/null to die on all the buildds.
<infinity> hunger: No, if you're asking how long upstream plans to stick around and support software, the answer is always the same.
<slomo_> infinity: sorry :( maybe we can finally find the package that breaks the world and fix it this time?
<infinity> hunger: No one's going to commit to supporting their crap for 3 years just because they like me.
<infinity> slomo_: I need to find the time to figure it out.  I can't reproduce it reliably, so it's a bit of a pain to nail down.
<hunger> infinity: Yes... I guess something like "nope, we play with the cool stuff" :-|
<infinity> slomo_: If I had to guess, I'd blame either mdadm or udev, since no other package build-deps on those (why does yours?)
<ogra> ARGH
<Pygi> pitti: it is higly unlikely that they will continue backporting fixes from 0.5 branch to 0.4.8 as they consider 0.5 to be too much experimental...and we are using "our own" patches on wpasupplicant 
* ogra wonders what the standard answer should be on bugs like: my GL screensaver crashes my box if i use Xgl/compiz 
<HrdwrBoB> where "experimental" = works
<slomo_> infinity: good question... where do the b-d exactly come from?
<Pygi> yes, that is true HrdwrBoB, but do you really want to support that? :-/
<infinity> slomo_: Let me hunt that down for you.
<hunger> ogra: Xgl is experimental, so that is to be expected.
<Pygi> HrdwrBoB: and no, it doesn't work for anyone
<ajmitch> hunger: yes, but the frustration of getting many, many bug reports like that.. :)
<hunger> ogra: Plus xgl does not support direct rendering by apps which is probably what the gl screensaver is doing.
<ogra> hunger, yes, but is the workload that crap puts on me also to be expected ? 
<ogra> damned
<infinity> slomo_: libnjb5 depends on "udev | hotplug" ... That's obviously just plain wrong.
<Pygi> ogra: just tell them them to stop reporting such bugs ^
<Pygi> not that they will listen, but...
<ogra> exactly 
<infinity> slomo_: You should change that to a Suggest, perhaps.
<ogra> *sigh*
<hunger> ajmitch: Is that at all surprising?
<infinity> slomo_: (or remove it completely, since an Ubuntu system without udev is pretty rare)
<slomo_> infinity: sure, will do... but don't ask me why it depends on those :)
<Pygi> pitti: so, what we will do? :-/
<pitti> Pygi: well, it seems I'm overturned by the large number of people who need WPA :)
<pitti> Pygi: really, I'm fine with putting it into main if it helps many people
<pitti> Pygi: but please make it a Recommends: nevertheless, so that it can be uninstalled
<slomo_> infinity: hm, was added by the debian maintainer in the last version we synced... anyway, let's move it to suggests
<hunger> pitti: I need WPA, but I do not need it in main.
<infinity> slomo_: Yeah, I saw the Debian changelog.  He changes the "hotplug" depends to "udev | hotplug"... Changing one to the other is correct, but it should never have been a Depends in the first place. :)
<pitti> hunger: but you know what wpasupplicant is, presumably :)
<hunger> pitti: I'll probably switch to dapper+1 as soon as the archives are opened for that;-)
<slomo_> infinity: ok, uploaded :) can you delay banshee until this is built?
<Pygi> pitti: I don't think having wpasupplicant in restricted for example, is bad...people who need it, will just install it
<infinity> slomo_: And it would appear that's what's pulling in mdadm as well (through a lovely udev -> initramfs-tools -> mdadm dependency chain), though that won't happen anymore with the latest initramfs-tools.
<hunger> pitti: I am using it for a long time now...
<pitti> so either we say 'yes, we want WPA', then we need to commit to that and put it into ship, or we say 'sucks to be you' and entirely leave it in universe
<infinity> slomo_: Not easily.  I'll just clean up if it breaks.  No big deal.
<Pygi> pitti: why not restricted?
<pitti> but if it's really that important, then it rather sounds like we shoould do (a)
<infinity> slomo_: And we can see on your NEXT banshee upload if that fixes the issue. :)
<hunger> Pygi: Is wpasupplicant restricted?
<pitti> Pygi: what should that be good for? isn't it free software?
<Pygi> pitti: we did the the same with madwifi -ng (puted) it into restricted
<Pygi> pitti: ah, yes, it is..
<pitti> Pygi: or does it violate patents of any kind?
<Pygi> nop
<slomo_> infinity: hehe... i think the next one could take a bit longer this time ;)
<Pygi> hm, ok, I guess we'll just have to make it recommend :-/
<pitti> Pygi: we have to support restricted as well as main
<infinity> slomo_: Note that it's the weekend for me already, so I'm trying to avoid anything that smells too much like work. :)
<Pygi> pitti: yes, I know...hm, if we put it into universe it's unlikely it will ever get fixes, patches, etc :-/
<pitti> infinity: wanna bet how long you can resist? :)
<infinity> pitti: I'll be strong.  I promise. :)
<pitti> infinity: use the force :)
<Pygi> pitti: if it's up to universe or main, I say we go for the main ... and make sure we apply proper patches if/when needed
<Pygi> pitti: and make wpasupplicant "Recommended" of N-M
<hunger> Pygi: If it is a recommend, then it will not work out of the box. Then it can go into universe as well IMHO.
<Pygi> hunger: bah, do we erally want to make it "Depend"??
<Pygi> really*
<hunger> Pygi: if you don't then a normal user won't be able to set up a wpa connection without help.
<infinity> hunger: All high level package managers will install Recommended packages by default.
<hunger> Pygi: wpasupplicant can then just as well go into universe.
<Pygi> pitti: thoughts?
<hunger> infinity: They do?
<infinity> hunger: If we're not putting NM in -desktop (we're not), then the only way users will install it is manually.
<hunger> infinity: I never used one.
<Pygi> hunger: no, it universe it's less likely to get proper support
<pitti> Pygi: recommends, and putting it into ship should DTRT, shoudln't it?
<infinity> hunger: And if you're assuming "stupid users", you assume they use "stupid user package management", which will always pull in recommends by default.
<pitti> infinity: aptitude won't install recommends if they are in ship?
<hunger> infinity: Oh, then why move it into main at all?
<infinity> pitti: Oh, if it's a ship/supported split, and all you have is the CD, then it won't work, yes.
<infinity> pitti: We'd need to explicitely seed wpasupplicant to ship to make the CD corner case work.
<pitti> infinity: I mean, if both n-m and wpasupplicant are in ship, then I don't see a problem with recommends
<infinity> pitti: Right.
<pitti> infinity: yes, that's what I was up to
<Pygi> pitti: yes, agreed...
<Lure> WPA is becoming mainstream and I think it makes sense it is always installed with NM (=depends)
<Pygi>  Lure: bah, you haven't been following all..
<hunger> Oh, I'll just shut up. You will do the right thing anyway.
<ogra> fabbione, ping
<Pygi> hunger: nah, just say your opinion
<fabbione> ogra: pong
<infinity> Lure: Nah, Debian packaging is as much about choice as anything else.  If WPA isn't a REQUIRED feature of NM (and it's not), it's best as a Recommends (if "most" people want it) or a Suggests (if "some" people want it)
<Pygi> pitti: do we have place on CD for wpasupplicant?
<ogra> bug #34584
<Ubugtu> Malone bug 34584 in gnome-screensaver xserver-xorg-driver-ati "screensaver flicker ati" [Normal,Confirmed]  http://launchpad.net/bugs/34584
<pitti> Pygi: the default answer is always 'no' :)
<Pygi> pitti: I got the impression that it's "no" ;)
<fabbione> ogra: yes?
<Treenaks> Pygi: Unless you go back in time and invent bigger CDs, that is
<pitti> Size: 231746
<Pygi> pitti: ah, I knew it... but can we squeeze it in? ;)
<hunger> Pygi: I am for both in desktop and thus main or both in universe (but maybe on the CD).
<ogra> fabbione, intrestingly i can neither reproduce it on my amd64 lappie with nvidia card (amd64/i386) nor on my ibook ati ..
<pitti> well, that doesn't look too  bad
<Lure> infinity: if recommends means that you will get it with NM, then I think this is the right mode
<infinity> Yeah, 200~250k, depending on arch.
<infinity> That's a biggish package, but not horrible.
<ogra> fabbione, the flickering seems to appear only with certain ati cards
<fabbione> ogra: well they say that it is gnome-screensaver.. because it works with xscreen saver
<infinity> Lure: Recommends means that if you use high-level package management (aptitude, synaptic, etc), you'll get it by default, yes.
<hunger> Pygi: But then... if you got wlan you usually got broadband as well and can damn well grab the stuff of the net.
<Pygi> pitti: as far as I can tell, wpasupplicant is not that big ... so squeeze it? ;)
<fabbione> ogra: and i recalled some gnome-screensaver flickering issues
<ogra> fabbione, and its reproducable in xscreensaver if you switch the visual for the screensaver from GL to default
<Pygi> hunger: yes, but if it is in main, and we ship n-m, it'll be good to have it on the cd
<Mithrandir> fabbione: I'm grabbing the xorg lock
<Lure> BTW, what is Debian doing - depend or recommend?
<pitti> Pygi: yeah, yeah, you folks should just say that we don't need langpacks :)
<mvo> Lure: synaptic has a option for this (in preferences) 
<fabbione> Mithrandir: sure
<Pygi> pitti: nah, we need langpacks ;)
<pitti> Pygi: (nm, we'll squeeze it in, I suppose)
<infinity> Lure: Debian would almost certainly go with Recommends or Suggests, given that they're completely splitting the package to make it modular.
<fabbione> ogra: ok.. you can reassign it back if you want
<ogra> fabbione, so my question is, can it be related to the ati driver and the handling of visuals there ?
<Pygi> pitti: yes, about nm ... but wpasupplicant...
<infinity> Lure: They're splitting out all the VPN/PPTP stuff, etc.  Specifically so people can pick and choose.
<hunger> Pygi: I do not think that it makes sense to have one but not the other.
<pitti> Pygi: sorry, nm == nevermind 
<fabbione> ogra: yes it could
<ogra> hmm,k
<Pygi> pitti: ah, ok ;) great :-D
<ogra> its one of my little nightmare bugs :)
<Kamion> pitti: somebody appears to have put wpasupplicant into the minimal seed, BTW, in case you hadn't noticed
<simira> ogra: the flickering screensaver? Is that yours?
<Lure> infinity: OK - I am all for recommend with your great explaination
<Lure> ;-)
<pitti> Kamion: minimal??? *gulp*
<Pygi> pitti: I'll need to poke keybuk to make it recommended I belive, as I have no more powers over the package (or do I?), as Scott is official maintainer now
<ogra> simira, yes
* infinity wonders if he should switch his WAP from WEP to WPA (ooh, nice TLAs) to test the new NM...
<Kamion> pitti: I won't promote it until that's been decided on properly
<pitti> Pygi: you have as long as it's still in universe
<pitti> Kamion: it seems that after this discussion, ship seems to be the right place
<Pygi> pitti: it has been promoted to main
<Pygi> Kamion: shipping, making wpasupplicant recommeded
<pitti> Kamion: I assume the plan is still to put n-m into ship?
<Lure> infinity: you should, unless you have unsupported card (or badly behaving one like madwifi)
<infinity> Lure: well, it's just about testing here.  I don't care about the security aspect.  I only have WEP enabled for testing purposes too.
<infinity> Lure: I normally just run with MAC filters.  If people want to sniff my traffic or spoof a MAC, they're welcome to it.
<Lure> infinity: ;-)
<infinity> Lure: Anything I do that's "private" is encrypted in other ways anyway (ssh, pgp, etc)
<Pygi> pitti: k, so we've settled that ^_^
<pitti> yes, I think so
<Pygi> anything else to settle regarding n-m? 
<hunger> Pygi: knetworkmanager?
<Pygi> hunger: we are still to see what is going to happen with knetworkmanager ... I  hope we can get it into main, but ...
<Pygi> hunger: so KDE people can have it :-/
<Pygi> pitti: how should we go with knetworkmanager? first inclusion into universe, then promotion to main?
<Lure> hunger: knetworkmanager is waiting for NM-dev packages in order to be able to build it with VPN
<pitti> Pygi: yes, please
<Lure> hunger: then we need to get FF exception (as kNM was not in Dapper yet!)
<Pygi> pitti: but I suppose we won't be able to ship that on kubuntu cd? 
<pitti> Pygi: why not?
<Pygi> pitti: well, the default "no" for place on cd ;)
<Lure> Pygi: why not - kNM is simple code that could be accepted to main
<Lure> Pygi: NM was the hard part
<pitti> Pygi: right, that requires a beer or two for Riddell 
<Pygi> pitti: told you ^_^
<Pygi> Lure: no, the cd is full ... it is always full ^_^
<Pygi> pitti: considering that we need to put wpasupplicant also on kubuntu cd :-/
* Pygi pokes Riddell
<pitti> the question is never whether we have space for something new -- it's always 'what do we kick in favor of this one?'
<dholbach> Kamion: thanks for the UVF approval
<Lure> Pygi: Kubuntu CD will have plenty of space if Ooo is replaced with KOffice (just joking ;-))
<Pygi> Lure: joy
<Pygi> pitti: yes, but we can't really kick something important :-/
<Pygi> pitti: and what are we to kick from ubuntu cd because of wpasupplicant? :-/
<pitti> Pygi: that's where the beer and Riddel come into play
<pitti> and Riddell, too
<Pygi> pitti: hm, ok, I guess you will talk to him ... or should I?
<pitti> Pygi: I think you'd do better, I don't have a strong motivation for wpasupplicant :)
<pitti> Pygi: and seb128 always hits me so hard if I say a K-word
<Pygi> pitti: bah, me neither actually, but a lot of people want it ;)
* pitti hugs seb128
<Pygi> pitti: lol ;)
* seb128 hugs pitti
<Pygi> pitti: what? Kubuntu? ;)
<Lure> pitti: why would Riddell need to drop something for wpasupplicant - it is needed for Ubuntu
<pitti> seb128: HE SAID IT! HE SAID IT!!!
<Pygi> Lure: NO PLACE
<Pygi> seb128: what? ;)
<Lure> Riddell just need to find something for space for knetworkmanager...
<Pygi> Lure: bah, leave it to me... I'll talk to him ^_^
<Pygi> Lure: you just make sure Knetworkmanager hits the universe
<ajmitch> simple, just put gnome on the cd instead
<Pygi> pitti: why is the Kubuntu so important? ;)
<Pygi> s/Kubuntu/Kubuntu word
<seb128> pitti: what? That I'll kick you if you use a k-word? :p
<pitti> Pygi: nevermind
<Pygi> pitti: ah, ok :-/
<pitti> Pygi: just bitching
* Pygi loudly shouts Kubuntu word at seb's ear
<siretart> oh, there is already a main inclusion report for wpasupplicant.. interesting..
<mdke> sladen, volume hotkeys working nicely on my thinkpad, except the mute button mutes and doesn't remute. can I put that on the tpb bug, or shall I file a separate one? if a separate one, is it gnome related, or hotkey-setup related?
<mdke> s/remute/unmute
<Pygi> siretart: heh
<sladen> mdke: the mute key never unmutes on thinkpads.  You press up/down to unmute
<mdke> sladen, are you sure? I could have sworn I've always used it like that.
<sladen> mdke: it's hotkey-setup, but it follows the design of the hardware (it's how ThinkPads have worked for since RMS had a PDP-11 in at his nursery school)
<mdke> ok
<seb128> Kamion: thank you for the libcairo UVF approval. Should I send ChangeLog with it instead of NEWS only next time?
<infinity> mdke: On my thinkpad, mute's always been a one-way thing.
<mdke> infinity, well, given that you have the same as me...
<infinity> mdke: T43?
<mdke> :)
<mdke> yes
<infinity> Yeah.  It's never un-muted. :)
<infinity> Volume up to unmute.
<mdke> ah ok
<mdke> the gnome mute dialogue is incredibly confusing
<sladen> mdke: how so?
<seb128> mdke: you would like a striked speaker icon?
<sladen> mdke: would it be better if it showed the volume level at zero when muted?
<mdke> it doesn't have the red cross in it which the applet has, so it looks like it's telling you it's not muted
<mdke> seb128, that's exactly what I'd like :)
<sladen> seb128: I like the one at the moment.  What about the current icon with a small [x]  in the corner
<seb128> mdke: there is some bugs and dup about it
<mdke> seb128, cool. is it too late for gnome to fix it?
<seb128> sladen: I'm fine with current one, but if somebody wants to send a patch using a different icon and if it looks nice I'm fine to use the patch
<Kamion> Pygi: what makes you say that wpasupplicant has been promoted to main? (it hasn't)
<Kamion> pitti: n-m ship> yes
<seb128> mdke: probably for that cycle, UI freeze
<mdke> hmm
<Pygi> Kamion: yes, it still isn't in main ... but it will be  ^_^
<mdke> seb128, in that case, a good alternative would be for it to show the volume level as zero, as sladen suggests. I think the best would be to use the same icon as for the applet though
<seb128> we can change the icon
<seb128> I might have a look on it later
<Kamion> seb128: in general, yes, especially when mdz asks you for it (which I guess you missed) ;-)
<seb128> all those are small details
<Kamion> seb128: send NEWS as well if available, since it's usually a useful summary
<mdke> seb128, that would be great
<seb128> but we have a long list of small details, so not easy to take everything
<Kamion> seb128: unfortunately NEWS in this case was not very useful really
<seb128> Kamion: oh, he did? Oh, I took the question about 1.0.3
<seb128> Kamion: I had a look on the ChangeLog before asking for the UVF but I was not sure if that was something too verbose to send or not. Noted for next one :)
<infinity> Kamion: Do you know if there's been any movement on making the queue tool less hideously confusing?
<Pygi> pitti: around?
<infinity> Kamion: I did a binary NEW of libsvn-javahl/sparc earlier today, and was amazed at the hoops I had to jump through to figure out what was new, what priority it should be, etc, etc.
<pitti> Pygi: yes
<sladen> mdke: btw, when you press volume up, are the steps smaller than volume down?
<Pygi> pitti: just talked to Riddell, he says we can squeeze it in 
<mdke> sladen, yes
<Pygi> pitti: altought I did somethin' silly first ;) lemme quote it for you...
<Pygi> pitti: "Pygi first pays Riddell a bear or two then talks to him"
<pitti> lol
<Pygi> lol ;)
<pitti> Pygi: most of the Ubuntu folks prefer a pony, btw
<Pygi> pitti: lol ^_^
<seb128> sladen: might be a feature
<seb128> the steps not beeing the same both way
<seb128> it allow you to move quite quickly one way
<mdke> sladen, i quite like it, assuming that is the actual behaviour :)
<seb128> and then to adjust
<mdke> it's nice to move down quicker
<infinity> sladen: I view that as a feature, since you often want it "quieter NOW, dear god!", but you want control when going up.
* Tm_T is more llama person
<sladen> infinity: it's probably one of those real-world UI improvements that just never got done because normal users couldn't accept it
* _ion is a giraffe/squirrel person.
<Pygi> _ion: bah ;)
<Kamion> infinity: I keep bugging cprov, but he seems to think that coding style improvements are more important
<Tm_T> _ion: 7join #animal-perversions eh?
<_ion> tm_t: http://johan.kiviniemi.name/tmp/giraffe_licks_squirrel 
<infinity> Kamion: Ahh.  Well, he's on VAC (marriage/honeymoon) now, so I guess we deal with what we have for a while.
<pitti> infinity: oh, cprov is not there?
<simira> who is cprov?
<pitti> simira: our Soyuz god
<infinity> pitti: He's either just leaving the sprint now/soon, or has already left.
<pitti> ah, thanks
<infinity> pitti: He gets married this weekend, so was cutting it a bit close. :)
<simira> must be something going..
<mwright1night> Is the Firefox maintainer about,  check out this bug: It affects all users outside of the USA...  https://launchpad.net/distros/ubuntu/+source/firefox/+bug/10910
<Ubugtu> Malone bug 10910 in firefox mozilla-firefox "Default page size for printing is letter" [Normal,Unconfirmed]  
<Kamion> infinity: wow, didn't know he was getting hitched
<mwright1night> Default paper size is letter, AND the setting can't be changed in any way (only on a per print basis)
<Kamion> infinity: bug 30933, incidentally
<Ubugtu> Malone bug 30933 in launchpad-upload-and-queue "queue should show me which binaries are new" [Wishlist,Confirmed]  http://launchpad.net/bugs/30933
<infinity> mwright1night: It's not pulling it from /etc/papersize, is it?
<Kamion> (if you want to subscribe)
<mwright1night> nup
<infinity> Kamion: Thanks, done.
<Kamion> infinity: also, that's weird, because I NEWed libsvn-javahl on the other architectures. It must have hit NEW at the point when the binaries I processed were in accepted, which seems to be where the race happens
<infinity> mwright1night: So, that's correctly set to a4?
<Tm_T> _ion: nam
<Kamion> (empirically)
<mwright1night> yep
<infinity> Kamion: Yeah, all of soyuz appears to race on accepted.
<mwright1night> This is an upstream bug, however in my terminal server environment is its in the top 4 worst bugs for end users
<infinity> Kamion: (hence yesterday's fiasco)
<Kamion> yeah
<infinity> mwright1night: I don't suppose you can find it in upstream's bugzilla?
<infinity> mwright1night: (No, I'm not the firefox dude, but I'd still be interested in adding more info to the bug)
<mwright1night> yer I can
<mwright1night> and the redhat bug
<infinity> mwright1night: Excellent.
<infinity> mwright1night: Hook 'em all up to the LP bug. :)
<mwright1night> give me a minute, I upgraded my redhat server to FC5 where I keep my mail, FreeNX broke and now I cant' get my email
<infinity> Oh, I didn't even look at the bug...
<infinity> This is ancient, and has the mozilla bug in it already.
<mwright1night> let me check if that's the right mozilla bug though
<mwright1night> i'll confirm
<mwright1night> I think it is
<mwright1night> something needs to be done about it, I Had to replace 4 printers, to buy ones that had A4/letter auto override just to accomodate that
<mwright1night> costs our not for profit organisation 15k AUD
<mwright1night> so do you think it's an important bug?
<mwright1night> to get resolved
<mwright1night> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133658
<infinity> mwright1night: You may want to bring iwj's attention to the bug.  It shouldn't actually take much patching to shoehorn the feature in there, assuming the mozilla suite only does paper size selection in one fairly isolated are in the codebase.
* infinity fins it rather funny that the bug was submitted in 2002 by someone who's now a Canonical employee.
<mwright1night> yes that is the correct upstream bug number, one of the distros needs to fix it then send it upstream, cause they don't care to fix it
<mwright1night> if not geeks start to use this software, this is the kind of thing that makes the user experience really frustrating
<infinity> Oh, fun.  network-manager build-deps on wpasupplicant, I didn't notice that.  So the promotion needs to happen regardless.
<_ion> infinity: It shouldn't build-dep on wpasupplicant.
<mwright1night> infinity: who is iwj?
<ogra> mwright1night, Diziet
<ogra> our firefox hero
<_ion> From the package i have here: Build-Depends: automake1.9, debhelper (>= 4.1.0), patchutils (>= 0.2.25), intltool, libtool, libiw-dev (>= 27+28pre9), libdbus-glib-1-dev (>= 0.60), libglib2.0-dev, libhal-dev (>= 0.5.0), libgtk2.0-dev, libglade2-dev, libgconf2-dev, libgnome-keyring-dev, libnotify-dev (>= 0.3.0), libnl-dev, libgcrypt11-dev, libpanel-applet2-dev, libgnomeui-dev
<mwright1night> ok I left him a proivate msage
<infinity> _ion: keybuk's package clearly build-deps on it, cause my buildds all dep-waited the package. :)
<infinity> And my regexes are never wrong!
<_ion> Interesting.
* infinity goes to check if his regexes were wrong.
<_ion> Is keybuk's source package available from somewhere? I'd like to diff my source to it.
<infinity> _ion: Yeah, the source should be in the archive.
<infinity> Build-Depends: debhelper (>= 4.0.0), gnome-common, intltool, libgnome-keyring-dev, libdbus-glib-1-dev (>= 0.60), libiw-dev(>= 27+28pre9), libhal-dev, libgnomeui-dev, libpanel-applet2-dev, libglade2-dev, libgconf2-dev, docbook-to-man, libnl-dev, wpasupplicant
<stub> Launchpad is going down in 25 minutes for updates. Downtime will be approx. 10 minutes. Wikis will be in read only mode during this time.
<_ion> infinity: Seems like those dependencies were copied from some completely different package.
<_ion> infinity: That package doesn't use e.g. docbook-to-man.
<infinity> _ion: Probably.  He didn't use your package, just used some of your patches/changes, afaik.
<_ion> infinity: I think one should be able to remove dockbook-to-man and wpasupplicant from the Build-Depends line without any problems.
* infinity would love a way to have his default gnome-keyring be unencrypted.
<infinity> The only thing in there is my WEP key... And the password protecting the WEP key is more secure than the key itself.
<infinity> Which seems pointless.
<_ion> :-)
<infinity> I don't dig having to log in twice (effectively).
<infinity> That's my only gripe with NM, really.
<infinity> (Well, my only major gripe... Lots of minor ones)
* ..[topic/#ubuntu-devel:Kinnison] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Flight 5 released | If your initramfs is broken in any way, please save a copy for infinity | UI sprint in #dapper-look | LP/Soyuz down for upgrade
<infinity> Kinnison: Bah, like anyone reads the topic anyway.
<infinity> Kinnison: (Guess how many broken initrds I get sent to me)
<ogra> thats probably because they simply arent broken ?
<ogra> :)
<infinity> Nice theory, but I get enough complaints.
<infinity> And I say "did you save me a copy, like the topic asks for?"
<infinity> And they go "Oh, no, I didn't see that, I just dpkg-reconfigured and it works now"
<infinity> And I die a little inside.
<KaiL_> infinity, that's life - and the same effect, you can see in EVERY web-forum. There you'll read hundreds of complains, that something important doesn't work. But how many bugs marked "critical" exist?
<ogra> evil users !
<infinity> I'd love it if someone would go through the Ubuntu forums and try to file some bugs on behalf of people with weird problems.
<ogra> letting you die ..
<infinity> But it's not something I have the time for.
<KaiL_> infinity, forget it - 99% of those problems are PEBKAC
<infinity> The ubuntu-users mailing list is full of "this is horribly broken and must be fixed before release!!" stuff too, but no one on the list ever seems to suggest that the users in question should file a bug.
<KaiL_> and the last 1% is so bad described, that you can't find out, what he means
<infinity> KaiL_: Sure, many are, but some aren't.  And the non-problems still get lost, because we don't read the forums, cause we just plain don't have the time.
<infinity> err, non-PEBKAC problems, that is.
<KaiL_> so just fix those bugs, which find the way into LP :)
<mdke> a bug filing team...
<KaiL_> like the ~15 I reported last week (of which at least 5 are from crying friends..)
* ..[topic/#ubuntu-devel:Kinnison] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Flight 5 released | If your initramfs is broken in any way, please save a copy for infinity | UI sprint in #dapper-look | Soyuz updated, report issues in LP
<sivang> hrm, since last update *last night) my panles are complete mess, no ALT-TAB, and no workspace switching, any ideea ? :)
<sivang> panles , even
<Treenaks> panels, too :P
<sivang> Treenaks: what's the idea ? :)
<Treenaks> no idea
<Treenaks> still works fine for me
<sivang> what about keyboard setup, do you have ALT-TAB and ALT-F2 working as expected?
<Treenaks> yes
<Treenaks> (I updated last night, too)
<Kamion> infinity: hmm, queue output just changed somewhat, I have a suspicion some of our problems may be answered
* infinity logs in to look.
<Kamion> at least, I see a star there, that might maybe disappear when a binary is already overridden, or something
<Kamion> no examples of binary-new to check with at the moment, though
<Kinnison> Kamion: have you done vim-ruby already?
<infinity> Yeah, I see...
<infinity> vim was ages ago.
<Kinnison> well it was worth a thought
<infinity> I could do a gratuitous upload and reject it. :)
<Kamion> I've been trying to keep new pretty clear of late
<infinity> I noticed that.
<infinity> What's the deal on the ifolder/libflaim business in there?
<infinity> Also, uhm, why is the newest not at the bottom anymore?
<infinity> That seemed intuitive and Correct to me.
<infinity> Kamion: Did you request that the queue sorting get inverted, or is this a bug?
<Kamion> I didn't request it; presumably somebody thought it was a good idea ...
<Kamion> I dunno, I can see arguments either way
<infinity> Seems entirely backwards, since it's a CLI tool, you want the more recent stuff closer to your prompt.
<infinity> I'd think.
<Kamion> you could argue that older queue items ought not to be forgotten
<Kamion> although on balance I did prefer the older order
<infinity> They won't be forgotten, once you clear out the ones you really care about at the bottom. :)
<Kamion> infinity: ifolder/libflaim are pending an e-mail conversation with Mez that I need to get back to
<infinity> Ahh, check.
* infinity wonders if the sorting really did get inverted, or if the sorting's just buggy and not working anymore.
<Kamion> infinity: it's a bit harder when you're dealing with a queue 70-odd items long, which it was when I first started poking at the Soyuz queue
<infinity> Kinda hard to tell with so few things in the queue.
<Kamion> 'queue -R breezy -Q unapproved info \*' is inverted, so I think it's consistent
<infinity> Check.
<mvo> Kamion: you want some discussion about debconf/gnome and the upgrade tool? what is your preferred time for this?
<mvo> Riddell: I uploaded new app-install-data, it should be more complete now (fixed some bugs). I checked various kde apps and the icons are extracted so adept_installer should find them
<Riddell> mvo: great, thanks, will take a look
* mvo goes for lunch
<mvo> Riddell: most kde icons seems to be xpm, no idea if that is good or bad (or dosn't matter)
<mvo> Riddell: oh, and it's pretty big :)
<Riddell> mvo: no kde icons are xpm
<TheMuso> Mithrandir: ping
<Kamion> mvo: now's fine, just want to know what the problem is
<Mithrandir> TheMuso: pong
<mvo> Kamion: i'm about to leave for lunch
<Kamion> fine, after lunch is good too
<Kamion> I'm here all day, thankyou, etc.
<TheMuso> Mithrandir: http://www.themuso.id.au/ubuntu/casper -- An update to the accessibility script. Not much was trimmed, as most of the settings that are set in the profiles are not otherwise desired by other users if that makes sense. :)
<TheMuso> Just passed a patch to dholbach to move important settings into the necessary packages.
<_mvo_> Riddell: sure? http://paste.ubuntu-nl.org/10718 shows some in kreversi
* _mvo_ kicks his wlan
<_mvo_> Kamion: maybe after lunch? I'm about to leave for lunch
<Kamion> _mvo_: fine
<Riddell> mvo: the debian packages do still have some xpm icons, but the KDE icons are all PNG.  kreversi has hi128-app-kreversi.png ./usr/share/icons/hicolor/128x128/apps/kreversi.png
<_mvo_> Riddell: hm, the extractor is not smart enough to decide which on to pick then and he preferes standard locations (/usr/share/pixmaps)
<Riddell> /usr/share/pixmaps is obsolete, /usr/share/icons is the standard
<ogra> seb128, thanks ! :)
<seb128> ogra: you're welcome
<mdke> sladen, the chap for whom the thinkpad hotkeys don't work on bug #341 says that he uses xfce, could this be the difference?
<Ubugtu> Malone bug 341 in Ubuntu "tpb doesn't work" [Normal,Fix released]  http://launchpad.net/bugs/341
<mjg59> mdke: xfce doesn't do visualisation of volume controls, I suspect
<mdke> mjg59, i suspect so too. so it's a choice between using tpb (works with any desktop), and hotkey-setup (works with GNOME only)?
<mjg59> Or xfce getting its act together
<mjg59> tpb is not an acceptable general answer
<mjg59> Any user who can use tpb can render the system unbootable
<mdke> mjg59, i suppose there isn't any possibility of the hotkey-setup solution becoming desktop independent?
<mjg59> It /is/ desktop independent
<mjg59> It sends standard keycodes
<siretart> mdke: you just need to configure your desktop to react on those keycodes
<siretart> mdke: therefore hotkey-setup integrates more nicely than tpb
<mdke> i see. well I'm happy anyway, because I use gnome :)
<jsgotangco> too bad for others though
<mjg59> (Well, they could, I don't know, fix the desktops...)
<mdke> well, they haven't lost anything, because their desktop *never* did have visualisation of volume control
<siretart> gnarf. stupid acx111 not being able to do wpa on their own :(
<mdke> siretart, what acx111 have you got?
<siretart> mdke: I'll look
<siretart> mdke: Texas Instruments ACX100 PCI adapter
<siretart> this is my brother's machine :/
<mdke> i've got one of those. siretart, did it work out of the box?
<mdke> although I think there are lots, with different firmware
<mdke> seb128, do you know whether gnome-sudo has been replaced by another command in dapper?
<Treenaks> gksudo?
<mdke> could be
<ogra> ogra@edubuntu:~$ apt-cache search gnome-sudo
<ogra> gksu - graphical frontend to su
<ogra> :)
<mvo> Kamion: I think I found the cause of the debconf/gnome fontend problem, my bad
<siretart> mdke: WEP worked for me out of the box, yes
<mdke> ogra, it seems to have disappeared from gksu between breezy and dapper
<mdke> siretart, cool
<siretart> mdke: now I switched my home network to wpa, but now I read this: http://acx100.sourceforge.net/wiki/WPA
<seb128> mdke: did we have a such command once?
<mdke> seb128, in breezy
<seb128> are you sure?
<ogra> ogra@edubuntu:~$ apt-cache show gksu|grep Provides:
<ogra> Provides: gnome-sudo
<mdke> seb128, yeah, I'm on breezy now
<siretart> hm. seem that I have to fiddle with ndiswrapper :(
<seb128> mdke: dpkg -S `which gnome-sudo`
<mdke> siretart, WEP has only supported for about 6 months :)
<seb128> ogra: Provides is for packages not command
<ogra> seb128, i know
<mdke> seb128, gksu: /usr/bin/gnome-sudo
<seb128> mdke: ls -l /usr/bin/gnome-sudo ?
<seb128> (maybe it used to ship a compatibility command)
<ogra> but there was a package called gnome-sudo once that provided /usr/bin/gnome-sudo
<mdke> seb128, -rwxr-xr-x  1 root root 32 2005-10-18 06:09 /usr/bin/gnome-sudo
<seb128> mdke: cat /usr/bin/gnome-sudo
<siretart> mdke: I'd rather say for a couple of GB of traffic
<mdke> seb128, yes, it's gksudo :)
<mdke> thanks
<seb128> that's weird that you ever suggested that one
<seb128> we use gksu for everything since warty :)
<seb128> gksu or gksudo
* mdke shrugs
<mdke> we inherited it from the unofficial ubuntuguide, I think
<ogra> but there was a gnome-sudo package pre warty
<mdke> I'll update it
<mjg59> siretart: That's the normal state of WPA support
<seb128> ogra: that's not the point, stop arguing on that
<mjg59> siretart: We do it all in userspace
<ogra> i guess it got merged for backwards compatibility
<seb128> mdke: thank you
<seb128> ogra: we are not discussing why it got merged, but why people were still using a stuff deprecated for ages now
<ogra> ah
<mdke> seb128, thanks
<ogra> sorry then 
<siretart> mjg59: err, right, but the kernel has to provide some extensions for wpa support. 
<mjg59> siretart: Yes. And they claim that the acx driver does
<siretart> mjg59: who claims that?
<siretart> http://acx100.sourceforge.net/wiki/WPA claims that you need ndiswrapper for that :(
<mjg59> http://acx100.sourceforge.net/wiki/WPA implies that the necessary wireless extensions are in the driver (though untested)
<siretart> mjg59: if that means that wpasupplicant needs another driver backend, than thats not written (yet)
<Treenaks> siretart: they're unifying WPA upstream
<Treenaks> siretart: into the 'standard' wireless extensions
<siretart> Treenaks: they tell driver developers to implement WE19, I know
<Treenaks> siretart: so you don't need 600 backend modules for wpasupplicant anymore
<mjg59> siretart: No, it doesn't mean that
<siretart> Treenaks: AFAIK only ipw2200 (and perhaps ipw2100) implement that sufficiently :(
<mdke> seb128, by the way, should a tip on how to open files as root in nautilus even be in the guide, in your opinion? does it carry security problems?
<Treenaks> siretart: and prism54
<mjg59> It's actually pretty trivial to add the support
<siretart> mjg59: I just tried breezy/acx100.ko with wpasupplicant_0.4.8 - no luck with any driver backends
<mjg59> siretart: The only one which would have any chance of working is wext. If that doesn't work, it's a failing in the driver and we can fix that
<siretart> Treenaks: I'd be happy if madwifi and acx would implement WE19 soon. but I don't see that happen in short time
<Treenaks> siretart: Why not?
<siretart> Treenaks: madwifi upstream doesn't consider WE19 important
<mjg59> madwifi is probably harder due to it being made out of string
<siretart> mjg59: so I shall try upgrading to dapper and see if wext works there?
<siretart> I intended to do that tomorrow anyway
<mjg59> siretart: It's worth a go. If it still doesn't work, then file a bug.
<siretart> mjg59: ok. will do
<infinity> madwifi upstream actually seems to have become more receptive to WEXT in the last week or two.
<infinity> They've been asking for specs and pointers on how to support the current API.
<infinity> (Which will most likely just end up as wrapper around their own interface for now, but that's fine)
<Treenaks> infinity: wow.. madwifi devs, listening to demands?
<mdke> what do other people think? is it a bad idea to document a nautilus script which permits you to open files as root from the file manager? if so, what are the hazards, perhaps we can include an appropriate warning
<neuralis> mdke: what's the use case?
<mdke> neuralis, browse to /etc, right click fstab, select Scripts -> Open as root
<mdke> for example
<neuralis> mdke: it should say 'open as administator', but other than that, there's no real hazard. you're not doing anything that a user can't already do via sudo.
<neuralis> mdke: no such action should exist for 'execute', though. that'd be evil.
<mdke> it uses gnome-open
<mdke> good point on the s/root/administrator
<mdke> neuralis, does gnome-open execute stuff?
<neuralis> mdke: let me check.
<siretart> infinity: do they plan that wrapper for madwifi-ng only or for madwifi-old as well?
<neuralis> mdke: "Error showing url: There is no default action associated with this location."
<neuralis> mdke: that's for a binary, so it appears not.
<mdke> neuralis, ok, I'll include a health warning anyway
<neuralis> mdke: another warning on top of gksudo asking for the root password seems a bit overbearing.
<mdke> neuralis, just a warning in the documentation, not in the script
<neuralis> mdke: ah, okay.
<infinity> siretart: Only -ng, the -old branch hasn't had a commit for a very long time, it's just there so people have something to use while -ng is broken.
<siretart> I see
<seb128> mdke: I don't think that explaining people how to do that if they want to do it is an issue, no
<mako> Gwynn: yes.. i'm available
<mdke> seb128, cool. thanks
<Kamion> mvo: oh, ok, cool, what was it? I asked partly because I know there was a libglib-perl/libgtk-perl issue at one point in dapper, but it should be fixed now
<mvo> Kamion: hm, i'm still investigating. it looks like a issue with the environment and the XAUTHORITY
<Riddell> infinity: kdenetwork is not compiling on those platforms because it can't find /var/run/utmp, any idea where utmp might have gone?
<infinity> Not required to be there?
<infinity> It's not in my chroots either, hence why I could reproduce it.
<infinity> And I didn't do anything fancy to "clean" my local chroots.
<doko> pitti: please can you move the locale-gen calls from the -pack into the -support packages?
<pitti> doko: hm, not move, but I can additionally do them in -support
<mvo> is the live-cd of today working? it drops me into a busybox here
<doko> pitti: fine with me
<infinity> pitti: How do you propose I get ubuntu-live installable on hppa?... Should I just unseed langsupport-* from hppa/live, or can you think of something more clever?
<infinity> pitti: (Due to langsupprt depending on openoffice packs which depend on openoffice..)
<pitti> infinity: which packages are uninstallable in particular?
<pitti> ah
<pitti> infinity: as a quick fix, unseeding certainly works
<pitti> infinity: alternatively I change the dependencies to be [i386 powerpc amd64]  or so
<infinity> Alternately, it might work if the openoffice packs didn't depend on openoffice, but that only works if they can install with it (can they?)
<Kamion> infinity: that indicates that netboot will probably be broken though
<Kamion> I'd almost rather we didn't paper over that ...
<infinity> pitti: If they're arch:all packages, you can't do that.  You can't use [arch]  in depends, only build-deps.
<pitti> infinity: oops, right
<Kamion> oh, live, I guess netboot doesn't matter
<pitti> infinity: hm, once upon a time, the ooo langpacks depended on openoffice.org | language-support-XX
<pitti> doko: ^ that's not the case any more?
<infinity> doko: Do the openoffice packs have to depend on openoffice, or is that just there to get the version right?  (which could be done with a set of conflicts instead)
<infinity> I think that's the only real thing blocking me from turning on livecds for hppa again...
<infinity> So, if we can sort it somehow, that would be awesome.
<infinity> Even if it means tying up an i386 buildd for another 12 hours on an OOo-l10n build. :)
<doko> infinity: parse error ...
<infinity> Err, wait.  The deps are correct?
* infinity scratches his head.
<infinity> Let me hop in a chroot so I can argue with this britney output. :)
<infinity> Ah-ha.
<infinity> doko / pitti: It's not the langpacks, it's the thesaurus... openoffice.org-thesaurus-en-us depends on openoffice.org-core, and you've added the thesaurus to language-support-en.
<pitti> infinity: hm, then maybe the same alternative dependency should be applied to the thesauri?
<infinity> doko: Same with openoffice.org-hyphenation-de, it requires openoffice to be installed.
<infinity> Yeah, I expect the thesauri and heyphenation packages should get the same treatment the langpacks got.
<infinity> Luckily, none of them require an OOo-l10n rebuild.
<infinity> The thesauruses and hyphenation stuff all come from a bunch of smaller packages...
<doko> infinity: ok
<infinity> doko: You okay with applying that hack to those?
<doko> sure
<infinity> They don't break without OOo installed, I hope?  (ie: postinsts fail, etc)
<pitti> at least for the similar firefox hack I had to add an if [ -x ... ]  to the postinst/prerm
<infinity> Does firefox still use evil update-chrome stuff?
* infinity is glad that's gone from thunderbird.
<pitti> infinity: nope
<Diziet> infinity: I give up.  Which package do I have to dpkg -i to reproduce https://launchpad.net/distros/ubuntu/+source/defoma/+bug/6614 ?
<Ubugtu> Malone bug 6614 in gs-common "Use of uninitialized value in print at /var/lib/defoma/scripts/gs.defoma line 108" [Normal,Confirmed]  
<ogra> Diziet, all font packages ? 
<ogra> Diziet, i see it on every flight install for every font package
<Diziet> I just installed (eg) gsfonts-x11_0.17ubuntu3_all.deb ttf-arabeyes_1.1-4_all.deb x-ttcidfont-conf_20ubuntu1_all.deb and a couple of others.
<Diziet> I see   Can't exec "locale": No such file or directory at /usr/share/perl5/Debconf/Encoding.pm line 16.
<Diziet> Use of uninitialized value in scalar chomp at /usr/share/perl5/Debconf/Encoding.pm line 17.
<Diziet> But that's something different.
<ogra> yeah
<ogra> strange
<infinity> Diziet: Grab an ISO and do a fresh test install?  I'm pretty sure the bug didn't just recently go away.
<ogra> i'm 100% sure it was there in flight 5
<Diziet> test install> I was hoping for a shortcut :-).  Fair enough.
<Diziet> Do I have to select CJK or something ?
<ogra> it happens for me in either english (uk/us doesnt matter) or german installs
<infinity> Diziet: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325598 tries to explain why it may only happen on initial install.
<Ubugtu> Debian bug 325598 in gs-common "Subject: gs-common: uninitialized value in print in /var/lib/defoma/scripts/gs.defoma" [Normal,Open]  
<Diziet> Ooo.
<infinity> Diziet: (note that the Debian bugs are linked in a portlet on the side of the Malone bug)
<Diziet> Oh, so they are.  I always ignore all of that clutter ...
<infinity> Yeah, that particular feature could be made more prominent.  I'd never look for it if I didn't already know there were linked bugs.
<ogra> at least it moved to the left and you can actually click it :)
<infinity> Oh, look.  hoary-updates appears to work.  Snazzy.
<j^> seb128 you said you might accept a patch for the osd volume icons, i attched one to use the stock icons from the current theme to launchpad 20302
<seb128> j^: thank you, I'll have a look on that later :)
<mdke> j^, rock! hope that gets in
<pitti> Mithrandir, Kamion: yay, this is the first time I went through the espresso steps without any bug :) (on ppc)
<pitti> good work!
<pitti> ... says pitti and finds the last step crashing
* seb128 should try a new espresso
<seb128> lol
<mvo> Kamion: woah, that took ages, the reason for the debconf problem in the upgrade tools seems to be a bug in gksudo that made the XAUTHORITY file (gksudo makes a private copy) cleaned up too early so the gnome frontend wasn't able to initiallize
<mvo> pitti: what image did you used? I had no luck with the current daily
<pitti> mvo: today's ppc daily
<pitti> mvo: oh, I used the live image, not the install (I'm Kamion's worst nightmare wrt. espresso testing)
<Diziet> ogra/infinity: Well, I had a Flight 1 CD.  After installation /var/log/installer/messages has no complaints about gs.defoma.
<Diziet> Ah!  I've reproduced it by reinstalling gs-common.
<sladen> mdke: oh, *xubuntu*... righto.  *ponder, ponder*
<Lure> sladen: seen you mentioned broken ACPI for HP/Compaq - is this what broke hibernate on my HP nw8240
<sladen> Lure: maybe, when did it break for you?  We might be able to track down the kernel-change/etc that did it
<Lure> kernel -18, I suppose - see bug 34617
<Ubugtu> Malone bug 34617 in linux-source-2.6.15 linux-image-2.6.15-18-386 "hibernate broken on HP nw8240 with 2.6.15-18" [Normal,Unconfirmed]  http://launchpad.net/bugs/34617
<Lure> I also had problems with daily install (not sure if related) - bug 34586
<Ubugtu> Malone bug 34586 in Ubuntu "Kubuntu Dapper 20060312 cannot install on HP nw8240" [Major,Needs info]  http://launchpad.net/bugs/34586
<Lure> I downloading Kubuntu Flight5 now to see if I can install
<Kamion> pitti: hmm, talk about a non-informative traceback :(
<Kamion> I suppose it might be fixed by the various changes in that area I've been doing today, but sadly I can't say for sure
<suck> hi.how are u?
<mjg59> sladen: Why did you just mark 34617 a dupe of 34586?
<JasonF> I just found a horrible regression in Xorg 8 that you guys might want to be aware of. I filed an ubuntu bug here https://launchpad.net/distros/ubuntu/+source/xorg/+bug/36461 and the fdo bug is here 
<Ubugtu> Malone bug 36461 in xorg "XOrg 8 dualhead regression" [Normal,Unconfirmed]  
<JasonF> https://bugs.freedesktop.org/show_bug.cgi?id=2597
<Ubugtu> Freedesktop bug 2597 in Server/general "Dual Head broken" [Major,Reopened]  
<sladen> mjg59: because the root-cause is the same.  ACPI being bust on HP's...
<infinity> JasonF: Xorg 8?
<infinity> JasonF: We're only shipping 7.0.. :)
<mjg59> sladen: Firstly, it's not - I have a 6220 here (same platform) that's working fine
<mjg59> sladen: Secondly, hibernation doesn't use any ACPI
<JasonF> er
<JasonF> infinity: version may be wrong, but the bug is in the version you ship, heh
<Diziet> defoma is completely insane inside !
<Robot101> its hardly sensible outside either... :)
<infinity> Diziet: No shit. :)
<ogra> lol
<carlos> Riddell: hi, so, are you going to upload a kde-i18n-* update today?
<sladen> mjg59: what's the best soft-keys daemon to suggest to the Xubuntu lot so that soft volume-keys work for them?
<mjg59> sladen: No idea, I'm afraid
<mjg59> acme, perhaps?
<ogra> bcm43xx-fwcutter :)
* ogra yays for Kamion
<Kamion> been meaning to do that for a while
<ogra> i just compiled it myself again today and podered to do it ... pitti as well :)
<doko> mvo: ping
<mvo> doko: pong
<Lure> just released xserver-xorg_7.0.0-0ubuntu24_all.deb seems to have bug in preconfigure script:
<Lure>  /tmp/xserver-xorg.config.122781: line 957: syntax error near unexpected token `esac'
<KaiL_> somebody killed lists.ubuntu.com?
<Burgwork> KaiL_, appears all of ubuntu.com is down
<KaiL_> at least the package server just came back to life ;)
<KaiL_> ...or not..
<KaiL_> they need ages to connect, but then everything works
<doko> mvo: did you look at the font in multiverse (moved it to universe)?
<mvo> doko: ttf-gentium? or some other font(s)?
<doko> yes
<mvo> doko: I'm in contact with the upstream person, it seems to be good quality, especially for printing
<mvo> doko: why? 
<mvo> doko: it will be part of ubuntu-desktop soon, it covers a big unicode range
<doko> mvo: cool, just for preparing OOo ...
<mvo> doko: what kind of stuff needs to be prepared?
<mvo> doko: I'll add something to fontconfig for gentium too
<doko> mvo: default font selection for docs, etc
<mvo> ah, ok
<lemsx1> /var/lib/dpkg/tmp.ci/config: line 957: syntax error near unexpected token `esac'dpkg: error processing /var/cache/apt/archives/xserver-xorg_7.0.0-0ubuntu24_all.deb (--unpack):
<lemsx1>  subprocess pre-installation script returned error exit status 2
<dholbach> have a nice evening
<bddebian> GNight dholbach
<dholbach> night bddebian
<LaserJock> cya dholbach 
<dholbach> bye guys :)
<zyga> anyone? xserver-xorg has a syntax error in postinst script
<slomo_> zyga: was fixed some seconds ago by infinity 
<zyga> 7.0.0-0ubuntu23
<zyga> oh
<zyga> thnx
<slomo_> zenrox: -0ubuntu25
* Kamion wonders if the bug tracking system is down or something, since that's three people who felt it necessary to report this by IRC ...
<zyga> hum I got -0ubuntu24
<Kamion> dude, stuff takes a while to build.
<zyga> Kamion: right, I'm sorry
<sladen> is Release signing bust?  Has a warning about every package now being untrusted
<infinity> Kamion: Two people filed it in Malone too.
<zyga> Kamion: I ought to have checked the bugtracker 
<infinity> Kamion: And a fantastic blind-leading-the-blind thread on the forums.  "Did you try 'apt-get install xserver-xorg' instead of 'apt-get dist-upgrade'?... Does that work any better?"
<infinity> "Yes, that magically puts bash in 'ignore typos' mode..."
<mdke> i would have thought that these small bugs are sometimes more easily fixed by someone reading the typo on irc and fixing it, rather than having to bother opening/closing bugs
* infinity decides that this level of sarcasm clearly means it's bedtime.
<mdke> i spose someone will always open the bug tho
<Kamion> which means that every developer reading IRC has to go "ooh, I wonder if somebody's fixed this yet", download the source packages etc., before realising that it's already fixed
<infinity> mdke: I fixed it because I spotted someone popping on IRC and pasting it... Of course, I got the bug in my INBOX about 2 minutes AFTER I fixed it, so that would have worked just as well.
<Kamion> bugs are good for tracking what's happened *as well* as the problem. :)
<mdke> Kamion, not every developer, just infinity
<zyga> OTOH fixing bugs this way gives you developer connection :-)
<Kamion> mdke: how do you know?
<infinity> mdke: No, I'm sure I'm not the only one who saw the report, went to look at -changes, saw no recent upload fixing it, then went to fix it.
<Kamion> I can prove you're wrong because I did the above ...
<infinity> mdke: The fact that my upload was ther first in just proves I have a local mirror and I type quickly.
<mdke> was just a joke
<mdke> remember what you said earlier about last-touched-it maintenance
<infinity> TILM for that bug passes to Mithrandir, but I don't think he's around right now.
<Kamion> I think the above is *why* infinity suffers from TILM so badly. :) (or would, if he let himself)
<mdke>  [08:08:01]  < infinity> If I suffered from touched-it-last maintenance, I'd maintain the whole dist by now.
* infinity is rather shocked that he even found time to TEST the package and was still the first upload in.
<infinity> I suppose others are working, while I'm just idling at 7am and pretending to sleep. :)
* infinity goes to pretend sleeping in bed instead of on IRC.
<mdke> night
<KaiL> hmm, scrollkeeper-update produces an error...
<KaiL> /usr/share/omf/serverguide/serverguide-C.omf:23: parser error : Entity 'distro-rev' not defined
<KaiL>     <description>This document is a Ubuntu &distro-rev; Server Guide. It
<KaiL> strange: this only happenes here (?!?), not on my laptop
<mdke> KaiL, can you file a bug on ubuntu-docs please
<mdke> oh actually, don't bother
<mdke> i know it
<KaiL> mdke, I'd like to find at least a second system for that - I had some hd-issues here recently
<mdke> KaiL, no, i see the bug
<KaiL> even better
* Kamion does his near-daily espresso upload and wanders off for the weekend
<mdke> KaiL, nice catch, thanks
<KaiL> well, it results in having no help here :/
<mdke> oh crap
<zyga> oh, this reminds me of something
<KaiL> uhm...
<KaiL> that wasn't all :/
<zyga> there are lots of references to undefined variables or something similar during deforma script runs
<mdke> KaiL, paste them
<KaiL> no more errors on scrollkeeper-update
<KaiL> but yelp stays empty
<mdke> KaiL, but the guy who does ubuntu-docs uploads isn't around so the fix i've done won't get uploaded until monday
<KaiL> any other script/app needed to be run to get yelp back to work?
<mdke> no, scrollkeeper-update
<mdke> sorry about that, I'll try and make sure that gets tested before each upload in the future
<mdke> if you want to fix it, edit the file and remove the &distro-rev; expression
<KaiL> I/O warning : failed to load external entity "Cannot write to log file: /var/log/scrollkeeper.log : Permission denied"
<KaiL> that's what I did, so scrollkeeper-update runs
<KaiL> but yelp starts with this
<mdke> do sudo scrollkeeper-rebuilddb
<KaiL> I/O warning : failed to load external entity "/usr/share/ubuntu-docs/common/authors/ubuntu-documentation-project.xml"
<KaiL> three times - but works
<mdke> ok, I'll fix that too
* mdke grumbles
<KaiL> is this rebould-db automatically run from time to time? would be nice, if it runs at least once on the update
<mdke> monthly
<mdke> but it runs when you install ubuntu-docs too, I think
<KaiL> doesn't look like - neigher that nor the normal scrollkeeper-update
<KaiL> rebuild-db takes VERY lonk on slow computers :/
<KaiL> now I guess, we have the next bug :)
<KaiL> on one laptop here, I only ran scrollkeeper-rebuilddb, and did NOT fix the &distro-rev; before... and now yelp works
<KaiL> looks like rebuilddb is never run
<mdke> it's in cron.monthly, I think
<sobersabre> guys. I have heard of 'breezy security issue'. 
<sobersabre> that /var/log/installer/cde<something> contains initial passwords... I couldn't verify it.
<Amaranth> it's fixed in the latest isos
<mdke> sobersabre, that was fixed a while ago
<Amaranth> not fixed on any shipit cds though
<setuid> Seems the dapper kernels get Palm devices completely wrong at connect time, for the first time ever (I'm the pilot-link maintainer, and this is the first time in hundreds of thousands of connection attempts from thousands of users, that I've ever seen this) 
<Amaranth> but as soon as you install you'll be notified of security updates and one of those is the fix
<sobersabre> ok, but I used not the latest breezy when installed it. and I should've been hit... but I haven't... I didn't enable root on install or something...
<KaiL> mdke, looks ok there - but isn't run after OS installation?
<mdke> KaiL, i dunno, it's run when it has to be I suppose
<Amaranth> sobersabre: As I said, if you have security updates installed the problem is fixed.
<sobersabre> you mean one of the updates cleaned up the mess ?
<Amaranth> yes
<sobersabre> how do you do something like this in a deb ? write arbitrary script and package it as a deb ?
<KaiL> mdke, well, at least, if you installed with flight4, you need to wait one month to have yelp running then :/
<sobersabre> it needs not to exist afterwards...
<mdke> KaiL, that's why we try to fix bugs before releasing
<sobersabre> so you somehow need to remove it then...
<KaiL> sobersabre, updated tool, which doesn't produce this error again AND remove that problem :)
<sobersabre> KaiL the problem was that some installer remain contained the cleartext data.
<sobersabre> so ... what does your sentence state  ? 
<mdke> sobersabre, ok, relax please. It's fixed, let's move on.
<sobersabre> OK... I need to rtfm about packaging... mdke you could use that too ;-)
* sobersabre goes off to rtfm..
<sobersabre> oh! I came for other purpose.
<sobersabre> I have a C q. can somebody maybe tell me: can I write something like #ifdef (X && Y) ?
<infinity> Not if you want portable code.
<infinity> #ifdef X
<infinity> #ifdef Y
<infinity> do stuff
<bddebian>  Or #if defined(x) && defined(y) I think
<infinity> #endif
* mdke puts a sleeping pill in infinity's drink
<infinity> #endif
<sobersabre> I got that from ##c now.. thanks! :)
<Amaranth> what compilers work/don't work with #ifdef (X && Y)?
<sobersabre> Amaranth gcc -ansi -pedantic doesn't
<sobersabre> :)
<sobersabre> byebye
<Amaranth> ahh
<nysosym> hi there :)
<nysosym> is a changelog for every day updates available?
<chris_> !seen \sh
<chris_> anyone know anything about \sh?
<neuralis> chris_: he was on planet recently, things didn't sound very well
<Burgwork> neuralis, how goes life for you?
<chris_> neuralis: well, i read his blog.. i'm confused.. i worry about him ;\
<chris_> do you know anything more?
<neuralis> Burgwork: been pretty ill for about two weeks, but well otherwise. 10 days of vacations starting today.
<neuralis> Burgwork: you?
<Burgwork> pretty good. Made my first sale yesterday, which is a major event (6 months of work, paying off)
<neuralis> chris_: unfortunately, no. i hope he's alright, though.
<neuralis> Burgwork: congrats, mate
<chris_> okay, I still hope, that we hear some from him..
<chris_> will still read the blog
<chris_> thx and bye
<Burgwork> neuralis, sometimes I wish I worked in a place that had more frequent sales
<neuralis> Burgwork: i can understand that. it's exactly the same with working on all long projects -- frequent microsuccesses (milestones, etc) make everyone a lot happier
<Burgwork> neuralis, what about you? you haven't been around here very much
<neuralis> Burgwork: i've been extremely busy with research, some work on the personal genome project (http://pgen.us) and recently one laptop per child
<Burgwork> what are you doing for olpc?
<neuralis> Burgwork: pushing python :) 
* Pygi pokes Keybuk
<neuralis> Burgwork: more seriously, advising them on some of the system management aspects
<Lure> Pygi: no Keybuk
<Pygi> Lure: ah,kk
<ptlo> oo, neuralis :)
<neuralis> ptlo: long time no talk, still haven't gotten around to replying to your mail
<KaiL> *grbel*
<KaiL> *extrem doof guck*
<KaiL> hmm, nu geht wieder alles
<KaiL> auch gut
<KaiL> ups, wrong window :)
<CarlFK> Kamion: (or anyone that wants to see)  drive by bug report: daily setup errored installing kernel - I am running out, back in a few hours  - log files: http://dev.personnelware.com/carl/temp/Mar24/c/
<infinity> CarlFK: 403 on syslog.
<lamont> mvo: update-manager needs a versioned depends or two
<lamont> ImportError: /usr/lib/libcairo.so.2: undefined symbol: FT_GlyphSlot_Embolden
<lamont> hrm... or is that libcairo....
<zyga> mvo: ping^^^
<infinity> That's cairo having broken depends.
<zyga> lamont: oh, sorry - didn't notice 'mvo' in there
<lamont> zyga: np
* lamont -> home
<_ion> Morning.
<Amaranth> network-manager seems to be failing on wpasupplicant not being in main
<infinity> Yes, I know.
<Kamion> 20:27 < Amaranth> it's fixed in the latest isos
<Kamion> Amaranth: please, please, please don't say that until you *know*
<Amaranth> Kamion: It's not?
<Kamion> Amaranth: we haven't done the ISO update yet, no
<Kamion> one is planned
<Amaranth> Kamion: Err, everyone I asked said it was.
<Kamion> everyone you asked was wrong, I'm afraid
<_ion> Have the n-m build-deps been fixed yet?
<Kamion> if you install breezy and upgrade from security updates, you're fine
* Amaranth stops relying on #ubuntu for these questions
<Kamion> but no updated ISOs have been made available
<Amaranth> _ion: I just commented on that
<infinity> _ion: Nope, bug keybuk.  I'm not going to touch until until I know if he had a valid reason for doing it that way.
<Kamion> I hope to do it next week
<Amaranth> doesn't pitti have to approve main inclusions?
<_ion> amaranth: Yes, but wpasupplicant shouldn't be needed at all in the build-deps.
<infinity> He's already approved wpasupplicant, but we haven't promoted it yet.
<Amaranth> ah
<Amaranth> well, anyone impatient can use apt-get source to build it themselves
<Kamion> wpasupplicant drags in qt4 as well and I'm kinda reluctant to promote
<infinity> Oh, you're kidding.
<Kamion> see anastacia ...
<infinity> Well, that's going to beed to be fixed, then.
<infinity> need, too.
<Amaranth> wha?
<Amaranth> crap, i hope i didn't just install qt4
* Kamion -> bed, then away from the computer for the weekend; manage your own archive, folks ;-)
<infinity> ;)
<Amaranth> night kamion
<Amaranth> it doesn't seem to depend on qt4 here
<infinity> No, but wpagui does, which comes from the same source package.
<infinity> So promoting the source to main means promoting libqt4-dev to main.
<infinity> Which so ain't gonna happen on my watch either.  I'm with Kamion.
<Amaranth> ah, is see
<Amaranth> -s
<Amaranth> hmm, i guess either make network-manager only suggest wpasupplicant or make the package stop building wpagui
<infinity> Or build the other wpagui that's gt3.
<infinity> qt3, too.
<infinity> Odd type, that one.
<infinity> And that typO too.
* infinity gives up.
<Amaranth> hehe
<Amaranth> oh well, i guess people will have to wait until monday to get the new crack :)
<SEJeff> But monday will be n-m 0.6 with working wpa?
#ubuntu-devel 2006-03-30
<CarlFK> infinity: doh.  I keep meaning look into that... fixed c$ chmod -R a+r *
<neuralis> infinity: mail to adconrad@u.c will end up in the right place, right?
<OgMaciel> anyone gonna be at Linux World in Boston this April by any chance?
<infinity> neuralis: Yes.
<_ion> Any X maintainers online? /tmp/xserver-xorg.config.258983: line 957: syntax error near unexpected token `esac'
<_ion> xserver-xorg failed to preconfigure, with exit status 2
<crimsun> _ion: it's already fixed in 25 (as of 6 hours ago)
<_ion> Ok. :-) The updated version hasn't got to se.archive yet, then.
<Amaranth> _ion: That's why when I'm using the devel version I switch to the archive.ubuntu.com repos
<Amaranth> _ion: then switch back when/if i get to a stable release
<_ion> I don't know why, but using the main archive is quite problematic at least in Finland. File downloads (during apt-get update/install) seem to stall until a timeout randomly and often. I have noticed the problem with multiple different computers and multiple ISPs.
<_ion> The fact that fi.archive.u.c points to archive.u.c causes problems for many users. I tell them to switch to se.archive (Sweden is our neighbor).
<Kyral> you sure it points to archive.u.c?
<infinity> Yes.,
<infinity> (base)adconrad@cthulhu:~$ host fi.archive.ubuntu.com
<infinity> fi.archive.ubuntu.com   A       82.211.81.151
<infinity> fi.archive.ubuntu.com   A       82.211.81.182
<Kyral> (Just pulled a DNS record from it and don't see any CNAME record)
<infinity> (base)adconrad@cthulhu:~$ host archive.ubuntu.com
<infinity> archive.ubuntu.com      A       82.211.81.182
<infinity> archive.ubuntu.com      A       82.211.81.151
<Kyral> oh
<Kyral> *feels like an idiot*
<Kyral> I should have checked for that....
* Kyral is just beginning to fully comprehend DNS
<wasabi_> Anybody aware of hte current state of NFSv4?  ie is user-based auth working?
<wasabi_> Or is it still host based?
<wasabi_> And does Ubuntu have the neccassary pieces?
<_ion> I tested NFSv4 with Kerberos a few months ago, it seemed very unstable.
<_ion> The Linux implementation, that is.
<_ion> It might have matured since then.
<wasabi_> Bah.
<wasabi_> Trying to even find some docs on how to set up the export
<wasabi_> Darnit. Latest dapper update made my mythtv box unresponsive on reboot. =(
<wasabi_> prolly stuck at grub again or something, argh.
<nictuku> fix for bug #26601 http://revu.tauware.de/details.py?upid=2184
<Ubugtu> Malone bug 26601 in bittornado bittornado-gui "btdownloadgui crashes on startup" [Normal,Unconfirmed]  http://launchpad.net/bugs/26601
<nictuku> the package needs some cleanups
<nictuku> my fix was a oneliner, I didn't want to mess with it
<dieman> bastards! broke my networking ;)
<dieman> (wpa)
<crimsun> pager /usr/share/doc/wpasupplicant/README.Debian
<dieman> plus, wpa + ifplugd doesn't work as well out of interfaces. hrmpfh.
<dieman> yah
<dieman> i know
<crimsun> I didn't have time to muck, so I just used wpa-conf /etc/wpa_supplicant.conf.dpkg-bak
<dieman> its interesting, but wont work in the long run to do it that way -- how do you know if you have link state without having wpa supplicant configuring wireless interfaces?
<dieman> with ifplugd
<dieman> and then when you do, how the heck does ifplugd know to fire off ifup to what interface again? :)
<dieman> its far too late to be thinking about this, i need some sleep
<infinity> Riddell: I added a /var/run/utmp to the LP buildd chroots so I could get kdenetwork up to date, but lamont's "The (non)presense of files on the build system should not affect what gets build and installed for the target system" argument holds, and I'd appreciate a less confused kdenetwork source package uploaded at some point.
<glick> scuse me i gotta quick question
<glick> now that apple has patented the automatic updates notifier, what will that mean for ubuntus auto update notifier feature?
<infinity> Nothing.
<glick> what do you mean nothing
<infinity> Apple's patent is reasonably specific on certain features we don't do (ie: when an application is accessed that has updates, the updater will fetch them, etc), plus most of their patent has lots of prior art.
<infinity> In other words: We don't much care.
<glick> fuckin gay ass software patent bullshit
<infinity> I appreciate your enthusiasm, but please tone it down.
<_ion> Fortunately software patents are not legal in EU  yet.
<glick> does that mean that EU doesnt recognize us software patents?
<_ion> Of course the megacorporations are brib^Wlobbying the lawmakers all the time.
<_ion> glick: Yes.
<infinity> The EU doesn't recognise US patents anyway, they have their own patent office(s).
<zakame> hi all
<Burgundavia> glick: currently whether or not a EU county recognizes US software and business process patents is left up to each county
<Burgundavia> the EU patent directive would unify that for the entire EU, either way
<glick> but so no European country recognizes them?
<Burgundavia> I believe that the UK recognizes them. I have no idea about other countries
<glick> psshht
<infinity> Not that it matters.  Patents are meaningless without someone taking legal action to defend one.  And if that happened in this case, there's enough prior art to get the patent revoked, I'd suspect.
* infinity shurgs.
<infinity> Either way, I don't see any reason to be concerned.  It's a curiosity.
<glick> but then why get the patent/
<glick> ?
<_ion> infinity: You need money to defend yourself.
<infinity> Much like the kids who patented a method for swinging sideways on a swing.  Neat, but not relevant to reality.
<infinity> _ion: If the defendant was a corporation, they'd survive.  If Apple decided to attack, say, Debian, I'm sure the EFF would be all over it.
<Burgundavia> apple attacking an OSS project with a patent would be a suicidally stupid move
<Burgundavia> the have got a lot of hackers hooked on Apple stuff
<infinity> Yeah, I'm sure everyone would throw out their iPods in disgust.
<infinity> </sarcasm>
<Burgundavia> no, but it wouldn't earn them any brownie points
<Burgundavia> plus patent lawsuits are not "cool". Apple is very much about cool
<infinity> They may be cool, but they're also the second most litigous software company after Adobe.
<glick> heh
<Burgundavia> besides, patent are better left unlitigated. If you go to court you might lose your toy
<Burgundavia> http://en.wikipedia.org/wiki/Fleet_in_being in another field
<Kamion> CarlFK: your kernel installation problem is because gpgv is failing due to a badly skewed local clock. Evidently we haven't quite nailed down all the problems with that case yet.
<_ion> Is he not using NTP?
<Kamion> _ion: not in the installer he isn't
<Kamion> and in any case that doesn't excuse bugs
* infinity looks suspiciously at nautilus dep-waiting on beagle-dev on all arches.
<infinity> I'm guessing that wasn't well thought-out.
<infinity> Kamion: Do you know if beagle was meant to be promoted to main, or if this was just a very poorly thought-out feature that should be reverted?
<Burgundavia> infinity: I think seb128 did it so that people, if they install beagle, could use the search
<infinity> (Either way, it was poorly though out, since beagle doesn't exist on all arches, but I'm trying to figure out if I should upload to completely revert the change, or upload to add [amd64 i386 powerpc ia64]  to that build-dep...
<infinity> Burgundavia: Yes, but you can't build-dep on universe stuff from main. :)
<Burgundavia> indeed
<infinity> Burgundavia: Hence the question.  "Was it meant to be promoted, or an oops?"
<Burgundavia> I would rather go for the "not well thought out" answer
<Kamion> infinity: pitti approved it I think, but it depends on a big pile of CIL stuff that he didn't approve
<Kamion> so I believe it was meant to be promoted *and* an oops
<infinity> Check.  I'll wait for Monday to resolve that one, then.
<mwright1night> There is a bug with nautilus the default copy action is cp -a meaning that if you have done chmod g+s on a directory, ordinary users can't have the permissions of the group inherited by copying into a group folder
<Burgundavia> Kamion: did I not read something about you not turning the computer on this weekend? :)
<mdke> mwright1night, you can report bugs here: https://launchpad.net/distros/ubuntu/+bugs
<mdke> sladen, what is wrong with the use of sudo -i? you just slammed it on the mailing list but two core developers have recommended it. I'm interested in what is wrong with it because we should cut it out of the documentation if it is really a bad idea
<sladen> mdke: it's like lynching the security guard and then  (a) wedging the front-door wide open and  (b) removing the vistors' book.
<tseng> sudo -u foo -H does the trick for me
<tseng> in most cases
<ogra> fabbione, https://lists.ubuntu.com/archives/ubuntu-users/2006-March/071258.html
<glick> hey where would report a bug about pmount?
<glick> to the author 
<glick> or to ubuntu?
<tseng> the author is the maintainer of the ubuntu package
<tseng> he will get it
<glick> so where/how would i submit the bug to?
<Tonio_> hello everyone
<Tonio_> _ion: ping ?
<Tonio_> _ion: the network-manager uploaded to main doesn't include the libnm-util* packages..... which causes knetworkmanager to ftbfs
<_ion> tonio: I don't think the binary is even built yet. Only the source package is in main so far.
<Tonio_> _ion: ftbfs ?
<Tonio_> it should be built in a cycle of a few hours only
<_ion> tonio: For some reason wpasupplicant has been added to the package's build-deps, and it's not yet in main.
<Tonio_> _ion: that explains ;)
<_ion> Also docbook-to-man is in the build-deps, and it's not used by the package either.
<Tonio_> _ion: I'm gonna look at the source package, that might explain why I don't get libnm-util
<fabbione> ogra: point him to ports.ubuntu.com
<fabbione> ogra: sparc 5 i doubt is going to work anyway
<fabbione> ogra: we only support 64 bit processors
<ogra> ah, k
<_ion> ddp nnqn
<Yagisan> _ion: why is ubuntu dapper upside down ?
<Kinnison> _ion: apart from a missing 'n' (u?) in your ubuntu, very cute
<_ion> yagisan: Because you're on the opposite side of the globe.
<zakame> er?
<_ion> Whoops. :-) ddp nunqn
<giftnudel> _ion: I still like to know how you do that ;)
(infinity/#ubuntu-devel) joelbryan: What do you mean "include a license agreement"?
<infinity> joelbryan: The software should have a license, certainly, but you shouldn't have a click-wrap license agreement, no.
<enrico> infinity: the debtags I have here is 1.5.5
<joelbryan> ok
<joelbryan> infinity: just username setup.
<enrico> infinity: and libapt-front is 2.3.9
<enrico> infinity: there's been many important changes in the meantime
<infinity> enrico: Yes, I realise we're likely out of date, since we've been in an upstream version freeze for a while.
<infinity> enrico: That doesn't change the fact that this really SHOULD build, and doesn't. :)
<enrico> infinity: easy to fix: where you have shortDescription("foo"), put shortDescription(string("foo"))
<joelbryan> Is there an adduser API, or should I use it externally?
<infinity> joelbryan: It's a CLI app, that /is/ the API. :)
<ploum> Hello
<ploum> Can someone reproduce bug #36596 ?
<Ubugtu> Malone bug 36596 in pan "system freeze after clicking task manager trash icon" [Critical,Unconfirmed]  http://launchpad.net/bugs/36596
<ploum> Is it a kernel issue ?
<ploum> (the reporter told on IRC that his system was completely frozen, cannot even switch to a console)
<infinity> Reporting a bug on IRC won't make it get fixed any faster than having it reported in Malone.
<infinity> It may, however, annoy perpetually busy people.
<Tm_T> yup
<infinity> Also, burgerspace is uninstallable.  This is clearly the gravest of grave bugs, and we can't ship like this.l
<bddebian> uhm
<ogra> infinity, really ? burgerspace ? 
<ogra> damned
<infinity> Thank god moon-buggy still works, that's all I can say.
<ogra> should we form a task force ?
<bddebian> hehe
<Yagisan> ogra: you'll head the team of course ?
<ogra> nah
<ogra> that needs more whipping ... i'd opt for JaneW ;)
<ogra> its to important to slip through :)
<infinity> See, and while people may think you're kidding, I'm going to go fix it.
<infinity> A world without burgerspace is a sad place indeed.
<ogra> :)
<ogra> cant we replace gnome-screensaver with it ?
<infinity> DUDE.
<infinity> Best.  Idea.  Ever.
<joelbryan> what's burgerspace?
<joelbryan> seems like I'm living on a sad place. :-(
<ogra> or even with moon-buggy, since it seems more stable ;)
<infinity> joelbryan: UNIX clone of the old DOS/Atari game BurgerTime.
<joelbryan> ah ok
<infinity> ogra: Or Jump'n'Bump... Do we ship that?
<joelbryan> I love that game
<ogra> dunn, but i'd guess so ...
<infinity> Oh good, we do.
<ogra> even the extra levels :)
<infinity> (I don't recommend adding it to edubuntu, it's kinda.. Uhh.. Violent)
<infinity> Cute bunnies, sure.  And blood.
<infinity> Lots of blood.
<ogra> heh
<joelbryan> damn, my father just busted out my door with a hammer. it sucks.
<ogra> unless the default standard for CD media switched to 800MB, i wont add *anything* to edubuntu :)
<_ion> xjump is teh rules. :-)
<ogra> .oO(which reminds me ...)
* ogra updates edubuntu-meta 
<ogra> joelbryan, how did you make him *this* angry ?
<joelbryan> ogra: I won't let him in, he told me to find another place to live if I'm not going to follow his rules
<ogra> uuh
<slomo> infinity: hm, burgerspace is installable here...
<infinity> slomo: Not on i386.  Seems to have missed out on the allocator rebuild by accident.
<robertj> and does it have appropriate desktop entries ;)
<infinity> slomo: Easy enough to rebuild it.
<robertj> yeah, I just did an apt-get update & burgerspace now seems happy
<slomo> infinity: i'm on x86 :) maybe i still have the old libraries flying around
<infinity> slomo: Possibly.  Definitely has crusty deps.
<infinity> Depends on libgengameng4c2, should be libgengameng4c2a.
* infinity uploads for a rebuild.
<wasabi_> Was anybody working on an arm port? If so, there a repository?
<infinity> wasabi_: Not yet, no.
<infinity> wasabi_: I may attack arm/mips/m68k next release cycle, if the Powers That Be decide that embedded Ubuntu is a go.
<infinity> I have some ColdFire kit sitting on my floor that's begging for some love. :)
<wasabi_> Heh. I have a n770. =)
<robertj> has moonbuggy always gone from right to left?
* ogra would love to make any use of his old indigo2
<mjg59> ogra: They run Linux fine...
<tseng> burgertime seems like pac man for people on lsd
<ogra> mjg59, but not X
<mjg59> Well, no
<ogra> mjg59, at least my weird graprics card doesnt
<mjg59> But they'd be stupidly slow for a desktop system nowadays anyway
<ogra> yep
<ogra> and horrible loud as well ...
<tseng> ogra: i have an o2
<ploum> robertj, yes, as far as I remember
<tseng> it does some crazy caching stuff and makes linux blow up
<mjg59> tseng: The O2s should be ok in that respect
<ploum> wasabi, I have one too. Why ? Is someone discussion the 770 here ???
<ogra> still the more beautiful choice
<mjg59> It was the 10ks in the Indigo 2s that had that problem
<tseng> mjg59: the r10k?
<mjg59> Yeah
* ploum is trully mad of his 770
<tseng> hm
<desrt> my dvd drive (firewire) does not appear in hal if it's turned on at system startup but powercycling the cd drive gets it to show up (ie: coldplug is broken)
<desrt> do i bug pitti benc or keybuk?
<ogra> sounds like Keybuk ... but i might be wrong
<mjg59> desrt: Does the kernel know about it if it's there on boot?
<infinity> desrt: Does it show up at a lower level (ie: in /dev)?
<desrt> (it *does* have its modules loaded and device nodes created)
<mjg59> Sounds like a hal problem
<infinity> desrt: Right, then it's a hal issue.
<desrt> and it's in sysfs
<zyga_> hey
<mjg59> (So pitti)
<desrt> awesome
<desrt> thx
<wasabi_> ploum: I just wish I had a "normal linux distro" on the n770
<wasabi_> instead of a normal linux distro which requires pacakges specially set up (/var/lib/install)
<wasabi_> and apps to use special gtk classes, etc.
<zyga_> wasabi_: what is /var/lib/install on the maemo?
<wasabi_> Where .deb's install to.
<wasabi_> You can't really install to /
<zyga_> hmm
<zyga_> hmm
<zyga_> b / is RO ?
<wasabi_> No.
<zyga_> then why?
<wasabi_> Because you don't use root to install.
<zyga_> !?!
<zyga_> what the heck
<wasabi_> dpkg runs as a special user named 'install'
<wasabi_> I mean, the goal is nice, to prevent users from installing stuff that screws up /
<zyga_> suid dpkg?
<zyga_> hmm
<zyga_> hmmm
<zyga_> might be true
<wasabi_> But it makes porting a pain in the ass for me.
<zyga_> okay but that's ackward
<wasabi_> I'd rather just apt-get source some crap and recompile it. ;)
<zyga_> does /var/lib/install mimick a normal /
<wasabi_> Sorta.
<wasabi_> It has no init script infrastructure.
<wasabi_> ANything that integrates into the desktop has to do so in special folders.
<zyga_> could you do a find / | gzip | mail zyga@suxx.pl  for me?
<zyga_> and - home that is
<wasabi_> I could mimick one. No  mail. ;)
<zyga_> oh
<zyga_> there *is* a terminal emulator on the 770, right?
<wasabi_> if you install it on your own.
<wasabi_> it goes to /var/lib/install. ;)
<wasabi_>  / has busy box only 
<zyga_> something more sane than xterm?
<Robot101> there's an osso-xterm for it
<wasabi_> Yeah it's X term with input methods.
<koke> JaneW: I've just replied to you
<koke> sorry, but I've been in bed with fever all this week
<wasabi_> I just have a fairly clear picture how I think the device should be. Plain ol' linux. Custom desktop environment.
<wasabi_> Not a lot more.
<koke> now checking hundreds of mails :)
<wasabi_> I suspect though, I can get Ubuntu (an ARM port) running on it, and configure it up to boot into an X server, and start the maemo interface automatically.
<wasabi_> Package those bits up for Ubuntu, etc.
<wasabi_> I have a 1GB flash card, so not worried about memory.
<zyga_> wasabi_: how large..
<zyga_> oh :)
<zyga_> I was just wondering
<wasabi_> Yeah.
<zyga_> I've got a spare arm lying around
<zyga_> it lacks network support of any kind though
<zyga_> I'd have to setup ppp over serial line to make it online
<zyga_> could be a nice reason to try something like that
<Hwyvar> can I laugh in here? "I've got a spare arm lying around" :-D
<Robot101> Hwyvar: I found that funny too :)
<zyga_> hehe
<zyga_> right ;] 
<Hwyvar> :)
<siretart> sladen: thanks for your work on the thinkpad numlock issue
<ploum> wasabi, it seems that the next release of their OS will not have this /var/lib issue anymore
<ploum> following the speech I saw at FOSDEM
<siretart> infinity: re my acx100 card from yesterday. I just upgraded that box to dapper, but wpa still doesn't seem supported. I filed malone bug #36603 for that
<Ubugtu> Malone bug 36603 in linux-meta linux-restricted-modules-2.6-686 "[acx100]  doesn't support WPA" [Normal,Unconfirmed]  http://launchpad.net/bugs/36603
<joelbryan> Is the --gecos option in adduser ubuntu specific?
<siretart> joelbryan: isn't it in debian as well?
<robertj> where do you report gdebi bugs?
<siretart> robertj: https://launchpad.net/distros/ubuntu/+source/gdebi/+filebug
<robertj> siretart: https://launchpad.net/products/gdebi/+filebug didn't include that information :(
<robertj> thanks
<siretart> thats another issue then. you're welcome
<joelbryan> siretart: oops, silly me, yeah it was debian
<robertj> siretart: now bug #36609
<Ubugtu> Malone bug 36609 in malone "Page that tells you that you can't file a bug here doesn't tell you where to file it" [Normal,Unconfirmed]  http://launchpad.net/bugs/36609
<siretart> robertj: thanks :)
<robertj> btw, has there been any thought about replacing the message box informing you of new menu entries with a notification bubble from the Applications menu?
<Toadstool> sladen: I've got an answer from a lintian dev about the ubuntu adaptation :)
<Toadstool> (hi by the way)
<sladen> Toadstool: oooh, excellent (and greetings)
<sladen> Toadstool: what was the suggestion?
<Toadstool> sladen: they may include -D and --debian switches as no-op switches in debian
<sladen> Toadstool: did they say anything about the opposite, eg.  --ubuntu or --nmu
<Toadstool> nope
<sladen> Toadstool: okay, see if you can get it applied then!
<Toadstool> sladen: the problem is they're working on lintian 1.23.16 and we only have 1.23.14...
<siretart> I think lintian/linda and other package tools are a good candidate for updating. they are well tested, after all
<Toadstool> there are huge changelogs for .15 and .16 :)
<zyga> is dholbach here on weekends?
<sladen> siretart: mmm, ponder.  Toadstool: ideally I'd like it to go into upstream and then backport it.  That means in the future the Ubuntu patch can just be dropped when it is imported again
<Chipzz> hrrrm, I know this is a bit off-topic, but how would I run an application in a different language from the command-line?
<Chipzz> "LANGUAGE=nl_NL program" doesn't appear to work
<sladen> Chipzz: LANG=aa_CC.UTF-8 programname
<Chipzz> $ LANG=nl_NL.UTF-8 sudo gnome-software-properties
<Chipzz> (gnome-software-properties:25250): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale.
<Chipzz> ?
* Chipzz tries reconfiguring locales
<sladen> Chipzz: do you have the appropriate langpacks installed?
<sladen> that too.
<Chipzz> hrrrm
<Chipzz> sudo dpkg-reconfigure -p low locales
<ogra> not in dapper ...
<ogra> run locale-gen instead :)
<Chipzz> that should give me the debconf front-end in which I can select languages, right?
<ogra> afaik not anymore ...
<Chipzz> so how DO I get that list?
<ogra> it depends on the installed langpacks and calling locale-gen 
<ogra> iirc
<Chipzz> is /etc/locales.gen deprecated?
<ogra> i think so
<Chipzz> I only have /etc/locale.gen.dpkg-old ?
<Chipzz> hrrrm hrrrm
<ogra> ?
<Chipzz> ok, so, I don't feel much like installing an entire langpack, and gnome-software-properties has its translations shipped anyway; is there a way to teach ubuntu about that locale without installing the langpack?
<Chipzz> nm, will just install the language-pack :P
<sladen> Chipzz: I think the locales were moved out of the langpacks and back into locales again
<sladen> Chipzz: $ sudo dpkg-reconfigure locales
<ogra> sladen, that wont give you a selection ...
<Chipzz> sladen: allready installed a languagepack ;)
<Chipzz> what I was testing appears to work :)
<lifeless> mjg59: around ?
<mjg59> lifeless: Hi
<lifeless> mjg59: so, evevent or some such was where we got up to 
<mjg59> evdev
<lifeless> yes
<mjg59> Your lshal output claims that hald-addon-keyboard (or whatever) should be running
<lifeless> I have that loaded, but not by intention
<mjg59> And I can't think of any reason why it wouldn't be
<mjg59> So sounds like a hal bug
<lifeless> what can I do beyond filing a bug with a synopsis of our talk to help fix this ?
<mjg59> Only thing I can think of is killing hal and starting it in verbose mode, then seeing if you can see any indication of why it's not starting it
<lifeless> will that wedge anything? If not I'll do it now
<mjg59> It'll make anything that's using hal unhappy, but it won't kill the machine
<lifeless> how can I tell whats using hal ? if its just nautilus I dont give a f*** so I'll do it
<sladen> lifeless: dbus-viewer
<lifeless> sladen: ok, nice. now how do I acieve the goal here with that ?
<sladen> lifeless: it'll show you what's listening on the bus
<lifeless> does it show my hwats interesting in hal ?
<lifeless> s/ing/ed/
<sladen> lifeless: D-Bus is effectively broadcast based, with filters to narrow down what messages get delivered;  what are you after knowing?
<lifeless> sladen: see context above - I've been asked to bounce hal and run it manually. I want to know wheat will fall over and ough
<lifeless> s/wheat/what
<lifeless> s/ough/cough/
<lifeless> s/garbage/sane text/
<sladen> $ sudo /etc/init.d/dbus restart
<sladen> gnome-power-manager unexpectedly quit
<lifeless> I tak ei tdbus depends on hal ?
<sladen> ideally they should just wait a moment and try again
<lifeless> ok, lets do this thing
<lifeless> mjg59: ok, I'm a muppet
<lifeless> let me demonstrate
<lifeless> robertc@lifelesslap:~/source/baz/bound-test-speed$ ps fux | grep hal
<lifeless> robertc   4203  0.0  0.0   2880   796 pts/7    S+   08:02   0:00              |   \_ grep hal
<lifeless> robertc@lifelesslap:~/source/baz/bound-test-speed$ ps fx | grep hal
<lifeless>  4212 pts/7    S+     0:00              |   \_ grep hal
<lifeless> robertc@lifelesslap:~/source/baz/bound-test-speed$ ps fax | grep hal
<lifeless>  4124 ?        Ss     0:45 /usr/sbin/hald
<lifeless>  4125 ?        S      0:00  \_ hald-runner
<lifeless>  4130 ?        S      0:00      \_ /usr/lib/hal/hald-addon-acpi
<lifeless>  4136 ?        S      0:01      \_ /usr/lib/hal/hald-addon-keyboard
<lifeless>  4219 pts/7    S+     0:00              |   \_ grep hal
<lifeless> robertc@lifelesslap:~/source/baz/bound-test-speed$ 
<Chipzz> does anyone have mvo's email?
<lifeless> mihcael dot voigt @ ubuntu.com I think
<lifeless> meh, adjust sanely
<lifeless> mjg59: so, having reset the analysis somewhat, what is the analysis now ?
<Chipzz> s/mihcael/micheal/ ?
<lifeless> yes
<Chipzz> http://chipzz.studentenweb.org/um2.patch for anyone who wants to try
<Chipzz> sanify gnome-software-properties :)
<mwright1night> gnome-vfs2 which nautilus plugs into has a default copy action same as cp -a.  This is counter the conventional Unix security model for fileystems
<mwright1night> and basically destroys the ability to share documents amongs workgroups within a work place.
<mwright1night> As part of the Shuttleworth polish
<mwright1night> can someone fix this stuipd problem with nautils
<LaserJock> mwright1night: is there a bug report on Malone?
<mwright1night> No
<mwright1night> how do you describe chmod g+s in english
<neuralis> mwright1night: "turn on the setgid bit"?
<Chipzz> mwright1night: I'ld strongly suggest filing a bug upstream
<mwright1night> I've been using this in cron to get around it
<mwright1night> *       *       *       *       *       find /home/shared \! -group shared -exec chown :shared {} \; -exec chmod u+rw,g+rw {} \;
<Chipzz> mwright1night: also: http://mail.gnome.org/archives/gnome-vfs-list/2006-March/msg00042.html
<Chipzz> ugh
<Chipzz> neither michael.voigt@ubuntu.com nor micheal.voigt@ubuntu.com exist?
<tseng> my guesses would've been michael.voight@canonical.com or mvo@ubuntu.com
<tseng> but look for his post on the mailing list.
<Chipzz> michael.vogt@ubuntu.com apparently :P
<Chipzz> without the i :P
<tseng> oh, that helps
<mwright1night> The other bad problem is , Firefox does not use LC_PAPER and there is no way to set A4 as your paper time
<mwright1night> type i.. it alwasy reverts back -- pain in the arse
<yves> hi
<nictuku> I've sent a patch to a bug, now what? wait until a ubuntu staff member process it?
<LaserJock> ubuntu staff member?
<nictuku> we'll someone who maintain main packages
<nictuku> well*
<LaserJock> oh, it's a main package
<nictuku> forgot to mention that, sorry
<nictuku> bug is #26601
<nictuku> Ubugtu, bug #26601
<Ubugtu> Malone bug 26601 in bittornado bittornado-gui "btdownloadgui crashes on startup" [Normal,Unconfirmed]  http://launchpad.net/bugs/26601
<nictuku> i've confirmed the issue reported, then sent a trivial patch
<LaserJock> nictuku: I'd assume somebody would pick it up.
#ubuntu-devel 2006-03-31
<joelbryan> Hi, I just found out oem-config is in GTK+ mode
<minghua> Is there any place I can find old source pacakges that was in dapper?
<minghua> I can find old binary packages in launchpad, but now the source
<raphink> I think the sources get removed
<raphink> permanently
<minghua> :'-(
<minghua> then why are we keeping the binaries?
<dark_light> distributing the source without the binaries isn't a viollation of gpl, raphink ?
<raphink> no it's not
<raphink> of course
<raphink> distributing the binaries without the source is
<dark_light> ooops
<dark_light> i meant distributing the binaries without source
<raphink> yes
<LaserJock> hi raphink
<wasabi_> mdz: i notice there are mythtv packages on marillat's site. Those Ubuntu-compat?
<wasabi_> are they yours?
<wasabi_> Oops. I found a message that says you no longer maintain them. ;)
<dotwaffle> Damn timezones!
<_ion> Amen.
<dotwaffle> Much as I hate Swatch for doing it, their "beat" system or "internet time" is damn appealing.
<_ion> Yep.
<dotwaffle> Which timezone are you?
<_ion> su maaliskuun 26. 07:06:53 EEST 2006
<dotwaffle> suomalainen?
<_ion> Yep.
<dotwaffle> I work for Assemlby Organizing Oy during the Summer ;)
<_ion> Cool. :-)
<dotwaffle> Interestingly enough, sladen was on about bringing an Ubuntu stall to Assembly this year, would be good to have an open source company there - Microsoft getting the cold shoulder from the guests isn't funny anymore :S
<_ion> That would be cool.
<dotwaffle> I work for the media division "livecrew" and was head of Production last year, so I could even get him some national airtime ;)
<dotwaffle> anyway, enough of that.
<fabbione> slomo_: ping?
<neuralis> fabbione: hey, did the cd md5 checker ever get unblocked?
<fabbione> neuralis: no
<fabbione> it's still in admin queue.. and deferred
<neuralis> fabbione: okay, thanks. i'll reflect that in the book.
<fabbione> neuralis: thanks
<_ion> "Germans risk two years in prison if they illegally download films and music for private use under a new law agreed yesterday." Good that the legislation finally punishes piracy harsher than lesser crimes such as murder or rape.
<infinity> Riddell: If you're going to be updating libapt-front, you need to update debtags as well, which is FTBFS with the newer versions.
<sladen> dotwaffle: yeah, we should follow that up some more :)
* Amaranth stops breaking things
<Pygi> pitti: around?
<spacey> hi Pygi:)
<spacey> good morning
<Pygi> mornin' spacey ;)
<Pygi> spacey: good work on the wiki for now, but we have a lot more to do ^_^
<spacey> Pygi: i'll be away from home monday-wednesday, so have a little less time
<spacey> but we can finish it up a the meeting, but as long we have something to start from
<Pygi> spacey: no problem at all ;)
<spacey> :>
<Pygi> Do we have anyone by now who wants to contribute?
<siretart> Pygi: I installed nm 0.6.1 on my girlfriends laptop yesterday
<Pygi> siretart: and? ^_^
<siretart> Pygi: and made her connect to my wpa-psk2 secured network. she has an ipw2200 adapter, and on the second try, it worked
<siretart> no idea why it didn't succeed in the first place, but in the second time it worked
<Pygi> siretart: great, altought it should work on first try ;)
<siretart> what we both found very very annoying is that nm uses gnome-keyring to store the passwords
<Pygi> siretart: we need to get wpasupplicant promoted to main, so we'll have official packages ;)
<siretart> it is not possible to have that unsecured
<Pygi> siretart: ah, yes, I know :-/
<siretart> Pygi: I've built the official 0.6.1 nm packages from the archives
<Pygi> siretart: I don't know why it still hasn't been promoted, when it's accepted ;)
<siretart> using wpasupplicant from the archive
<Pygi> siretart: ah, ok, glad it worked ^_^
<Pygi> spacey: you alive? ^_^
<siretart> Pygi: wpasupplicant does not need to be promoted to main, afaiu, because it is only a recommends
<j^> Pygi any idea what to do about orinoco_pci/hostap_pci cards?
<j^> 0.6.1 does not work at all for me for WEP anymore
<siretart> Pygi: but to be serious, up to now, nm seems to be only a solution to ipw users. no other drivers seem to be supported similar well
<Pygi> siretart: yes, I know, but n-m is still in building queue
<Pygi> because of wpasupplicant
<siretart> j^: she uses wep at home, she will tell me if that still works for her
* _ion wonders where Keybuk is.
<siretart> Pygi: because of libnl, at least when I last looked at it
<siretart> _ion: I think he doesn't work on sundays
<_ion> I sent him a message about the n-m build-deps using MemoServ a few days ago.
<_ion> I don't know whether he has received it.
<siretart> I havn't seen him ircing since friday
<spacey> Pygi: pong
<Pygi> siretart: nop. now it's because wpa-supplicant
<siretart> ah, yes, your right: http://librarian.launchpad.net/1840598/buildlog_ubuntu-dapper-i386.network-manager_0.6.1-0ubuntu1_MANUALDEPWAIT.txt.gz
<Pygi> spacey: well, why don't you respond? ^_^ Do we have anyone by now willing to contribute?
<siretart> but I'm not happy with the wpasupplicant package in dapper
<spacey> Pygi: sorry was busy
<crimsun> we definitely need to do something about the upgrade path
<siretart> we are working in the pkg-wpa team on nice packages. 
<siretart> right
<Pygi> siretart: it's not *that* bad
<crimsun> I'm surprised it was uploaded as-is
<siretart> crimsun: so was I. believe me
<spacey> Pygi: you and me :P We'll see at the meeting. its not really useful to call out for contribution before anyway.
<siretart> Pygi: it is horrible, because it breaks existing installations
<Pygi> siretart: yes, aware of that I am afraid :-/
<Pygi> spacey: O joy ^_^ And what if none else would be willing to contribute? :-/
<spacey> Pygi: well i will make my collegue contribute as well
<Pygi> spacey: ah,ok
<spacey> but thats only 1 :p
<spacey> i'm sure it will be fine
<siretart> Pygi: Perhaps you/we should update https://wiki.ubuntu.com/DapperNetworkManager to not point to tonios archive anymore
<Pygi> siretart: wrong, I told you wrong ;) WPAsupplicant is going to main, because we agreed that we are going to ship it on a cp
<siretart> his archive seems to be quite outdated
<Pygi> siretart: official n-m doesn't exist yet anyway
<Seveas> Pygi, there has been no such agreement yet
<siretart> Pygi: it does. how do you think I'm using it ;)
<siretart> Pygi: the source is available in the archive since some time
<Pygi> siretart: ah, yes, the source ;)
<Pygi> Seveas: hm, yes it was ... talk to pitti if you don't truest me ;)
<Pygi> spacey: ah, yes it will be fine ;)
<Seveas> Pygi, they *may* be in ship if *they are good enough*, but they're really really far away from even remotely goof enough 
<siretart> Pygi: anyway, http://kubuntu.no-ip.org/kubuntu needs updating. the packages in there look quite broken with uptodate dapper
<siretart> Seveas++
<Pygi> siretart: ah,k
<siretart> what I've seen today is that it has this annoying dependencies on gnome-keyring and that it seems to only work with ipw resonably well
<Pygi> siretart: nah, we've had a lot of reports where it works
<Pygi> much more reports where it works then where it doesn't
<siretart> Pygi: on madwifi? on acx? on ipw2100?
<siretart> what about ndiswrapper?
<Pygi> yes, on madwifi, ndiswrapper as well
<Pygi> on ipw2100 as well
<siretart> madwifi as in madwifi-ng or madwifi-old?
<Pygi> madwifi-old
<Pygi> some people experience disconnects, but just a few
<siretart> Pygi: could you please link to such success and failure stories on the wiki page?
<Pygi> siretart: hm, it's on the forums, but I'll do my best ^_^
* siretart doesn't read forums
<siretart> sorry
<Pygi> no problems 
<siretart> not activeley, that is
<Burgundavia> forums are a horrible place for longterm data, but great for chatting
<Pygi> siretart: links to threads about new N-M along with that stories, is already in the wiki
<siretart> yeah. perhaps you can link to releavant forum threads
<Pygi> siretart: linked already ^_^
<siretart> Pygi: there are some horribly long threads linked from there. I'm not gonna click through 20 pages to get my opinion
<crimsun> please summarise
<siretart> yes. that would help
<crimsun> a graph/chart is best
<Pygi> crimsun, siretart: ah,ok, will do ^_^
<Seveas> siretart, have you seen bug 36614?
<Ubugtu> Malone bug 36614 in wpasupplicant "wpa-driver-file implementation" [Normal,Unconfirmed]  http://launchpad.net/bugs/36614
* Pygi goes to see
<Seveas> siretart, it looks both like serious crack and serious help (only need to configure interface, wpa_supplicant knows the rest if packagers provide these files)
<siretart> Seveas: like said above, I'm not happy with the current wpa package in dapper
<siretart> Seveas: Keybuk took the work-in-progress on our experimental packages and uploaded them to dapper. Kel wasn't finished yet at that time
<Seveas> hmm
<siretart> Seveas: we (= crimsun, kelmo and me) are working in the pkg-wpa team on alioth on nice wpa packages
<siretart> perhaps and with some luck, we can upload that to debian next week. well, we'll see
<Seveas> all I can say is "works fine for me" - if you need testers for any new packages: just poke me
<infinity> siretart: So upload some fixes.  It's still in universe.  Just don't repackage it (again and again..)
<siretart> infinity: we already switched to cdbs on debian :(
<siretart> infinity: you know, we are working on some nice ifupdown integration
<siretart> infinity: kelmo has even integrated roaming to that new world order
<siretart> infinity: but it still needs testing and documentation
<infinity> kelmo?
<siretart> infinity: I've even worked on a interim solution to the new world order, in order to make bug sumitters in debian/unstable happy
<crimsun> Kel Modderman <kelrin@tpg.com.au>
<siretart> kelmo is the third man in our pkg-wpa team on alioth. he did the work on ifupdown integration
<infinity> Erm, so kylem isn't working on the Debian side of it anymore?
<siretart> kyle is still in the maintainer field, but he seems to be very busy lately. we havn't heard from him since some time
<infinity> I assume you've been keeping him in the loop about all this, though?
<infinity> It's pretty unfriendly to repackage using cdbs (or whatever) without consent from all the maintainers.
<siretart> everything goes via pkg-wpa-devel@lists.alioth.debian.org, a list he created
<infinity> Fair enough.
<siretart> and we work on the alioth svn only. so he should be informed about everything
<siretart> well, I'm off for a few hours. cu later
<netdur> hey, to what package should this bug belong? http://www.flickr.com/photos/77122833@N00/118048954/
<infinity> Package: rhythmbox; Subject: Should blacklist Kylie Minogue songs to avoid long term damage to users.
<_ion> :-D
<netdur> he he
<netdur> serious... what package that's?
<infinity> Which bug?  The weird shape in the bubble?
<netdur> ah... bubble looks strange
<infinity> Not positive what actually draws the bubbles...
<Mithrandir> notification-daemon, I thought
<infinity> Different bubbles.
<infinity> These are the new GNOME panel/applet egg bubbles.
<infinity> Anyhow, if you file it on your music player, someone should be able to redirect the bug in the right place.
<infinity> Someone who's not me, clearly.
<netdur> okay... I will file it to rb
<netdur> thanks
<netdur> done
* greenpenguin13-a is Away, Reason: ( cheese ) | Since: ( Sunday March 26 2006. 10:51:35 ) Xlack v2.1
<infinity> greenpenguin13-a: Please turn off the verbose (and coloured?) away messages in this channel.
<greenpenguin13-a> woops
<greenpenguin13-a> sorry
<Tm_T> whoooo
<Tm_T> colours ;(
* Tm_T hates public aways (including awaynicks)
* greenpenguin13-a wasnt' expecting that :P
<Tm_T> ;)
<_ion> I have seen that notification bubble bug with update-notifier as well.
<_ion> Oh, and nm-applet.
<slomo_> fabbione: pong?
<fabbione> slomo_: hey
<fabbione> slomo_: i am taking a lock on mono ubunu6 -> ubuntu7
<fabbione> slomo_: adding some interesting stuff
<fabbione> slomo_: but i need sometime to run the entire build/testsuite and rebuild a few packages
<slomo_> fabbione: what will you add in ubuntu7? :) and where did you get it from?
<fabbione> slomo_: sparc support, david s. miller via mono svn.
<fabbione> it's all upstream stuff
<fabbione> so no biggie..
<fabbione> but i need the time to test it
<fabbione> if it works it will be in the archive by tomorrow and you can take over again
<fabbione> does it work for you?
<slomo_> fabbione: cool :) i didn't plan any new mono uploads in the next time so feel free to test it as extensively as needed before uploading ;)
<fabbione> slomo_: ok thanks
<slomo_> fabbione: how big will the patch be btw? should be rather small as solaris/sparc support is already there afaik...
<fabbione> slomo_: they are small and in debian/patches
<fabbione> i didn't change the packaging or anything
<fabbione> just added
<fabbione> and modified debian/control
<fabbione> for the Architecture: field
<fabbione> (all documented in the changelog)
<j^> right now orinoco_pci is loaded for Prism 2/2.5/3 chips, but hostap_pci is much better, specially with the NM patch in bug 36708
<Ubugtu> Malone bug 36708 in network-manager "[PATCH]  wpa_supplicant needs to know about hostap driver" [Normal,Unconfirmed]  http://launchpad.net/bugs/36708
<slomo_> fabbione: cool :) good work :) i'm really interested in looking at the patches later :)
<j^> which package is responsible for the module order
<fabbione> slomo_: it's mostly asm stuff.. 
<j^> or is the only way to blacklist orinoco_pci?
<fabbione> and they are upstream svn
<mdke> i was looking at some errors in a build log - it looks like they are due to the machine not having internet access: is that possible?
<slomo_> fabbione: ok thanks :)
<fabbione> slomo_: no problem
<fabbione> mdke: buildd must not have internet access and pkgs that requires so to build are bad
<mdke> fabbione, oh. in all cases?
<fabbione> yes
<mdke> hmm
<mdke> i've never seen this problem before
<mdke> has internet access recently been removed?
<fabbione> it was never there
<fabbione> and it's not a problem.. it's absolutely normal
<mdke> i mean, the problem while building
<j^> after reading up on hostap_pci vs. orinoco_pci, it looks like orinoco_pci should be blacklisted, have to check for orinoco_cs vs. hostap_cs
<fabbione> mdke: if you can be more specific on at least what package you are talking about
<fabbione> mdke: perhaps the log?
<mdke> fabbione, ok. go to http://librarian.launchpad.net/1838629/buildlog_ubuntu-dapper-i386.ubuntu-docs_6.03.4_FULLYBUILT.txt.gz and search on "oasis"
<mdke> it is failing to find the dtd for docbook xml
<fabbione> mdke: ok.. it's an error in the packaging and/or source
<fabbione> have seen it before
<mdke> we'll have to change the documents to use a local dtd
<mdke> or maybe we can just ignore the warnings in the build
<mdke> yeah, ignoring must be the way forward, i don't see that we can change the reference to the online document in the doctype
<fabbione> mdke: the kernel used to do the same and it has been patches upstream. i really see no reason why you can't do the same
<mdke> fabbione, do you know what the solution was? I don't like the idea of changing the doctype for the documents
<fabbione> it was patched to use local doctypes
<fabbione> that oh.. my dear.. they are the same as on the website..
<siretart> _ion: re the wep problem with nm_0.6.1: my girlfriend is just chatting with me over her WEP secured network with network manager 
<mdke> fabbione, my dear?
<_ion> WEP "secured" network? ;-)
* mdke goes for lunch
<siretart> _ion: YMMV, right. ;)
<infinity> mdke: docbook XML DTDs are in the "docbook-xml" package, oddly enough.
<j^> hm, pccard: PCMCIA card inserted into slot 0
<j^> nothing more...
<j^> it works with Cardbus cards
<infinity> PCMCIA is scary ISAPNP fu.
<infinity> You may well need pcmcia card services running and such to make old pcmcia cards work.
<infinity> (Whereas CardBus is basically just hotplug PCI)
<j^> /etc/init.d/pcmcia start
<j^>  * Linux >= 2.6.13-rc1 requires pcmciautils instead of pcmcia-cs
<j^> hmhmhm
<j^> no pcmcia support and only cardbus is quite a regression
<infinity> Do you have pcmciautils installed?
<Mithrandir> cardbus is handled by the hotplug pci layer, iirc.
<infinity> Mithrandir: Yes, but PCMCIA isn't.
<Mithrandir> mpe
<j^> infinity sure i have pcmciautils installed
<infinity> j^: Did the card in question work in breezy with pcmcia-cs?
<infinity> j^: If so, I'd file a but on pcmciautils (which may or may not get reassigned to the kernel..)
<j^> if i remember right it did
<j^> i have one orinoco silver, one linksys ver.3 and one AVM isdn controller B1
<mdke> infinity, yeah, I'm aware of that. But reading the dtd, it says to declare the doctype using the online url. I'll read up more
<infinity> mdke: You do declare using the URL, generally, but with docbook-xml instealled (you don't build-dep on it), it should Just Work anyway, IIRC.
<mdke> sure, it probably would
<mdke> but it already Just Works :)
<mdke> I'm gonna look and see what the gnome-user-docs do
<mdke> yeah they use the online one too
<infinity> mdke: But they probably build-dep on docbook-xml. :)
<infinity> (Or theirs doesn't work right either)
<infinity> mdke: I'm going to do a local test in a chroot without network access right now.
<pimp^air> hi
<pimp^air> upgrading from breezy to dapper confused my alsa configuration as it changes the order of the cards on every boot. is this something to discuss in here or shall i file a bug?
<infinity> pimp^air: Bug please.
<pimp^air> 'k
<mdke> infinity, in gnome's case, they don't build html at the build stage, or at all. they just ship the xml
<mdke> infinity, if adding the build-dep solves it, lemme know and I'll add it in our svn. If not, we can leave it, I think, unless you tell me that the warnings in the log are a really bad thing
<pimp^air> where does autoloading of the modules take place in dapper?
<infinity> mdke: Just verified locally, if you build-dep on docbook-xml, it'll Just Work.
<infinity> pimp^air: udev.
<mdke> infinity, fantastic, thanks for going to the trouble of doing that
<infinity> mdke: NP.
<j^> after rebooting several times i was going to looks for a way to silence grub a bit, there is even a patch bug 20736
<Ubugtu> Malone bug 20736 in grub "Would be very nice to hide grub spew on boot" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/20736
<KaiL> ...even suppresses the "press ESC for menu"?
<infinity> I would hope not.
<soumyadip> anyone know why prozilla was removed from the universe after hoary ?
<slomo_> fabbione: good work :) would be nice to have everything working on sparc
<fabbione> slomo_: it does work just fine.. 
* fabbione did run tomboy from his sparc
<slomo_> fabbione: was this the only part of main that was missing for sparc?
<fabbione> slomo_: yes
<slomo_> :)
<fabbione> slomo_: for the next week or so, let's keep in touch to coordinate possible uploads
<fabbione> David tends to produce a copious amount of code/bugfixing per day
<siretart> how to use pdb in xemacs?
<fabbione> slomo_: also... you might want to take a debdiff and send it to Debian but tell them they need at least glibc 2.4 and kernel 2.6.17
<fabbione> (stuff we do have backported)
<slomo_> fabbione: i already talked to the debian maintainer. but he isn't interested, he wants to wait for a release with sparc support
<fabbione> slomo_: ok
<yves> how to properly help on bugs in main packages? After making a patch and sending to malone, what else? wait until a maintainer catch it up?
<fabbione> slomo_: good he doesn't want it.. somebody is going to say soon that we didn't push it
<slomo_> fabbione: but the only thing i plan to do for mono in the next days would possibly be an update to the 1.1.13.5 bugfix release...
<fabbione> yves: assuming the patch is good yes
<slomo_> fabbione: hehe, the cooperation between the debian mono group and us is in general very good... so nobody should complain there :)
<yves> Ubugtu, bug #26601
<Ubugtu> Malone bug 26601 in bittornado bittornado-gui "btdownloadgui crashes on startup" [Normal,Unconfirmed]  http://launchpad.net/bugs/26601
<fabbione> slomo_: sounds ok to me... i don't really care.. i just want sparc to fly high :)
<slomo_> fabbione: will you care for all the million give-backs that are possible now on sparc?
<fabbione> slomo_: there is no need to
<fabbione> all the packages are DepWait on libmono-dev and chain
<fabbione> they will unblock themself
<fabbione> already checked :
<fabbione> :)
<sladen> infinity: bug #29767 seems to suggest that 2.6.16 fixes some of the IDE issues, so that may help with #6367 aswell.
<zbbb> hello, i'm looking for some way to throttle my network throughput. any ideas?
<neuralis> zbbb: see lartc.org. this is not the appropriate channel; in the future, please ask on #ubuntu.
<yves> or #ubuntu-server
<zbbb> thanks!
<neuralis> yves: it's a general linux question. #ubuntu is best.
<yves> well ok
<zbbb> btw: this throttling functionality is a useful one that is not visible in any control panel of ubuntu
<zbbb> that's why i asked it here. maybe it should be a good theme for further development
<neuralis> zbbb: write a specification on the ubuntu wiki, and we'll be happy to consider it at the next developer meeting.
<zbbb> do you have any specific url?
<neuralis> zbbb: see https://wiki.ubuntu.com/SpecSpec -- then use the SpecTemplate it mentions when creating your new spec.
<zbbb> thanks again
<neuralis> zbbb: sure. you can see the list of dapper specs here: https://launchpad.net/distros/ubuntu/dapper/+specs ; clicking on one of them lets you hit 'read more' to see their wiki spec.
<dotwaffle> sladen: ping re/ Assembly06
<sladen> dotwaffle: ubuntu-marketing@lists.  is the place to raise this and then get in contact with finnish people like mjr and the other sange.fi people who did the Ubuntu Finnish localisation
<dotwaffle> Is it majordomo or is there a sign-up page?
<neuralis> dotwaffle: lists.ubuntu.com/mailman/listinfo/ubuntu-marketing
<dotwaffle> yeah, found it through gmnane, cheers
<fabbione> yves: #ubuntu-server is not appropriate either.
<neuralis> infinity: ping
<yves> fabbione, sorry
<TheMuso> c
<wasabi_> haha now the notification color is puke yellow.
<wasabi_> I love you guys.
<KaiL> uhm, are there any plans to fix DVD playback in totem for dapper release? ;)
<mjg59> KaiL: To the extent possible under various laws, yes
<robertj> mjg59: any plans to prompt users about setting a region?
<mjg59> robertj: No
<KaiL> mjg59, I thought more about the problem gstreamer0.10 not to be able to read DVDs at all...;)
<mjg59> Region coding is fairly uninteresting in comparison to CSS
<mjg59> KaiL: gstreamer0.10 can read DVDs fine
<robertj> mjg59: new drives won't play without a region will they?
<mjg59> robertj: Hm. My experience is that they tend to, but I haven't had an unregioned drive for some time
<KaiL> robertj, afaik the region is already set in the firmware to the region, where the drive got sold, or?
<robertj> KaiL: I have a new Dell and it was not
<mjg59> KaiL: No, PC drivers are often sold unregioned
<psusi> no.. new drives come with no region set and you have to set one correctly when you get the drive
<mjg59> (Not all regions)
<robertj> andi t wouldn't play until I used setregion from the command line
<KaiL> hum, really?
<KaiL> didn't have such problems here with drives from BenQ (that one had only other problems), LG, NEC, Panasonic and Toshiba
<robertj> so my understanding is if I owned Joe's Computer store in Country X where it was perfectly fine, it would take some doing to get it to work
<KaiL> mjg59, I thought about this DVD-Problem: {i} Note: "With Ubuntu 6.04 (Dapper Drake), the gstreamer dvd plugin has not been ported to the new version of gstreamer, 0.10. Please use the xine backend. "
<KaiL> ..from the wiki "RestrictedFormats"
<mjg59> KaiL: Progress has been made since then
<KaiL> but problem still exists - just tried..
<mjg59> KaiL: This isn't the place to report bugs
<robertj> KaiL: same result here btw
<KaiL> wasn't thought as such - but some types of bugs are way better to get verified as known here, then with a bugreport waiting to get duped ;)
<mjg59> KaiL: Reporting bugs here is never the right thing to do
#ubuntu-devel 2006-04-01
<mjg59> It always takes up more time than simply flagging a bug as a duplicate
<mjg59> But it's also better to check whether a bug has already been filed
<KaiL> if those checks wouldn't fail that often, even if a bug exists..
<KaiL> ...and it doesn't help that much to loose time for meta discussions, if there are more usefull things to do
<KaiL> robertj, maybe the unregioned drive is something dell-specific, as they sell identical systems in 2 regions?
<robertj> robertj: I doubt it, I'm pretty sure that is pretty common
<mjg59> It's not Dell-specific
<KaiL> hmm - so why I never saw that problem here?
<robertj> KaiL: people use setregion, recycle older drives, etc?
<mjg59> KaiL: That's not a question we can answer, and it's off-topic
<robertj> mjg59: should gstreamer be responsible for that?
<mjg59> robertj: Setting region? A good question.
<mjg59> One that I'm going to defer for now :)
<KaiL> the problem to ask to set a region is, that you can only change is several times
<robertj> KaiL: I've thought about that, and my thinkingis that any user should be allowed to change the region to match the dvd in the drive, but only an administrator should be able to use the last change
<robertj> it's feels dirty but I think the pragmatic benefit outways the dirty feeling I have a night
<KaiL> I'd like to allow only administrators at all to change that setting - and with a VERY big warning
<bmonty> what package is the setregion command in? (apt-cache search isn't giving me anything)
<KaiL> imho this warning should be bigger than every normal warning, as it's an option, which can trash hardware, even better than every beta-driver can
<robertj> on a positive note the gstreamer error message is generally less sucky
<mxpxpod> _ion: ping
<Drac[Server] > Shutting down temporarily to change surge protectors.
<infinity> neuralis: Pong.
<mxpxpod> ogra: ping
<desrt> how far from the next flight/prerelease?
<Burgundavia> desrt: Wednesday I believe
<infinity> ... ish.
<infinity> These things are rarely precise.
<infinity> But given that the world is currenly installable and (mostly) buildable, assuming any of it works, this is a good time.
<desrt> hmm
<desrt> i just got a new harddrive
<desrt> so i think i'm going to install onto it using RAID1 with only 1 drive
<desrt> copy my stuff over then add the other drive to the array
* desrt is gonna try something gutsy -- boot from external USB CD drive but get the installer to detect the external firewire CD drive by unplugging the USB one just after the kernel starts booting
* desrt wonders what kind of boot-time speedup he'll see from having 2 drives instead of 1
<joelbryan> anyone knows what values for /apps/nautilus/icon_view/default_zoom_level, standard is 100%, large is 150%, larger is 200%, same for small, smaller. I don't know that values for 400% and 25%. does anyone knows it?
<neuralis> infinity: have a minute now to talk about advocacy?
<infinity> neuralis: I'm taking a sick day (and heading back to bed in a moment to do so), could we catch up on this a bit later?
<neuralis> infinity: unfortunately, i need to send in the final version of the chapter before tomorrow. but no worries, what's there already will do fine. take care of yourself and get better.
<desrt> awesome.  it worked.
<desrt> the installer just grabbed my firewire drive as if it was meant to be
<desrt> interesting factoid about the installer:
<desrt> it makes no attempt to prevent you from installing a brick
<desrt> ie: doesn't do any checks to make sure /boot lives outside of RAID
<desrt> ok.  actually, it just fails to properlty determine the device number
<desrt> guys... flight5 is fast...
<desrt> i thought it was just all the gnome, etc improvements made... but doing a fresh install of the OS (box was upgraded from warty before) really speeds stuff up a lot
<_ion> Morning.
<Burgundavia> _ion: mxpxpod was looking for you
<_ion> Yep, i noticed. He didn't tell why, though. :-)
* _ion takes a shower and goes to the hospital. 
<fabbione> morning
<jsgotangco> hi ogra 
<G0SUB> jsgotangco
<fabbione> ogra: i have been confirmed that the flickering issue is due to the apps. DRI and driver in X are fine. fix it. kthxbye
<pitti> Good morning
<Burgundavia> pitti: morning
<Burgundavia> pitti: http://lists.freedesktop.org/archives/xdg/2006-March/007904.html
<fabbione> hey pitti
<pitti> hi fabbione 
<Burgundavia> pitti: and http://thread.gmane.org/gmane.comp.autopackage.devel/4671
<pitti> Burgundavia: hm, sounds like a bad hack - they should require .desktop to be executable in the first place
<pitti> Burgundavia: thanks for the links!
<Burgundavia> pitti: indeed, but the second is even worse
<Burgundavia> pitti: I should note that the autopackage devs are NOT planning to use this gross hack
<Burgundavia> and see it rightly as a security hole
<pitti> *gulp*
<Burgundavia> pitti_laptop: did I ruin your breakfast?
<pitti_laptop> Burgundavia: oh, not really, we discussed the .desktop issue a long time ago :)
<pitti_laptop> Burgundavia: the hack doesn't really change much anyway
<pitti_laptop> Burgundavia: there's not a big difference between running arbitrary commands (including sh -c) with a .desktop, or *being* a shell file
<pitti_laptop> (AFAICS)
<pitti_laptop> or is it?
<dholbach> good morning
<simira> dholbach: It's morning, anyway
<dholbach> simira: is it so bad?
* mdke_ hugs dholbach 
<dholbach> hey mdke_ :)
* dholbach hugs mdke_ back
<mdke_> hi, thanks for doing all those docs uploads
<dholbach> not to worry :-)
<simira> dholbach: I don't know yet, I'm not awake
<dholbach> simira: we're all getting there ;)
<Pygi> mornin' people
* Mithrandir ruffles simira 
<highvoltage> mornin'
<pitti> hi JaneW 
<JaneW> hi pitti
<hendry> what is the best avenue of moaning about malone?
<hendry> filing a bug?
<Mithrandir> yes, or mailing launchpad-users if it's something where you need to discuss and work out a solution
<hendry> launchpad-users
* hendry is hopping mad. Tries to cool down.
<Simira> hendry: try #launchpad
<Mithrandir> hendry: being hopping mad won't help.  Calm down.
<Burgundavia> hendry: patience is key to dealing with LP
<hendry> on irc no one can hear you scream
<hendry> ;)
<pitti> carlos: hi! does rosetta spit out a list of packages with missing POT files?
<pitti> carlos: I can still use my own import script to get that, but in the future rosetta should tell us anyway
<carlos> pitti: no, but I can create a page with that information
<pitti> carlos: it should list all import errors, like 'no pot file', or 'pot file, but no domains', or '2 .mo file domains, but 3 pot files', or so
<carlos> pitti: could you file a bug about it, please?
<pitti> carlos: sure
<carlos> pitti: well, atm I'm not using the .mo files at all
<carlos> we are not importing any .pot file automatically until it's reviewed manually once
<carlos> to prevent the mess we have with hoary and breezy
<dholbach> Kamion, Kinnison: did you have any plans to get some cherrypicked fixes of the new gparted releases (0.2.2 now) into gparted?
<Kamion> dholbach: if Kinnison or you can do it without breaking the gparted installer functionality you have now, be my guest
<Kamion> I don't have time myself
<pitti> carlos: bug 36825 
<Ubugtu> Malone bug 36825 in rosetta "please generate an import error page" [Normal,Unconfirmed]  http://launchpad.net/bugs/36825
<pitti> carlos: hm, that sounds like a lot of work to me
<StevenK> Kamion: Do I have any hope of getting Linda 0.3.20 into Dapper?
<carlos> pitti: it's
<dholbach> Kamion: yeah, that's what I thought... if we can't have 0.2.2 we should at least have the important stuff backported
<pitti> carlos: I get very good results by looking at the mo files, and I only need to manually fix ~20 packages
<carlos> pitti: only KDE and OO.org remains to get all .pot imported
<Kamion> StevenK: what does it change?
<carlos> pitti: we only need to do it once
<pitti> carlos: btw, fixed blender is test-building here ATM
<Kamion> dholbach: if possible, I'd rather go straight to 0.2.2 than backport
<carlos> pitti: cool, thanks
<Kamion> just because of the complexity
<pitti> carlos: and you can detect layout changes?
<StevenK> Kamion: Um, the changelog is large. It fixes a few things sladen did an upload for.
<pitti> carlos: what broke for you if you apply some heuristics to automatically process the 95% of the packages that usually make no problem?
<carlos> pitti: also, this manual review prevents us to import gtk+ and glib+ as much times as buildtrees it has or as much times as it changes the version....
<carlos> pitti: no, we don't detect layout changes (yet)
<tepsipakki> Kamion: is the install-cd bootable on a mactel yet?
<Kamion> StevenK: remember that we're in feature freeze. If it's bug fixes only, then sure; otherwise we'd have to talk.
<pitti> carlos: I use an 'override database' for these cases (one of the 20ish packages that require manual treatment)
<Kamion> tepsipakki: no
<tepsipakki> duh
<tepsipakki> ok
<StevenK> Kamion: Most, if not all of the changes close a Debian bug or two.
<carlos> pitti: override database for layout changes?
<pitti> carlos: hm, then this seems to be prone to break even harder than with heuristics... package layout changes from time to time
<Kamion> StevenK: http://wiki.ubuntu.com/DeveloperResources has the process for requesting freeze exceptions
<carlos> pitti: prone to break?, if it's on hte same path is imported automatically
<pitti> carlos: e. g. I say in domain-overrides/gtk+2.0:
<carlos> if it's not... we need to review it manually...
<pitti> gtk20-properties build-tree/gtk+-*-shared/po-properties/
<pitti> carlos: ah, ok
<carlos> that's not prone to break ;-)
<pitti> carlos: i. e. my db assigns translation domains to a specific subdirectory of the build tree
<carlos> pitti: oh, I see, that's something I was planning to do too
<StevenK> Kamion: Thanks, I'll do that.
<carlos> pitti: what happens with multiple .pot files on the same directory?
<carlos> pitti: like iso-codes package
<pitti> carlos: the import process will complain for me and refuse; this requires an override for me
<sladen> Kamion: I think the only issue with linda out the box is that it tries to run NMU checks on Ubuntu which don't make sense;  and the locales issue has been worked around for the moment, although there was a better patch that I've asked somebody to take straight to upstream
<carlos> pitti: it's more or less the same we do then ;-)
<pitti> carlos: right now I ignore iso-codes, and it's the only package with multiple pot files in one dir
<tepsipakki> kamion: how about netboot, there should probably be a elilo.efi to be loaded on pxeboot or something?
<carlos> pitti: glibc has also multiple .pot files in one dir
<carlos> pitti: one of them is useless
<pitti> carlos: well, I don't need to tweak/review the vast majority of our packages
<carlos> header.pot
<pitti> carlos: my glibc override: libc build-tree/glibc-*/po
<Kamion> tepsipakki: I have no clue about how netboot would work and not much interest in looking at it before CDs
<pitti> carlos: i. e. easy to fix for me
<tepsipakki> Kamion: ok, no problem
<Kamion> tepsipakki: you can fish elilo.efi out of the elilo package and try it out yourself if you like
<tepsipakki> yes, I will ;)
<carlos> pitti: you have much more flexivility
<carlos> ;-)
<pitti> carlos: I'm just mentioning that because it seems to me that manually reviewing 3000 packages is a horribly boring and unnecessary work...
<carlos> pitti: do we have 3000 packages with translations in main?
<pitti> oh, true
<pitti> so, s/3000/300/ :)
<carlos> pitti: :-P
<carlos> pitti: we already did most of them
<carlos> the most complicates one are the KDE ones
<pitti> carlos: (just wait for dapper+5, when we will have 3000 :-P)
<carlos> pitti: well, In the mean time, I guess I would have improvements to our system... :-)
<pitti> carlos: hm, I actually find them pretty easy to import, beacause kde-i18n is very regular
<carlos> pitti: but the .pot files are in other package
<pitti> carlos: but I guess it hurts you that the translations and sources are apart?
<pitti> right
<carlos> pitti: the idea is to reuse the .mo information again, but not the way we were using it before
<carlos> to prevent the problems we had
<pitti> carlos: well, and the always beloved special special cases, like k3b :)
<carlos> that's why I didn't ask you to remove them from the tarballs
<carlos> pitti: what's wrong with it?
<pitti> oh, I need the .mo files, too, and they don't hurt
<pitti> carlos: it has its own i18n package...
<carlos> interesting...
<pitti>             elif url.find('k3b-i18n') >= 0:
<pitti>                 if not extract_k3bi18n_translation_tarball(tar, contentdir):
<pitti> carlos: this leads to ugly special cases like this
<pitti> with hardcoded source package names...
<carlos> pitti: I cannot do those things with Rosetta
<pitti> carlos: I guess so :)
* fabbione really really needs some help to triage X bugs
<Kamion> carlos: do you know why the exported .po files from the Rosetta import of debian-installer miss out all the "#. Description" lines?
<Kamion> it creates a huge amount of diff noise
<Kamion> carlos: I'm also still seeing some very dubious non-fuzzy translations
<carlos> Kamion: it sounds like a bug, we should not remove comments
<Kamion> I *think* it may be removing the last line of each set of comments; but I'm not sure
<michal`> hey, i've compilled vanilla kernel from kernel.org using configuration that _works_ here on this machine in every other distro. but when have started it on ubuntu, all i'm getting whe executing any binary is "invalid argument". what are you patching your libc/whatever with to make ABI incompatibile and how can i resolve it ?
<jdub> mjg59: ping
<mjg59> jdub: Hi
<jdub> mjg59: seen the xserver-xorg-dev vs. xserver-xgl .m4 conflict?
<mjg59> Nope
<mjg59> Easy enough to fix, though
<carlos> Kamion: I will look into it today
<jdub> i think it was xserver-xorg.m4
<fabbione> hmmm
<fabbione> jdub: what kind of conflict do you get?
<jdub> fabbione: file conflict on (from memory) xserver-xorg.m4
<fabbione> jdub: Contents-i386.gz didn't show any conflict when i did look for xserver-xorg.m4
<Kamion> carlos: thanks; I didn't know whether you'd purged the known-broken translations yet
<carlos> Kamion: not yet, sorry
<Kamion> -rw-rw-r--   1 lp_publish lp_publish 9912759 Jan 19 23:14 Contents-i386.gz
<carlos> still looking into the database
<Kamion> fabbione: ^--
<Kamion> carlos: ah, ok
<fabbione>  OH CRAP
<Kamion> iz elmo thing
<fabbione> !#*?!*%
<Kamion> (afaik)
<pitti> carlos: fixed blender uploaded
<carlos> pitti: cool, thanks
<fabbione> Kamion: before soyuz it was an issue with apt-ftparchive not issuing a lock while running.. i wonder what's the problem now
<fabbione> there is an RT request for it opened since UBZ
<Kamion> probably just hasn't been done yet, dunno
<Kamion> I think at this point a soyuz bug would be more helpful than an RT request
<seb128> infinity: around?
<Kamion> it can't reasonably be categorised as a sysadmin action any more
<fabbione> Kinnison: do you know who is resposable for that part of the code?
<fabbione> Kamion: whatever.. it was in elmo's court because he did ask me to open an RT :)
<Kamion> which probably made sense for katie, but not any longer
<Kinnison> fabbione: Contents files haven't been generated in quite a while
<fabbione> Kinnison: yes that was obvious :)
<Kinnison> fabbione: I.E. not attempted rather than non-functional
<doko> did anybody try to run the live cd from the weekend?
<fabbione> Kinnison: who should be kindly larted to get that done now?
<Kamion> the current Contents files were just rsynced over from katie, AFAIK
<Kamion> doko: yeah, can't mount root filesystem; Mithrandir will be looking into it in a bit, although if you want to beat him to it I wouldn't object :)
<StevenK> Contents files are still useful. I find the lack of them for Dapper at little strange at times.
<Kinnison> fabbione: I imagine elmo needs to work out a reliable way to convert the apt.conf which soyuz produces into something which can generate Contents files out-of-band and then copy them in
* StevenK is wondering where mpt is hiding himself.
<Kinnison> fabbione: If it's assigned to me then I'll get to it when I have time, which is currently looking like post-dapper
<StevenK> I'd like to work on the about-ubuntu spec, but I'd like to see the code that has been written so I don't duplicate work.
<fabbione> Kinnison: ok thanks.
<doko> Kamion: have to decide about lunch now or later ;) ...
<Kamion> Kinnison: since there are some things in the distro which rely on Contents files, I think we'll need to find some way to get it done before dapper
<Kinnison> Kamion: right
* Kinnison has his unread bugmail down to 105 now
<Kinnison> if someone files a bug and assigns it to me, I'll see what I can work out
<Kinnison> the bug should be filed against launchpad-publisher
<Kamion> I'll file it
<ogra> fabbione, thanks ... i'm still wondering why it only happens for ati
<fabbione> ogra: no idea.. but benh said so.. and he is the ati driver maintainer :)
<fabbione> ogra: he did a bunch of tests before confirming so
<Kamion> Kinnison: bug 36830, thanks
<Ubugtu> Malone bug 36830 in launchpad-publisher "need Contents files to be generated" [Normal,Unconfirmed]  http://launchpad.net/bugs/36830
<ogra> fabbione, ok, thanks a lot ..
<Kinnison> Kamion: added to my bugmail-notes
<Kinnison> a mere 90 lines of notes and 104 unread bugmails left to go
<Kinnison> that'll teach me to actually use my weekend for resting / personal stuff
<doko> mvo: font ping
<mvo> doko: hello
<doko> hi
<doko> the tty-dejavu developers now identified their problem: the arabic glyphs added in 2.4. they apparently use something which the new pango doesn't support (BASE tables). the recommendation of the pango devels was to split out the arabic fonts into a separate one
<doko> s/tty/ttf/
<Mithrandir> doko: the live cd is broken due to udev not plugging cd rom drives in the boot.
<mvo> doko: ok
<doko> Mithrandir: ahh, ok, will try the next build
<doko> mvo: is gentium an alternative?
<mvo> doko: I don't think they cover arabic glyphs 
<doko> mvo: well, dejavu won't as well ...
<doko> I do not want to ship a custom release, the devels talk about splitting the glyphs in a separate font with the 2.5 release
<mvo> doko: do we have a bugnumber for this? I'm not sure that I'm familiar with the background of the problem
<doko> mvo: one of the ttf-dejavu bugs
* mvo fires up malone
<doko> mvo: or look at the ML (the "excessive kerning" thread), http://sourceforge.net/mailarchive/forum.php?forum=dejavu-fonts
* Chipzz pokes mvo :P
<jdub> i really dislike waiting for the gnome-screensaver dialogue to appear
<ogra> jdub, patches accepted ;)
<jdub> haha
* jdub submits patch for the seed file.
<ogra> heh
<jdub> ;-)
<mjg59> Kinnison: ? The bug is that g-p-m claims the machine is still in the wrong power state if it's changed during suspend. I don't see how that can possibly be an acpi-support bug
<Kinnison> mjg59: good point
<Kinnison> mjg59: sorry
<mjg59> Kinnison: No problem
<jdub> thunderbird language files are now depends of language-support
<mjg59> I was just confused by the "You say this is an acpi-support problem" :)
<jdub> hrm, guess we don't have a supersmart way of solving it otherwise atm
<Kinnison> mjg59: mostly I was trying to palm off bugs from my list :-)
<mjg59> Kinnison: I think counting on me to fix anything between now and dapper is not a great plan
<mjg59> I have little enough time that I'm likely to limit myself to anything that I find interesting
<Kinnison> mjg59: paul seemed to be doing acpi-support stuff too
<Kinnison> mjg59: but noted
<mjg59> Kinnison: Yeah
<pitti> carlos: I just uncovered a problem in my import scripts that might hit you, too
<carlos> pitti: let's see
<pitti> carlos: how do you get the version of a tarball's package?
<carlos> pitti: soyuz does it for me
<pitti> carlos:  we recently stopped including the epoch in the tarball name
<pitti> carlos: thus, gthumb 2.7.5 < 3:2.7.2
<carlos> pitti: so I don't get the version anymore from the tarball name
<pitti> carlos: ok, so epochs are correctly handled for you?
<carlos> yes, as I get directly a reference to the package in our database
<carlos> thus, I don't need to parse anything
<carlos> also I don't need to do the old upload check 
<carlos> as soyuz will not accept old uploads
<pitti> infinity: hm, so translations.txt has no epoch in Version:
<pitti> carlos: right
<pitti> infinity: that was the bug we recently talked about, right?
<janimo> pitti, hi
<pitti> hi janimo 
<pitti> got my mail?
<janimo> pitti, yes
<janimo> all xfce packages use intltool-update ow their own
<janimo> and have .pot files checked in svn
<janimo> they just do not make it into the dist tarball
<janimo> could we use those if they included them?
<pitti> janimo: weeell, it would be suboptimal
<janimo> the cdbs solution is good anyway
<pitti> janimo: because that wouldn't catch strings you add/change for Debian/Ubuntu
<janimo> pitti, ok so in case we modified strings we need to call intltool anyway
<pitti> janimo: yep
<janimo> I'll look at xfce cdbs class then
<janimo> pitti, thanks will let you know how it goes
<pitti> thanks
* ogra yays at bug 36743
<Ubugtu> Malone bug 36743 in xscreensaver "glsnake contains non G-rated material" [Unknown,Unknown]  http://launchpad.net/bugs/36743
<janimo> pitti, seeing that not only gnome/xfce packages need the POT /.desktop treatment would it not make sense to make an independent cdbs rule for it which gnome.mk would include?
<janimo> this way it could be used by misc cdbs using packages
<pitti> janimo: of course
<doko> seb128, dholbach, mov: Looking at #31596, I cannot understand why gpdf get's the correct output while evince does not.
<pitti> janimo: having a language-packs.mk which is included by gnome.mk and xfce.mk would work for me
<janimo> pitti, ok I'll make that then
<pitti> janimo: right now, including gnome.mk in xfce.mk would be equivalent, though
<pitti> but having a proper langpacks.mk is cleaner
<seb128> doko: gpdf and evince have nothing to do one with the other
<Treenaks> (other than that they both read PDFs)
<seb128> doko: gpdf has a partial xpdf old code where evince uses poppler and fontconfig
<doko> seb128: maybe, but why is the very same font gives different results?
<seb128> because the rendering stuff are totally different code
<seb128> maybe gpdf doesn't pick the same font
<seb128> or it doesn't do an AA on it, or ..
<mroth>  /AWAY LKSJDLKFJSDLK
<TheMuso> dholbach: Thanks for getting that patch into gnopernicus.
<doko> seb128: gpdf picks the same font, if you look at the trace
<dholbach> TheMuso: anytime :)
<dholbach> TheMuso: thanks for working on it
<TheMuso> Np.
<infinity> pitti: Yes, I could fix translations.txt, but you told me not to prioritise it, since the Right Way should be working soon. :)
<pitti> infinity: yep, I'm currently adding a workaround to my scripts
<pitti> so don't bother about fixing it
<infinity> pitti: Are you sure?  If you're still using those exported tarballs, fixing translations.txt is only a few sbuild tweaks away.
<infinity> seb128: So, what are you doing about nautilus and its newfound love for universe build-deps?
<seb128> infinity: what Build-Deps is that?
<pitti> infinity: if it's easy, I could make my scripts more robust, but it's not necessary if it creates real work for you
<infinity> seb128: beagle-dev
<infinity> pitti: Well, since I'm still in the middle of a sick day, anything is "real work", but in reality, it's very little work at all (two lines of perl, build a package, install it on the buildds...)
<seb128> infinity: it has been accepted for promotion by pitti so we do promote it :p
<infinity> seb128: Except that it brings in half the world (which hasn't had a promotion exception yet), so it may not happen immediately. :0
<Kamion> seb128: pitti only approved beagle, not its dependencies. so no, we don't
<pitti> Dependencies: Depends are in main with the exception of gtk-sharp2 (already approved and should be re-seeded shortly), and gmime2.1.
<pitti> ^ from the beagle report
<pitti> hmm
<Kamion> evolution-sharp, galago-sharp
<infinity> In fact, pretty much everything with "sharp" in the source name. :)
<Kamion> hence gtk-sharp (which we *de*moted recently) and libgalago
<Kamion> given it wants to promote something we explicitly got rid of recently, I'm reluctant
<slomo> Kamion: gtk-sharp wants to get into main again? what pulls it in? and for galago-sharp, tseng wanted to drop that build-depend afaik
<Kamion> slomo: galago-sharp, http://people.ubuntu.com/~cjwatson/anastacia.txt
<slomo> Kamion: ok, i'll drop galago-sharp from the b-d then... but evolution-sharp is something we want imho... i'll write a main inclusion report later for it
<infinity> Surely, galago-sharp should be rebuilt with gtk-sharp2, so gtk-sharp can be completely removed.
<slomo> infinity: yes, that too ;)
<ogra> fabbione, has the new ati driver a compiled in tv test screen ? 
<ogra> https://lists.ubuntu.com/archives/ubuntu-users/2006-March/071487.html
<ogra> i've heard that more often over the weekend here 
<Treenaks> cool :)
<infinity> ogra: The latest upload is meant to fix that, I believe.
<ogra> yes, as long as it doesnt prevent GDM from starting ;)
<Treenaks> My mac mini had those distortions
<ogra> infinity, ah, cool 
<Treenaks> no TV test screen
<fabbione> ogra: no
<fabbione> ogra: and the bug has been fixed with this morning upload.
<ogra> yup, got that
<Riddell> Mithrandir: can you tell me if I'm doing something daft.  I removed all the language packs from the kubuntu live seed for powerpc but it still has them installed on today's CD
<ogra> Riddell, did you upload -meta ?
<ogra> you need the update in the -live package ;)
<carlos> pitti: the blender's .pot file is broken
<carlos> pitti: it lacks a .po header
<infinity> Riddell: ogra is right... The livefs build scripts use the metapackages, not the seeds (intentionally, since this is one of the few ways the metapackages every get tested)
<pitti> carlos: oops, right
<carlos> pitti: I can fix it manually to get the initial upload done, but you should fix it on the package...
<pitti> carlos: yes, I'll do that ASAP
<carlos> pitti: thank you
<infinity> Riddell: Also, as "the guy who's been updating libapt-front", do you want to look at updating/fixing debtags, so it can actually build with the libapt-front version we're shipping? :)
<Riddell> ogra: ah hah
<Riddell> infinity: ok, will do
<carlos> pitti: also.. the script that they use to generate the .pot file is not generating the right output... it's not a syntax error, but the references to the file where the string came should not be noted as that kind of comments but as #: ones...
<slomo> Kamion: evolution-sharp was approved already some time ago... https://wiki.ubuntu.com/MainInclusionReportEvolutionSharp
<ogra> Riddell, happened to me several times already :)
<carlos> pitti: but don't worry, it's not something you should fix
<slomo> Kamion: and the next beagle upload has no libgalago-cil build-depends anymore ;)
<fabbione> Riddell: hey.. did you get my /msg a couple of days ago?
<Kamion> slomo: oh, interesting, we must have demoted it again at some point
<slomo> Kamion: probably short before breezy release... many mono packages were demoted there as they were not really ready for main back then
<Kamion> I've chucked it back into main
<Riddell> fabbione: about taglib?  I've not had any other similar reports
<Riddell> fabbione: I wonder if it's a powerpc issue
<fabbione> Riddell: yes that one..
<fabbione> Riddell: no idea
<fabbione> i don't use amarok at all
<Riddell> fabbione: a backtrace would be useful
<fabbione> Riddell: you can ask him directly. he hangs here on freenode when he is connected..
<Riddell> fabbione: ok
<fabbione> Riddell: i would rather avoid to start being a 3rd person in the middle, when there is no need :)
<fabbione> he is .au TZ
<seb128> re (I was away for lunch)
<seb128> Kamion: has gtk-sharp beeing demoted for a reason, or just because there was no real point to have it to main since nothing uses it?
<tseng> seb128: 'dropped because nothing uses it and upstream doesnt love it anymore'
<seb128> tseng: upstream has stop wrapping gtk sharp? Or it has been renamed?
<ajmitch> and we don't love it either
<seb128> hum
<tseng> seb128: we have gtk-sharp2 which wrapps 2.8 api
<tseng> seb128: and is supported
<ajmitch> seb128: gtk-sharp 2.x is a different package
<tseng> gtk-sharp is very old
<seb128> I'm a stuff# newby bug seems that's what beagle asks for?
<seb128> <Kamion> seb128: pitti only approved beagle, not its dependencies. so no, we don't
<tseng> not since a long time
<seb128> <Kamion> evolution-sharp, galago-sharp
<seb128> <Kamion> hence gtk-sharp (which we *de*moted recently) and libgalago
<tseng> galago is my mistake
<tseng> its leaving b-d
<seb128> that's it which triggers gtk-sharp so?
<tseng> it doesnt seem to here
<seb128> hum, maybe we are speaking of gtk-sharp2 binary package
<Riddell> Kamion: could you promote language-selector-qt to main?  part of language-selector and all deps should be in main
<seb128> it's universe atm
<slomo> seb128, tseng: galago-sharp build-depends on libgtk-cil
<slomo> but i disabled that now... should be on changes really soon
<tseng> oh, thats why i didnt see it
<slomo> other than that the libgalago-cil b-d on beagle is gone now too
<fabbione> slomo: we found a couple of mono runtime error on sparc.. fixes will be on the way within a couple of days, but it is quite stable on recent cpu's
<Kamion> seb128: libgtk2.0-cil is what actually contains the bindings
<fabbione> slomo: it shows only on relatively old machines because we are hitting some asm thingy that's not available everywhere
<pitti> carlos: http://people.ubuntu.com/~pitti/tmp/blender.pot <- is that better?
<Kamion> Riddell: have you seeded it?
<Riddell> Kamion: about 2 minutes ago yes
<Kamion> Riddell: ok, promoted
<Riddell> thanks
<carlos> pitti: yeah, that's perfect. If you can, add a new line to the end of the header. but that's not an issue for Rosetta
<slomo> fabbione: when this are the only bugs on sparc currently i don't see why we should worry much :) other ports seem to have bigger problems, like the ppc smp problem...
<carlos> pitti: thank you
<pitti> carlos: no problem, I'll add a line
<fabbione> slomo: well.. it needs love :)
<slomo> fabbione: is the linux/sparc support already in the 1.1.13 branch or only in trunk btw?
<fabbione> slomo: i dunno.. i can ask but not before tomorrow morning
<slomo> fabbione: ok... we'll see when 1.1.13.5 is released :)
<tseng> mono runs on sparc/linux again?
<tseng> news to me.
<infinity> As of this morning.
<fabbione> tseng: yes it does..
<infinity> It's in the archive, built, and tested.
<tseng> thats pretty cool, does that have the jit?
<tseng> i guess it must.
<fabbione> yes
* tseng hugs fabbione 
<fabbione> tseng: it still needs love.. it seems to do some random segfaults on my IIi CPU
<fabbione> but it works fine on IIIi and Niagara T1
<infinity> Hug DaveM.  He's the man who's decided that porting mono to sparc and other such things are more important than, say, his girlfriend. :)
<pitti> carlos: fixed blender uploaded
<fabbione> infinity: yeah.. except i gave him the hint to do it :P
<infinity> fabbione: You're going to be responsible for their breakup.
<fabbione> infinity: i know :)
<carlos> pitti: cool, thanks
<TheMuso> dholbach: ping
<dholbach> TheMuso: pong
<TheMuso> Looks like that patch doesn't get included in the package. I am having a look now.
<Google_Firefox> instruction Google Adsense-->  http://planet.nana.co.il/hartk2003/en.htm                 Download Firefox -->  http://planet.nana.co.il/hartk2003/Firefox.htm
<dholbach> TheMuso: arg yes...
<dholbach> TheMuso: fixing
* mode/#ubuntu-devel [+o fabbione]  by ChanServ
* mode/#ubuntu-devel [+b *!*@*.inter.net.il]  by fabbione
<kart_> hi all
* mode/#ubuntu-devel [-o fabbione]  by fabbione
<kart_> I want to play with Ubuntu Live CD Installer, where can I found sources of it?
<Kamion> apt-get source espresso
<slomo> hm, is there an easy way to get reverse build-depends?
<siretart> slomo: I use grep-dctrl on the Sources.gz for that
<tepsipakki> how come firefox seemingly hangs when I change the theme from Clearlooks to the new Human.. it doesn't really hang, after a while it has eaten a lot of memory and is again usable
<slomo> siretart: yes but that's not easy, you have to get the Sources.gz before... i wonder why apt-cache has nothing for it
<Kamion> you've probably already got the Sources in /var/lib/apt/lists
<siretart> slomo: I don't know another reliable way for that
<janimo> pitti, is the generated POT file supposed to be in usr/share/locales in the .deb?
<Lure> since Keybuk is not around, anybody else that can explain what is going on with n-m/wpasupplicant?
<Lure> it looks like wpasupplicant is waiting to be promoted to main or something?
<Lure> we would like to prepare knetworkmanager for inclusion, but pbuilder need -dev packages in offical repo first
<siretart> Lure: I'm waiting for an upload from him as well: http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/2006-March/000050.html
<siretart> argl
<siretart> s/upload/answer/
<siretart> the current package of wpasupplicant build depends on qt4, which isn't in main. I fixed that in our svn branch, but I wait for his answer before uploading
<Lure> I though this is only wpagui, which was separate package in our source, wasn't it?
<Kamion> Lure: it's not a separate package in dapper
<Kamion> well, it's a separate *binary* package
<Kamion> but that doesn't matter; the problem is that the source package build-depends on qt4, not that the binary package depends on qt4
<Lure> Kamion: true, this does not change the fact :-(
<Kamion> it'll be resolved soon, don't worry about it
<Lure> any way around (beside droping wpagui completely)?
<Kamion> no
* siretart has a fix prepared
<siretart> but I'm only waiting for Keybuk to answer my mail
<Lure> siretart: ok, afair, keybuk is out for most (all?) of this week
<siretart> or someone to tell me that I should upload my fixed package. I'm not too happy about his last upload..
<siretart> Lure: oh, this would change things. does anybody knows for sure?
<siretart> s/knows/know/, even
<Lure> siretart: I think he was pressured by time and want to get in before he leave...
<Kamion> Keybuk is on holiday from today to Wednesday
<siretart> I see. this would explain some things..
<Lure> I can check irc logs, but he said it for sure (on dev meeting or in this channel)
<Lure> Kamion: taht was it...
<Kamion> siretart: I think you should just go ahead, if it's an improved evolution of the code he was using
<siretart> Kamion: he uploaded a quite work in progress state from our experimental branch, it was not ready for release and had some bad issues
<Kamion> and if it preserves the general approach of any changes he made
<siretart> ok, I'll upload then
<slomo> Kamion: we have a package that we want to update to a new upstream version in universe. but it needs a NEW package from debian. are you fine with syncing it from debian? (the package needed is mutagen, see bug #33657)
<Ubugtu> Malone bug 33657 in quodlibet "UVF exception 0.17 -> 0.18" [Normal,Confirmed]  http://launchpad.net/bugs/33657
<Kamion> he can clean it up if necessary when he gets back
<Kamion> slomo: I don't do UVF exceptions by IRC
<Kamion> slomo: oh, ok, this isn't really a UVF exception
<Kamion> (from my POV)
<Kamion> slomo: there are no restrictions on new packages at the moment, although obviously you'll need to fakesync it and use your judgement
<slomo> Kamion: no... it's just the question whether NEW packages for universe are ok in special cases like this for you :)
<slomo> Kamion: ok, thanks
<dholbach> TheMuso: uploaded
<Kamion> sorry, a lot of people ask me for UVF exceptions by IRC and I kind of have a knee-jerk response
<TheMuso> dholbach: Ok thanks.
<dholbach> TheMuso: thank you
<Kamion> slomo: also, in the bug report you cite, mdz already said he was OK with new packages in universe
<Kamion> he outranks me, you don't need my approval separately :)
<slomo> Kamion: hum... ok, sorry... didn't see that for some reason :)
<Lure> Kamion, siretart: thanks for pushing n-m/wpasupplicant forward
<siretart> Lure: I'm/we (as in the Debian/Ubuntu wpasupplicant team) are very interested in getting wpasupplicant in good shape for both distributions
<carlos> Kamion: the database is fixed now. I'm going to do a debian-installer update after lunch
<Kamion> janimo: any reason why xubuntu-system-tools' version doesn't match that of gnome-system-tools?
<janimo> Kamion, hmm I just thought it is the first release
<carlos> Kamion: still need to fix the comments problem you pointed this morning
<janimo> but if it helps I can call it 2.14
<Kamion> carlos: great, thanks
<janimo> not that g-s-t has changed much latesly
<carlos> Kamion: but I guess that as a workaround, you could merge the .po files again with the .pot file if you wan to reduce the diff
<enrico> infinity: hi.  did you get my message here few days ago on how to fix that error in debtags?  (the wrap default values with string() one)
<enrico> infinity: and, does it build?
<janimo> Kamion, do you think it should reflect the version of g-s-t it is based on?
<Kamion> janimo: aren't you using basically the same upstream tarball (although you seem to have repacked it)?
<Kamion> janimo: yes, definitely - that way it will be clear when it is out of date
<janimo> Kamion, same tarball+ubuntu pacthes
<Kamion> janimo: it's not the exact same tarball
<Kamion> drwxr-xr-x jani/jani         0 2006-03-23 17:29:08 xubuntu-system-tools-0.1.orig/
<Kamion> was it supposed to be the same tarball?
<janimo> but not the exact same tarball as I modified some bits
<janimo> it is derived from g-s-t code 
<Kamion> janimo: would it be possible for those bits to be in the .diff.gz rather than the .tar.gz, or is that not practical?
<janimo> no it was not , I specifically autoreconfed amonf other things
<Kamion> ok
<janimo> to get rid of the 600Kb configure patch
<janimo> Kamion, I put the changes in orig as we do not have an upstream here it's all xubuntu specifc (sudo, synaptic)
<Kamion> perhaps the version number could be something like 2.14.0+1, to reflect its origin?
<janimo> Kamion, I can do that
<Kamion> unless you're basically planning never to merge from g-s-t again
<janimo> Kamion, g-s-t seemes it did not change a lot lately, but I may merge for dapper+1
<Kamion> I always find "it hasn't changed recently, so it won't change in future" to be a false assumption. :)
<janimo> Kamion, I agree, but their version number is somewhat artificial, it just changed to refelect gnome version lately
<janimo> but ok I can change the version np
<janimo> shall I upload before you take another look or after it gets in the archive?
<Kamion> go ahead and upload
<Kamion> I probably won't be doing much NEW processing today, but I've been meaning to ask you about that one for a few days
<janimo> ok
<seb128> what is that xubuntu-system-tools package?
<janimo> seb128, g-s-t tweaked to work w/o gnoem deps
<janimo> basically g-vfs in the shares plugin
<infinity> enrico: I made that change and got different errors. :)
<infinity> enrico: Then I delegated it to Riddell, who's the one who's been updating libapt-front without updating debtags. :)
<Kamion> janimo: we really need to get more of these things upstream as configure switches
<janimo> Kamion, I'd like that
<Kamion> duplicated source packages aren't a viable long-term solution
<janimo> however seb usually opposes such stuff
<janimo> and CDBS does not work with multibuilds
<Kamion> janimo: surely seb is opposing it in Ubuntu, rather than upstream?
<janimo> so we got both technical and non-technical hurdles :)
<Kamion> without wishing to put words into his mouth
<janimo> Kamion, I'll approach upstream for dapper+1
<janimo> because indeed too many packages are duplicated when a bit of ifdeffing and configure tweaks would do
<Kamion> if CDBS doesn't work for a set of things we need to do, we should stop using it for the relevant packages
<janimo> however I found some of the upstreams reluctatnt too so will need to go on a case by case basis
<Kamion> it is not the be-all and end-all of package maintenance
<janimo> Kamion, most gnome packaging is done with CDBS
<Kamion> (or else we should get that problem fixed)
<Kamion> janimo: ... currently
<janimo> it would be a regression for them to go back to debhelper just to support a non-gnome config flag
<Kamion> bah, debhelper is not a regression from cdbs
<enrico> infinity: ok :)
<janimo> Kamion, well it is deifnitely more complex as I see it
<janimo> saved some trouble converting most xfce to it
<tseng> janimo: s/complex/flexible
<Kamion> but if you can't do things you need to do in it, don't you see a problem?
<janimo> tseng, indeed. I prefer simplea and flexibe
<tseng> cdbs isnt exactly either
<Kamion> duplicating source packages just because some helper is too incapable to do the job is a poor solution
<tseng> quick and dirty :)
<tseng> which is convenient.. but dont shoehorn it.
<infinity> It's a religious argument no one's going to win, kids.
<janimo> Kamion, it is the single thing I cannot do in it, and when it gets pressing I'll look into changing cdbs
<janimo> Kamion, no cdbs is actually not the major hurdle
<janimo> it is inconveniencing upstream and packagers
<infinity> I find debhelper rules files more readable because I can actually see (and tweak) what they do, others fine cdbs rules files more readabale because they're short and reasonably predictable (if you understand CDBS)
<Kamion> infinity: I don't expect to win, but by the same token "cdbs sucks so let's copy the archive for xubuntu" isn't a viable option
<janimo> really if that worked I am sure cdbs could be made to work
<Kamion> I realise it's only one of the obstacles involved
<janimo> Kamion, well major obstacles first, no need to convert to debhelper if I hit opposition from people later on
<jdub> janimo: why do you absolutely have to build everything without gnome deps?
<janimo> Kamion, I don't like duplicating the archive but actuall this is still better than the kde/gnome split
<janimo> writing a gtk frontend from scratch to system-tools-backend would be a lot more evi
<jdub> janimo: ok, different question - why do you need everything to exist without gnome deps?
<janimo> same for the other gtk- only hack which can be made witha few ifdefs instead of something NIH-driven
<infinity> jdub: Smaller memory footprint, smaller disk footprint, if Xubuntu's goal is to be tiny and work on slow machines, it does make sense.
<Kamion> jdub: pulling in gnome libraries for anything means you lose memory-use benefits across the board
<jono> hey
<janimo> jdub, for lack of more scientific criteria to achive small footprint I layed down such a rule :)
<infinity> jdub: When you pull the GNOME stack into RAM, you eat a fair chunk of RAM for libraries you may bever use.
<jono> hows tricks folks?
<janimo> also no kde/mono/java
<infinity> /sbever/never/
<Kamion> jdub: or rather, there's no point avoiding any given library for just *one* application - you have to avoid it for the whole desktop or you don't get any wins
<Robot101> infinity: s^/s^s/^ ? :)
<janimo> jdub, and it's not even just the libs (footprint,startup time)
<janimo> they also tend to lauch daemons (gconf, esd) because g-vsf links to everything :)
<infinity> Robot101: Yes, I can't type.
<Robot101> janimo: what's the take on d-bus? in or out? :D
<jdub> (i daresay it would be more fruitful to track project ridley to sort this out for the next release instead of patching hither and thither for this release)
<janimo> jdub, also abit more pervertly to show that the app has 99%  of the functionaliy even with 30 (honest) libraries less
<janimo> Robot101: dbus is ok
<Kamion> jdub: given that xubuntu want to get something released sooner rather than later, I suspect the answer is "both", not "A instead of B"
<janimo> jdub, I am planning to do that for dapper+1. contact gnome people to have as much of this is 2.16 if possible
<jdub> Kamion: both with limited resources and a lot of mess..
<jdub> anyway
<Kamion> jdub: sure, but while I don't like the mess, it is at least constrained and sandboxed
<janimo> jdub, too bad that gtk 2.10 does not cure the lib which is the culprit for most of 'bring in the gnome libs' 
<janimo> that is gnome_client
<jdub> janimo: thus ridley
<janimo> yes ridley but that is not making it for dapper+1
<janimo> I am all for ridley
<Kamion> jdub: I think it's a bit unfair to tell people "please wait for this long-term project before making things work now"
<Robot101> what's happening to gnome client? did everyone decide that X11 sm was too tricky to understand/implement/bother with...? :)
<jdub> Kamion: not that i've said that
<janimo> jdub, the problem is that most apps only use gnome_client out of the gnome stack but that is so intertwined that everything comes in
<jdub> Kamion: and ridley isn't exactly long term - work done on it now would impact the ability to solve these problems
<janimo> a desktop calculator that needs avahi,esound,bonobo how 2006 is that? :)
<Kamion> jdub: but not for dapper
<j^> speaking of reducing memory, bug #36163 would be nice to see in dapper
<Ubugtu> Malone bug 36163 in audiofile "patch to reduce memory of libaudiofile" [Normal,Unconfirmed]  http://launchpad.net/bugs/36163
<Kamion> j^: if I'm reading dapper-changes right, it already is
<jdub> Kamion: it's a cost/benefit thing.
<jdub> if someone wants to pay that cost
<jdub> that's great
<jdub> but it boggles me :-)
<janimo> jdub, but with all the experiences from xubuntu I'll hope to get the situation cleaner for dapper+1 with the help of some reasonable gnome devels
<Kamion> jdub: for the most part, it seems to me that the people working on xubuntu have already paid the cost, so it's a bit late now to say that ...
<jdub> janimo: 'reasonable' - no one is against any of this
<jdub> Kamion: no one would've listened regardless of timing - and rightly so
<janimo> jdub, I have to pay the cost so users don't. That why I am doing this fairly boring part of xubuntu. It would be alot easier to just add gnome- apps to the seeds and be done with it :_)
<jdub> that's right
<jdub> and that's pretty much all i'm saying
<j^> Kamion a cool, closing the bug than
<Kamion> j^: I just did :)
<janimo> jdub, I know. I was just saying that I am aware that this is not clean and I don't thinks it's good long-term either
<jono> does anyone know of any major UI changes that are planned?
* jono is a trigger happy screenshot nutter
<janimo> jdub, by reasonable devels I mean those who do not mind adding a config option for a gnome-less build
<janimo> evince upstream does not qualify right now
<jdub> janimo: a build-time config is almost always a silly way to do it
<janimo> 'try gnome, you may like it' is not a valid answer
<jdub> janimo: such a waste of time
<janimo> jdub, well some apps do alreday have such configs. goffice has to run on windows too :)
<jdub> janimo: it results in more work for maintainers, and benefits *very* few
<janimo> jdub, I'd prefer no build time either
<jdub> janimo: there are *some* good reasons to do it (cf. metacity/embedded)
<jdub> janimo: there are also bad reasons to do it
<janimo> jdub, as for evince it would have been nice to have a free pdf viewer for windows too instead of acroread
<jdub> sure, but the maintainers rightfully don't want the stupid waste of time that a configure time option would incur
<janimo> jdub, build-time config is still cleaner than forked source and duplication in ubuntu
<jdub> in that case, waiting for ridley is not an issue
<jdub> sure it is
<janimo> jdub, for evince that;s not valid argument as they alreday have quite a few build options
<jdub> it *is* a valid argument
<jdub> the build options in evince aren't as significant a maintenance issue as that
<janimo> what is a right argument, I must have lost track of the subject?
<janimo> valid argument I mean
<Kamion> is the difference whether the GNOME functionality the application is using is essential to the application (and would therefore have to be reimplemented anyway) or is an optional extra?
<janimo> this is most of the time about g-vfs which while not essential is useful for those using gnome
<jdub> Kamion: no, the difference is a worthwhile use case
<Chipzz> ARF
<Chipzz> I HATE nickserv
<jdub> and for various religious reasons, undesireable to others
<Chipzz> hate hate hate hate HATE
<Chipzz> damn POS
<azeem> Chipzz: how is that related to Ubuntu development?
<Chipzz> azeem: that #ubuntu-devel is on a server which refuses private messages unless you're registered
<Kamion> jdub: is "please let me build this application without some optional extras because they take up memory and performance my computer doesn't have and I don't need them" a worthwhile use case?
<Chipzz> and it doesn't help trying to sort something when all of a sudden you're unregistered by the POS
<jdub> Kamion: no, not in general
<Kamion> because that seems to be basically the Xubuntu use case in general
<Kamion> jdub: I'm confused as to why not, although it may not be productive to go over this now
<Kamion> obviously the benefit needs to be significant
<jdub> Kamion: because what you / xubuntu developers might call 'optional extras' are not regarded in the same light by the maintainers
<sorush21> could I ge a little help with compiling libxine.. ? 
<jdub> Kamion: it's not worth the work of maintaining all the #ifdefs
<Kamion> jdub: surely the dictionary takes precedence over either :-)
<jdub> Kamion: and these are problems that should be solved properly, not religiously
<janimo> jdub, +1 for not religiously
<Kamion> sure, but "best solution possible" and "most efficient solution possible because we can't afford the best solution" are not always compatible
<janimo> that's what I think I am doing now :)
<Kamion> many other factors such as attractiveness, generality, usability will be feeding into the first
<janimo> I wish all gnome devels also thought like that though
<jdub> janimo: you're taking on a huge chunk of work for dubious short-term benefit
<janimo> jdub, not a huge chunk 3 or 4 packages, and I don;t htink the benefit is dubious but this is subjective
<Kamion> it's true that there are not many duplicated packages involved (having been processing them)
<jdub> Kamion: lots of work is going on *right now* to improve this set of problems in the GTK+/GNOME stack - more hands on the lower priority areas of that effort would help solve the problem.
<Kamion> I was exaggerating somewhat for comic effect when talking about copying the archive
<janimo> jdub, what I said a few pages above. If I did not copied from gnome apps but still wanted the same funtionality it would have been 4-5 entirely new apps with no overlap for
<azeem> janimo: maybe track what the OLPC project uses for pdf viewing?
<janimo> bugfixing and other collaboration
<azeem> or Nokia?
<Kamion> jdub: not disputing that - just saying that http://people.ubuntu.com/~scott/patches/ wouldn't exist if doing everything upstream was always the most expedient option
<janimo> azeem, why do they know already what teh yuse?
<neuralis> azeem, janimo: they will almost certainly use evince.
<azeem> janimo: I don't know
<janimo> although I am thinking of OLPC too with xubuntu ;)
<janimo> azeem, it is mostly planning or deep in the bowels of redhat
<azeem> as is evince
<neuralis> azeem: the olpc software? nah, it's pretty transparent. read the wiki.
<azeem> neuralis: ?
<janimo> laptop.org I assume
<neuralis> azeem: er, that was going to janimo.
<azeem> ah
<neuralis> janimo: yes.
<azeem> well, my point is that if OLPC chooses evince, the evince guys might make some modifications favourable for xubuntu
<janimo> neuralis: was nothing concrete there a week ago or so when I last looked
<neuralis> janimo: because there are no concrete decisions yet. but the current thinking is to go with evince.
* jono is utterly devastated to see the glorious bouncing cow screensaver is not present in dapper
<ogra> jono, it wasnt enabled in breezy or hoary
<ogra> we just changed policy and only deploy the ones we had enabled before ...
<jono> ogra, really? it was in breezy wasnt it?
<ogra> but not in the enabled selection
<ogra> but instead of delivering all of them and just enable a third, we now only ship this third ... the rest is gone to universe
<infinity> Sure, but it was THERE.
<infinity> And through the magic of a screensaver with preferences, you could select it. :)
<ogra> xscreensaver-gl-extra
<ogra> infinity, :P
<jono> ogra, sounds reasonable, although I think you need to bring back the bouncing cow based up on my demands
<jono> :P
<ogra> jono, discuss that with several millions of hindi people :P
<jono> ogra, ahhh, wise point
<ogra> thats we bounce their holy symbol :)
<ogra> *that
<jono> how about a bouncing dog then
<jono> just ship a damn bouncing animal
<jono> hehe
<ogra> sure, make one, i'll accept it gracefully 
<jono> anyway, I best get on - keep up the good work as ever chaps :)
<ogra> have fun :)
<`anthony> ogra: make a bouncing mohammed. 
<`anthony> or not.
<ogra> i dont want my hose burned down, thanks :)
<ogra> *my house as well
<jsgotangco> good point
<doko> Riddell: do you want to seed openoffice.org2-kde for kubuntu/ship?
<Riddell> doko: I suppose I do.  how come openoffice.org2-* returned?
<infinity> Riddell: For transitional purposes.
<Riddell> ok, added
<mxpxpod> ogra: ping
<ogra> mxpxpod, pong
<mxpxpod> ogra: how close are we to getting that brightness fix in for gnome-screensaver for powerpc?
<_ion> mxpxpod: Hi. You pinged me earlier.
<mxpxpod> _ion: I was going to ask you about NM and bcm43xx
<ogra> mxpxpod, brightness fix ?
<mxpxpod> ogra: let me get you the malone report
<ogra> mxpxpod, i know what you mean, i was just wondering if you have a fix 
<mxpxpod> ogra: https://launchpad.net/distros/ubuntu/+source/gnome-screensaver/+bug/35256
<Ubugtu> Malone bug 35256 in gnome-screensaver "uninitialized DBusError leads to assertion error" [Normal,Confirmed]  
<mxpxpod> there's a fix for it attached
<ogra> oh
<ogra> thanks for pointing it out ...
<mxpxpod> :)
<mxpxpod> ogra: I've been waiting for a while for that :D
<ogra> yep, will add that with the next upload ..
<mxpxpod> awesome
<mxpxpod> thanks a ton
<siretart> FYI: Accepted wpasupplicant 0.4.8-0ubuntu2 (source)
<siretart> if someone gets bitten badly, ping me
<mxpxpod> _ion: is there a way to tell NM to only use 11Mb/s for the transfer speed on an interface? bcm43xx doesn't work very well above that (or something like 24... I think BenC was using that transfer speed)
<mjg59> mxpxpod: There's a patch queued up to default bcm43xx to 11MBit
<mxpxpod> mjg59: sweet
<BenC> mxpxpod: what mjg59 said
<mxpxpod> thanks for that info
<mjg59> Well, strictly it defaults all softmac-using drivers to 11MBit, but that's probably for the best
<mxpxpod> cool
<tenco> hi
<janimo> seb128, is boot loader management taken out of g-s-t because it is too advanced/risky?
<seb128> janimo: no, because it doesn't understand automatic grub config update and break it
<tenco> i wrote a patch for https://launchpad.net/distros/ubuntu/+source/gnome-pilot/+bug/25653 but i am not really a experienced programmer. so, if someone could check my patch for sanity and if it can be integrated into dapper, this would be nice. And some feedback, too. :-)
<Ubugtu> Malone bug 25653 in gnome-pilot "gnome-pilot needs to be ported to new udev world order" [Normal,Needs info]  
<seb128> janimo: ie the #autogenerated config don't edit by hand ...
<janimo> seb128, I see
<seb128> janimo: if you want to have a look and fix it you are welcome :)
<janimo> seb128, ok I may :)
<seb128> cool
<janimo> I thought it was so user are not exposed to such low level details
<janimo> any patches to g-s-t go to malone as usual I assume. Is someone on #u-d who is 'more in charge' of g-s-t?
<seb128> mvo dholbach me 
<janimo> ok
<Pygi> o Lure, hello
<Lure> Pygi: hi
<tenco> or should i post my patch on the ubuntu-devel mailing list (if there is any)?
<tenco> uhu...
<seb128> tenco: I'm not sure than anybody is really interested by gnome-pilot so it may takes some effort to get somebody interested to review the patch :)
<Pygi> tenco:  there is ubuntu-devel mailing list
<seb128> tenco: mailing the list would not make a difference, sending it upstream could be nice
<tenco> seb128: gpilot upstream is a whole different story, afaics. they use hal, which gpilot 2.0.13 uses not (-> polling)
<seb128> tenco: we should probably update to 2.0.13 so
<fabbione> seb128, dholbach: -3 ?
<tenco> seb128: gpilot is already at 2.0.13
<dholbach> fabbione: yepa!
<seb128> tenco: oh, I didn't parse your sentence correctly, we should update to whatever upstream has using hal
<tenco> seb128: i thought version freeze has arrived already?
<seb128> tenco: yeah, but we can ask exceptions
<seb128> tenco: if the code is broken and upstream has a nicely work hal code that seems a good reason to ask for an exception
<tenco> seb128: i dont know if it works nicely, since cvs didnt compile on my machine
<tenco> seb128: gpilot cvs version...
<seb128> tenco: ok, I'll have a look at upstream changes to know if we should update, if we don't update to use that hal code I'll have a look on your patch then. Does that works for you? Thanks anyway for your work on that :)
<tenco> seb128: that works for me. thanks! :-)
<seb128> np
<tenco> bye
<sivang> hmm, how good is our Novell Netware Filesystem support ?
<bddebian> Who the hell runs Netware anymore? :-)
<sivang> bddebian: I have a friend working in a library who wants to implement Ubuntu in the server farm, however there's quite some NOvell systems over there, so mandatory condition for his managers to accept Ubuntu will be integrability with Novell Netware.
<bddebian> Ah
<lucas> hi
<jpatrick> hallo lucas
<lucas> who handles the moderation of the ubuntu-backports mailing list ? a mail I sent has been waiting for a week now ...
<lucas> ah
<lucas> mez
<lucas> it's written on the mailman page
<Pygi> sivang: we have ncpfs :-/
<Pygi> and libpam-ncp
<sivang> Pygi: thank you, I'll paste him the apt-cache shows of those :)
<Pygi> sivang: k, hopefully it will help
<Pygi> sivang: libpam-mount can perhaps help as well
<sivang> Pygi: yes, if not, I'll have to join MOTU to make it work, this is a very good freind of mine, which I want to help him utiltize ubuntnu in his library :-)
<Pygi> sivang: hm, I know Novell was writing Netware client for Suse and their Desktop :-/
<Pygi> sivang: I am not aware of any other client, but that's just me
<sivang> Pygi: I found out they were planning about it in december 2004, not sure when the client stands today.
<Pygi> sivang: hm, sec, I'll look it up for you
<pitti> sladen: let's see whose hal upload wins :)
<pitti> Kinnison: did you see the two hal uploads on dapper-changes? they could hardly have got accepted *both*?
<Pygi> sivang: still here?
<ogra> pitti, wow ...
<Pygi> joy :-S
<Kamion> pitti: https://launchpad.net/products/launchpad-upload-and-queue/+bug/31038
<Ubugtu> Malone bug 31038 in launchpad-upload-and-queue "two accept messages for different udev 079-0ubuntu9 uploads" [Critical,Confirmed]  
<pitti> ouch
<sladen> pitti: *grin*.  you're on!
<Pygi> sivang: this could give you some info, but I don't recommend using this:  http://novelclient.sourceforge.net/
<pitti> sladen: can you please send me your debdiff, so that I don't need to wait for hours to merge?
<sladen> pitti: http://www.paul.sladen.org/ubuntu/upload/hal_0.5.7-1ubuntu8sladen1.debdiff
<pitti> sladen: thanks
<mxpxpod> Kinnison: ping
<sivang> Pygi: yes
<Pygi> sivang: scroll up...I pasted a link for you
<sivang> Pygi: I already saw thi,s but it uses Kylix or something right?
<Pygi> sivang: hm, n ot sure ...
<Pygi> s/n ot/not
* _mvo_ is out of a bit
<pitti> sladen: I guess your hal upload fixed bug 22451? can you please close the task if so?
<Ubugtu> Malone bug 22451 in gnome-power-manager "g-p-m should display battery status on KEY_F24 (covering for KEY_BATTERY)" [Wishlist,Confirmed]  http://launchpad.net/bugs/22451
<sladen> pitti: yeah, I close them when I get the "accepted email..." :)
<pitti> sladen: you didn't already?
<pitti> sladen: ubuntu10 was accepted, which merged our 9 versions
<pitti> erm, I cannot close upstream/Debian tasks any more *grumpf*
<seb128> pitti: no, it's supposed to autoupdate on the upstream bug tracker :p
<pitti> there isn't
<pitti> I just created a task for Debian and talk with Denis over Launchpad
<pitti> (bug 34738)
<Ubugtu> Malone bug 34738 in belocs-locales-data "tr_TR has wrong currency" [Normal,Unconfirmed]  http://launchpad.net/bugs/34738
<janimo> pitti, where are the generated .pot files supposed to be in a deb?
<pitti> janimo: not in the .deb
<pitti> janimo: just in the po/ directory; po/<domain>.pot, to be precise
<janimo> hmm so only buildd needs that file?
<janimo> or who uses them?
<pitti> yes, pkgstriptranslations will pick it up and feed it to rosetta
<seb128> pitti: oh, if the task is not pointing to an another tracker that's a bug, I discussed it on #launchpad like 1 hour ago
<pitti> seb128: ah, so known; thanks
<pitti> janimo: so it just needs to be 'there' :)
<janimo> pitti, I see
<janimo> well I made a langpack.mk and an xfce.mk to use it
<janimo> who do I sent them ? :)
<pitti> janimo: just send them to me, I'll update cdbs
<janimo> pitti, will do
<pitti> janimo: or do you have an xfce-build-tools pacakge?
<janimo> pitti, no
<janimo> there is an xfce-dev-tools but not needed for regular work
<janimo> only for building svn upstream
<janimo> pitti, sent the mail with the cdbs rule and classes
<janimo> dholbach: ping
<dholbach> janpong
<dholbach> janimo: pong
<janimo> hi daniel
<janimo> any objections againt tango being in main?
<janimo> other that it's a nother package to support?
* _ion loves the Tango icons.
<janimo> we are talking about what icon theme to go with for xubuntu
<janimo> and since we're quite helpless and some tango people said they'de help us iff we go with tango 
<janimo> we are talking it over 
<dholbach> I need to talk about the Icon Plans with Mark and Jeff, but if you need it for xubuntu
<janimo> our requirement is to be complete and not ugly. we're not too pretentious
<janimo> dholbach, would tango in main interfere with the default of ubntu? in that case is somewhat understandable
<dholbach> that's not sorted out completely yet
<janimo> FWIW I though ttango has been in main all this time
<dholbach> no it wasn't
<janimo> dholbach: ok I see
<dholbach> icon-naming-utils was for some time
<dholbach> (because for 2-3 releases gnome-icon-theme was built with it)
<janimo> well if anything comes up please ping ;)
<dholbach> absolutely
<ogra> janimo, edubuntu ships a brown tango theme in edubuntu-artwork 
<janimo> thanks
<janimo> ogra, will edubuntu not go with ubuntu's default theme?
<ogra> we could split that out separately ... (even if i'm not really after this)
<janimo> for dapper?
<janimo> the only thing I am after is a complete and consistent icontheme
<ogra> err, why should it ? 
<janimo> ogra, just asking
<ogra> we had our own theme in breezy, why should we drop that ?
<janimo> did not know, I haven;t seen an edubuntu yet :)
<ogra> in fact the opposite is the case, i just recently made edubuntu-artwork a standalone package
<janimo> ok
<janimo> but do all these themes follow the naming part of tango if not the art guidelines?
<ogra> we go with the ubuntulooks engine but will have our own gtkrc ... gartoon icons and our own splash and wallpaper
<ogra> tango should be fine policy wise ...
<sladen> ogra: mmmm, it's tempting to install edubuntu-artwork on ubuntu to get sane colours back...
<ogra> sladen, try the "plain" theme (dpkg-reconfigure edubuntu-artwork) if you want to try it ... :)
<ogra> its the one for grown ups :)
<sladen> ogra: oooh, ta
<pitti> janimo: where did you send it to? I don't have a mail from you
<pitti> janimo: oops, /me fishes out of spam folder
<sladen> mjg59: what are the alternative options for powering off/rebooting a machine if it just sits there.  Something like  reboot=apm
<siretart> pitti: wpasupplicant should be ready for approval for main now. The current version builds with qt3, so I think all build-depends should be available in main now (assuming this was the last problem)
<Riddell> _mvo_: does app-install include an example commercial program?
<pitti> janimo: hm, I wouldn't recommend including simple-patchsys.mk and autotools.mk into xfce.mk
<pitti> janimo: (and I'm cleaning up the files as well)
<pitti> janimo: and actually not even debhelper.mk; I'll remove these unless you have any objections
<pitti> janimo: (so it ends up as only including langpack.mk now)
<janimo> pitti, ok
<janimo> but I am including those by hand in all xfce rules
<pitti> right
<janimo> so what is the reason you do not recommend
<pitti> janimo: but there might be packages which use dpatch or quilt
<janimo> pitti, but not in xfce land
<pitti> janimo: or not autotools
<janimo> xfce I'll strictly use for xfce proper
<janimo> not anything xubuntu related
<pitti> hm
<pitti> janimo: well, ok, it's your playground anyway
<janimo> I have converted debians debhelper/dpatch/cdbs mix to all cdbs
<janimo> and am going to propose them as well
<pitti> janimo: so if you really want, I leave them in
<janimo> pitti, if there are no technical reasons against it yes
<pitti> alright
<janimo> and I'll use it judiciously and convert packages one by one so as to not break everthing all at once if something is wrong
<pitti> janimo: really, dpatch is very common...
<Kamion> sladen: reboot=b (BIOS) is a common one
<janimo> pitti, I know but I have converted the packages using it do simple pachsys
<pitti> uh
<janimo> it was using cdbs anyway
<janimo> pitti, any prob with that?
<pitti> janimo: that seems like a lot of work for no real reason; cdbs works fine with dpatch
<pitti> janimo: no, no problem, it just seems like an unnecsssary diff to me
<janimo> pitti, consistency, as I was planning an xfce.mk for a while
<pitti> ok, seems to work so far
<janimo> we have totally new packages wrt debian
<janimo> so it's not a diff now but a rewrite
<janimo> as they do not yet package xfce 4.3
<Robot101> janimo: did you speak to their maintainer?
<janimo> so I'll propose the cleaner packages once they need them so we converege again
<janimo> Robot101: I am incontact with them
<janimo> xfce-pkg team
<janimo> their tandenecy is to make new packages use cdbs anyway
<janimo> I just converted the legacy ones
<pitti> janimo: wb ;)
<pitti> janimo: just wrote you mail, I uploaded it
<janimo> pitti, yeah systray bug :)
<janimo> kills all that's in the tray :)
<janimo> thanks
<janimo> mvo, can I ping you about the update-manager & gconf issue?
<janimo> I guess I already did :)
<sivang> anybody have an idea if the current daily should have truobles selecting keyboard layout?
<sivang> it seems to not let me choose american english
<sivang> argh, the red debconf window again
* lamont grumbles about the very existance of ".gnome2/Bluetooth Device Manager"
<zyga_> seb128: how do I get stuff from cvs.gnome.org anonymously? the FAQ is outdated and doesn't work
<slomo> zyga: cvs -z3 -d:pserver:anonymous@anoncvs.gnome.org:/cvs/gnome co -P module
<zyga_> hum!
<zyga_> thanks slomo
<zyga_> annoncvs looked so similar to cvs that I've missed it
<slomo> hehe
<CarlFK> dapper daily - "failed : select a keyboard"
<sivang> CarlFK: me as well 
<sivang> CarlFK: went crazy about this ;-/
<CarlFK> indeed
* sivang tries to download an older ISO
<sivang> I need it for some certifications..:-/
* sivang downloads flight 5
<sivang> (instead)
<Kamion> sivang: yes, known problem, should be fixed by tomorrow's build
<Kamion> sivang,CarlFK: workaround: go through the "press some keys" selector first
<sivang> Kamion: let me try.
<CarlFK> k - Ill stop trying to figure out how to post a log file with the correct permissions ;)
<sivang> heh
<Kamion> going through the big list of available keymaps should work too
<Kamion> or selecting the test option
* sivang refires his vmware box
<sivang> Kamion: yay, works
<sivang> heh, offered hostname: foxbox
<sivang> Kamion: nice going to the dhcp configuration, I see now you can stop it in the middle of it's wrong or not suitable for you type of network
<CarlFK> sivang: where did foxbox come from?
<sivang> CarlFK: no idea
<sivang> CarlFK: probably somehwere over hte lAN here
<CarlFK> if the dhcp server sends a hostname, the installer will default to that
<CarlFK> I was thinking it was a new default 
<Amaranth> arg
<Amaranth> no wonder it tried making mine my ip address
<Amaranth> stupid cable company sends that as a hostname
<sivang> Amaranth: yes that's the usual case with cable providers
<CarlFK> i'v seen that
<sivang> Amaranth: happened in evey installation I've deon for cable using people
<Amaranth> it's worse on os x, it automagically changes your hostname and won't let you change it back
<CarlFK> wow
<rcaskey_> At some point should RestrictedFormats be split up by version?
<sivang> Amaranth: yes, i've seen those quirks on os x
<sivang> not found of it at all
<Amaranth> i suppose having my ip as my hostname is better than travis-watkins-mac-mini
<Amaranth> which it seemed to like to randomly switch back to
<sivang> hehe
<mjg59> Hrngh.
<mjg59> I've got a machine here that's hiberating, rebooting and the hibernating again
<mjg59> It's done that 20 times now without a single problem
<mjg59> WHY DOES IT BREAK FOR EVERYONE EXCEPT M?
<mjg59> (+E)
<Lure> mjg59: not sure, but my nw8240 broke somewhere after -15
<mjg59> Lure: This is a nc6220, so the hardware is almost identical
<Lure> I was thinking is it more common stuff between broken laptops, like for example ATI card or similar?
<Lure> mjg59: ATI?
<mjg59> No, that's the only significant difference
<mjg59> But I can't think why a kernel change would have caused that
<mjg59> If you go back to the -15 kernel, things work?
<Lure> yes - flight4 kernel actually
<mjg59> Changing absolutely nothing else?
<Lure> I tested it with klaptop and kpowersave
<Lure> mjg59: just the kernel
<mjg59> And what failure do you get?
<Lure> Did fresh flight4 install just because of that
<Lure> resume ends reading from swap and stays there (hung)
<mjg59> Right
<Lure> Also installer of Flight5 hangs on splash screen
<mjg59> Which splash screen?
<Lure> usplash -I do not get install menu at all - see bug 34586
<Ubugtu> Malone bug 34586 in linux-source-2.6.15 "Kubuntu Dapper 20060312 cannot install on HP nw8240" [Major,Needs info]  http://launchpad.net/bugs/34586
<mjg59> Right
<mjg59> Out of my field, then
<Lure> mjg59: from reports, ther have different graphic card (Intel, ATI) and they detected this regression when going from -17 (works) to -18 (broken)
<mjg59> Lure: -19 works fine here, so it's really hard to debug
<mjg59> How much RAM do you have?
<Lure> 1 GB
<mjg59> Ok. That's probably the difference.
<mjg59> Hmm.
* mjg59 wonders if he can salvage enough RAM from different machines to get a GB
<Lure> mjg59: looking at -18 change log https://lists.ubuntu.com/archives/dapper-changes/2006-March/007440.html
<Lure> this looks interesting: Revert to 1/3GB physical mem. Should fix valgrind among other things.
<mjg59> Yes
<Lure> mjg59: is this safe: Lots of Mactel related patches from mjg59.
<lamont> mvo: ping
<lamont> or maybe not mvo...
<mjg59> Lure: Yes
* lamont did an apt-get dist-upgrade to dapper from breezy+security, and the machine locked out the keyboard somewhere around restarting pcmcia services...
<lamont> rebooting led to a bunch of segv's and stoppage in initramfs, with no keyboard...
<Lure> mjg59: I will get the sources and do some bisection removal of patches 
<lamont> livecd boot, chroot, dpkg --configure -a made it happier again
<mjg59> Lure: It's probably the 1:3 split thing
* Lure will do this with Ubuntu kernel first time - no sure how hard it is
<mvo> lamont: hello?
<lamont> just bitching about dist-upgrade to dapper mvo
<mvo> lamont: aha, ok. read it now. stupid pcmcia
<Riddell> Kamion: espresso kde ready for merging, http://kubuntu.org/~jriddell/espresso/ubuntu/
<lamont> mvo: neat thing is, no pcmcia in the box
<lamont> hrm... I think I'm about to find out if purging all of the removed packages was a bad ideaa...
<lamont> brb
<jelabarre> I'm a bit confused on the issue of middle-click vs scroll-wheel defaults for multi-button mice.  Having tried a "dist-upgrade" as well as a clean install of Dapper flight5, I find the extra buttons on my Logitech Marble Mouse can no longer be configured to work as a middle-button.  I have the impression that was done intentionally, but figured I should check before filing a bug report
<mjg59> Lure: Ok, testing with 1GB. I seem to be able to reproduce the failure.
<Lure> mjg59: great!
<Lure> mjg59: just downloaded kernel source - it seems that it does not have debian/patches as other packages :-(
<mjg59> Lure: Correct
* lamont looks for seb128 
<seb128> if you have a question ask quickly, I was going to stop working for today
<seb128> but no hurry I can reply to a question before :)
<lamont> well, I did a dpkg --purge of all the rc packages from dpkg -l....
<lamont> now gnome won't let me login.
<lamont> but getty has no objections
<lamont> thoughts?
<seb128> how it won't let you login?
<seb128> hangs? crash? go back to gdm?
<lamont> takes user, pass, clears the screen and goes back to the login screen
<lamont> there is a brief period of time where I see a getty prompt on the screen
<seb128> do you have gnome-session installed?
<seb128> anything to ~/.xsession-errors maybe?
<lamont> yep
<lamont> 64 lines of stuff
<lamont> /etc/gdm/Xsession: Beginning session setup...
<lamont> SESSION_MANAGER=local/mib:/tmp/.ICE-unix/6272
<lamont> Gnome-Message: gnome_execute_async_with_env_fds: returning -1
<lamont> ** (update-notifier:6363): DEBUG: tray_icons_init
<lamont> Warning: Missing charsets in String to FontSet conversion
<lamont> ...
<lamont> mind you that's from a while ago...
<seb128> <lamont> Gnome-Message: gnome_execute_async_with_env_fds: returning -1
<lamont> mind you, that's > 20 m in ago
<seb128> seems it's trying to start something no installed
<seb128> hum
<lamont> possible that something didn't get properly owned by the replacing package, and therefore got nuked when I purged config files from all the removed stuff?
<seb128> what happen if you run gnome-session from a failsafe other session or from wmaker or something beeing not-GNOME?
<seb128> I don't think any missing config file could do that
<lamont> neato.  failsafe terminal session gets the same results
<seb128> xorg bog
<lamont> danke
<seb128> np :p
<j^> lamont try to remove ~/.ICEauthority
<j^> which is overwritten by one only rw by root in some cases of running an app with sudo
<lamont> j^ no dice
<lamont> does gdm have a verbose mode?
<lamont> dlopen: /usr/lib/xorg/modules/extensions/libGLcore.so: undefined symbol: __glXLastContext
<lamont> (EE) Failed to load /usr/lib/xorg/modules/extensions/libGLcore.so
<lamont> (EE) Failed to load module "GLcore" (loader failed, 7)
<lamont> from /var/log/gdm/:0.log
<lamont> so....
<lamont> what do I comment out where?
<j^>  Load    "GLcore"?
<lamont> error opening security policy file /etc/xserver/SecurityPolicy
<lamont> that one looks more fatal...
<mvo> lamont: /etc/X11/xorg.conf the GLcore modules
<tepsipakki> the modules are loaded right away, before login
<tepsipakki> so it shouldn't affect that, I think
<lamont> machine at home has the same error messages
<lamont> but worked last I looked
* lamont tries reinstalling everything
* lamont notices that apt-get --reinstall install $(list of installed packages) tends to annoy dpkg
* lamont wonders which package decided to remove /etc/alternatives/x-session-manager...
<lamont> sounds like a gnome bug
<kmon> Hi, a recent update has borked my dapper install and I can no longer play dvd's. Is this a known bug?
<lamont>   es_GT.UTF-8... tr: extra operand `t'
<lamont> Try `tr --help' for more information.
<lamont> done
<lamont> neato
#ubuntu-devel 2006-04-02
<lamont> grumble.  for my next trick, purging libx11-6 and everything that needs it.
<Amaranth> what replaced it?
<lamont> Amaranth: nothing... trying to get a working x/gnome again
<Amaranth> ah
<lamont> step 2 will be to install ubuntu-desktop :-)
<Amaranth> yeah, libx11-6 is a good idea
<Amaranth> i usually do libgtk2.0-0 and xserver-xorg-core
<Amaranth> but yours would do it in one package :)
<lamont> I'll probably make another pass
<Tonio_> hi everyone
<Tonio_> I have a little question concerning soyuz
<Tonio_> I need to provide a little change to a package already waiting in the NEW queue
<Tonio_> can I simply overwrite by reuploading ? or does this require manual action by Kamion or someone else ?
<Amaranth> upload with a new ubuntuX version
<Tonio_> Amaranth: isn't that a problem if NEW package is 0ubuntu2 ?
<Amaranth> i don't think so, as long as your next upload is 0ubuntu3
<Tonio_> okay
<Tonio_> Amaranth: thanks
* lamont scratches his head...
<lamont> Tonio_: once you upload a package with a given version and it's in soyuz anywhere, you're pretty much stuck with uploading a later version number before it will let you play
<Tonio_> lamont: so you suggest me to wait and then reupload the package with modifications named to 0ubuntu2
<Tonio_> .
<Tonio_> ?
<lamont> no
<lamont> I was saying that if you already uploaded -0ubuntu2, an want to make changes to it, then you get to upload something with a newer version number (e.g., -0ubuntu3
<lamont> )
<Tonio_> okay :) so I need to upload version 0ubuntu2
<Tonio_> thanks for the info :)
<lamont> I though tyou said -0ubuntu2 was already uploaded and sitting in NEW?
<lamont> well... that's a different error...
<lamont> "GDM could not write to your authorization file.  This could mean that you are out of disk space, or that your home directory could not be opened for writing.  In any case, [you're screwed] ."
<Tonio_> lamont: 0ubuntu1 is in NEW actually, so I will upload 0ubuntu2 as you said
<lamont> ah, ok
* lamont wonders which "authorization file" gdm can't open
<j^> lamont still trying to log in? last message is saw, X was looking for /etc/X11/xserver/SecurityPolicy in /etc/xserver/SecurityPolicy
<xTina> Is anyone around who admins launchpad (i.e. the actual machine / web server)?
<lamont> prolly not
<lamont> brb
<lamont> xTina: the admins of that box are in .uk, which makes it about midnight their time.
<xTina> lamont: hey, that's about an hour earlier than here :P
<lamont> ENOSEB.  sigh
<lamont> heh
<lamont> the real question is what did you need one of them for?
* lamont runs out of time to play with gnome
<lamont> but now I'm afraid to log out of the machine at home... :-(
<xTina> To check if the reason for bug https://launchpad.net/products/launchpad/+bug/6659 might not be an actual launchpad bug but just caused by the fact that mod_ssl's SSLVerifyClient is set to anything but "none". But I can as well just add to that bug report, I'm just lazy since I just turned off my Linux box before getting that idea and that's the box that contains the browsers that are not affected by this bug ;)
<Ubugtu> Malone bug 6659 in launchpad "Launchpad requests user certificate from Safari, MSIE/Windows, MSIE/Mac" [Major,Confirmed]  
<xTina> Hm. Camino is working :)
<xTina> neat
<lamont> probably best in the bug - since that's not actually somethign that the admin would change without it going through the LP team, I expect...
<xTina> I don't know how independent launchpad is from a specific mod_ssl config ... so I guess you're right.
<lamont> anyway, time to flee
<dAndy> can anyone tell me where the sky2 module might live: re bug #32591 ?
<Ubugtu> Malone bug 32591 in linux-source-2.6.15 "Network card not detected during setup, but available after installation" [Normal,Fix released]  http://launchpad.net/bugs/32591
<mjg59> dAndy: ?
<dAndy> mjg59: yes?
<mjg59> dAndy: I don't understand the question
<dAndy> benc said in the bug that a fix was released, but as far as I can see, the sky2 module is still not in the mini.iso, I figured I could rebuild the mini.iso, but I cant find the udeb that includes that kernel module
<mjg59> dAndy: I believe that there is currently no udeb that includes that kernel module
<mjg59> It's possible that it's been fixed in the git tree, but not pushed out yet
<dAndy> ah ok, that would be why I cant find it, thanks
<mjg59> Yeah, it's in git
<dAndy> so Kamion just needs to grab it and add it to the installer?
<mjg59> Well, it'll probably need another kernel binary upload
<mjg59> Which ought to happen before too long - there's a pile of queued fixes
<dAndy> alright thanks alot for the help, I will wait a bit longer :)
<childe> Why did they removed all the quick-search bookmarks in Firefox?
<childe> Yesterday I upgraded to the latest Dapper, and in the new Firefox I can't use quick search anymore
<infinity> childe: They're still there in mine.
<mjg59> I think I've fixed hibernate
<infinity> childe: Are you sure you're not suffering from "firefox has broken chrome because I upgraded it but haven't closed/killed all running instances yet"?
<mroth> mjg59: what bug is that being tracked on?
<mroth> sladen: around?
<ifr> Sorry but I've tried the other rooms to no avail with a KERNEL CONFIG QUESTION:  I'm trying to make one patch to an otherwise ducky kernel.  I downloaded the source tree for the kernel.  BEFORE I do make oldconfig should I apply the patch by doing patch -p0 < patch-name.patch in the source directory of the kernel I'm compiling? Thanks
<childe> infinity: !!!
<childe> infinity: Stupid me...then, how can I get them back?
<ifr> No one? 
<infinity> childe: Log out, or reboot, or anything else that's pretty much guaranteed to kill every single running firefox instnace.
<mjg59> mroth: About 10 zillion different ones
<mjg59> mroth: Hw much RAM do you have?
<mroth> heh
<childe> infinity: Then, remove the .mozilla directory and run Firefox?
<infinity> mjg59: Oh, is part of this the "I have too much RAM, and people think that breaks swsusp" thing?
<mjg59> infinity: Yes
<mroth> mjg59: uh.. in which machine?  my thinkpad has 1GB, my HP has 1GB, my vaio has 512MB, and my desktop has 2GB
<infinity> mjg59: Cause I've had off again on again luck between breezy and dapper with my 2GB Thinkpad.
<mjg59> infinity: I've just sent a patch to Ben that works for me
<ifr> Can anyone suggest a better chat room where I can get that compiling question answered? 
<mjg59> Test machine worked fine with 0.5GB, broke with 1GB and now works fine again (with 1GB)
<infinity> mjg59: Rock.  Does it apply cleanly to -19.29, or does it rely on some other changes in git?
<infinity> mjg59: If the former, pass it my way and I'll build myself a test kernel (unless you have a -686 test image I can play with?) and deliver you some results.
<mjg59> infinity: Should apply cleanly. Hang on
<mjg59> infinity: http://www.codon.org.uk/~mjg59/tmp/swsusp.diff
<ifr> I just don't get why no one will even answer...
<Amaranth> sorry
<infinity> ifr: Because this isn't a help channel, please read the topic.
<ajmitch> afternoon
<bddebian> Heya ajmitch
<Chipzz> ajmitch: no, good nighty ;)
<Chipzz> s/y//
<childe> c
<infinity> mjg59: That's some patch.
<LaserJock> ifr: I'd just try it and see
<ifr> Thanks infinity
<ifr> Thanks LaserJock. 
<infinity> mjg59: What happens if there just plain isn't enough swap space to DTRT, no matter how hard you try to free up RAM while suspending?
<infinity> mjg59: Does it return a useful "nu uh!" of some sort?
<childe> infinity: I closed all the Firefox instances then re-installed it, but still no quick search
<mjg59> The echo gets ENOMEM
<mjg59> We should probably really catch that and pass it back up, but, well.
<infinity> childe: Whacky.  File a bug, I guess.
<childe> infinity: So the new version of Firefox doesn't have quick search by default?
<Chipzz> childe: did you try on a clean user?
<infinity> mjg59: Passing it back up could make things friendly... Could have a nice dialog that says "You don't have enoug swap space to do this; Try closing some applications before trying again" or some such.
<Chipzz> s/on/with/
<childe> Chipzz: Haven't tried that. Let me try
<childe> Chipzz: Nope, fresh user doesn't work.
<childe> And there is no quick search in /usr/lib/firefox/defaults/profile/bookmarks.html
<infinity> childe: Again, I recommend filing a bug.  If it disappeared from the default profile template, it was probably a mistake, since I don't spot any mention of it in the changelog.
<childe> infinity: I've filed this as #36941 on launchpad :-)
<infinity> (Hint:, if you say bug #36941, ubugtu may wake up and tell us something about it)
<Ubugtu> Malone bug 36941 in firefox "No Quick Search Bookmarks" [Normal,Unconfirmed]  http://launchpad.net/bugs/36941
<infinity> Looks good to me.  Now you get to sit back and wait for iwj to fix it. :)
<childe> infinity: No problem :-) I can use Opera instead.
<jjesse> mako: ping
<lakin> mjg59: what's the approximate time frame for that patch to hit the dapper archives? (so I can't remember to test it?)
<mjg59> lakin: No idea
<mjg59> Probably within the next week
<lakin> k.  that's close enough.  Sometime at the end of the week I'll test hibernation again. :)
<infinity> mjg59: What's the magic invocation to build just one kernel flavour again?
<TheMuso> c
<jjesse> is the help docs not installed by default for openoffice.org in dapper?
<infinity> jjesse: Do you have language-support-en installed?
<jjesse> infinity: need to check
<jjesse> nope not installed
<infinity> That would be why you have no help.  Not sure if the installer is meant to install that, or if it just isn't there by default..
<desrt> cool factoid about the swap partitions
<jjesse> shouldn't it be installed by default?
<infinity> Kamion: Is there a valid reason for pcmcia-cs still being in *-desktop?
<Kamion> infinity: yes, (a) bluez-pcmcia-support, (b) we still need it for some cards
<Kamion> anything that needs CIS firmware needs pcmcia-cs
<Kamion> jjesse: it's installed by default, yes
<Kamion> check /var/log/installer/ to start investigating why it didn't get installed for you. One possible reason would be that it was uninstallable on the media you used for installation.
<Kamion> Riddell: somehow, you didn't push that branch correctly (you seem to have pushed the working copy, but not .bzr) which means 'bzr merge' says "Nothing to do" for me
<ToadZzZztool> before I go to bed, what about an UVF exception for lintian 1.23.16? :) I've got a patch to nearly adapt it to ubuntu (needs a little more work though)
<infinity> Speaking of UVF...
<infinity> Kamion: You probably won't touch this one with a 20 foot pole, but I need a UVF exception + permission for a mass rebuild to fix up ABI breakage in MySQL 5.0.. :/
<Kamion> can you send mail?
<infinity> Kamion: (Debian/Ubuntu had versioned symbols, and had pushed a patch upstream... Upstream finally decided to accept the patch, but named their symbol versoin differently... Boom)
<infinity> Yeah, I can mail you/mdz.  I think it's pretty critical that we remain ABI compatible with Etch and upstream.
<Kamion> ToadZzZztool: UVF exceptions are by mail, not IRC
<Kamion> I'm too sleepy to process them now
<Kamion> ToadZzZztool: is forward-porting the current patch not sufficient?
<ToadZzZztool> Kamion: the patch is mainly about removing nmu checks and better handling ubuntu targets
<ToadZzZztool> for the moment...
<Kamion> ToadZzZztool: that sounds like a forward-port of the current patch
<ToadZzZztool> Kamion: the patch I've made adds a -D/--debian switch to lintian, jvw said it could be included to Debian lintian as a no-op switch
<ToadZzZztool> since I'm quite new to Ubuntu/Debian dev' I don't know what to do now :)
<mxpxpod> ogra_ibook: ping
<ToadZzZztool> good night devs', I'll be back tomorrow ;)
<Kamion> ToadZzZztool: !
<ToadZzZztool> Kamion: ?
<Kamion> I'm not sure I like the idea of a command-line option for that
<Kamion> (speaking as one of the other upstream lintian maintainers, although a less-active one ...)
<Kamion> I don't really see why it's inappropriate to just patch the thing for Ubuntu normally the way we've been doing
<ToadZzZztool> well, that's exactly what I'd like to hear/read :)
<ToadZzZztool> I didn't have real feedback before
<infinity> The idea of a --distro={ubuntu,debian,xandros,foo,bar,baz} switch that subtly changes some tests doesn't sound too horrible (defaulting to using the dist reported by `lsb_release -is`)
<infinity> Would mean I could run lintian on Debian packages in my Ubuntu base system (and vice versa)...
<Kamion> right, certainly a more general pick-a-distro flag would be better than a pick-Debian flag
<Kamion> lintian already has a somewhat misnamed --dist option to pick the suite, though (for the lintian lab, I think)
<infinity> That would be oddly confusing, yes. :)
<Kamion> so that would be awkward to cram in
<Kamion> we'd have to rename --dist and leave it a while to avoid breaking back-compat
<Kamion> so for dapper I'd say we just keep patching lintian as normal
<ToadZzZztool> well, since dholbach patched lintian to handle breezy, dapper and so on directly in the source, I didn't pay attention to --dist :/
<Kamion> the patch we have is unrelated to --dist
<Kamion> --dist is for when you're scanning a whole archive, like lintian.debian.org
<Kamion> bah, dholbach threw away the older changelog when he merged
<ToadZzZztool> :)
<Kamion> I actually did that patch originally
<Kamion> for hoary
* ToadZzZztool got to dig a little further
<ToadZzZztool> now, I really should go to bed, I feel like I'm saying nonsense and missing some important things
<ToadZzZztool> good night everybody
<Kamion> you seem to be doing OK
<Kamion> night
<ToadZzZztool> thanks Kamion 
<infinity> Kamion: Now that wpasupplicant no longer wants to pull in QT4, is there anything else pending its promotion to main?
<infinity> Kamion: (perhaps the "WTF is it in the minimal seed" question, but that can be sorted after it's promoted..)
<infinity> Kamion: Would be nice to get NM 0.6 building and tested in Flight-6.
<infinity> Kamion: Same with beagle and gmime2.1 to get the new nautilus happy again.
<Kamion> infinity: waiting for main inclusion reports
<infinity> Kamion: Did they not all get some?
<Kamion> for both wpasupplicant and gmime2.1 (both have reports, but not approved yet)
<infinity> Ahh.
<Kamion> the wpasupplicant seed question needs to be sorted first so that it doesn't immediately get sucked onto everyone's systems if we don't want it to be
<infinity> Fair.
<Kamion> Tonio_: when you're uploading a package that's in NEW, *please* bump the version; it makes life much less difficult for me when trying to compare the things
<Kamion> Tonio_: IMHO launchpad should have rejected your second upload
<Kamion> (you uploaded kmplayer 0.9.1.99+0.9.2-pre3-0ubuntu1 twice)
<LaserJock> Kamion: weird he said earlier he was going to bump it
<Kamion> yeah, I saw that, but he didn't
<infinity> mjg59: You win.  Hibernate works on my machine now.
<infinity> mjg59: Of course, I have some goofy video corruption going on post-resume, but that's probably not your fault.
<siretart> morning
<ajmitch> morning siretart 
<fabbione> BenC: can you please pull from david before you upload?
<pitti> Good morning
<ajmitch> morning pitti 
<lbm> nm 0.6.1 doesn't seem to be build
<lbm> can't even find build logs
<infinity> It's dep-wait right now.
<lbm> oh, internal marking in soyuz?
<infinity> Build logs, however, aren't so hard to find.
<infinity> https://launchpad.net/distros/ubuntu/+source/network-manager/0.6.1-0ubuntu1
<lbm> well, i looked at http://people.ubuntu.com/~lamont/buildLogs/n/network-manager/, but these are the before-soyuz logs obviously
<infinity> Yes.
<lbm> infinity: do you know when wpasupplicant will be promoted to main?
<infinity> lbm: It's still pending approval.
<infinity> pitti: ^^^
<lbm> infinity: :)
<infinity> pitti: What's the story with wpasupplicant, gmime2.1 and beagle?
<fabbione> am i right if a pci-x card can't be mounted on standard pci slots?
<infinity> Not without pushing REALLY HARD.
<lbm> :)
<infinity> They should have mismatched keys.
<pitti> infinity: wpasupplicant and beagle themselves are approved
<infinity> pitti: wpasupplicant claimed not to be.
<pitti> infinity: there might be some missing dependencies; I don't remember gmime
<infinity> pitti: wpasupplicant is in the "needs work" category still.
<fabbione> infinity: ok :))
<pitti> infinity: oops, yes, I did a quick code review, it was ok
* pitti approves and moves queue
<infinity> pitti: And gmime2.1 is a dependency of beagle.
* infinity thanks the stars that glibc's shlibs haven't bumped since breezy, and builds some stuff on dapper for a breezy system..
<pitti> infinity: any idea why n-m needs wpasupplicant as a *build* dependency?
<infinity> pitti: I suspect it doesn't at all, on the other hand, this was a handy way to make sure 0.6 didn't get into main before wpasupplicant did. :)
<pitti> infinity: but it's perfectly usable without wpasupplicant, so if the build dep can be dropped, it shuold be done IMHO
<infinity> pitti: Oh, agreed, and Keybuk will be appropriately whipped.
<jamesh> pitti: ping?
<pitti> infinity: alright, I reviewed/approved gmime2.1
<pitti> hey james, how are you?
<jamesh> pitti: good.  I ran into a problem that made postgres uninstallable on dapper
<jamesh> I also found the cause, so it should be pretty easy to fix: https://launchpad.net/distros/ubuntu/+source/postgresql-common/+bug/36921
<Ubugtu> Malone bug 36921 in postgresql-common "postgresql fails to install" [Normal,Unconfirmed]  
<jamesh> doing s/6.04/6.06/ in /usr/share/postgresql-common/supported-versions fixes the post-install scripts, adjusting for the new version number for dapper
<pitti> jamesh: argh, yes
<pitti> jamesh: I didn't think of that when I saw the change
<pitti> jamesh: yep, will fix now; thanks for the report
<jamesh> pitti: as I said in the bug, the other problem is that the error message seems to be eaten by either debconf, dpkg or apt-get
<jamesh> so it isn't obvious why it failed
<pitti> jamesh: I'll send them to stderr instead, so that you can see them
<pitti> jamesh: and I'll also let it default to just the latest version for an unknown release to prevent such hard failures
<jamesh> pitti: I don't know if it would cause any problems on non-Ubuntu systems, but using "lsb_release -cs" rather than "lsb_release -rs" might improve reliability
<jamesh> the release codename stayed as "dapper" while the version number changed
<pitti> so far I believed in our regular release cycle :)
<mdke> is the release number agreed on 6.06 now, or 6-06?
<infinity> I'm hoping for 6.06... I find the latter rather ugly.
<mdke> so not confirmed yet?
<infinity> Not sure.
<mdke> ok
<jamesh> mdke: "lsb_release -r"and Launchpad both say 6.06
* mdke nods
<mdke> there was some suggestion of changing to 6-06
<pitti> jamesh: fixed version uploaded, thank you
<jamesh> pitti: thanks!
<pitti> hey mvo
<desrt> so is edgy getting pushed back too?
<desrt> or will it be a 4-month release cycle?
<mvo> hey pitti!
<pitti> Mithrandir: would I disturb your revision control if I uploaded a new casper? I'd like to add sth. like '[ "$(uname -m)" = powerpc ]  && manual_add_modules snd_powermac || true' to debian/casper.initramfs-hooks
<pitti> Mithrandir: bug 27862, btw
<Ubugtu> Malone bug 27862 in casper "sound does not work any more on ppc live CD" [Normal,Confirmed]  http://launchpad.net/bugs/27862
<tepsipakki> dapper+1 might have integrated some of the fedora stateless linux work, if there is interest? https://www.redhat.com/archives/fedora-devel-list/2006-March/msg01223.html
<Mithrandir> pitti: the .bzr directory is in the source.  Feel free to upload, but also please put the branch somewhere so I can just do merge on my next upload.
<Mithrandir> bzr should be able to do something like bzr merge distro://ubuntu/dapper/casper
<Mithrandir> (and then fetch the source and merge that)
<pitti> Mithrandir: hct :)
<pitti> Mithrandir: anyway, it's not utterly urgent, so if you prefer to just add that like to your branch, that's fine for me
<Mithrandir> pitti: sure, I can do that.
<pitti> would be much less overhead
<Mithrandir> true. :-)
<pitti> Mithrandir: ok, great :)
<Mithrandir> I just haven't done a casper upload since the bug was filed and have been lazy.
<Mithrandir> now I'm off to test the live cd to see if my udev fix fixes the problem
<pitti> Mithrandir: btw, does that look sane? it's the only platform specific module loading so far in that file
<infinity> pitti: initramfs hooks have access to $ARCH
<pitti> oh, cool
<infinity> Which apparently Tollef doesn't use. :)
<infinity> Oh, the one place he doesn't use it is commented out.
<lifeless> moin moin
<pitti> hey lifeless 
<pitti> hi seb128 
<Mithrandir> infinity: and is not in a hook
<seb128> Hi pitti
<infinity> pitti: Anyhow, check {scripts/init-premount/thermal,hooks/thermal} in /usr/share/initramfs-tools for ARCH.
<infinity> Mithrandir: You have it at runtime too.
<infinity> Oh, and it's DPKG_ARCH.  My bad.
<infinity> (Good thing I told you to look)
<pitti> so that would be easier than checking uname -m for powerpc and powerpc64
<infinity> pitti: ^^^
<infinity> pitti: Or, for powerpc, powerpc64, ppc, ppc64, yeah.
<infinity> pitti: powerpc was the reason I did it.
<Mithrandir> pitti: hmm, you don't need it in the initramfs, do you?  Can't I just stuff it in /etc/modules?
<pitti> Mithrandir: sure, that'll work as well
<pitti> Mithrandir: I just didn't find any reference to /etc/modules (I don't know the casper package at all)
<infinity> Does snd_powermac need to be manually loaded?  Ick.
<pitti> infinity: yes, it doesn't have udev support
<pitti> it's this 'ADB' bus or so
<pitti> no usb/pci/sth. sane
<infinity> Yeah, my PowerMac is ADB.  It's also headless, though, so I've never cared about sound on it.
<Kagou> hi
<Mithrandir> would anybody be very sad if the live cd stopped ejecting the cd and just rebooted instead?  It interacts badly with splashdown.
<Mithrandir> (this is bug 34537, btw)
<Ubugtu> Malone bug 34537 in casper "On livecd shutdown, cd ejects and usplash does nothing" [Normal,Confirmed]  http://launchpad.net/bugs/34537
<Mithrandir> I think it's less important to eject the cd now that we have "boot from first hard disk"
<Seveas> Mithrandir, is boot from first harddisk the default?
<Mithrandir> no
<infinity> Mithrandir: The bad interaction wit splashdown is my bug, not yours.  I need to get usplash to stop getting killed (so people get a nice "It's safe to reboot" message)
<Mithrandir> infinity: no, it's not.  casper has a down-script which ejects the cd and says "please remove the cd and press enter to continue"
<Mithrandir> obviously, the user never sees that.
<infinity> Mithrandir: Right, and it should be able to say that through usplash... But it can't, because usplash has been killed by init. :)
<infinity> No reason that can't be fixed.
<infinity> 9And it needs to be fixed for the installed system anyway)
<Mithrandir> infinity: no, it hasn't at that point.  It will relativetly after, though.  And usplash doesn't have a "wait for keypress" thingy yet.
<infinity> s/9/\(/
<Kamion> Mithrandir: that makes sense to me, and ejecting has never been all that reliable anyway
<Mithrandir> relativetly quickly, even.
<infinity> usplash doesn't need a wait for keypress thingee.  You usplash_write, then read.
<infinity> Keystrokes are passed to the underlying shell.
<Mithrandir> ok
<infinity> (Which is why you can happily Ctrl-C and Ctrl-Alt-Del during boot)
<infinity> But none of this impacts your decision to eject or not.
<Kamion> hmm, as Tollef points out it doesn't work so well on powerpc
<Kamion> and powerpc is where you actually need software eject in many cases
<infinity> Just saying that the usplash behaviour isn't a good excuse to change things. :)
<Kamion> the user may not be *able* to get the CD out without a paperclip
<Mithrandir> I could eject and not wait, but that will cause users to complain about the cd drive closing over their fingers.
<Kamion> so I'll reverse my position - I think we should fix the usplash bug but keep ejecting
<infinity> Easy enough.
<infinity> Thogh, would it be possible to wait for input BEFORE you eject, too? :)
* infinity hates it when the CD drive rams into the inside of the door on Zofia's case.
<Mithrandir> "press enter and I will eject cd" (ejects cd) "press enter to continue rebooting".
<infinity> Yeah, it feels icky...
<Mithrandir> I'm wondering if we should just always eject on ppc and not on i386/amd64, since those have "boot from hard drive" in the menu.
<Kamion> and you have to wait after ejecting, too, because some machines reboot pretty quickly and suck the CD tray back in as you're trying to get the disk out
<Kamion> which can lead to broken CDs and/or bruised fingers
<Mithrandir> sure, but change the behaviour from "always eject" to "eject on ppc"?
<Kamion> hmm, unsure, I'm not so keen on radically different behaviour on different architectures, but your call
<Mithrandir> it'd solve the "ram drive door into case" use case that infinity has too.
<Mithrandir> since I don't think there are macs with those kinds of cases?
<Mithrandir> (yes, we have really small use cases like somebody having such a case on a pegasos or something, but those are uncommon enough that I won't special-case it)
<Kamion> I was going to say, yes, my Pegasos has that kind of case
<Mithrandir> I don't see how I can accomodate that without making the UI suck for everybody, though.
<Mithrandir> (and I think cases with doors are an abomination :)
<childe> I don't know if this is a bug
<childe> When I start the gnome-terminal, it's 80x24. After I created a new tab then close the new tab, it changed to 80x25
<childe> It will get larger and larger if I repeat this steps
<childe> Does this worth a bug report?
<Kamion> sounds like it, yes, if there isn't already one reported
<robitaille> https://launchpad.net/distros/ubuntu/+source/gnome-terminal/+bug/35342
<Ubugtu> Malone bug 35342 in gnome-terminal "Geometry size of the terminal window increases (dapper)" [Unknown,Unconfirmed]  
<mjg59> infinity: Hurrah
<childe> Nice
<robitaille> I like that bug...the really poor man's way of resizing a terminal :)
<mantiena-baltix> Hi all
<sivang> morning all
<mantiena-baltix> it seems daily dapper doesn't start since Friday (Mar 24). Should I report a bug ?
<mantiena-baltix> I'm about live cd
<Kamion> known, should've been fixed yesterday by Tollef's udev change
<hunger> Hmmm... beagle takes lots of space! Is there a way to reduce that?
<hunger> I.e. by having a global index for shared stuff in addition to the privat one?
<mantiena-baltix> Kamion, thanks for info, yesterdays live CD still not starts, but I can try todays if you think, that todays live CD should start
<Kamion> yesterday's was before the fix
<Kamion> today's should be better, but I haven't tested yet
<mantiena-baltix> OK, so I will download and test - it's not hard for me ;)
<Mithrandir> today's works.
<Kamion> good
<Mithrandir> at least, it works for me.
<Mithrandir> apart from the unionfs bug.
<mantiena-baltix> Mithrandir, what unionfs bug ?
<Mithrandir> mantiena-baltix: /sbin becomes mode 0700 when the initramfs moves a file about
<mantiena-baltix> Mithrandir, will this bug cause some problems during live CD startup ?
<Mithrandir> mantiena-baltix: no, not really.  It'll just cause the live cd to behave a little bit erratically since /sbin is then mode 0700
* mantiena-baltix is thinking about mean of "litttle bit erratically" ;)
<mantiena-baltix> Btw, I think Live-CD should have one more entry in startup menu, for booting in sort of "safe" mode :) Now there are lots of problems when booting on various laptops, especially with new AMD Turion CPU's
<mantiena-baltix> should I report a bug about this ?
<mjg59> mantiena-baltix: What do you mean by "problems", and what would this safe mode do?
<mantiena-baltix> main problem is, that Live CD doesn't start at all :)
<Kamion> safe modes are usually bogus, they're often unsafe on hardware different from what the safe mode designer was using
<mantiena-baltix> second problem is, that clock is running 2x faster, and because of this Music/Video and games looks very funny, but are unplayable :)
<Kamion> surely a better bug report would be "please fix the live CD on AMD Turion CPUs" :-P
<mjg59> mantiena-baltix: That'll be fixed in the next kernel upload
<mantiena-baltix> mjg59, problems with 2x clock speed will be fixed in the next kernel upload ?
<mjg59> Yes
<siretart> what part of gnome handles hotkeys and starts programs? I'd like to reassign bug 20939 to the correct package
<Ubugtu> Malone bug 20939 in evolution "evolution doesn't use seahorse-agent when started by hotkey instead of gnome-panel or shell" [Normal,Needs info]  http://launchpad.net/bugs/20939
<infinity> mjg59: Oh, there's talk on the -users list of a newer powernowd (available in sid) being required for proper behavior on Core Duo and some Athlon X2 CPUs...
<Kamion> oh yes, I have a pending UVF exception request for that
<Kamion> any second opinions on it?
<mjg59> infinity: Yes - I thought someone had already asked oh what he said
<mjg59> Kamion: Given the number of dual core systems shipping, we probably want it
<Kamion> have folks tried it out on non-dual-core systems?
<infinity> Kamion: No new bugs in Debian yet, and it's been cooking there for a week.
<sivang> pitti: ping
<pitti> hey sivang
<sivang> hey martin!
<sivang> I'll PM you
<infinity> Kamion: I could give it a spin on my single-core Centrino laptop.
<mjg59> infinity: Did the initramfs-tools issue ever get sorted? (The one where an upgrde from breezy stamps all over RESUME=)
<infinity> mjg59: The upgrade has been preserving RESUME= since Feb 17, according to the changelog.
<mjg59> infinity: Excellent
<Kamion> mjg59: it's a configuration file now, and we suck RESUME= out of the old conffile on upgrade before trashing it
<infinity> mjg59: And it even works right.  Just dist-upgraded a friend's machine earlier today, no conffile prompt, RESUME properly set.
<infinity> \o/
<infinity> (Hideous hack, though)
<mjg59> Yay!
<Mithrandir> infinity: how can I tell the kernel (or init) to reboot?  From the initramfs.
<infinity> Good question.  I'm not that familiar with klibc's init.
<mjg59> infinity: On the other hand, failed resumes currently seem to trash swap - I'm sure we used to mkswap that?
<jordi> mjg59: wow dude
<infinity> mjg59: My failed resume didn't trash the swap..
<jordi> when I went to bed last night you were already talking about suspending and swap :)
<mjg59> infinity: Hm. Maybe it's just if RESUME= isn't set
<infinity> mjg59: That's possible.
<hendry> are there some Ubuntu tools to diff an Ubuntu package with Debian's SID package of the same name?
<mjg59> If there's no RESUME, we currently suspend but then refuse to resume (and they end up with no swap)
<infinity> mjg59: Special...
<infinity> mjg59: We could start fiddling with the possibility of autodetecting the resume partition...
<mjg59> infinity: Mm
<infinity> mjg59: But that's always struck me as a bit dangeours.
<mjg59> Yes
<infinity> Dangerous, too.
<Mithrandir> infinity: oh, it's a syscall, apparently.
<infinity> Then again, "I just lost my resume data because I dual-boot two hibernated OSs" probably isn't as ciritcal as some may want you to believe.
<infinity> No worse than a power outage.
<infinity> (And if you are the sort that wants to dual-boot two hibernated OSs, you can manually set resume= ..)
<infinity> Seems a crazy corner case to worry about, and not necessarily worth worrying about, when autodetection of resume data would be a win for everyone else...
<mjg59> infinity: Yeah
<jordi> carlos: got my mail re: the Debian GNOME thing? If you replioed, I missed it with the outage.
<Kamion> infinity: if we do that, it would be nice to make sure that the installer sets it up safely (as in, won't trash another hibernated OS) if it can
<infinity> mjg59: Alternately, in the "hey, that's a sketchy idea" department, do we have some unused space hiding in a superblock of the root filesystem where we could encode the location of the resume partition when we hibernate?
<mjg59> infinity: Ngh.
<carlos> jordi: not yet, but the answer is yes, you can remove me
<mjg59> infinity: That would probably depend on the filesystem...
<infinity> mjg59: Well, it would tie the root to the resume, which is really what we want here.
<jordi> carlos: ok
<jordi> carlos: don't reply then :P
<mjg59> infinity: What we /really/ want is for grub to check for a file and then automatically append that to the kernel command line
<infinity> mjg59: Yeah, or that.
<mjg59> That would be great
<mjg59> Get on it
<mjg59> I'm sure we could find all sorts of other uses, too
<infinity> mjg59: There's nothing stopping me from mounting the root FS to poke around it, of course.
<infinity> mjg59: So it doesn't have to be grub at all.  I could just mount /, poke at a file that knows what the resume parititon is, then carry on.
<mjg59> infinity: Uh. Yes there is.
<mjg59> You'll replay the journal and then the FS will explode
<carlos> jordi: ok
<infinity> mjg59: Oh, poo.  Even if I mount it ro?
<mjg59> Yes
<mjg59> grub doesn't replay journals, so it's safe to do it there
* infinity curses ext3.
<mjg59> Also xfs and jfs
<mjg59> jfs refuses to mount until it's been fscked
<infinity> mjg59: I don't dig grub-only solutions either, though.
<Mithrandir> mjg59: that should be easy enough to do.
<infinity> I suppose we could start chaning initrds, and have hibernate create a tiny one with nothing but the resume config file.
<mjg59> infinity: Yeah, just dump another cpio file on the end
<Mithrandir> you could just continue doing that.
<mantiena-baltix> Kamion, when I'm talkin about "sort of safe mode", then I mean standart live CD mode with some parameters, like noapic nolapic
<Mithrandir> so your initramfs would grow forever (by about 1 or 2 blocks per hibernate)
<mjg59> infinity: that would also let us pass a list of block numbers for suspending to swapfiles
<infinity> Mithrandir: That sounds.. Wrong. :)
<mjg59> mantiena-baltix: noapic shouldn't be necessary with the next kernel
<Mithrandir> infinity: no shit. :-)
<mantiena-baltix> mjg59, in all cases ? (I'm talking not only AMD Turion case)
<mantiena-baltix> btw, does dapper livecd use swap partition if there are suspend data inside ?
<Kamion> mantiena-baltix: that actively breaks machines other than yours
<Kamion> mantiena-baltix: so no, that's not a "safe mode"
<Kamion> if your machine needs the APIC to do interrupt routing, turning it off will make it a SAD panda
<mantiena-baltix> Kamion, I'm not wanna to make "safe mode" as default
<TheMuso> c/
<Kamion> mantiena-baltix: I don't want to have a combinatorial explosion of "safe mode" boot options for all the different sets of boot options people might need
<mantiena-baltix> Kamion, btw, this is not my machine - previous week I went to computer shop and was dissapointed, because Ubuntu Live CD didn't started on majority of new laptops :(
<Treenaks> mantiena-baltix: dapper or breezy live CD?
<Kamion> "noapic nolapic" breaks some machines. Other machines need different parameters. The correct solution is *not* to add more and more boot options, but to fix the damn problems
<mantiena-baltix> Kamion, but it seems we can't fix these problems, because of new hardware 
<Kamion> mantiena-baltix: we can't psychically determine which boot options are going to be necessary on new hardware in the future
<Kamion> picking one that happens to be needed on some hardware now is not an option
<mantiena-baltix> sorry, my child is crying now :(
<mjg59> mantiena-baltix: We can fix most of these problems
<hunger> When will NM finally work with interfaces set to dhcp in /etc/network/interfaces?
<hunger> Having to comment stuff out there is somewhat annoying... as it breaks the interfaces for non-NM use (i.e. when doing system recovery).
<infinity> hunger: It's meant to work with interfaces that are set to DHCP *and* auto, afair.
<hunger> infinity: For me NM stopps responding whenever it seen "iface whatever inet dhcp" in a line.
<infinity> hunger: With the packages in the archive, or with the 0.6 packages that people have been tossing around?
<hunger> infinity: and it should not work on auto interfaces at all: Those are meant to be up and stay up.
<hunger> infinity: The stuff in the archive.
<siretart> hunger: I think the policy was that nm should ignore interfaces handled by ifupdown, because they solve  fundamentally different use cases
<siretart> hunger: btw, we had yesterday some discussion at our regulars table about xen. do you know if the xen kernel patch would/should apply cleanly to the ubuntu kernel?
<hunger> siretart: it won't.
<siretart> :(
<doko_> Kamion, Mithrandir: shutdown/reboot on the live CD doesn't work. which package should be used for reports?
<Mithrandir> doko_: "doesn't work" is not an error message.
<hunger> siretart: At least it did not when last time I tried. I gave up on it for the time being since I couldn't get a full-featured xen-kernel of a version close to ubuntu's to compile properly at all.
<siretart> hunger: I'm curious, where can I find out about the status for inclusion into the mainline kernel of xen?
<hunger> siretart: NM should ignore "auto" interfaces IMHO.
<hunger> siretart: Those without the auto flag should be handled by NM IMHO.
<doko_> Mithrandir: that was not my question, but anyway, it hangs after displaying "Stopping kernel log daemon" and ejecting the CD
<hunger> siretart: There is a mercurial repository for the merge work.
<siretart> hunger: I rather think that NM should ignore any interfaces listed in /etc/network/interfaces. It makes no sence to ifup an interface which is already handled by NM
<hunger> siretart: No!
<Mithrandir> doko_: don't file a bug, it's already filed and we discussed how to fix it a few hours ago
<Kamion> doko_: on the live CD, don't expect anyone to be able to even tell you which package to use unless you describe the bug properly ...
<hunger> siretart: Start up in single user mode and you will be happy to have ifup.
<Kamion> there are too many packages involved for that
<hunger> siretart: When going singleuser you usually do not have the time to figure out network settings:-)
<hunger> but then since ubuntu does not have single user mode anyway... you might be right:-)
<siretart> hunger: isn't dbus (+ ancestors) started in single user mode as well?
<hunger> siretart: It definitly should not.
<siretart> hunger: why?
<hunger> siretart: possible that it is, but it shouldn't.
<siretart> again, why? I think it should.
<hunger> siretart: Because it does not help to have that stuff meddle with a system that is disfunctional.
<hunger> siretart: dbus is one of the really few things not started in rcS.d
<siretart> so your rationale is that single user mode should be some sort of 'failsafe' startup mode. Even then I think you could start dbus easily with /etc/init.d/dbus start, which will start NM as well
<siretart> hunger: the fact that NM cannot be configured without an x-session is a lack of a seriously required feature.
* mvo is away for a bit
<hunger> siretart: You can... but it won't work when i.e. /usr is not there.
<hunger> siretart: When going single-user the system usually is in a very bad state after all.
<siretart> so mount it then :) - seriously, if your system is so broken that it cannot mount even usr/, you should be able to configure your interfaces with /sbin/ip as well
<hunger> siretart: Keeping the "requirements" low is essential then. Some stuff might just be broken.
<hunger> siretart: I can.
<siretart> hunger: NM has very high requirements. better don't use this in environments like you describe
<hunger> siretart: But when a system breaks I have enough werries getting it runnig again.
<Kamion> is there a way to use a different cellrenderer for each row in a GtkTreeView?
<hunger> siretart: I can not use the extra trouble to set up interfaces at that time.
<Kamion> I need to do this because each cell is in a different language, so (AFAIK) I need to set the language on each cellrenderer to get proper rendering for RTL languages
<Kinnison> Kamion: if you can know if the language is RTL, you could insert the unicode RTL character into the display name?
<Kamion> not without a sucky big table
<hunger> siretart: Ever had a customer breathing down your neck when trying to fix their "mission-critical" infrastructure?
<hunger> siretart: Ever tried to find out the IP of the box at such a time?
<Kinnison> Kamion: the cellrenderer is at liberty to add other controls to the cell, yes?
<Kamion> I'd rather just let pango figure it out if possible
<Kamion> Kinnison: can you elaborate?
<Kinnison> Kamion: IIRC a treeview can have any gtk widgets you want in the cells
<Mithrandir> infinity: hmm, casper-md5check doesn't seem to be able to get anything back when doing a getchar().
<Kinnison> Kamion: so couldn't you set the language on a gtklabel you put in the cell?
<siretart> hunger: again, I don't consider NM mature enough for such environments (yet). 
<hunger> siretart: OK, usually such a box has no gui (and no NM), but you know how customers are...
<siretart> hunger: there are design issues like this..
<Kinnison> Kamion: it's a couple of years since I last played with treeviews though. I can look if you want
<Kamion> Kinnison: oh, er, I guess. The CellRenderer interface is data => gtk.gdk.Drawable though so that sounds complicated
<hunger> siretart: Yes. At the moment it is not. But the decissions made now will carry on in the debs for a long time.
<Kinnison> Kamion: urgh, sounds like pygtk is being helpful for you
* Kinnison ponders
<Mithrandir> infinity: but if I switch to tty1 and press a key, it reboots.
<Mithrandir> (as it should)
<Kamion> Kinnison: you can if you like; basically I want to make the language selection box look right
<seb128> carlos: you are right, it used normal spaces for it ....
<hunger> siretart: "Nichts haelt laenger als ein Provisorium" :-)
<Kinnison> Kamion: give me a few minutes to familiarise myself with treeviews again
<siretart> hunger: I'm not sure if they are installed by default at all, but even if they are, I think implementation makes sure that the user HAS to comment their interfaces out in order to use it with NM
<siretart> hunger: :)
<hunger> siretart: NM is happy with the interfaces removed...
<carlos> seb128: that's bad...
<hunger> siretart: And the "old" NM used the interfaces file to grab default values from (i.e. static IP or dhcp) or so I was told.
<carlos> seb128: that means that we need to do something special as we do with tabs (\t)
<hunger> siretart: That no longer works since NM chokes on the file.
<carlos> seb128: what do you think?
<hunger> siretart: and whatever you say: choking on a valid configuration line is a bug.
<seb128> carlos: I think rosetta should make the difference between spaces and unbreakable spaces clear somewhat, using a special glyph for it or something
<hunger> siretart: It might interpret it, it might ignore it, but it may never stop its job.
<seb128> carlos: but dunno what you can technically do
<carlos> seb128: that's what I'm suggesting
<infinity> Mithrandir: Oh, fun
<Mithrandir> infinity: should/will the initramfs behave differently than the regular boot here?
<seb128> carlos: so that's a good suggestion imho
<carlos> seb128: the problem is that it only appears with the translation, or is there any way to automatically detect when a normal space in an english strings should appear as a unbreakable spaces?
<infinity> Mithrandir: On an installed system, the whole boot process tends to happen on tty8 (though I now question the sanity of that, and have half a mind to just move it over to tty1), so keystrokes pass through just fine, since usplash and init are all happily on the same tty.
<hunger> siretart: The xen linux merge repository (mercurial) is here: http://xenbits.xensource.com/ext/linux-2.6-merge.hg
<infinity> Mithrandir: There's a fair chance that anything runinng in the initramfs is bound to tty1, and it's not until we exec the real init that we end up on tty8, or something equally cute.
<seb128> carlos: that's described by the feature request I sent :p
<infinity> mjg59: Was there ever a sane and rational explanation for running usplash on tty8?
<carlos> seb128: did you file it again?
<seb128> carlos: used before ";:!? " chars and after "".
<Mithrandir> infinity: yeah, I guess.  Should I just do an open on /dev/tty8 and try to read from that instead?
<mjg59> infinity: So people could press alt+f1 to get rid of it
<seb128> carlos: dude, I gave you the URI to the bug on the other chan
<mjg59> (Not that that really seems to work, but still)
<carlos> seb128: do you know the languages that use unbreakable spaces? (other than french)
<seb128> no
<infinity> mjg59: Sure, but Alt-F2 would get rid of it too.
<carlos> seb128: to the new bug?... I missed it... sorry :-(
<infinity> mjg59: Oh, but not if you only have one VC at that point.  I see.  Is that a use case that actually matters? :)
<seb128> carlos: np :)
<infinity> Mithrandir: That would probably work, but is hackish, and is encoding a bit much about usplash in your app (so if I move usplash to another VC, you break)
<infinity> mjg59: All the complaints about "usplash times out and I'm stuck on tty8 and don't know what to do!" and other oddities would vanish if we didn't do the VC switch.
<mjg59> infinity: I think that ought to be fixed by making sure it changes back to vt1 on timeout...
<infinity> mjg59: Well, if it times out, it's meant to switch back, but put some other "icky stuff happened" in there.
<Kinnison> Kamion: If you had a pangolayout would that help?
<mjg59> infinity: I'm more thinking of the "If you want to see messages, press this" use case
<infinity> mjg59: The fact that tty8 has no shell, no login banner, and utter confusion for anyone who sees it means that dumping people there by accident EVER seems bad.
<mjg59> I guess that could just cause usplash to exit instead
<mjg59> So, uh.
<Kinnison> Kamion: then again, even gtk_paint_layout needs a widget, never mind
<infinity> mjg59: Well, pressing alt-f1 won't get you meesages anyway, since the boot seems to be happily running on tty8 at that point.
<siretart> hunger: thanks
<carlos> seb128: http://en.wikipedia.org/wiki/Non-breaking_space
<carlos> seb128: seems like we should be using also for other languages....
<carlos> althought French is the only one with fixed rules that we can do automatically
<seb128> nice :)
<seb128> yeah
<Mithrandir> infinity: casper-md5check knows a bit too much about usplash already, though.
<infinity> Mithrandir: Yeah, I know. :/
<Mithrandir> but as long as it's a single other app, it's not too bad.  If there was a plethora, we'd need to make a library or something
<infinity> Mithrandir: Anyhow, for other reasons (as discussed above), I've been considering moving usplash to tty1 anyway, so if that makes it work, yay.
<Kinnison> Kamion: aha, got it
<Mithrandir> I'd assume it fixes it.
<Mithrandir> infinity: is that a trivial change?
<infinity> Mithrandir: Easy enough to test, remove the "-c" from usplash's command line in the initramfs script.
<Kinnison> Kamion: you need a cell-data-function to set the language for the GtkCellRendererText before each cell is rendered
<Mithrandir> infinity: excellent, thanks
<Kinnison> Kamion: http://scentric.net/tutorial/sec-treeview-col-celldatafunc.html may help
<Kamion> Kinnison: ah, cheers
<Kinnison> Kamion: I *knew* there was something to do what you needed :-)
<Kinnison> Kamion: I was on the verge of writing a replacement for GtkCellRendererText but then I realised what you needed :_)
<Kamion> I'll have a go at that after coffee, then
<Kamion> then I really need to get onto apt-setup work
<Kamion> doko_: oh, so what you're saying in #36973 is that it doesn't say "What language do you speak?" or whatever anywhere?
<Kamion> I understand then - I thought you meant that the selector box contents were empty or something
<jvw> Kamion: the lintian lab stuff is quite annoyingly fragile etc anyway, I'd rather get rid of that and replace it with something decent then keeping that alive :-/
<hunger> My screen freezes when switching virtual desktops. Is that a known problem?
<hunger> The windows still refresh, but the switching gets stuck for up to several secounds.
<hunger> Could that be the kernel starving the X server? I read on LWN that such a problem was fixed recently.
<sladen> mjg59 / infinity: switching back to tty1 and a login prompt was in the original spec/requirements
<sladen> infinity: probably better to keep the original log messages on tty1 
<doko_> Kamion: yes, it's a minor thing
<infinity> sladen: Sure, but the way it is now (and has been since it was implemented), the log messages are on tty8.
<Mithrandir> infinity: losing -c fixes it.
<sladen> Kamion: when's the next Flight due out?
<Kamion> sladen: Wednesday, I believe; Mithrandir will be doing it
<Kamion> sladen: it's better to just set the source package to the empty string than to set it to ubuntu-meta, if it's a general problem with the distribution
<Mithrandir> sladen: tomorrow, yes.
<sladen> Kamion: oops sorry, it's specifically ubuntu-minimal
<Kamion> no it's not
<Kamion> surely?
<Kamion> is it really a flaw with the dependencies of the ubuntu-minimal binary package?
<Kamion> oh, sorry, so it is ... that acpi-support thing
<Kamion> ok, never mind me then
<sladen> Kamion: yeah, it's actually dependant on a policy decision that I don't know the answer of;  eg.  should power-management work on machines without a desktop installed.  Eg. how minimal is minimal.
<Mithrandir> oh, roxxors.
<Mithrandir> 29203 fixed.
<doko_> pitti: are you working on #24999?
<pitti> bug 24999
* pitti looks at ubugtu
<pitti> doko_: I hope that I can find some time for doing priting bug triage, but not right now
<pitti> and I'm lost with hplip stuff anyway
<doko_> pitti: should I assign it to me?
<pitti> doko_: that would make me (and even more the people who suffer from this) very happy :)
<ogra> Mithrandir, the current edubuntu i386 live stops booting with: "+ set - thermal udev" and hangs there
<Kamion> ogra: should be fixed next rebuild
<ogra> oki
<ogra> i guess thats on all livecds then ...
* ogra goes for install tests
<infinity> Mithrandir: Great, then I'll poke at some usplash changes in the next day or two, including dropping the VT switch.  It's been responsible for all sorts of workarounds elsehwere too.
<Mithrandir> infinity: if you manage to fix the "usplash is killed by init" bug too, I'll love you forever.
<Mithrandir> (almost)
<infinity> Mithrandir: That'll be included in the same round of "looking at usplash bugs".
<Mithrandir> thanks
<Mithrandir> infinity: do you have a bug about it or should I reassign the casper one?
<infinity> Reassign away.  Not sure if I have any open bugs as reminders.
<Mithrandir> done
<ogra> urgh
<ogra> the install CD stops at the keymap selector ...
<Kamion> also fixed yesterday
<Kamion> you can work around it by selecting the test option first
<Mithrandir> I'll be offline for an hour or so, I have to return the Korean keyboard to the embassy.  I'll have my phone with me if anything urgent pops up.
<Kamion> ogra: you sure these are really today's images?
<ogra> Kamion, nope, keeps me in an ednless loop
<Kamion> 20060328
<sladen> ogra: given a URL like http://hwdb.ubuntu.com/?xml=835a2d0b2d075ce4051a553f1211537a  how do I get the raw information?
<ogra> Kamion, my rsync finished 10min ago :)
<Kamion> ogra: because I'm *sure* we fixed these issues. please investigate?
<ogra> sladen, wget  http://hwdb.ubuntu.com/835a2d0b2d075ce4051a553f1211537a.xml.bz2
<ogra> Kamion, 
<ogra> ogra@edubuntu:/media/usbdisk/isos/edubuntu$ ls -l
<ogra> total 4188776
<ogra> -rw-rw-r-- 1 ogra ogra 723585024 Mar 28 01:47 dapper-install-amd64.iso
<ogra> -rw-rw-r-- 1 ogra ogra 722837504 Mar 28 01:49 dapper-install-i386.iso
<ogra> -rw-rw-r-- 1 ogra ogra 711081984 Mar 28 01:52 dapper-install-powerpc.iso
<ogra> -rw-rw-r-- 1 ogra ogra 714768384 Mar 28 02:00 dapper-live-amd64.iso
<ogra> -rw-rw-r-- 1 ogra ogra 717029376 Mar 28 02:01 dapper-live-i386.iso
<ogra> -rw-rw-r-- 1 ogra ogra 695783424 Mar 28 02:02 dapper-live-powerpc.iso
<ogra> definately tonights images
<Kamion> please investigate, then
<ogra> yep
<nyu> hi
<nyu> is dapper the equivalent of debian sid?
<nyu> or is there a bleeding edge somewhere else
<Treenaks> We have no edges that bleed more than dapper's edge (in Ubuntu, currently)
<nyu> besides, debian debootstrap only seems to support breezy and older.  is "ln -s breezy dapper" known to work?
<nyu> (in /usr/lib/debootstrap/scripts
<nyu> )
<nyu> Treenaks: ah ok
<nyu> i'd like to setup a chroot rather than installing the full thing
<ogra> Kamion, the version of kbd-chooser seems right (kbd-chooser_1.23ubuntu9)
<ogra> and i dont see any special stuff in /var/log/syslog ... :/
* nyu tries with symlink
<infinity> nyu: You're better off just installing the dapper debootstrap on Debian.
<infinity> nyu: It's an arch:all package, there's no reason it shouldn't work.
<ogra> (or instrall breezy and upgrade ;) )
<ogra> *install
<Kamion> nyu: the dapper script isn't quite the same as the breezy script
<Kamion> -      base="apt binutils cpio cpp cpp-4.0 dpkg-dev g++ g++-4.0 gcc gcc-4.0 gcc-4.0-base ${LIBC6}-dev libdb4.2 libgdbm3 libstdc++6 libstdc++6-4.0-dev linux-kernel-headers make patch perl perl-modules"
<Kamion> +      base="apt binutils cpio cpp cpp-4.0 dpkg-dev g++ g++-4.0 gcc gcc-4.0 ${LIBC6}-dev libgdbm3 libstdc++6 libstdc++6-4.0-dev linux-kernel-headers make patch perl perl-modules"
<Kamion> -    echo >"$TARGET/var/lib/dpkg/available"
<Kamion> +    : >"$TARGET/var/lib/dpkg/available"
<Lure> mjg59: any progress on HP laptop (1GMB RAM) hibernate issue with -19?
<infinity> Lure: Looks like he has a patch that fixes it (tested here on my Thinkpad with 2GB of RAM with good results), and it should be in the nexr kernel upload.
<nyu> Kamion: ah, i thought the package selection was dynamic (Priority: required filter)
<HiddenWolf> infinity: a laptop with 2gb ram?
<infinity> Lure: Are you using a -686 kernel?
<infinity> HiddenWolf: Yes, I like RAM.
<HiddenWolf> infinity: wtf!
<Kamion> nyu: it is, but the segment above is for the buildd variant
<nyu> infinity: ok will try that if this one fails
<Lure> infinity: great - I use 386 currently
<Kamion> nyu: we haven't made that part dynamic yet due to lack of archive support
<ogra> ahh 
<ogra> hmm
<nyu> Kamion: ok no problem, i want the normal variant
<infinity> Lure: Oh, nevermind then.  I was just going to toss you the test kernel I built, that's all.  But I only built the 686 flavour.
<infinity> Kamion: What do we have against using "build-essential" in the buildd variant again?
<Lure> infinity: I can upgrade to 686 - where can I get the package (I would really like this fix in Flight6)
<Kamion> infinity: it's not actually what we want?
<infinity> Kamion: Most people will want it there anyway (to catch updates to build-essential when they upgrade their chroot)
<Kamion> oh, I suppose we could *include* it, but it's not sufficient on its own
<Kamion> because debootstrap shouldn't depend on --resolve-deps
<infinity> Kamion: Oh, yeah, I suppose not.
<Kamion> infinity: file me a bug, I'll look at it
<Lure> infinity: is it supposed to fix also DF5 install CD hand in usplash (or is this unrelated)?
* infinity always wondered why fakeroot wasn't in the list either.
<infinity> But then I assumed whoeever maintains debootstrap had their reasons. :)
<infinity> Lure: Err, no idea what bug you're referring to now..
<Lure> infinity: https://launchpad.net/bugs/34592
<ogra> Kamion, hmm
<ogra> Kamion, there are no german keymaps at all ...
<ogra> funnily the rest seems to be there
<Kamion> ogra: er, no idea about that, sorry
<Lure> infinity: and hibernate is this: https://launchpad.net/bugs/34587
<ogra> Kamion, err, sorry, i shouldnt look for german in qwerty :)
<infinity> Lure: Ahh, well, since that can't possibly be a kernel bug (it's in the bootloader, before the kernel is even touched), I'm afraid this test kernel won't fix it.
<ogra> Kamion, but using en_US seems to work flawless
<Lure> infinity: ok, so only hibernate - where can I get your fixed 686 version (just to confirm)
<Kamion> ogra: kbd-chooser is working fine for me on today's Ubuntu image
<infinity> Lure: Uploading it now...
<ogra> Kamion, it doesnt for me using french, german or spanish.... but en_US works
<Kamion> ogra: what did you select in the bootloader (just so that I can try to duplicate this)?
<Kamion> ah, yes, German fails for me too
<ogra> try french
<infinity> Lure: http://people.ubuntu.com/~adconrad/linux-image-2.6.15-19-686_2.6.15-19.29_i386.deb
<Kamion> presumably it'll fail the same way German does, so I won't bother for now
<ogra> hmm, now spanish works here :/
<ogra> thats really strange
* Kamion boots with DEBCONF_DEBUG=5
* ogra notes that down ...
<Kamion> it's invaluable for d-i debugging
<ogra> yes, but vi always forget that you can use it as bootoption :)
<Treenaks> ogra: 'vi'? not 'I'?
<Lure> infinity: thanks - downloaded - will report back...
<ogra> Treenaks, :P
<janimo> do you know if more fine grained upload rights vs uni/main are on LP roadmap? 
<infinity> janimo: So people can be given rights to a specific set of packages, etc?
<janimo> like say people who can touch xfce packages only (expressed as a list for examole)
<janimo> infinity: yes
<infinity> janimo: I think it's been discussed, but I don't think it's urgent enough to happen right away (we still have a lot of real bugs to squash before going back to feature implementation)
<janimo> infinity: good to hear that it's been discussed
<janimo> at least
<infinity> Finer-grained ACLs have been discussed all over the place, so derivates that are hosted in the Ubuntu archive (like Kubuntu and Xubuntu) can have some control over build retries, CD triggers, and other scary things, but all of this will take some time to think about how to do securely and in a fashion that won't upset the current flow.
<infinity> janimo: (eg: If giving derviatives the ability to retry builds or trigger CDs led to someone retrying a build over and over again that crashed buildds, I'd be miffed)
<infinity> janimo: So, yeah.  Derivative ACLs.  On the table.  Nowhere near out of the discussion stage. :)
<janimo> infinity: ok. I don;t grok the big picture of the LP/soyuz infrastructure, so I was thinking maybe upload is separate enough of the rest of the platform to be tackled independently
<janimo> but I understand it is a lot of work so for now I am happy with the answer
<infinity> janimo: Well, it could be tackled seperately, but the whole thing needs to be discussed anyway (and is perhaps best dealt with as a logical unit), so... <shrug>
<Kamion> ogra: oh, I think I see it; some bits of kbd-chooser think that the loadkeys_wrapper function is an int, while others think it's a void
<janimo> it's just that there is a possibility of one or two xfce uploader sidekicks, now when xfce is almost in main :)
<Kamion> easy fix
<infinity> janimo: For now, the goal is still "make the Ubuntu main uploaders as happy with soyuz as they were with dak", which is still going to require some more bugfixing and optimising, so I suspect "new features that dak never had" will have to wait until after dapper's release.
<nyu> Kamion: is localechooser going to be synced with debian?  I got fixes merged in 1.06 that i'd like in ubuntu too
<Kamion> nyu: unlikely at this point, although I can backport individual fixes. Catalan, right?
<nyu> Kamion: erm, sorry, I mean I sent fixes to deb BTS that are to be merged soon
<janimo> infinity: I did not even dream of this being done for dapper ;)
<nyu> Kamion: yeah.  it's a one-liner
<infinity> janimo: Nothing wrong with you acting as a sponsor (which also means you can verify the correctness of the uploads) for those people.
<Kamion> nyu: OK, added to my to-do list
<nyu> Kamion: want me to file a bug or something?
<janimo> infinity: sure that's how we'll continue
<Kamion> nyu: if you like, yeah
<ogra> Kamion, oh, how did you find that ... even with DEBCONF_DEBUG set my syslog looks ok (apart from the kbd-chooser failed message)
<nyu> Kamion: ok thank you
<infinity> janimo: In general, I prefer to see lots of sponsorship (if it also means mentoring and verification), rather than more and more people in the keyring who may or may not be fully up to speed.
<nyu> Kamion: it is alright to file bugs referring to debian BTS for details, or duplicating the info / patch is needed?
<janimo> infinity: yes the person I am talking about has quite some sponsored uploads already
<janimo> I try convincing him to become a MOTU at least 
<infinity> janimo: Never hurts to have more. :)
<Kamion> ogra: looked through the debconf trace, figured out that it was probably the run of kbd-chooser-apply from kbd-chooser.postinst at fault; edited /var/lib/dpkg/info/kbd-chooser.postinst to stick a sleep in there to confirm this; then eyeballed the code
<ogra> ah, k ... so i didnt dig deep enough 
<infinity> janimo: Lots of us spent months (or even years) being sponsored in Debian before we could upload directly.  While this annoys some people, I found it was very educational to get shot down and told off on a regular basis by people more informed than I.
<Kamion> nyu: file a bug with a brief summary, then use the "Link to Other Bug Tracker" option down the right-hand side of the page
<nyu> Kamion: ah, nice. ok
<infinity> janimo: (And now I do the telling off, and the circle is complete... Isn't that thpethial?) :)
<janimo> I suppose :)
* janimo wonders what thpethial is
<Kamion> ogra: also I was made suspicious by the reported exit code of 147, which is normally "killed by SIGSTOP"; since that's implausible here, I reckoned it must be a random exit code, and void/int confusion is a classic cause for that
<janimo> aha silvester lisping
<ogra> ah, k, so also a matter of experience :)
<nyu> !seen jbailey?
<nyu> ~seen jbailey
<ogra> nyu, no bot 
<nyu> oh :)
<nyu> any human can tell me if Jeff comes here sometimes?
<ogra> yup, he does
<nyu> okie
<nyu> just in case someone likes to know: debian debootstrap can handle dapper fine with a "ln -s breezy /usr/lib/debootstrap/scripts/dapper"
<Kamion> hopefully we can get a dapper script into Debian debootstrap reasonably soon
<Kamion> aj's been helpful in the past
<mjg59> Lutany: Should be fixed in the next kernel relese
<nyu> jordi: there?
<nyu> jordi: ca_FR and ca_AD in ubuntu locales need a sync, there are some improvements/bugfixes that went into debian but are not in your version
<nyu> jordi: notable, ca_FR@euro and ca_AD@euro shouldn't exist, and it'd be nice to have ca_IT as well
<nyu> *notably
<jordi> they should be synced entirely
<nyu> that's fine
<mjg59> Ugh.
<nyu> jordi: do we keep your name in there?  i don't really care
<jordi> shrug
<mjg59> Lutany: Sorry, wrong person
<jordi> as you wish
<nyu> well, since this isn't in glibc upstream yet i suppose it doesn't matter
<nyu> when it's added it'll superceed it
<nyu> is it a problem for ubuntu to remove these @euro variants?  they should have never been created in first place
<nyu> because upstream will not accept them
<jordi> I don't think
<jordi> nyu: re: names, I guess you can keep both. Put me in the maintainer field if you like. I want to submit a patch for ca_ES too, it's way too large.
<jordi> I need to submit ast_ES as well
<nyu> why the 3-letter variant, conflict?
(Sirex2/#ubuntu-devel) is this the corrent place to ask if there's plans to revent the 64bit ubuntu's 32bit library handleing to 32bit-> /lib 64bit ->/lib64 like other distros ? and/or why it is how it is currently ?
<Yagisan> Sirex2: Ubuntu has a pure 64bit system. Other distros are hybrid 32bit/64bit
<Yagisan> Sirex2: Why go backwards ?
<jordi> Riddell: ping
<Sirex2> er... because some of my programs are 32bit ?
<jordi> Riddell: there's a request to import katapult translations into the *product*. Is this correct? Is rosetta the place where katapult translations are meant to be kept?
<Sirex2> i mean, is it possible to take the nice pure 64 bit system, and make it a 32bit hybrid without that chroot nightmare ? 
<Yagisan> Sirex2: chroot ? ia32-libs-* ? file a bug on the program for non-portability ? I usually do 1 and 3 myself
<Yagisan> Sirex2: chroots are very simple things
<Sirex2> well, one example program i use is secondlife which is closed source and 32bit.
<Kamion> Sirex2: there are plans to implement multiarch so that using 32-bit programs on an amd64 installation is less painful, yes
<Riddell> jordi: was that Mez?  he's the "upstream" admin for katapult but it's maintained only for kubuntu at the moment so it wouldn't surprise me if he requested translations on rosetta
<Kamion> but it will take some time to do.
<Yagisan> Sirex2: usually ia32-libs-* is all you need for those
<jordi> yes
<Yagisan> Sirex2: works for doom3 for me eg
<jordi> Riddell: can you set the Rosetta flag on, if it's official?
<Riddell> jordi: how do I do that?
<Kamion> Riddell: could you please tell bzr your real name? it's really weird to be merging from "Ubuntu LiveCD user"
<Sirex2> ill check it out. i prob have already, but im under win32 atm so need a reboot
<jordi> Riddell: Define launchpad usage, in the product pages
<jordi> Kamion: heh
<jordi> Riddell: katapult imported
<Kamion> Riddell: also, please write a debian/changelog entry; you know better than I what you did
<Riddell> jordi: do I hvae to do that or can Mez?
<Riddell> Kamion: ok
<Kamion> janimo: in fact, you *shouldn't* cut out packages which are in universe. The seeds express the desired state, not necessarily the current state
<janimo> Kamion,ok
<Kamion> Riddell: (let me know when you have, and I'll merge that lot)
<jordi> Riddell: you're in the team who owns the product
<jordi> I guess you can
<Kamion> Riddell: what version of espresso-kbd-chooser did you have installed?
<Kamion> looks like an old one, from the line numbers
<Kamion> Riddell: yeah, in fact you have espresso-keyboard-setup installed, which is dead and superseded by espresso-kbd-chooser, which actually works now
<Riddell> ah hah
<doko_> Riddell: what are these KDE system: URLs?, can these be replaces by file:// ?
<seb128> Kinnison: Daaaaaaaaniiiieel
<Kinnison> seb128: yah?
<seb128> Kinnison: https://launchpad.net/distros/ubuntu/+source/metacity/+bug/36497
<seb128> <lapo> giftnudel: looks like the problem is caused by debian/patches/010-transience-for-plugs.patch, well at least metacity works fine here w/o that patch applied
<seb128>  lapo lakin
<seb128> ups, extra line copied too :p
<seb128> Kinnison: please fix you crasher patch :)
<Kinnison> seb128: ooh did I break it?
<seb128> whoever did debian/patches/010-transience-for-plugs.patch 
<seb128> that's you?
<Kinnison> yep that's me
<ogra> phew ... wasnt me :)
* Kinnison will fix
<seb128> thank you
<Kamion> tepsipakki: I've applied your apt-setup local repository patch upstream, BTW
<Riddell> doko: nasty troublesome things, KDE should translate them to file:/ but doesn't seem to always do so
<seb128> Kinnison: 
<seb128> <crispin> seb128: I can reproduce it in galeon (closing the window that spawned a 'what app do you want to open this file with' dialogue)
<Kinnison> seb128: thanks
<seb128> Kinnison: galeon upstream gets the crash too which the case described
<herzi_x41> seb128: ping
<seb128> herzi_x41: pong
<herzi_x41> seb128: can you include the patch from http://bugzilla.gnome.org/show_bug.cgi?id=336254 into the GTK+ package, please? It's a simple two-liner
<seb128> herzi_x41: are you in a hurry? ie: is that a "today would be nice", or with next upload works fine for oyu?
<herzi_x41> with the next upload would be fine
<herzi_x41> it's just annoying warnings while developing for me
<seb128> ok, will do
<herzi_x41> thanks a lot
<Riddell> Kamion: you can merge now
<Riddell> I'm assuming I can't change that "ubuntu live CD" commit very easily
<Kamion> nah, just leave that
<jordi> Kamion: hmm. When was the last time you pulled translations from d-i svn?
<jordi> Kamion: Catalan seems to be a bit outdated. Does that make sense?
<Kamion> jordi: UVF
<jordi> Kamion: makes sense.
<Kamion> I've selectively pulled newer versions of certain packages
<Kamion> but only where it isn't a large amount of work to do so
<jordi> Kamion: ok, I pointed translators at seppy's webpages in case they want to pull the lates.
<jordi> +t
<Kamion> jordi: bear in mind that I only routinely pull translations from Rosetta for Ubuntu-specific strings
<Kinnison> seb128: okay I can reproduce the crash, I'll try and fix it
<Kamion> jordi: it causes me far too much work to pull everything, I'm afraid
<seb128> Kinnison: cool
<jordi> Kamion: yeah. Well, if it happens, great, if not, oh well.
<jordi> Kamion: Catalan had 200 missing strings
<Kamion> jordi: a fair number of those would have been in espresso, I'm guessing?
<nyu> Kamion: i think he's gone already
<Kamion> Riddell: righto, merged, thanks
<jordi> Kamion: I'll tell you in a min...
<nyu> jordi: eps.  i get 403
<nyu> erm, 401
<doko> Riddell: how? system:/home/foo -> file:///home/foo? (system: -> file:// ?)
<Riddell> doko: yes, KDE should do that before it launches the app, but doesn't seem to for some reason, I need to look into it
<doko> Riddell: ok, I'll add a workaround for now
<Kinnison> seb128: that should do it
<seb128> Kinnison: fixed? 
<Kinnison> seb128: yep, uploaded
<seb128> you rock :)
<Kinnison> seb128: well, it corrects it on my machine
<seb128> feel free to close the bug
<HiddenWolf> Can anyone tell me if the behavior of volume keys was recently changed?
<seb128> it was not
<kmon> Hello. I can't play dvd's on dapper (kubuntu) amd64 anymore. I could a few days ago. Is this a known bug?
<Riddell> kmon: using what program?
<kmon> kaffeine
<Riddell> does it work in xine?
<Riddell> kaffeine hasn't changed recently, don't think xine has either
<kmon> I don't have xine installed (only libs)
<kmon> I think it's related to a recent hal
<kmon> but i'm guessing, really
<kmon> audio cd's play fine though
<j^> seb128 looked at switching the default password char from * to ?
<mvo> Kamion: is there anything else you need for apt and the installer beside the fix for the "0s remaining" when apt repots it's progress? I'm preparing a new upload now
<kmon> ....
<Kamion> mvo: "Downloading" => "Retrieving" would be nice
<Kamion> can't immediately find a bug about it, although I'm sure somebody filed one
<mvo> Kamion: ok, done
<Kamion> basically it says "Downloading" even when it's retrieving files from the CD
<Kamion> thanks
<seb128> j^: built a package with the change but didn't try it yet, it's on my list, any hurry?
<j^> seb128 not hurry just wanted to know, i guess some apps will needs fixing. those using glade, since glade right now defaults to add default values to the glade file, so they have it set to *
<j^> the more time to find those the better
<j^> on my system i can find 225 glade files that set <property name="invisible_char" translatable="yes">*</property>
<Kamion> I maintain one of those; should I be removing that property, or changing it, or what?
<j^> since its set to the default it should be removed
<j^> that way one can change the system default
<Kamion> but if I edit the file with glade again (which I will), won't glade put it right back?
<j^> i filed a bug about that and its a general glade bug that it puts default values into the glade files
<Kamion> I don't want to have to edit the file by hand every time I edit it with glade, and I don't want to get all my contributing developers to do the same
<j^> but since one should use gazpacho anyway...
<Kamion> glade doesn't always write out default values ...
<Kamion> gazpacho would be that thing that used to crash all the time on me so people told me to use glade, right? :)
<j^> its gnome bug #335702
<Ubugtu> Gnome bug 335702 in general "Don't output default values in .glade files" [Normal,Unconfirmed]  http://bugs.gnome.org/show_bug.cgi?id=335702
<j^> Kamion its better these days... 
<Kamion> well, I'm not switching over at this point in the lifecycle of my application
<j^> possibly one can strip it in with a make/make install hook
<Riddell> is there something stopping packages entering the archives?
<Kamion> Riddell: any package in particular?
<Riddell> kerry and network-manager 0.6
<Kamion> Riddell: NEW queue
<Kamion> Riddell: and I asked you to pass on a message about kerry a while back
<Kamion> 15:48 < Kamion> Riddell: can you pass this on to whoever's packaging kerry? the binaries in the NEW queue contain this file:
<Kamion> 15:48 < Kamion> -rwxr-xr-x root/root       104 2006-02-27 14:00:53 ./usr/shutdown/beagled-shutdown.sh
<Kamion> 15:48 < Kamion> that needs to be moved somewhere FHS-compliant
<Kamion> I haven't checked over network-manager yet; the binaries only hit NEW less than two hours ago
<Riddell> I must be confusing source NEW with binary NEW
<Riddell> kerry is being worked on
<Tonio_> Riddell: means we can now revu network-manager-kde ;)
<Tonio_> Riddell: I'll ping lure for latest source package from suse
<j^> network-manager should not works as long as wpasupplicant is in universe
<Kamion> right, they're both in binary NEW
<Kamion> j^: which it isn't
<Kamion> I promoted that this morning
<Lure> Tonio_: what do you need?
<Tonio_> Lure: the *promissed* tarball from the suse guy
<Kamion> Riddell: normally I wave binaries through NEW pretty quickly but I tend to stall them if they violate the FHS or some such
<Tonio_> to update knetworkmanager on revu and get it revu now it shouldn't ftbfs anymore
<Lure> Tonio_: I have sent you in e-mail, but anyway I have the patch to build too
<Lure> Just running now
<Tonio_> Lure: checking, sorry, I'm just back home :)
<Lure> Tonio_: I can upload my source package to your system - I just did not remove dialUp (I may just add kppp instead)
<Tonio_> Lure: updating the package
<Tonio_> Lure: want to use kppp finaly ? nm-applet doesn't have any ppp feature anyway
<Kamion> I've accepted network-manager binaries now
<Lure> Tonio_: not yet, but debian team is interested to get this addressed to (mbiebl)
<Tonio_> Lure: okay
<Lure> Tonio_: but we can drop for now, and return back later (to reduce expectations)
<Lure> Tonio_: do I upload my source package or do you need just patch?
<Tonio_> Lure: hum......... I can do them, butif you already did :) just send me
<Tonio_> Lure: I checked, and including kpp ability isn't just a link, there is a complte conection reading and launching management to perform...... that's not just a little patch :)
<Lure> Tonio_: ok, will forward port noDIalUp patch too
<Lure> btw, should we move to #kubuntu-devel ;-)
<Tonio_> Lure: thanks :)
<Tonio_> Lure: agree ;)
<mroth> sladen: ping
<_ion> Wow, the network-manager build-deps are still broken?
<jjesse> mako: ping again, did you get my email?
<sladen> mroth: just ask the question!
<neuralis> jjesse: he's been really bad about responding to e-mail lately, i imagine he's horribly busy
<Lure> _ion: dependancy was resolved, now it does not build (one patch should be droped)
<Burgwork> neuralis, jjesse mako is always busy and always bad to get a hold off
<Burgwork> jjesse, is it in regards to the book?
<jjesse> Burgwork: yup i'm waiting to hear back from jono and mako on things deb and it alked about
<Burgwork> ah
<jjesse> just more changes to the Kubuntu chapter
<sladen> mjg59: can you ask kiko to merge/delete http://launchpad.net/people/old  which seems to be a ghost alter-ego of you
<sladen> mroth: ping
<kiko> mjg59, yo
<mroth> sladen: wanted to ask you re: hotkey-setup automatically modprobing uinput and nvram, and loading /usr/sbin/thinkpad on boot.  is this "to be implemented", or is it a bug it is currently not happening on my thinkpad? (want to know whether to file it)
<Lure> _ion: Riddell uploaded fixed version (dropped 20_xxx.patch) and now it builds
<Lure> _ion: see: https://launchpad.net/+builds/+build/180455
<sladen> mroth: /me presses the volume-up key and notices that it isn't working.  hmmm
<sladen> mroth: doesn't seem to work over hibernate.  I'll pop some options into /etc/acpi/resume.d/
<sladen> mroth: it /should/ be working otherwise
<mroth> sladen: doesnt get loaded on boot for me
<mroth> nvram and uinput are not loaded, and thinkpad-keys is not executed   (if i do them all manually, it all works)
<sladen> mroth: naach.
<mroth> I don't know what 'naach' means, but it doesnt sound like a happy noise ;-/
<sladen> mroth: can you paste me  $ sudo sh -x /etc/init.d/hotkey-setup start 2>&1 | tail   privately
<mroth> sladen: yes, but not until later--the machine is at home and I'm at work currently, sorry
<mroth> knew i should have brought it today, heh
<sladen> mroth: yup, if it's easier, file a bug and I'll catch it later.  Yes it /should/ be working... :)
<mroth> sladen: ok.  hotkey-setup is the correct package, yes?
<sladen> mroth: yes
<mako> jjesse: which one?
<mako> Burgwork, jjesse: i'm a bit behind on book related mail.. i've got a list of priorities i'm working through (from deb) that included finishig ch06, a revision on ch01, and then a list of other things
<Burgwork> mako, ok
<mako> so i'm proceeding through things, and email about the book, in that order :)
<jjesse> mako: thanks for letting me know, deb was just asking if you responded to my email i sent you and jono
<mdz> doko: what happened to the progress bar in the OOo splash?
<mdz> Kamion,sabdfl,mjg59: TB
<elmo> sabdfl has gone to dinner with mbp, I doubt you'll get him
<mdz> does anyone have mjg59's number?
<Treenaks> 59! *hides*
<elmo> he's around, I think?
<mjg59> mdz: Yup
<zyga> hey ubuntueros
<Pygi> pitti: around? 
<Pygi> _ion: ping
<Seveas> Pygi, please please switch to NM 0.6.2 
<Pygi> Seveas: that's what I wanted to discuss, thank you very much  ^_^
<Seveas> hehe, rock 
<Seveas> it has the patch I was talking about previously
<Pygi> Seveas: now, awake pitti and -
<Pygi> _ion, preety please   
<swat_> hi guys, got a problem with libnl/libnl-pre6
<danimo> moin
<trappist> is there some kind of utf smileys not supported by my locale?
* Pygi shoots at pitti and _ion
<Pygi> Seveas: I suppose n-m 0.6.2 won't help you to get network running at ur work?
<Seveas> yes it will!
<Pygi> Seveas: hm, fine ;)
<Pygi> I shall discuss it with pitti and ion ;)
<Seveas> fwiw: 0.6.2 is mostly a bug-fix release with a few new features.
<Pygi> Seveas: are we capable of doing good work on QA for 0.6.2 in such a lill' time? :-/
<Seveas> not less than for .1
<Lure> Seveas: +1
<Pygi> hm, ok ^_^
<Lure> not sure if we need to wait for Keybuk to be back...
<Seveas> yes you should - he's the NM god ;)
<Lure> or can pitti or somebody else make decision on this
<pitti> Pygi, _ion: re
<pitti> I couldn't even look at 0.6.1, since it didn't build anywhere
<Pygi> pitti: built now
<pitti> but this should be mainly Keybuk's and mdz's call
<Pygi> pitti: ah,k, I'll ping them then ;)
<Pygi> joy, I am constantly pinging someone ;)
<Pygi> mdz: around perhaps? ;)
<Lure> Pygi - the n-m submarine sonar guy ;-)
<Pygi> Lure: hehe ^_^
<Pygi> It would be great if we could include 0.6.2 now when it's out ;)
<Pygi> Seveas: should be no reason why we wouldn't be allowed to do that, since it's not such a big change from .1, no?
<Lure> Pygi: we are in UVF - therefore it requires UVF exception as anything else
<seb128> Pygi: usually update request are documented, like changelog since previous version, NEWS entry, rational
<seb128> Pygi: you can't expect people to agree without nowing what the changes are
<Pygi> seb128: yes, agreed ^_^ changes are: lots of bugfixes, and support for dynamic WEP ;)
<seb128> Pygi: what I said, ChangLog since previous version, NEWS entry and rationnal make easy for somebody to have a look and confirm what you say
<Pygi> seb128: who do I ping this time to ask if it can be updated if we make pacakges? 
<Pygi> hm,kk
<Treenaks> Pygi: are there any APs that do dynamic WEP?
<seb128> Pygi: UVF requests are for Kamion and mdz usually
<Pygi> seb128: thanks, now I need to ping even more people ^_^
<Pygi> Treenaks: Not sure ^_^
<Lure> Treenaks: used often in corporate environment (Seveas needs it for example)
<seb128> Pygi: talking to Keybug and mdz seems to be right for nm
<Seveas> Keybug...
<Seveas> nice typo :
<Pygi> seb128: Keybuk ;)
<seb128> Pygi: just prepare what I said, changelog and rationnal
<Pygi> lol :-P
<Treenaks> Lure: Seveas needs WPA and/or 802.1x afaik :)
<Pygi> seb128: k, will look into it ;)
<Seveas> Treenaks, dynamic wep == 802.1x 
<Lure> exactly
<Treenaks> Seveas: uhr... sure?!
<Seveas> Treenaks, nm needs a gui redesign to support all wpa/802.1x/EAP options completely
<Seveas> they hacked in this bit for now after I complained about it not being supported ;)
<Seveas> Treenaks, actually 802.1x is more than that, but what w_s calls 802.1x is now supported in n_m
<Pygi> k, found the changes for 0.6.2 ;)
<Pygi> joy ;)
<j^> Pygi 0.6.2 patch for debian bug #36871
<Ubugtu> Error: I tried to send you an empty message.
<Pygi> j^: will look now
<Pygi> j^:  link perhaps?
<j^> not debian bug Ubugtu its an ubuntu bug  #36871 for the debian dir
<j^> https://launchpad.net/distros/ubuntu/+source/network-manager/+bug/36871
<Ubugtu> Malone bug 36871 in network-manager "NetworkManager 0.6.2 released" [Normal,Unconfirmed]  
<Pygi> k, will look
<j^> other than that change to the ubuntu backend all patches still apply cleanly
<Pygi> j^: perhaps, but does this patch contains code for applet as well?
<j^> and i use it here for some time now. with the hostap patches though (malone bug 36708)
<Ubugtu> Malone bug 36708 in network-manager "[PATCH]  wpa_supplicant needs to know about hostap driver" [Normal,Unconfirmed]  http://launchpad.net/bugs/36708
<j^> Pygi code for applet?
<Pygi> j^: ah, nvm
<Pygi> lemme checkout the patch
<Pygi> j^: is this entire patch to bring .1 to .2???
<KaiL> network-manager, wpasupplicant and friends are a bit buggy, or?
<j^> Pygi replace .orig and you can use the debian dir from .1 yes
<j^> to make hostap work there is also a need to blacklist orinoco_pci(malone bug 36718)
<Ubugtu> Malone bug 36718 in module-init-tools "blacklist orinoco_pci" [Normal,Unconfirmed]  http://launchpad.net/bugs/36718
<Pygi> j^: will look into it
<j^> KaiL once it works it ok, but in general the wireless drivers tend to be outdated
<j^> many solved problems on there own.
<j^> nm tries to bring that together now, which in some cases takes quite a long time.
<KaiL> j^, well, I just found 3 bugs - and that only in an WEP-WLAN
<Pygi> KaiL: please fill bugs if they are not duplicates, and gimme bug number
<KaiL> Pygi, 37067 and 39069
<Pygi> j^: more n-m bugs ?
<j^> KaiL which version are yu using?
<Pygi> bug 37067
<Ubugtu> Malone bug 37067 in network-manager "wpasupplicant required, not recommened" [Normal,Unconfirmed]  http://launchpad.net/bugs/37067
<Pygi> bug 39069
<j^> Pygi sure
<KaiL> bug 37069
<Ubugtu> Malone bug 37069 in network-manager "network-manager doesn't set WLAN-Config at all" [Normal,Unconfirmed]  http://launchpad.net/bugs/37069
<KaiL> :)
<KaiL> sorry
<j^> bug 36777 and 36710
<Ubugtu> Malone bug 36777 in network-manager "[PATCH]  silence wpa_supplicant messages in syslog " [Normal,Unconfirmed]  http://launchpad.net/bugs/36777
<Seveas> KaiL, wpa_supplicant changed a bit, you may need to edit your configuration
<KaiL> Seveas, should that be done automatically while installing it?
<Pygi> KaiL: bug 37067 is deprecated... it is recommended
<Ubugtu> Malone bug 37067 in network-manager "wpasupplicant required, not recommened" [Normal,Unconfirmed]  http://launchpad.net/bugs/37067
<Seveas> KaiL, that is a bug - explained on the bugtracker or the -devel list
<KaiL> Pygi, tried to use network-manager 0.6 for a WEP-LAN without?
<Seveas> someone prematurely uploaded an unfinished version of wpa_supplicant
<j^> nm 0.6 depends on wpasupplicant, that should be changed
<KaiL> Seveas, you mean, a version, which talks more than every woman can? ;)
<Pygi> j^: nm has wpasupplicant as recommended
<j^> Pygi thats what i say it has to be in Depends:
<Pygi> j^: no, not really ... it was there, and we decided to move it ^_^
<j^> why, it breaks silently without it
<KaiL> Pygi, it's even required for WEP, which isn't obvious
<Pygi> KaiL: Not really sure it's needed for WEP :-/
<j^> as long as recomended packages are not installed by defaul
<j^> Pygi it is, 
<Pygi> Seveas: can you confirm that wpasupplicant is needed for WEP?
<KaiL> Pygi, at least the connection-try stops very soon without
<Seveas> Pygi, I cannot, nor can I deny
<mdz> Pygi: keybuk returns Thursday
<KaiL> not, that it works much better with (as you can see in the other bug...)
<j^> Pygi read the code, it uses wpasupplicant to connect WEP networks
<j^> it even uses wepsupplicant to scan for networks
<Pygi> mdz: k, can you help?
<Pygi> j^: hm...
<KaiL> Pygi, did you get the query with the third bug number?
<Pygi> KaiL, j^: please post me all bug numbers related to new N-M in a private message, so I can confirm it
<Pygi> KaiL: yes, will look now
<j^> Pygi why dont you just look at https://launchpad.net/distros/ubuntu/+source/network-manager/+bugs
<Lure> Pygi: just subcribe to network-manager package and you will get all of them
<Pygi> K, just did
<j^> or to sort by date https://launchpad.net/distros/ubuntu/+source/network-manager/+bugs?orderby=-datecreated
<Pygi> KaiL: private message please ;)
<pitti> Pygi: https://launchpad.net/people/<yourid>/+packagebugs is very helpful, too
<Pygi> o pitti is alive ;)
<KaiL> Pygi, how privat?
<Pygi> KaiL: bah, nvm
<Pygi> pitti: can you confirm that we need wpasupplicant for WEP?
<pitti> Pygi: no idea, but I doubt it; nm 0.5.1 didn't need it
<Pygi> pitti: this is 0.6 branch :-/ A lot could have been changed :-/
<tseng> what does wpasupplicant have to do with wep?
<ogra> they both start with W ?
<tseng> thats about it.
<j^> pitti 0.5 did not need it 0.6 does
<j^> the backend in 0.6 is quite diffrent
<Pygi> I am currently looking at all n-m bugs
<ThomS> hi, does anyone know of a bug involving firefox and evolution repeatedly opening spontaneously?
<Seveas> ThomS, voodoo!
<mario_> this is so weird  :-/
<KaiL> ...and network-manager 0.6 should take care, that the (renamed) nm-applet get's updated too imho
<ThomS> Seveas: Haha it must be, I've tried rebooting etc, they just keep opening really quickly for a bout 7 instances at random times, its making my system unusable
<Pygi> huh, how should this be explained? 
<Pygi> bug 32817
<Ubugtu> Malone bug 32817 in network-manager nm-applet "nm-applet takes over cd drive?" [Normal,Unconfirmed]  http://launchpad.net/bugs/32817
<Pygi> somebody was drunk? :--
<Pygi> :-/
<KaiL> he started nm-applet from a shell in /media/cdrom? ;:)
<j^> anyway 0.6 does not restart, so he should reopen it if it happens again 
<Pygi> KaiL: I think I'll reject this :-S
<Pygi> or need more info :-/
<Pygi> bah
<KaiL> ask, if he ever could reproduce it ;)
<Pygi> this bug is so weird ;)
<Pygi> bug 35225
<Ubugtu> Malone bug 35225 in network-manager "Wireless WEP connection ask for password when the network goes down and returns" [Normal,Unconfirmed]  http://launchpad.net/bugs/35225
<Pygi> known behaviour of N-M ... anyone have more info?
<KaiL> had that here too, but I thought, it only didn't save the key, as the connection fails..
<j^> if it does its more a problem with gnome-password-manager
<LaserJock> mdz: do I need to get a FF exception for a bug fix NEW package for multiverse?
<KaiL> interesting, I have different icons for cable-network here - most systems show just 2 computers, only one system (installed yesterday from flight 5) shows something like an rj45-plug
<KaiL> slightly off-topic: do we have a problem to power off APM-only computers, or is that my crappy hardware?
<Pygi> joy, so much bugs to check out
<Pygi> ok, a lot of bugs solved
<Pygi> j^: around?
<KaiL> personal Todo: accept, that this PCMCIA-WLAN-Card IS dead
<j^> KaiL pcmcia is broken in dapper
<j^> it only works if you put the card in the slot before booting up
<j^> Pygi pong
<KaiL> ah, that explains something
<Pygi> j^:  can you provide proper patch to bug 36777
<Ubugtu> Malone bug 36777 in network-manager "[PATCH]  silence wpa_supplicant messages in syslog " [Normal,Unconfirmed]  http://launchpad.net/bugs/36777
<KaiL> and after the system is up, the card already overheaded (bug in the card), so no chance to try it on my WLAN - bad
<KaiL> j^, uhm, wait - a 54MBit card should be PC-Card, or? And so should still work?
<j^> Pygi thats fixed in 0.6.2
<Pygi> j^: k, will reject
<Pygi> hm, will not :-/
<Pygi> we don't have 0.6.2 yet
<j^> In Progress is fine
<KaiL> Pygi, to make it even more complicate, that's more of less my "friend"...
<Pygi> KaiL: hm :-/
<Pygi> KaiL, j^: please look up unconfirmed bugs, and see if you can confirm
<Pygi> thanks
<Pygi> https://launchpad.net/distros/ubuntu/+source/network-manager/+bugs
<Pygi> I'll sleep for a few secs, and I'll be back ;)
<swat_> anyone else got this problem with libnl
<Pygi> swat_: what one?
<swat_> well it refuses to install
<Pygi> :-P
<swat_> which means networkmanager doesn't work
<Pygi> networkmanager does work :-/
<Pygi> what error do you get?
<KaiL> bug 34458 - I guess, it he misses ndis
<Ubugtu> Malone bug 34458 in network-manager "Netgear WG511 v2 not supported on Flight 5 Live CD" [Normal,Unconfirmed]  http://launchpad.net/bugs/34458
<Pygi> KaiL: set as "Need more info" and ask him to provide you with what you need
<KaiL> esp. something to know, which hardware that really is - netgear is known to change their chips quite fast
<Pygi> KaiL: ah 
#ubuntu-devel 2007-03-26
<giangy> mh
<Johnny5_> nickserv register johnny5
<jmg> hello all
<Johnny5_> hey
<jmg> im trying to patch a package using quilt (libsdl1.2)
<jmg> it's not as straight forward as dpatch
<jmg> is there similar functionality to dpatch-edit-patch possible with quilt?
<Johnny5_> I have a suggestion for the "Ubuntu restricted extas" package.
<Johnny5_> The package seems to be only missing one thing. The libdvdcss2 file
<jmg> that cannot be included 
<Johnny5_> I did manually install it, but it seems when you play a dvd through totem, you can not just select "play dvd" in the totem menu
<Johnny5_> It only play's when you put the dvd and the autoplay recognizes the dvd
<Johnny5_> Or if you open a location "dvd://"
<Johnny5_> so perhaps there is a slight issue with totem.
<Johnny5_> There is no point for totem to have a button to play a DVD if it doesn't work even if you have the libdvdcss2 file installed.
<Johnny5_> Where can I go to make a suggestion to the developers of totem? Is there an open forum, or website? I realize totem is developed through gnome, or as part of gnome.
<Nafallo> Johnny5_: bugzilla.gnome.org
<Johnny5_> thanks.
<Johnny5_> feisty is working great other than that. I have had no problems. The 3d effects work pretty well though they it is just eyecandy
<Johnny5_> Search feature on Firefox 2.0 and higher, has bad search feature. There are no options. It's just a text box.
<Nafallo> Johnny5_: better to file bugs when you find them :-)
<Nafallo> Johnny5_: https://launchpad.net
<Johnny5_> are most programs on there??
<Nafallo> that's the bug tracking system ubuntu uses
<Johnny5_> Thanks again. Unfortunately at the moment I don't know enough about programming to help out directly, but I certainly can make some good suggestions to improve ubuntu software.
<reitblatt> any idea why opensync-plugin-google-calendar seems to be in main while all the opensync stuff is in unvierse?
<ajmitch> no, and I'd say it shouldn't be
<ajmitch> something weird going on there
<reitblatt> well, besides the fact that it doesn't even work...
<ajmitch> Mithrandir: in case you're awake still, opensync-plugin-google-calendar is another that appears to have binaries in main, with source in universe
<reitblatt> bug #84874
<ubotu> Malone bug 84874 in libopensync-plugin-google-calendar "missing helper" [Medium,Confirmed]  https://launchpad.net/bugs/84874
<alex-weej> can someone give me a hint as to where to look for the fix that fixed https://launchpad.net/bugs/71040 please?
<ubotu> Malone bug 71040 in linux-source-2.6.20 "Kernel 2.6.20 reboots instead of shutting down" [Medium,Fix released]  
<mpt> asac, once you're awake, I'm interested in hearing more about this "tailored bug workflow" the mozilla team has
<mpt> If different teams have different meanings for the same bug statuses, that makes collaboration across projects more difficult
<mpt> so it'll be good to come up with a set of statuses and meanings that suit the most projects
<hugo> BenC, ping
<BenC> hugo: pong
<hugo> BenC, i wrote a proposal to the device-manager
<BenC> hugo: what sort of proposal?
<hugo> BenC, https://wiki.ubuntu.com/DeviceManagerSpec
<hugo> BenC, but i dont know if it is good explained
<hugo> BenC, have anyone proposed this idea too?
<BenC> hugo: I don't see the idea, where in there is it?
<hugo> BenC, i did not submitted yet
<BenC> hugo: then how can I know what it is?
<hugo> BenC, can i send a mail to you ?
<BenC> hugo: yes, please
<hugo> BenC, i put here; http://atum.caco.ic.unicamp.br/~hugo/home/device-manager
<superm1> BenC, you see my note earlier about lirc?
<BenC> superm1: Yes, I'll have to take a look tomorrow morning
<superm1> BenC, very good
<superm1> BenC, i ran into a minor issue with one module, but the rest tested fine (linsmod'ing them)
<BenC> hugo: What in your proposal is any different than what is already in the spec?
<BenC> hugo: The spec is not for details like you've outlined
<hugo> BenC, i am thinking in change the UI to group devices
<BenC> hugo: Were you one of the ones that emailed me about SoC for this project?
<hugo> BenC, no
<hugo> BenC, i dont know your mail
<BenC> hugo: I have two applicants for this project to do it for Google's Summer of Code, so I need to see about what's going on
<BenC> hugo: Email me at bcollins@ubuntu.com (the info you just posted) and I'll have to talk to someone about how to handle this...I'd really hate to see 3 people working on the same thing and going off in different directions, or worse just doing the same thing separately
<hugo> BenC, my initial idea was to implement the proposal
<BenC> hugo: I've already partially implemented it, but the rest needs udev changes in order to work
<hugo> BenC, perhaps you will need choose between the 3
<BenC> hugo: I have a project started on launchpad.net
<hugo> BenC, ok, my idea would implement more since what is done
<hugo> BenC, i am really interested in this idea, i passed any time studying this proposal
<BenC> hugo: I realy appreciate your interest in it. I'm just trying to make sure this is done fairly
<BenC> hugo: There's nothing I can do to stop anyone working on it, but if we are going to include it, then I need to make sure it's done properly and suitable for our needs
<hugo> BenC, ok
<hugo> BenC, can you help me on a idea needed by Ubuntu available to be proposed?
<sladen> mpt: maybe "Needs Info" is actually "Debugging"
<sladen> mpt: and maybe there is a separate "Needs User followup to progress" (which should time out after 30days and close the bug)
<reitblatt> did launchpad just go down for ayone else?
<sladen> yup.
<hugo> BenC, the implementation you made is in gtk?
<BenC> hugo: It's based on hal-device-manager
<hugo> BenC, i am asking because theres a qt version
<BenC> hugo: hal-device-manager is PyGlade (gtk)
<hugo> BenC, i could implement based on kde-hal-device-manager too
<BenC> hugo: One of the people asking to do it for SoC wants to make the core UI-independent so it can be used for kde/gnome
<BenC> avoids too much duplication
<hugo> appears the wiki is out..
<alex-weej> and launchpad
<mpt> sladen, what would be the difference between "Debugging" and "Unconfirmed"?
<sladen> mpt: it tends to move out of unconfirmed when somebody takes ownership (starts proactively interacting with the reported)
<sladen> mpt: users really hate seeing their bugs as Unconfirmed, so there's also a tendancy (I believe) to move them to Needs Info to imply that they have at least been looked at
<sladen> mpt: I'd quite often [personally]  like to be able to set up   Confirmed ("yes, we know this happens")+Needs Info ("we haven't yet worked out /how/ (which method) to fix it by")
<fabbione> morning
* Starting logfile irclogs/ubuntu-devel.log
<pitti> Good morning
<Hobbsee> hi pitti!
<ajmitch> morning pitti 
<Mithrandir> ajmitch: indeed, I'll demote it.
<Mithrandir> Adri2000: do you have a NEW package exception for libclass-trait-perl?
<pochu> pitti: where is apport's compiz? there is no ~/.apport dir
<pitti> pochu: hmmm?
<pochu> pitti: isn't there an apport dir for the preferences? (such as: don't ask again)
<pitti> pochu: there is a file for that: ~/.apport-ignore.xml
<RAOF> pitti: It's been suggested that I ask you about the apport-retrace for bug #95814 - it was marked with need-amd64-retrace about 20 hours ago, and doesn't seem to have got a retrace.
<ubotu> Malone bug 95814 in banshee "[apport]  banshee.exe crashed with SIGSEGV (dup-of: 67344)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95814
<ubotu> Malone bug 67344 in banshee "Crash while importing / trying to play at the same time" [Undecided,Confirmed]  https://launchpad.net/bugs/67344
<pochu> pitti: thanks
<pitti> RAOF: let me have a llook
<pitti> oh
<pitti> RAOF: it's a duplicate
<pitti> RAOF: the retracer doesn't consider those
<RAOF> Ah, ok.
<RAOF> I'll have to unduplicate it and then re-add the tag, then?
<pitti> RAOF: is it actually necessary? the original bug isn't enough?
<RAOF> None of the original bug have stacktraces.
<pitti> RAOF: then duplicate it the other way around rather?
<RAOF> Also, I'm no longer sure that the bugs are actually duplicates.
<RAOF> pitti: Thanks./
<fabbione> Mithrandir: if you are not busy could you please give your opinion to bugs #96072 and #96076 ?
<ubotu> Malone bug 96072 in initramfs-tools "initramfs doesn't support setting NETBOOT variable for casper" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96072
<ubotu> Malone bug 96076 in casper "network interface must be enabled before calling nfsmount" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96076
<Mithrandir> fabbione: I can do in a bit.
<fabbione> Mithrandir: sure thanks
<fabbione> Mithrandir: also.. as soon as i can get back my workstation i am going to bug you again about redhat-cluster-suite. We have a bunch of code clean up and bug fixes to pull it on top of that one liner we already agreed on
<Mithrandir> sure
<Mithrandir> Mez: #69479, why have you subscribed the release team?
<reitblatt> Bug #69479
<ubotu> Malone bug 69479 in katapult "SRU: katapult" [Undecided,Needs info]  https://launchpad.net/bugs/69479
<Mithrandir> ajmitch: do you know how f-spot 0.3.6 is coming along?
<dholbach> hellas
<ajmitch> Mithrandir: not released yet, and the main fix that was needed for it is in the 0.3.5 we have
<Mithrandir> ajmitch: ok.
<dholbach> ogra: new dia (looks like final)
<slomo> Mithrandir: hi... can you take another short look at bug #93540? 1.2.9 was released recently with a bugfix, two new preferences options that people wanted very strongly and a performance fix... if that's fine with you i'll skip 1.2.8 completely ;)
<ubotu> Malone bug 93540 in liferea "UVF exception: liferea 1.2.9" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93540
<Mithrandir> slomo: looks good; approved.
<slomo> Mithrandir: thanks
<daseeb> hello... mhm... I developed an application that needs to link with option "-lgcc_s" but in /lib there is only a /lib/libgcc_s.so.1. why doesn't the symlink to libgcc_s.so exist? how should I properly set this up to share my sourcecode and others can compile it easily?
<hunger> daseeb: Are you sure you need that? IIRC gcc_s is always linked in by gcc.
<daseeb> hunger: I think so... it's a little bit weird. I use fmod. this is an audio library. When I link to libfmod.so I get an error /usr/bin/../lib/libfmod.so: undefined reference to `__divdi3'
<daseeb> I use freepascal as compiler
<daseeb> some people from fmod team suggested me to link to libgcc_s.so to solve the linking problem
<Mithrandir> sounds like libfmod isn't properly linked.
<pochu> good morning heno :)
<heno> morning pochu :)
<daseeb> mithrandir: mhm... ok... what exactly does this mean... what should be done to link fmod properly? how can I find out if fmod isn't linke dproperly?
<Mithrandir> daseeb: is libfmod linked against libgcc_s?
<daseeb> daseeb@daseeb-desktop:/usr/lib$ ldd libfmod.so
<daseeb>         linux-gate.so.1 =>  (0xffffe000)
<daseeb>         libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e01000)
<daseeb>         libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7dfd000)
<daseeb>         libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7dd7000)
<daseeb>         libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7dc3000)
<daseeb>         /lib/ld-linux.so.2 (0x80000000)
<daseeb> does this help?
<Mithrandir> yes, it's not linked against it.
<daseeb> should it be linked against it?
<Mithrandir> I don't know why; you might actually want to talk with doko, who's our toolchain guy and might know why gcc didn't link in libgcc_s correctly there.
<seb128> Mithrandir: there is a new libcairo bug fix version (1.4.0 to 1.4.2), is that ok to update?
<Mithrandir> seb128: do you have the changelog?
<doko> daseeb: you should show us the command line you use for linking
<seb128> Mithrandir: http://mail.gnome.org/archives/gnome-announce-list/2007-March/msg00065.html
<Mithrandir> doko: please read the last 30-ish lines and please correct me if I said something wrong there.
<seb128> doko: hi, did you read my python setlocale question on friday?
<Mithrandir> seb128: how does the malloc-vs-stack usage affect thread-safeness, or isn't cairo threadsafe to begin with?
<doko> seb128: sorry. maybe not
<daseeb> mithrandir: "/usr/bin/ld -b elf32-i386 -m elf_i386  -dynamic-linker=/lib/ld-linux.so.2  -L. -o ../cactus_jukebox ../link.res" 
<seb128> Mithrandir: cairo is not really threadsafe to begin with
<hunger> Any chance of seeing #78021? It contains a reference to another bug that seems to have the fix attached.
<Mithrandir> daseeb: you should probably use gcc to link with too.
<Mithrandir> seb128: ok, approved.
<seb128> Mithrandir: thank you
<daseeb> mithrandir: this means? how can I do that? 
<seb128> doko: 
<seb128> $ LC_ALL=de_DE.UTF-8 python -c "import locale; locale.setlocale(locale.LC_ALL, '')"
<seb128> Traceback (most recent call last):
<seb128>   File "<string>", line 1, in <module>
<seb128>   File "/usr/lib/python2.5/locale.py", line 476, in setlocale
<seb128>     return _setlocale(category, locale)
<seb128> locale.Error: unsupported locale setting
<seb128> doko: ^ do you consider that a python bug?
<hunger> I am seeing a message from python about there being no ScanPCI module during bootup. Is that a known problem?
<daseeb> mithrandir: adding option "-lgcc"?
<doko> seb128: hmm, I remember seeing that, will have a look today or tomorrow
<Mithrandir> daseeb: as I said, talk to doko.
<doko> daseeb: you should always link using the gcc driver
<seb128> doko: ok, thank you, there is bugs on random python apps due to that
<daseeb> doko: so what exactly is the gcc driver? I'm not so familiar with gcc, because I mostly use delphi/freepascal...
<doko> daseeb: the binary `gcc'
<daseeb> doko: can you give some more details? I should link with invoking gcc instead of ld? but I use freepascal for compilation. this produces some .a and .o files which get linked afterwards by the above commandline
<doko> daseeb: so the pasted command line isn't complete, is it?
<daseeb> doko: I do "/usr/bin/ppc386  -S2i -CX -OG1p2 -gl -Xs -vewnhi -Fi../../units/lnet-0.4.0/lib/sys/ -Fufmodintf/ " -Fu../../units/lnet-0.4.0/lib/ -Fu../../units/synapse/source/lib/ -Fu../../lazarus-svn/components/jpeg/lib/i386-linux/ -Fu../../lazarus-svn/lcl/units/i386-linux/ -Fu../../lazarus-svn/lcl/units/i386-linux/gtk2/ -Fu../../lazarus-svn/packager/units/i386-linux/ -Fu. -FU. -o../cactus_jukebox -sh -dLCL -dLCLgtk2 mp3proj.lpr". this
<daseeb> does the compilation
<daseeb> doko: and afterwards  "/usr/bin/ld -b elf32-i386 -m elf_i386  -dynamic-linker=/lib/ld-linux.so.2  -L. -o ../cactus_jukebox ../link.res"  does the linking
<daseeb> doko: but without passing the option "-lgcc" to the linker it fails with "/usr/bin/../lib/libfmod.so: undefined reference to `__divdi3'"
<dholbach> pitti: can you promote gnome-user-docs to main and demote gnome2-user-docs? (going to get gnome2-user-docs purged from the archive)
<daseeb> doko: as far as I see, -lgcc should link with /lib/libgcc.so
<pitti> dholbach: what's the principal difference?
<doko> daseeb: yes and no; please locate the libgcc.so (locate libgcc.so) and use that one.
<dholbach> pitti: gnome-user-docs is updated in debian (different maintainer), gnome2-user-docs isn't - same upstream source
<doko> daseeb: how did you install this free-pascal?
<pitti> dholbach: ubuntu-docs Depends: gnome2-user-guide
<daseeb> doko: from .deb created by the freepascal team
<dholbach> pitti: i'll change that too
<pitti> dholbach: no other rdepends
<pitti> dholbach: ok, if you fix that, I'll remove gnome2-user-docs right away and promote g-u-d, ok?
<dholbach> pitti: no bug to file, no mir? great :-)
<pitti> let's save ourselves the bureaucracy
<dholbach> yoohoo :-)
* dholbach hugs pitti
<pitti> dholbach: done
<dholbach> pitti: thanks a lot!
* dholbach hugs pitti again
<pitti> no problem :)
<doko> daseeb: then please file a bug report to this team that they should pass the appropriate -L option
<daseeb> doko: libgcc.so doesn't exist here...:( perhaps my gcc is broken. what package contains libgcc.so?
<dholbach> pitti: ubuntu-docs change uploaded
<doko> daseeb: apt-get install dlocate; dlocate libgcc.so
<cjwatson> err, dlocate only locates files on your system. use packages.ubuntu.com to find files not on your system
<dholbach> ogra: new gnome-power-manager too 
<doko> cjwatson: yeah, but this package is installed; daseeb: anyway, look for libgcc_s.so
<doko> daseeb: to automate that: gcc --print-file-name libgcc_s.so
<daseeb> doko: 
<daseeb> daseeb@daseeb-desktop:/$ gcc --print-file-name libgcc_s.so
<daseeb> /usr/lib/gcc/i486-linux-gnu/4.1.2/libgcc_s.so
<daseeb> doko: so this file exists... 
<doko> <doko> daseeb: then please file a bug report to this team that they should pass the appropriate -L option
<daseeb> doko: ok
<daseeb> doko: and finally: should I link directly to libgcc_s.so or do some symlink to libgcc.so?
<doko> daseeb: please ask the freepascal developers; I don't know anything of the freepascal internals
<daseeb> doko: ok... thx so far
<doko> mvo: does update-manager has some regexp expressions pickled?
<mvo> doko: no, but gnome-app-install
<doko> mvo: ok, there's a fix on the python 2.5 branch to correctly unpickle regexps pickled with 2.4; will prepare an upload today
<mvo> doko: cool, thanks
<mvo> doko: I tested the fix here, it works fine for me
<Enola_Gay> hi all
<Enola_Gay> Does it make sense to create a bug report according the link of screen saver with gnome power manager?
<Enola_Gay> That the lowest time you could choose in power manger is screen saver start time + 1 minute.
<Enola_Gay> Or is it just gnome philosphie?
<poningru> Enola_Gay: file a bug report with feature request in gnome
<Enola_Gay> poningru: Thanks.
<Enola_Gay> poningru: On Launchpad or the original Gnome hp?
<elianm> does importing to Rosetta work at the moment?
<poningru> Enola_Gay: just file it on lp
<Enola_Gay> k
<elianm> I'm having troubles like this https://launchpad.net/rosetta/+bug/76017
<ubotu> Malone bug 76017 in rosetta "Broken X-Rosetta-Export-Date header" [Critical,Fix released]  
<pitti> mvo: what's the current plan for bug 47044?
<ubotu> Malone bug 47044 in apt "apt cant work with disable proxy" [Medium,In progress]  https://launchpad.net/bugs/47044
<elianm> hehe, ubotu ? 
<mvo> pitti: still in verification-needed state, I can't sru-verify this myself as I did the sru reuqest and upload to -proposed
<mvo> pitti: bdmurray will have to sru-verify this (together with popcon in dapper and some other packages)
<pitti> mvo: right, I mean, is it still appropriate for an SRU in the first place, after the concerns raised?
<mvo> pitti: the concern from simon? I explained that in my comment (I hope :)
<pitti> mvo: at least the SRU queue slowly gets smaller :)
<mvo> pitti: most of the remaining items a either issued by me or HW dependant (I'm not quite sure how to verify those)
<Enola_Gay> Another problem is that "Add/Remove..." under Applications uses dpkg insteaf of apt-get or aptitude.
<Enola_Gay> Aptitude and apt-get since Edgy log the dependencies or manual installed applications so it is possible to remove unused dependencies.
<Enola_Gay> This isn't possible with the standard gnome installer.
<Enola_Gay> Bug or feature?
<Enola_Gay> You could live with it but the system has more and more installations which aren't needed and which are very hard without much knowledge to remove. That's why I like Edgy so much and reinstalled my system. Of course you can use synaptic or console tools but who knows it?
<dholbach> Enola_Gay: please file bug reports - add/remove uses synaptic which uses apt
<mvo> Enola_Gay: " problem is that "Add/Remove..." under Applications uses dpkg insteaf " where did you got that information?
<mvo> Enola_Gay: what dholbach said, its plain incorrect
<Enola_Gay> dholbach: But after installing xchat with add/remove with two dependencies it was not possible to remove those both after removing xchat with apt-get autoremove.
<mvo> Enola_Gay: under what release of ubuntu? if that is the case, this is a bug
<Enola_Gay> mvo: From someone on ubuntu-de-Channel and I got the experience described above.
<Enola_Gay> FEisty
<Enola_Gay> Ok, I made some more tests.
<Enola_Gay> *make
<dholbach> Enola_Gay: you tried to remove xchat with apt-get autoremove?
<mvo> Enola_Gay: the feisty version of g-a-i should even deal with that automatically. so if you remove xchat with g-a-i it should automatically remove the two deps it installed for it
<surak> Simple question: where are gnome's keyboard layouts stored? I am intended to fix a bug on it...
<ogra> dholbach, i found the bug with the vendor icon, you moved it from apps/ to places/ ... :)
<Enola_Gay> mvo: So if I remove xchat with it the dependencies are automatically removed too?
<dholbach> ogra: i didn't
<ogra> dholbach, thanks for the dia ping :)
<Enola_Gay> -with
<mvo> Enola_Gay: if you do it in g-a-i yes. with apt/synaptic it will (by default) just tell you about them and let you decide
<ogra> dholbach, well, its in the places subdir on all my systems on feisty
<dholbach> ogra: we added tangerine icons for all sizes and maybe upstream changed something in gnome-icon-theme
<ogra> while its in apps on edgy
<ogra> ah, k
<dholbach> ogra: you got the gpm ping too?
<ogra> anyway, moving my icons over fixes it :)
<dholbach> nice
<ogra> i'm subscribed to the gpm list, got the release mail yesterday ;)
<surak> I can fix the bug with xmodmap, however it's not clear to me how gnome sets up the keyboard. DHolbachy
<dholbach> neat
<surak> ?
<dholbach> surak: hm?
<surak> ops, dholbach - damn keyboard!
<dholbach> ok :)
<dholbach> i wondered if I missed something
<surak> it's bug #68357
<ubotu> Malone bug 68357 in xserver-xorg-input-keyboard "Spanish layout misses ~ combinations" [Undecided,Unconfirmed]  https://launchpad.net/bugs/68357
<Enola_Gay> mvo: Sorry, that would account why apt-get autoremove shows no unused dependencies afterwards.
<surak> it's surely posted against the wrong package.
<mvo> Enola_Gay: no problem
<Enola_Gay> Yeah, works fine. It doesn't remove all dependencies but they are still removable with apt-get autoremove. Great.
<mvo> Enola_Gay: g-a-i will only autoremove dependencies of the removed pkg on removal. not all no-longer-required dependencies
* mvo wonders if that sentence makes sense
<Enola_Gay> mvo: yes, it makes :)
<Enola_Gay> mvo: It seems to remove the direct dependencies but not the indirect ones I guess.
<mvo> Enola_Gay: what was your testcase? install xchat and remove it again all from within g-a-i? did it leave any deps for autoremoval in that case that werent present before?
<Enola_Gay> mvo, that works completly fine. It removes all dependencies.
* StevenK wonders how to get PCI device IDs with lspci.
<Enola_Gay> But I am checking it with kvpnc.
<mvo> Enola_Gay: great :) make sure that #ubuntu-de knows about this too so that we do not have false rumors :)
<Enola_Gay> Yeah, I have posted it
<mvo> thanks!
<Enola_Gay> yeah, I am right
<Enola_Gay> If you install kvpcn it has a bunch of dependencies. After removing it uninstalls kdelibs and menu but not arts and Co so I think kvpnc depends on kdelibs but kdelibs on arts so g-a-i removes only direct dependencies.
<Enola_Gay> Which is fine imho since it could be remove with apt-get autoremove
<Enola_Gay> the indirect ones
<mvo> Enola_Gay: nice catch. could you please file a bug about this? jus tso that its not forgotten?
<Riddell> Mithrandir: did you have an opinion on k3b 1.0 UVF exception?
<Enola_Gay> mvo: Ok, I make it. What is the name of this package?
<mvo> Enola_Gay: please file against "gnome-app-install"
<Enola_Gay> k
<Mithrandir> Riddell: hm, sorry, I haven't gotten to it.  I'll do so.
<Enola_Gay> Thanks.
<mvo> thank you!
<pitti> urgh, so many duplicates in the SoC applications
<evand> pitti: Why is that a bad thing?  Wouldn't you want multiple applications for the same task, that way you can choose which candidate you think will do the best job?
<pitti> evand: I just replied to the ubuntu-soc list about  that
<pitti> evand: best thing might be collaboration, if the rules allow that
<pitti> Free software is all about collaboration, after all :)
<evand> ah, indeed
<carlos> pitti: now that the beta has been released, will you do a lang pack update *now* before the final one ?
<Enola_Gay> mvo: https://launchpad.net/ubuntu/+source/gnome-app-install/+bug/96410
<pitti> carlos: not sure, do you think it would be a good idea?
<ubotu> Malone bug 96410 in gnome-app-install "gnome-app-install removes only direct dependencies" [Undecided,Unconfirmed]  
<pitti> seb128: ^ see carlos' question
<carlos> pitti: yeah, I fixed many templates and still approving some new ones
<carlos> so we get some more testing on it
<Enola_Gay> Which package consists Gnome power manager?
<seb128> pitti: what? language pack updates? sure, translators only started to work on feisty since it was not open before ...
<cjwatson> Enola_Gay: gnome-power-manager
<Enola_Gay> cjwatson: thanks :)
<pitti> carlos: I can use the current daily ones from yesterday afternoon's rosetta tarballs; is that a good one, or shall I wait a bit more?
<carlos> pitti: also, I wrote a script to fix the new line char and 'dot representing space' that should fix those translations
<pitti> cool
<carlos> pitti: wait until tomorrow
<carlos> I will execute my script to fix the data
<carlos> and do a new export
<pitti> carlos: so, wait for tomorrow afternoon's rosetta tarballs? or today's?
<mvo> Enola_Gay: thanks
<carlos> pitti: tomorrow afternoon
<pitti> carlos: alright
<carlos> pitti: I will ping you, just wanted to know your plans
<carlos> so I can schedule next steps
<Enola_Gay> mvo: You're welcome! :)
<ogra> Mithrandir, so whats the magic i need to make MN not touch my interface ? is there a gconf key i can set or something ?
<ogra> *NM
<ogra> else i'll need to drop it from edubuntu,m since it always hogs the server interface of ltsp
<ogra> i looked at the spec but there is no trace of how to disable NM management...
<gnomefreak> pitti: are you in charge of auto retrace bot project? (charge for lack of better word)
<pitti> gnomefreak: yes, I am
<gnomefreak> pitti: it seems to be auto tagging already retraced crash reports
<pitti> gnomefreak: that was me
<gnomefreak> oh ok
<pitti> gnomefreak: I re-tagged failed crash reports from the weekend after fixing the chroots
<Mithrandir> ogra: temporarily, you can add a mapping stanza.  I'm going to add something to interfaces(5) that you can use to tell NM to not touch it.
<gnomefreak> ok cause a few we ended up retracing i guess and getting decent feedback from apport. hjmf is seeing this. 
<ogra> cool, i was fearing i had to tear it out
<StevenK> I thought NM shouldn't touch it if the interface appears in interfaces(5)...
<ogra> i can wiat until that stanza is read ...
<ogra> *wait
<pitti> gnomefreak: it's possible that this created some unnecessary bug spam, but checking all of the 86 failed bugs manually was too much effort
<ogra> i think interfaces altready has a hotplug flag, just add nohotplug :)
* StevenK tries to convince his machine that it has a SATA controller, and fails miserably.
<gnomefreak> i understand i just didnt know if it was a bug or if it was meant to be done
<StevenK> Hrm. It appears in the PCI ID list for ata_piix.
<LeeJunFan> I've got what appears to be a pretty serious bug in genisoimage, I thought was growisofs at first, but genisoimage isn't selectable in the package list, and I want to make sure it get's noticed by the right maintainer. Bug #96096
<ubotu> Malone bug 96096 in dvd+rw-tools "Unable to burn good DVD+R" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96096
<cjwatson> LeeJunFan: genisoimage is from the source package cdrkit
<Enola_Gay> poningru: https://launchpad.net/ubuntu/+source/gnome-power-manager/+bug/96419
<ubotu> Malone bug 96419 in gnome-power-manager "it isn't possible to choose sleep times lower then the screen saver one" [Undecided,Unconfirmed]  
<LeeJunFan> cjwatson: I looked for that too. I'll try again.
<kwwii> dholbach: ping?
<dholbach> kwwii: pong
<LeeJunFan> cjwatson: nope, if I'm going the right way about this - trying to attach to an upstream product - cdrkit isn't there either.
<kwwii> dholbach: I'm updating the gdm theme gtkrc file (as well as the list theme gtkrc) to fix a problem with the icons no showing
<dholbach> kwwii: alrighty
<dholbach> kwwii: let me know once you have it done
<kwwii> dholbach: I'll let you know when it is pushed
<kwwii> ;-)
<cjwatson> LeeJunFan: no
<cjwatson> LeeJunFan: click on "dvd+rw-tools (Ubuntu)" and change the source package from dvd+rw-tools to cdrkit
<LeeJunFan> cjwatson: thanks.
<cjwatson> LeeJunFan: if you wanted to use the "Also affects" thing (although it doesn't sound appropriate if you don't believe the bug is in growisofs), you'd use "Also affects: Distribution", and select Ubuntu as the distribution and cdrkit as the source package
<LeeJunFan> cjwatson: no, the proper thing at this point is to reassign it totally.
<poningru> justdave's first law: all bug handling software must be convoluted enough to not accept bug reports from end user
<cjwatson> LeeJunFan: right
<Enola_Gay> Thanks for support, cu all.
<anti_pop> this might the wrong channel to ask, but is it possible that nvidias 9631 driver will not work with the latest 2.6.20-13 kernel ?
<asac> mpt: pong
<PriceChild> I noticed that nvidia-glx was updated to 9755... any chance of a "new-legacy" with 9631?
<asac> keescook: ping
<mpt> asac, I'm here
<asac> hi
<asac> about the bug workflow ... i don't think that there is one fits all :)
<pitti> does anyone know how to use grep to find NUL bytes in files? grep '\000' and variations doesn't work
<mpt> If there isn't, that's a problem for this whole "Launchpad" idea
<mpt> asac, so we need some uniform well-understood statuses that allow collaboration between everyone, and tags for everything else, probably
<asac> hmm
<mpt> "Needs Info" isn't "Needs Info From the Reporter" only because that was too long to fit :-)
<mpt> though to be more precise it's "Needs Info From the Reporter or Someone Else Who Can Reproduce the Problem"
<asac> yeah ... exactly ... it means "Needs Info" :)
<cjwatson> mpt: (ugh)
<lifeless> pitti: '[\0] ' ?
<asac> i mean as long as there is info missing ... e.g. we have no testcase ... its needs info
<pitti> lifeless: no :(
<asac> i think it would be wrong to say this only means "by reporter"
<cjwatson> mpt: my biggest source of confusion is info from people who thought they could reproduce the problem but actually can reproduce some totally different problem
<mpt> asac, sure, missing testcase is something that only skill will prevent the reporter from providing
<_ion> Yay, the new l-r-m + nvidia-glx dropped support for my nVidia card. Yeah, nvidia-glx-legacy does support my card, but the previous non-legacy driver supported running compiz/beryl with it.
<mpt> cjwatson, that problem seems orthogonal to bug statuses, isn't it?
<mpt> Oh, I suppose it would be lessened if the status was "Needs Reporter Info"
<mpt> hmmm
<mpt> interesting
<cjwatson> mpt: it would certainly be made worse if the status were explicitly "... or Someone Else Who Can Reproduce the Problem". :-)
<asac> if the status was "Needs Reporter Info", then we would lack a general "Needs Info" state 
<mpt> fair enough
<mpt> asac, we have that, it's called "Unconfirmed" :-)
<mpt> ok, that was too flip
<lifeless> pitti: egrep maybe?
<mpt> asac, what other kinds of info are you thinking of?
<pitti> lifeless: already tried that as well
<lifeless> pitti: python
<pitti> lifeless: right, I already gave up on grep, too
<asac> mpt: e.g. a properly traced stacktrace in case of crashers.
<mpt> asac, how is a stacktrace not something the reporter should provide? (keeping in mind Colin's problem that you don't want other people attaching stacktraces for similar-but-unrelated bugs)
<asac> mpt: its usually too much skill required by reporters ... we now have coredumps attached which team members or triagers can retrace
<Treenaks> or robots ;)
<asac> mpt: anyway, i don't think we have a problem here as this discussion started with single/maybe special case.
<doko> pitti: on amd64, a new memory stick apparently is detected as iPod, and rhythmbox is started.
<cjwatson> mpt: I think asac means retracing of apport-provided coredumps to add full symbols
<cjwatson> which is a "more information required" state in some sense
<mpt> asac, well, it's interesting, because it's one example of a kind of issue that needs to go through a process involving different people/teams
<mpt> In this case it's reporter -> retracing team -> developers
<mpt> in others it might be reporter -> developers -> QA
<asac> do you have bug number again?
<mpt> or reporter -> triager -> UI designer -> developer
<pitti> doko: oh, are there any files on it?
<doko> pitti: no mp3 and such stuff, even after formatting, rhytmbox is started
<pitti> doko: if not, the vendor/product ID might be weird; ls -l /media/stick and lspci/lspci -n output appreciated in a bug report 
<StevenK> Surely the USB vendor/device ID is also helpful?
<mpt> asac, bug 94322
<ubotu> Malone bug 94322 in firefox "Don't show warnings for non-dangerous HTTPS situations" [Low,In progress]  https://launchpad.net/bugs/94322
<asac> yeah right.
<mpt> In future (I hope) your Launchpad page will have a list of the bugs you reported that are Needs Info, so you can deal with them
<mpt> and that would break if it was being used for other things.
<asac> what state is "needs decision on how to go on"?
<doko> lol: Bug #96002: Gnome Volume Manager don't work and the sound is very loud
<ubotu> Malone bug 96002 in gnome-volume-manager "Gnome Volume Manager don't work and the sound is very loud" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96002
<kwwii>  dholbach: commiting now
<Lure> pitti: just a small "after beta" reminder about digikamimageplugins MIR ;-)
<cjwatson> heno: bug 96126: bit early yet to say "no time for Feisty" for minor UI tweaks to the new partitioner
<ubotu> Malone bug 96126 in ubiquity "used space in partition column should be visible in manual partitioner" [Wishlist,Confirmed]  https://launchpad.net/bugs/96126
<heno> cjwatson: is that a minor UI tweak, ok I though it was more invasive than that
<heno> cjwatson: thanks for correcting
<cjwatson> I think we've got the information already
<Mithrandir> hm, I wonder if we could have a way of taking packages out of a release, a bit like debian's testing, to avoid shipping RC-buggy packages.
<hunger> Any chance of the error messages that show up during bootup vanishing before the final release?
<hunger> s/error/error and annoying warning/
<heno> cjwatson: I get it now, you are talking about just placing a number in a table, not the graphical representation that gparted had
<AlinuxOS> BenC_, hello
<BenC_> AlinuxOS: hello
<DarkSun88> Hi all
<pitti> hey BenC 
<BenC> pitti: hey
<DarkSun88> Any main sponsor here?
<pitti> Lure: noted :)
<DarkSun88> Could you so kind to check this bug?  and without a freeze exception from <god of release maintainer> there are no syncs in main
<AlinuxOS> BenC_, do you remmember I've promissed you screenshot of my cat /proc/kmsg | grep ide
<AlinuxOS> finally I got it.
<DarkSun88> Ops: https://launchpad.net/ubuntu/+source/gpaint/+bug/95944
<ubotu> Malone bug 95944 in gpaint "Please sync gpaint 0.3.0pre5-4 (main) from Debian (unstable)" [Undecided,Unconfirmed]  
<DarkSun88> This
<AlinuxOS> long life to pitti ;)
<BenC> AlinuxOS: I already fixed the problem :)
<AlinuxOS> BenC, ah
<AlinuxOS> :D
<BenC> AlinuxOS: the fix is in the 2.6.20-13 kernel
<AlinuxOS> Found kernel: /vmlinuz-2.6.20-13-generic
<AlinuxOS> Found kernel: /vmlinuz-2.6.20-12-generic
<AlinuxOS> Found kernel: /vmlinuz-2.6.20-11-generic
<AlinuxOS> ah
<AlinuxOS> ok
<AlinuxOS> I'll try it.
<AlinuxOS> and tell you..what going here by me.
<pitti> AlinuxOS: live long and prosper
<AlinuxOS> pitti, ;) 
<cjwatson> heno: oh, right, yes
<dholbach> kwwii: ok looking
<reitblatt> could I bother someone to take a peak at this spec: https://blueprints.launchpad.net/ubuntu/+spec/seamless-windows-virtualization
<kwwii> dholbach: I also just commited a session splash change
<reitblatt> would make a great SoC project for someone I imagine
<dholbach> kwwii: alrighty
<heno> reitblatt: why does it link to a help.u.c page and not the wiki
<reitblatt> oops
<heno> reitblatt: I was just looking at the wiki page btw, interesting
* kwwii hugs dholbach 
<reitblatt> should link here
<reitblatt> https://wiki.ubuntu.com/SeamlessWindowsVirtualization
* Hobbsee hugs dholbach
<reitblatt> idea came from the help page
* dholbach hugs Hobbsee
* dholbach hugs kwwii too
<reitblatt> so I linked it at first
<Hobbsee> :)
<reitblatt> heno: thanks
<dholbach> kwwii: HumanList/icon-session.png is missing
<kwwii> dholbach: ouch, guess I missed that...I'll put it back in ;-)
<dholbach> kwwii: Human looks good
<kwwii> dholbach: oops, I removed all the icons :-(
<dholbach> kwwii: session splash uploaded
<kwwii> dholbach: great, thanks...I'll replace the icons in the list theme
<dholbach> kwwii: ok
<AlinuxOS> cjwatson, hello, debian-installer has new strings, I though that there was string freeze.
<birgstef> u make a mistake? when u upped the follow file? http://de.releases.ubuntu.com/7.04/ubuntu-7.04-beta-desktop-i386.iso ... u get DAPPER instead feisty!
<kwwii> dholbach: committing next gdm now
<dholbach> kwwii: alrighty
<kwwii> dholbach: thanks again man
<birgstef> dholbach?
<dholbach> birgstef: ?
<dholbach> kwwii: de rien
<birgstef> deu?
<dholbach> birgstef: can you elaborate?
<birgstef> are u german?
<dholbach> Yes
<birgstef> fein, ihr habt nen dicken Fehler -.- auf der http://de.releases.ubuntu.com/7.04/ubuntu-7.04-beta-desktop-i386.iso 
<birgstef> da steckt dapper hinter, nicht feisty -.-
<dholbach> birgstef: http://de.releases.ubuntu.com/7.04/ does not load for me - if it really says dapper, somebody needs to notify the admins of the german mirror
<birgstef> where can i find the admins?
<dholbach> birgstef: https://launchpad.net/ubuntu/+cdmirrors is all I know
<Znarl> birgstef : I will contact the admin about this issue.
<dholbach> Znarl: ah great
<dholbach> birgstef: thanks
<birgstef> ty Znarl
<maswan> Znarl: btw, I'm downloading the iso now to chekc
<birgstef> the checksum is: b48f708dd3680b337fb8edb54c5cda31
<maswan> It's a really slow mirror though
<dholbach> birgstef: hum, it loaded fine now but doesn't say 'dapper' for me
<birgstef> well, i burn the iso on cd, open the "dists" folder, there is "dapper, stable, unstable"
<birgstef> ive installed it, and have now dapper 6.06 on my system
<birgstef> ?!?
<shawarma> seb128: Why do we run scrollkeeper-rebuilddb each month? The man page even says it's not necessary unless the db has been corrupted somehow..
<seb128> shawarma: no idea, that's coming from Debian
<shawarma> seb128: Hmm... It's just annoying to have it run every month if it's not really necessary. It's quite CPU heavy.
<shawarma> seb128: => makes the cooler in my girlfriend's laptop *really* noisy => I can't get any work done. :-)
<seb128> shawarma: nobody else complained about it yet
<seb128> and it should not be that slow
<seb128> take like 3-4min
<shawarma> seb128: Hm... I'm almost sure it was like 10 minutes of infernal noise. :-)
<shawarma> seb128: I'll file a bug.
<seb128> shawarma: yeah, one of those hundred of bugs we get a week and can't deal with ;)
<seb128> shawarma: I don't think anybody is subscribed to that package and the bug is likely to stay there
<dholbach> make it a 'ubuntulove' task :)
* dholbach gives seb128 some chocolate
<seb128> dholbach: it's not ubuntulove
<Mithrandir> mvo: so, we just had a user who upgraded and where his chipset support moved from nvidia-glx to -legacy.  Is this something you think update-manager a) could handle, b) should handle?
<seb128> dholbach: it's "need decision from somebody who knows what he's doing"
<shawarma> seb128: *G* I'll assign it to myself. I'll see if I can figure out why it was put there in the first place.
<seb128> shawarma: that will just make bug noise but feel free if you really want
<seb128> shawarma: it would better be discussed on a mailing list
* dholbach still gives seb128 some chocolate :)
<seb128> dholbach: thank you ;)
<dholbach> :)
<shawarma> seb128: I'm just quite busy these days so it's easier to remember it that way for me.
<seb128> shawarma: ok
<welshbyte> could i request a rebuild of gurlchecker to fix an unmetdep? (Bug #96381 )
<ubotu> Malone bug 96381 in gurlchecker "[UNMETDEPS]  gurlchecker has unmet dependencies" [Undecided,Confirmed]  https://launchpad.net/bugs/96381
<Hobbsee> shawarma: did you get back to dabien?
<seb128> welshbyte: no
<seb128> welshbyte: there is "rebuild", you need an upload
<shawarma> Hobbsee: No, I haven't seen him online since then.
<Hobbsee> shawarma: ahh.   wrong times then, he's been around
<welshbyte> seb128, but it doesn't need to be changes, the shlibs:Depends should make it depend on the correct library
<welshbyte> s/changes/changed/
<shawarma> Hobbsee: Hmm... I'll probably run into him at some point.
<seb128> welshbyte: there is already binaries for that version, it needs a new upload to have new binaries
<seb128> welshbyte: only updating the changelog with a "rebuild for soname change" entry is enough
<welshbyte> i see.. so, just bump the version
<welshbyte> ?
<StevenK> welshbyte: I'll do it, if you like.
<welshbyte> StevenK, if it's no trouble :) i'd only be able to do a debdiff anyway
<mvo> Mithrandir: it certainly could handle it, but I I'm not sure if it should do that. it should be the exception to do fixes in the release-upgrader. if it could be handled on a packaging level somehow, that would be better IMHO. but I guess this case is hard
<Mithrandir> mvo: packages can't (currently) depend on hardware features, so that bit is hard.
<Mithrandir> mvo: I'm a bit worried about leaving users with a black screen saying "Login:" after an upgrade.
<mvo> Mithrandir: do we have a bugnumber for this (the nvidia, nvidia-glx thing)
<mvo> Mithrandir: make that nvidia, nvidia-legacy. 
<Mithrandir> mvo: no, it was discussed on a private channel.
<mvo> Mithrandir: ok, if the user could file a bug, that would be appreciated
<Mithrandir> mvo: sure
<mvo> Mithrandir: I will put it into the release notes as well 
<asac> hmmm firefox build did not find latest libthai0 while it found latest libthai-dev on most architectures ... where do buildd get their packages from?
<StevenK> The archive?
<StevenK> Most helpful answer ever.
* StevenK ducks.
<asac> lol
<Mithrandir> mvo: thanks.
<Mithrandir> asac: if the -dev package depends on an exact version, this often happens.
<asac> in de.archives.ubuntu.com i have Filename: pool/main/libt/libthai/libthai0_0.1.8-2_amd64.deb ... however buildd says its not there
<bddebian> Heya
<asac> Mithrandir: is this a bug? or just takes more time?
<Mithrandir> asac: the usual fix is "ask Tollef or another buildd admin to give back the failed packages", so I'll do that now
<asac> :)
<asac> Mithrandir: https://beta.launchpad.net/ubuntu/+source/firefox/2.0.0.3+1-0ubuntu1 ... though I doubt this info helps you.
<asac> thanks a lot
<Mithrandir> asac: given-back
<asac> Mithrandir: just curious, what does "given-back" mean?
<Mithrandir> asac: it means I told the buildd to retry the build.
<asac> ah :) ... hope not many rounds of these are needed.
<dholbach> kwwii: uploaded
<dholbach> kwwii: and I changed the version number to not be ...ubuntu1
<dholbach> kwwii: apart from that it' seems all good 
<asac> Mithrandir: again it failed
<pochu> heno: ping? #ubuntu-iso please :)
<asac> Mithrandir: maybe i just fail to see the obvious ... hmmm :/
<Mithrandir> asac: I'll take a look
<heno> pochu: sure
<Mithrandir> asac: ah, I see what happened; it'll be fixed in about an hour and a half and firefox can then be given back.
<asac> Mithrandir: any info for the noisy mob?
<asac> s/noisy/nosy/
<Mithrandir> asac: (the problem being that libthai0 depended on libthai-data, but libthai-data is arch: all, so it ended up in NEW with the i386 build.  This caused libthai0 to be uninstallable on all arches but i386.)
<asac> oh wierd ... i tried to install here on amd64 ... guess i missed the libthai-data part then
<asac> anyway thanks
<thekorn> pitti: I attached a patch to bug 95223, didn't know that you are assigned to that bug,
<ubotu> Malone bug 95223 in bughelper "Apport retracing service munging chars in bug summary" [Medium,In progress]  https://launchpad.net/bugs/95223
<pitti> thekorn: oh, thanks
<pitti> thekorn: oh, sanitize_html() *un*quotes?:
<thekorn> pitti: it changes &lt; into < and i think thats what you are looking for ?!
<pitti> thekorn: right
* pitti hugs thekorn, thank you
<thekorn> pitti: ok, i will merge it into main and the release branch
<dholbach> thekorn: i'll roll it into a package later
<thekorn> dholbach: thanks a lot!
<dholbach> np
<bddebian> dholbach: Since you acked gcc-h8300-hms, do you have a suggestion about brickos?  I can't get a clean build log of it without the newer gcc-h8300-hms?
<dholbach> bddebian: sorry, not at all
<bddebian> Bah :-)
<slomo> can someone please give-back seahorse on ppc?
<asac> Mithrandir: maybe ffox can get a new chance by now?
<iwj> seb128: (if you see this) Care to comment on bug 94166 ?
<ubotu> Malone bug 94166 in firefox "Get Help Online appears to do nothing if firefox minimised" [Medium,Confirmed]  https://launchpad.net/bugs/94166
<seb128> iwj: the "drop the menu item"?
<keescook> asac: pong, still no archive admins around.  :(
<pitti> hi keescook 
<keescook> hiya pitti
<seb128> hey keescook
<keescook> hiya seb128!
<seb128> keescook: archive admin or buildd admin?
<keescook> seb128: I'm unclear on the distinction, but it sounds like cjwatson's got it covered.
<seb128> ok
<ogra> dholbach, your command listed on bug 96340 disagrees with the bug content :)
<ubotu> Malone bug 96340 in squeak-vm "[UNMETDEPS]  squeak-vm has unmet dependencies" [Undecided,Confirmed]  https://launchpad.net/bugs/96340
<Mithrandir> asac: yeah; given-back.
<dholbach> ogra: on amd64?
<seb128> iwj: added a comment, we will likely mask that menu item for feisty anyway
<ogra> dholbach, there is no amd64 version odf squeak afaik
<ogra> might be that LaserJock didnt comment oiut that arch
<dholbach> ogra: no, it's Arch: any
<ogra> yeah, but since the content of the package are binary blobs ...
<dholbach> it ftbfs on all other archs: https://launchpad.net/ubuntu/+source/squeak-vm/3.7.7-5ubuntu6
<iwj> seb128: Right, thanks.
<seb128> np
<dholbach> ogra: ^
<ogra> dholbach, edgy and dapper ?
<dholbach> feisty
<Animortis> Hi, I had a question - Are there plans to patch the security holes in OpenOffice.org as posted last week?
<ogra> either i'm totally blind or in the left protlet is no feisty at all
<keescook> Animortis: yup, they're in the publication process now.  The libwpd one has already been fixed.
<ogra> i see it ftbfs in edgy and dapper
<dholbach> ogra: does it build for you on amd64 today?
<Animortis> Good, I'm glad. I know how Ubuntu feels about patching certain packages, but I couldn't see why not since Ubuntu keeps so in line with the Debian repos and those did it...
<Animortis> Thanks.
<ogra> dholbach, no idea, as i said, there is no amd64 executable for the vm 
<dholbach> ogra: then set Architecture to i386
<ogra> and i have it not in the broken deps list for i386
<ogra> i'd klike to hear from LaserJock about it, he packaged it like that iirv
<ogra> *iirc
<ogra> probably an amd64 port was announced or something 
<dholbach> i followed up in the bug report
<ogra> i just dont see it in the list and the bug doesnt talk about any sepcific arch
<ogra> *septic arch ? 
<dholbach> ogra: i added that information now
<ogra> oki
<dholbach> ogra: the command was run on an amd64
<ogra> yeah, i got that now :) 
<dholbach> you were complaining some seconds ago that the bug doesn't talk about any specific arch :)
<ogra> yeah, and you fixed it ... as well as i undersrtood it from our conversation ;)
* ogra hugs dholbach 
<dholbach> ok
<seb128> Mithrandir: https://beta.launchpad.net/ubuntu/+source/libxklavier/+bug/96561
<ubotu> Malone bug 96561 in libxklavier "UVF exception 3.1 to 3.2" [Undecided,Unconfirmed]  
<Mithrandir> seb128: approved
<seb128> Mithrandir: thank you
<iwj> Dammit, I want to lose this race!
<Mithrandir> switch camels with the other guy?
<iwj> Good idea.  Now all I need is that camel.
<jdong> BenC: what's the justification for nvidia-9755??
<jdong> now all the GeForce4 users are left without 9xxx-series nvidia.
<mjg59> Go nvidia.
<jdong> I just don't think it's the right decision for a major class of devices to lose support, past beta.
<PriceChild> Where was the decision made?
<mjg59> jdong: The alternative is to ship drivers without any security support
<unimatrix9> hello there....
<unimatrix9> any one home?
<jdong> mjg59: can we get a nvidia-new-legacy package then for tne intermediate cards?
<mjg59> jdong: That depends on whether nvidia are planning on doing security support on them or not
<jdong> mjg59: they are showing as legacy drivers, just like the 7184's
<jdong> so I'm assuming they'll do the same with them.
<mjg59> Also, the kernel team have expressed a lack of interest in supporting three sets of nvidia drivers
<jdong> that's really unfortunate.
<mjg59> Yes, being in a position where a driver vendor can screw you repeatedly /is/ unfortunate.
<PriceChild> The driver vendor isn't screwing us...?
<jdong> but we are in a position where we can ship some level of driver support.
<mjg59> By increasing the support load on an already overworked team
<jdong> it's the kernel developers who don't want the extra work who are screwing us.
<jdong> then don't upgrade nvidia-glx to 9755...
<mjg59> Not possible.
<mjg59> No guarantee of provision of security support for the hardware supported in them.
<jdong> then drop 7184 legacy and replace it with 9655
<mjg59> Screws anyone who has a card that's supported by 7184 but not the last release of the previous legacy ones
<unimatrix9> any developers of feisty fawn beta 1 around?
<mjg59> It's not like your card stops working. You just get to drop back to 7184 yourself.
<jdong> yes but you lose 3D effects support.
<jdong> on 20+ cards that are more than capable of 3D effects.
<PriceChild> mjg59, http://us.download.nvidia.com/XFree86/Linux-x86/1.0-9755/README/appendix-a.html
<mjg59> PriceChild: ?
<jdong> "Below are the legacy GPUs that are no longer supported in the unified driver. These GPUs will continue to be maintained through the special legacy NVIDIA GPU driver releases."
<PriceChild> mjg59, that says that the 9631 supported cards will "continue to be maintained through the special legacy NVIDIA GPU driver releases."
<jdong> it sounds like nvidia plans to continue legacy release cycles for them.
<Amaranth> err
<Amaranth> does it say 9631?
<PriceChild> Amaranth, read it ;)
<jdong> Amaranth: read it.
<mjg59> PriceChild: Yes. Please read the conversation.
<PriceChild> Amaranth, its above the 71** and 96** section
<cjwatson> unimatrix9: this is the developer channel, yes
<jdong> Amaranth: there's 96xx and 71xx sections in legacy releases.
<PriceChild> mjg59, what have I not read?
<mjg59> 18:17 < mjg59> Also, the kernel team have expressed a lack of interest in  supporting three sets of nvidia drivers
<jdong> umm...
<PriceChild> mjg59, I've a lack of interest in arguing this with you... but i'm doing it as its the right thing to do in my opinion.
<unimatrix9> i would like to say , you all have done an great job, i took an sneak preview of feisty fawn beta 1 , and its very very polished, i would just like to say it to you, really nice, keep up the good work!
<Amaranth> and all those card work with the 71xx driver, don't they?
<jdong> Amaranth: yes, but without composite or desktop effect support.
<unimatrix9> its the little things that matter, and i can see you care!
<PriceChild> Amaranth, I don't know... juging by the 8800 not working with lower than 9755 drivers, I'd assume there are cards that don't
<mjg59> PriceChild: The right thing to do is to ensure that the kernel team are able to support packages we ship in a timely manner
<cjwatson> unimatrix9: thanks for the comments; they are appreciated :-)
<Amaranth> PriceChild: i'm pretty sure the geforce 4 cards were done by the time they moved to 8xxx
<unimatrix9> most people come here to report bugs, i only come to say that its awsome!
<PriceChild> Amaranth, yeah I'm just looking at the notes to see :) I'm probably wrong :P
<jdong> it seems like time to start 3rd party repos again.
<Amaranth> jdong: It's your right to do so. Just remember that it's up to you to support it, we won't help users that have problems with it.
<jdong> Amaranth: yes, I'm fully aware of that.
<jdong> it would be better if something a bit less ad-hoc can be arranged.
<Amaranth> btw, card support with 96xx is funner than you think
<jdong> but given the globular nature of l-r-m it's gonna be nasty.
<Amaranth> iirc about half the cards they dropped support for in 97xx were actually subtly broken in 9631 and 9629 so you'd actually have to provide the 9626 beta driver
<mjg59> Remember, kids, It's so hard to write a graphics driver that open-sourcing it would not help.
<PriceChild> http://www.nvidia.com/object/linux_display_ia32_1.0-7667.html
<PriceChild> adds support for the 7800
<mjg59> PriceChild: 7800 is still supported in the latest 9000 series
* PriceChild head desks
<Amaranth> mjg59: Yep, that's why those nouveau guys are going nowhere. :)
<mjg59> So what version it was introduced in is entirely unimportant
<lemsx1> cjwatson: ping
<cjwatson> lemsx1: yes?
<lemsx1> cjwatson: remember that ssh problem?
<lemsx1> cjwatson: I added GSSAPIAuthentication no to my ~/.ssh/config file for all hosts and now it works as it should
<cjwatson> right, it would
<lemsx1> cjwatson: that at least trims down the possibilities to KRB5 for real
<cjwatson> not really
<cjwatson> I think it's avahi/mdns
<lemsx1> cjwatson: you think? so if i turn off avahi it should not give me that problem?
<cjwatson> I don't want to suggest workarounds
<lemsx1> cjwatson: i know. i just want to know exactly what the problem is before i go into the C code
<cjwatson> but my own researches suggest that, at least for some people, DNS queries are only done if GSSAPIAuthentication is turned on (the details are boring)
<cjwatson> and reverse DNS lookups through avahi take much longer to time out than normal reverse DNS lookups
<cjwatson> why, I have no idea
<lemsx1> cjwatson: umm... but if you use nscd (like i do) then the second time the IP is resolved should be lighting fast
<cjwatson> compare e.g. 'time host 82.211.81.190' and 'time avahi-resolve-address 82.211.81.190' if you don't believe me
<cjwatson> that's a host in the Canonical datacentre that currently has no reverse DNS (though we're trying to get that fixed)
<bmhm> hi, i'd like to report some occurances I found out with grub/ubuntu
<lemsx1> cjwatson: it does take 5 times longer to timeout
<dholbach> bmhm: try http://launchpad.net/ubuntu/+source/grub/+filebug
<bmhm> when I put "elevator=cfq" to my boot menu, I have to put "irqpoll" too, for my WLan-Card to be rconized
<bmhm> dholbach, just wanted to tell you before, just in case
<dholbach> bmhm: ok
<bmhm> btw i don#t want to register ;D
<dholbach> see you guys tomorrow
<cjwatson> bmhm: I'm sorry, but we don't accept unregistered bug reports because that means we have no way to get in touch with users later if there's a query
<bmhm> cjwatson, i just found out i am already registered
<cjwatson> in any case, that isn't a grub bug, but a kernel bug (https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+filebug if this is feisty)
<bmhm> i have no idea wether this is a kernel or a grub bug
<bmhm> i post it as a grub bug...
<cjwatson> it's not a grub bug.
<cjwatson> please do not file it as one
<bmhm> ok, edgy 64 then
<cjwatson> if it's edgy, then https://launchpad.net/ubuntu/+source/linux-source-2.6.17/+filebug
<bmhm> ok on it
<bmhm> cjwatson, https://launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/96575
<ubotu> Malone bug 96575 in linux-source-2.6.17 "loading with elevator=cfq forces using of irqpoll" [Undecided,Unconfirmed]  
<bmhm> hmm
<bmhm> I hope I did it right... 
<bmhm> ah i forgot dmesg
<kylem> ...
<kylem> the default ioschedular on amd64 generic is already cfq.
<bmhm> ah really?
<kylem> yes.
<bmhm> well, german wiki didnt tell this
<bmhm> it just said "add elevator=cfq"
<bmhm> ... "to tune your system"
<kylem> debian/config/amd64/config.generic:6:CONFIG_DEFAULT_IOSCHED="cfq"
<shawarma> bmhm: It's been default since Breezy, I think.
<bmhm> ok I just told them to correct that
<bmhm> anyway, got sth else to show you
<bmhm> http://nopaste.info/61126dd6bf.html
<bmhm> see those stancer with a blank line before and after?
<bmhm> it's being shown on bootup
<mjg59> bmhm: Harmless
<bmhm> ll 27-30
<bmhm> ok
<bmhm> anyway... any idea what it means?
<mjg59> It means that the resources requested by those bits of hardware were unavailable
<lemsx1> cjwatson: having avahi running or not (and removed from /etc/nsswitch.conf) has no effect on the ssh bug
<mjg59> Which usually means that the BIOS never bothered programming them correctly
<bmhm> ah I see
<cjwatson> lemsx1: hmm, ok, odd
<bmhm> how can I find out which device is meant by this msg?
<mjg59> lspci. But it's harmless.
<bmhm> it's my PCI bridge or ethernet-controller
<bmhm> well since it works
<bmhm> ...
<bmhm> okay thanks a lot guys
<bmhm> shawarma, is cfq default for just 64 bit or 32 bit, too?
<shawarma> bmhm: both
<mjg59> Yes
<bmhm> well... then I will fix the german wiki
<bmhm> it says Anticipatory I/O scheduler is standard
<bmhm> I will remove that part then
<yacoob> Hi. Will feisty have composite manager by default?
<mrsno> available but not enabled by default yacoob 
<mrsno> couple of clicks to enable
<Burgwork> keescook: you around?
<yacoob> mrsno, mhm. I gave it a try, but apparently my radeon 9600 plays dirty tricks on me.
<yacoob> (xgl worked but e-ve-ry-thing-went-sooo-sloooow... and that was BEFORE I launched any compiz/beryl :)
<keescook> Burgwork: yup, what's up?
<Burgwork> keescook: I noticed some people beating up the asterisk devs for lack of disclosure on security bugs. Is this still an issue?
<keescook> Burgwork: well, we'll know with their next release.  :)  They helped confirm the most recent patch, though.
<Burgwork> keescook: ok, is good. so if I file an MIR for asterisk, would you approve it?
<keescook> Burgwork: I've never done an MIR, but I'd like to see how things unfold with them
<Adri2000> Mithrandir: yes: https://launchpad.net/bugs/87662
<ubotu> Malone bug 87662 in Ubuntu "Please sync libclass-trait-perl from Debian unstable (main)" [Undecided,Fix released]  
<UBfusion> good evening from Greece
<UBfusion> is there a way to include the 2.6.20-13.21 kernel to be released tomorrow iinto the existing 0326 amd64 desktop iso?
<Mithrandir> UBfusion: easiest would be to just wait until tomorrow morning.
<UBfusion> forgot to mention the CD does not boot
<UBfusion> thanks Mithrandir 
<Mithrandir> we roll daily CDs and since -13 is current now, it'll be on tomorrow's CDs.
<UBfusion> i am doomed for so many weeks by the critical bugs and can't wait :-)
<UBfusion> that's what I was expecting
<UBfusion> #84964 is a pest... If Ben really nailed it, I'll send him a case of greek Ouzo :-)
<maxamillion> how close is feisty to the package freeze?
<Mithrandir> which package freeze?
<ajmitch> hi Mithrandir 
<maxamillion> Mithrandir: _the_ official feisty release repository freeze
<Mithrandir> hiya Andrew
<Mithrandir> maxamillion: around April 5th.
<maxamillion> Mithrandir: ok, thanks
<maxamillion> are there any really pressing bugs in the current state of feisty or would it be safe to install the current beta on the new lot of laptops i just got here at work and do the updates when it goes stable (or should i install edgy and re-do them in a month?)
<UBfusion> maxamillion, have a look here https://launchpad.net/ubuntu/+milestone/7.04-beta
<maxamillion> UBfusion: thanks
<UBfusion> most critical problems will hopefully be fixed tomorrow
<UBfusion> some minor issues are in the feisty discussion http://ubuntuforums.org/forumdisplay.php?f=179
<UBfusion> most have to do with wireless connectivity
<UBfusion> and some with sound
<maxamillion> hmmm... well wireless is needed, i might just stick with edgy for the next month to be safe
<UBfusion> search the feisty forum for your wireless model and see
<maxamillion> k
<anti_pop> is it just me, or is it not possible to install nvidias legacy driver from the repos for a gf4 (because 9755 has no support for it)
<UBfusion> i think i read something similar in the feisty discussions about an fx440.. so you may not be alone
<UBfusion> from what i read, feisty is in turning point these 2 weeks, where fixing one thing causes regressions to others
<UBfusion> peace and patience are needed in this phase.. and a lot of prayers ;-)
<anti_pop> the hole circle was very quiet for me but the last two days with some kde upgrades and nvidia-glx some things got messed up
<UBfusion> the metaphysics of it is really challenging.. on the one hand it's "if it ain't broke, don't fix it"
<UBfusion> on the other you want to see how feisty+1 will look like
<anti_pop> i will not take part in feisty+1 as long as it is not released. but i learned so much by using feisty as a linux beginner (after 2 month edgy)
<UBfusion> same for me... it's hard to find the balance... and newbies like me would really like to see more guides for regressing to previous states
<UBfusion> like "how to regress to your previous network/gfx/sound drivers"
<anti_pop> backports may provide enough fun i guess
<Hobbsee> oh dear.  if you're a newbie, and dont know how to file bugs and use apt, you should *not* be using the development release
<mooey> i love the idea that updates will break things :D
<mooey> gives me something to do
<Hobbsee> mooey: except when your machine doesnt boot, etc, and you need to chroot
<mooey> Hobbsee: nah thats great fun
<Hobbsee> heh
<mooey> i use this machine every day for work, too :-)
<Hobbsee> scary
<mooey> its never broken, really, not seriously
<UBfusion> Hobbsee, it's the other way round,  i use the betas in order to learn to file bugs
<anti_pop> Hobbsee, i know..but by jumping into the cold water i learned how to use apt, make x start again, configure grub, sources, and fstab
<Hobbsee> true.  X transition was mostly painless this time
<mooey> but i pick my updates selectivly, and always a while after they come out
<Hobbsee> anti_pop: true.  most people wont do that though
<Hobbsee> UBfusion: fair enough
<Hobbsee> a lot of people just upgrade everything at once, then go OH NO, THERE ARE PACKAGES HELD BACK!!! FEISTY IS SO BROKEN!!!
<mooey> and those same people don't file bug reports :-)
<Hobbsee> exactly
<mooey> most helpful
<Hobbsee> indeed.  not
<Hobbsee> or they report on the forums.  also not helpful
<UBfusion> they won't file bugs because they don't care much.. many of them are diggers that want to spend only 30 minutes with it
<Chipzz> Hobbsee: not even debian unstable is really broken a lot
<Chipzz> and they only have one archive run per day
<Hobbsee> Chipzz: you'd be looking at experimental
<Chipzz> instead of one every hour
<Chipzz> Hobbsee: been there, done that, got the tshirt
<Chipzz> :)
<UBfusion> :-)
<anti_pop> well not beeing able to install nvidia-glx-legacy is the first bug for me that i didnt find on launchpad
<Hobbsee> heh
* Hobbsee ---> sleep and such
<mooey> good night
<UBfusion> natti
<UBfusion> for me the egoist part is to make feisty work for myself.. the altrouistic part is to help fight bug#1
<anti_pop> maybe its cause my .de servers are somewhat behind the original servers
<anti_pop> my girlfriend lives with 2 other girls, at the moment they all got edgy running on their laptops, guess who showed em linux :)
<cjwatson> Chipzz: (Debian has been on two archive cycles per day for some time now)
<UBfusion> anti_pop, tha't the proper way to do a foursome ;-)
<Chipzz> cjwatson: oh, it is? didn't know that
<Chipzz> cjwatson: but point still stands
<Chipzz> cjwatson: bugs get fixed faster in ubuntu partly because of the bigger amount of archive cycles
<cjwatson> sure (though they also get introduced faster ;-)), was just a point of information
<Riddell> infinity: could you give back kmplayer please
<Riddell> infinity: and okular
<Crescendo_> Yarrrrrrrrr.  Ubuntu needs a built-in suggestion/misc bug reporting feature built in.
<Crescendo_> I don't want to have to log onto a website just to file a bug or report an annoying behavior. :(
<adamant1988> Crescendo_: there is one.
<Crescendo_> It's dysfunctional, though.  It only seems to be called when an application crashes.
<adamant1988> Crescendo_: I can open it right now, without an app crashing
<Crescendo_> The next time I'm trying to open an SFTP connection and the default keyring password box that I'm typing in is intruded by the "opening server" window, upon which the only option is "cancel" - I should be able to go System >> Help >> File a bug
<mooey> Crescendo_: system -> report a problem
<adamant1988> Crescendo_: Why don't you take 30 seconds to stop rambling and hit "System" and punch the "report a problem" button.  I think that's RIGHT up your alley.
<Crescendo_> I don't see a report a problem button.
<Crescendo_> Maybe that's only provided with fresh installs?
<Crescendo_> ;_;
<mooey> adamant1988: cool it
<adamant1988> It was in mine, herd 5
<mooey> Crescendo_: what version of ubuntu do you use?
<Crescendo_> Oh, of course - I'm not using Herd 5, I'm on 6.10.
<Crescendo_> So, problem is solved in the next release, awesome. :)
<adamant1988> Yup
<Crescendo_> Rawk, thanks for listening to my frustrated rant.  :P
<mooey> Crescendo_: i'm sure such a menu item existed in edgy
<mooey> Crescendo_: not with the same name, but in a simmilar vein
<Crescendo_> mooey, I've had problems with new features not showing up after upgrades, like the power button top right after... one of the releases, 6.06 or something.
<Crescendo_> It seems to come default on certain new installs, but not upgrades.
<mooey> Crescendo_: the upgrade probably decides you have your panels configured how you like them and leaves them alone :-)
<Crescendo_> mooey, probably, and it's not that much trouble to add it anyways.  Just a minor note I encounter on my daily install routines.
<Crescendo_> I'm looking forward to seeing the Windows migration in action, by the way.
* mooey hasn't used windows in many years
<mooey> Crescendo_: i've just checked a not-upgraded edgy install, theres no report a bug button. in feisty it exists on the system menu and in the help menu of many apps :-)
<Crescendo_> A lot of my clients use Windows, and are concerned about the migration issues.
<mooey> hopefully the new stuff in feisty will push them to migrate :-)
<Crescendo_> Me too.  Man, all of my requests for copious amounts of 6.06 CDs have been denied. ;_;
<mooey> :(
#ubuntu-devel 2007-03-27
<mooey> what files does the apport retracing thing need? does it use the attached .crash file, or coredump.gz?
<Fujitsu> mooey: It uses the new multi-attachment format.
<mooey> Fujitsu: i'm not sure what that is. the reason i ask, if somebody attaches the .crash file to a bug and i tag it to be retraced, will it?
<mooey> i dont know what the requirements are for retracing
<Fujitsu> It won't be retraced, AFAIK.
<mooey> Fujitsu: as i suspected, thanks
* robertj arghs...10 minute routine fsck on battery :(
<Lathiat> robertj: heh i love it when that happens
<robertj> I thought  a big part of these new fangled journeling file systems is that they didn't require manually fscking?
<desrt> "stuff happens"
<desrt> a fsck is good from time to time
<Lathiat> i really wish it gave you a few seconds to cancel it
<desrt> or let you ^C in the middle like it used to
<robertj> Lathiat: doesn't it happen before USB support is probed in?
<Lathiat> classic case in point: http://www.flickr.com/photos/lathiat/364496523/
<robertj> I seem to remember being cought by that on ppc64 a while back
<robertj> it just seems utterly worthless to 99.99% of people
<desrt> far better when someone gets stuck at fsck while trying to power their laptop up to give a talk
<robertj> could it <blasphemy>be disabled by default?</blasphemy>
<desrt> you really _should_ run it from time to time
<Lathiat> what we need is online fscking
<desrt> ya.  that would kick some serious ass
<desrt> we're talking my quality of life is significantly improved
<robertj> desrt: and I should lose 20 pounds
<desrt> robertj; if you lose data as a result of your extra 20 pounds it's not a problem in ubuntu
<robertj> desrt: neither is it if my HD goes toes-up
<desrt> it has nothing to do with your HD going toes-up
<desrt> it has to do with bugs in the filesystem code
<desrt> "stuff happens"
<desrt> and the journaling isn't absolutely perfect
<desrt> from time to time i'll see "inconsistent something-or-other" when fscking an ext3 fs.... it just happens
<desrt> i don't think it's 'cause i have bad disks or bad ram... i think the code just has some very small bugs
<mjg59> tepsipakki: Have we lost the patch that disables XAAOffscreenPixmaps when a compositing manager is running?
<desrt> tepsipakki; while you're looking: have you seen keithp's xcomposite bugfix that no feisty should be without?
<desrt> ((and applies absolutely cleanly to feisty's X))
<tepsipakki> mjg59: we had that?
<mjg59> tepsipakki: Yeah
<tepsipakki> desrt: no
<desrt> let me find it for you
<mjg59> tepsipakki: It meant compiz actually worked :)
<tepsipakki> thanks
<robertj> do SUSE & Fedora still fsck?
<tepsipakki> mjg59: was it in xorg-server?
<desrt> tepsipakki; http://lists.freedesktop.org/archives/xorg/2007-March/022668.html
<mjg59> tepsipakki: Oh, hang on, it's still there
<mjg59> tepsipakki: Path 120
<mjg59> tepsipakki: It's just been dropped from series for some reason
<tepsipakki> oh..
<tepsipakki> let me check
<mjg59> Seems to apply cleanly
<ssam> is it not possible for fsck to run at shutdown?
<robertj> also fsck is only going to run on my file server once or twice a year, where it is perhaps more important
<robertj> whereas my laptop gets fscked once a week
<pochu> is XAAOffscreenPixmaps the opposite to XAANoOffscreenPixmaps?
<mjg59> Yes
<mjg59> tepsipakki: Of course, we also seem to be missing the compiz half of that patch :)
* mjg59 looks into that
<tepsipakki> mjg59: yeah.. I dropped it because of the feedback I got from Michel Dnzer. Fedora still has it, so maybe we should reactivate it again, since it is generating pain for people
<pochu> then that pach would be really cool. we have a lot of compiz bug reports saying 'compiz doesn't work' and it's just because they're missing that option in the device section
<mjg59> tepsipakki: Yeah, it's something of a hack, but it's one that works
<mjg59> tepsipakki: If you can merge that back in, I'll handle the compiz side
<tepsipakki> also the dont_backfill_bg_none.patch
<tepsipakki> sure, I have the source ready
<mjg59> tepsipakki: Seems to still apply just fine, so it's just a matter of hitting it in series
<desrt> tepsipakki; he has updated the patch since i last tested it.  i'm trying the latest version to make sure it still works.
<geser> keescook: can you look at bug #96712 and bug #96723 and ACK them? thanks.
<tepsipakki> oh, that backfill-bg -patch was already re-enabled
<mooey> hm. is the apport retracing service working?
<mooey> i've just tagged a few bugs and its removing the tag but not actually attaching anything to the bug report
<geser> there are bugs with retrace info, so it should work
<mooey> it seems to not like bug 96681, but 96691 and bug 96718. i've tried three and all three failed
<tepsipakki> mjg59, desrt: I could upload the server without the new composite patch?
<tepsipakki> or leave it for the morning (it's 02:27 here :) and include that patch from keithp
<mjg59> tepsipakki: I'm easy with either
<mjg59> I'll upload compiz tonight (assuming this works)
<mjg59> I've done a test build of X here
<tepsipakki> I'm positive that the patch still works :)
<tepsipakki> hum, interesting commits in xserver master.. adjustments to the I2C timeouts
<tepsipakki> should make the DDC probing more robust
<mjg59> tepsipakki: Yeah, works fine here
<tepsipakki> nice
<Amaranth> tepsipakki: wait, this makes compiz not need XAANoOffscreenPixmaps to not suck?
<shawarma> That's the idea. :-)
<Amaranth> tepsipakki: I love you. Have my babies.
<tepsipakki> Amaranth: sorry, I have two already :)
<Amaranth> Hehe
<Amaranth> I think we have about 20 dupes of that bug
<tepsipakki> can you tell me the #
<Amaranth> and beryl has already had two dupes of it filed since it made it into universe
<Amaranth> bug 89189
<ubotu> Malone bug 89189 in xorg "No text in save/dialog boxes" [Medium,Unconfirmed]  https://launchpad.net/bugs/89189
<tepsipakki> ah _that_ one :)
<tepsipakki> I'll add it to the changelog
<Amaranth> someone will have to patch beryl too ;)
<shawarma> Amaranth: It needs a patch in the composite manager too it seems.
<tepsipakki> I'll just upload xorg-server_1.2.0-3ubuntu5 now so we get that fix out of the door
<mjg59> Hm.
<mjg59> So, why can't I trigger cube operations any more?
<tepsipakki> mjg59: they haven't worked for me since I can remember
<Amaranth> do you have the keybinding plugin loaded?
<mjg59> Amaranth: Yup
<Amaranth> that thing should provide the largedesktop feature so it conflicts with cube and plane
<Amaranth> well, rotate and plane
<mjg59> Hm.
<mjg59> "largedesktop feature"?
<Amaranth> afaik it's only purpose is making ctrl-alt-left/right work for workspaces
<Amaranth> yeah, in compiz if two plugins provide the same "feature" it won't let you have them loaded at the time
<mjg59> No, that doesn't seem to be it
<tepsipakki> oh, right
<mjg59> It's a bit awkward given that we have the "cube" checkbox in desktop-effects...
<tepsipakki> xorg-server uploaded
<Amaranth> mjg59: right, desktop-effects does not cope with workspaces
<Amaranth> it needs to set number_of_desktops to 1 and hsize to 4, it assumes those are done
<shawarma> mjg59: I assume you have just one desktop and hsize is 4?
<Amaranth> there was someone working on a patch, was letting him do it so maybe he'd do more patches :)
<shawarma> mjg59: there's a but about it already. 2 sec.
<Amaranth> bug 89786
<ubotu> Malone bug 89786 in desktop-effects "Desktop-effect does not enable cube" [Medium,In progress]  https://launchpad.net/bugs/89786
<shawarma> right.
<shawarma> :-)
<mjg59> shawarma: Right, that's it
<tepsipakki> ok, time to get some sleep, night all ->
<shawarma> It weird, actually. I've never gotten used to multiple desktop until they were put on a cube. :-) Now I can't live without them.
<keescook> geser: thanks for filing those, I've confirmed them and added some comments
<Amaranth> shawarma: with a patch from the beryl folks (taken with permission) we might be able to have cube on by default
<Burgwork> Amaranth: cube by default if it means no workspaces is a bad thing
<Amaranth> shawarma: it maps workspaces to viewports so when you have something on workspace 2 in metacity it'll go to viewport 2 when you start compiz
<Amaranth> Burgwork: what i just said to shawarma :)
<Burgwork> does it deal with the task bar as well?
<Amaranth> the task bar works fine?
<Burgwork> I found viewports to be extremely suboptimal
<Amaranth> oh, you mean when you right click on the window list
<Burgwork> does the task bar only show windows on the current viewport?
<Amaranth> oh, that, yes
<Burgwork> basically, it needs to act and work like metacity
<Amaranth> the only thing you lose is "Move to Workspace X" options in right click
<Amaranth> i have a patch for that too but it breaks ABI so it needs to get into libwnck upstream first
<Burgwork> ah
<Amaranth> i also have a plugin to do edge resistance without wobbly
<Amaranth> it's almost but not quite like metacity's
<Amaranth> that's a port of a beryl plugin thought, not my doing :)
<Amaranth> alright to use though, plugins can have whatever license they want
<Burgwork> almost but not quite nothing like metacity :)
<Amaranth> heh
<Amaranth> i think the only real difference between metacity and the snap plugin when you put it in edge resistance mode is that it doesn't pull windows off without resistance after you snap them together
<shawarma> Amaranth: Sound shiny!
<shawarma> Amaranth: Sounds shiny, even.
<Amaranth> it's in bug 73700 but i got scared when i tried doing a debdiff so it's just the .c file
<ubotu> Malone bug 73700 in compiz "Lacks edge resistence" [Low,Confirmed]  https://launchpad.net/bugs/73700
<Amaranth> i think the only "big" problem we have left is java apps
<Amaranth> oh, and drivers sucking with Xv
<zyga> Amaranth: what is the problem with java apps?
<Amaranth> they show up all white when compiz is running
<Amaranth> i think it's swing or something
<Amaranth> i don't know the details, i don't use java apps
<shawarma> Amaranth: Does that include applets, too?
<zyga> Amaranth: does it affect 1.6 or just 1.5 ?
<zyga> (java)
<Amaranth> shawarma: i don't think so, they don't use swing do they?
<supervillain> yay, 16 more hours had been added to the SoC deadline!
<Amaranth> zyga: i dunno :)
<shawarma> Amaranth: No idea. :-)
<zyga> Amaranth: applets can use swing, many do
<Amaranth> zyga: run compiz and test them ;)
<zyga> Amaranth: I cannot, I'm evil now :/
<zyga> I only use ubuntu on servers
<mpt> aaaaaaaaaaa
<mpt> asac, hi
<mpt> asac, how on earth did you end up with "upstream confirmed bugs are 'In Progress' for us"? :-)
<mpt> that's not even slightly true
<LaserJock> mpt: makes sense to me if they're working on it
<mpt> LaserJock, but they're not
<LaserJock> hmm, still make some sense but I probably wouldn't have bothered
<LaserJock> I need to work on my bug report skills, I'm kinda lazy. Things tend to go from Unconfirmed to Fix Released
<mpt> In this particular case, no developer has done anything about the bug since it was reported nearly six years ago
<mpt> LaserJock, that's fine, there's no need to do unnecessary virtual paperwork
<LaserJock> well, except users get a little upset
<LaserJock> when there's no action
<mpt> right
<mpt> It's a form of communication
<mpt> So instead of "no need" I should have said "no need from Launchpad's point of view"
<mpt> There may be from other users' point of view, though
<LaserJock> right
<mpt> e.g. marking a bug as In Progress says "don't bother trying to fix it yourself, someone else is already doing it"
<wick2o> hello
<wick2o> anyone around? 
<wick2o> i remastered the install cd and have a working 100% preseeded cd with a custom "main"
<wick2o> added a few packages (openvpn, joe + a few others)
<wick2o> now that i have that working, i want to update the cd so i dont need to apt-get dist-update after the install
<wick2o> is it really as simple as downloading the new packages and deleting the old versions?
<wick2o> even with the restricted linux-server and the main linux-server-src ?
<Amaranth> i thought bug 96430 was rejected
<ubotu> Malone bug 96430 in linux-restricted-modules-2.6.20 "MASTER: Request for new-legacy nvidia drivers (9631)" [Medium,Confirmed]  https://launchpad.net/bugs/96430
<desrt> oh god
<mjg59> Amaranth: Well, restricted-manager does need updating to deal
<desrt> so check it out.  i just bought a new mainboard.  two actually.
<Amaranth> mjg59: to install legacy instead of glx
<desrt> http://www.intel.com/products/motherboard/DG965MQ/index.htm
<mjg59> Yup
<Amaranth> isn't that just a rebuild?
<Amaranth> i thought it built that list dynamically
<desrt> onboard dvi.  intel gma x3000.  life is good.
<mjg59> It comes with firewire?
<desrt> yup
<desrt> one out the back plus an internal pin header
<desrt> see also: 8gb memory and 6 sata ports
<desrt> nvidia and ati can both suck it.
<Amaranth> desrt: *boing*
<ajmitch> ah nice, free drivers & all
<Amaranth> dude you can use blur in compiz with that thing ;)
<ajmitch> wow ;)
<desrt> ya.  it's a freakin' sweet board
* ajmitch wouldn't mind one
<desrt> buy one.  junk your nvidia card.
<ajmitch> and the rest of my hardware
<desrt> my p4 3.0ghz is getting slow these days.  time to move up :p
<ajmitch> since I have an amd64 (socket 939), so ddr ram, etc
<ajmitch> hm, nice cheap board too
* desrt watches #ubuntu-devel buy new computers
<desrt> (all thanks to matthew having a hissy fit in livejournal)
<ajmitch> hah
<ajmitch> nah my geforce 6600 isn't legacy (yet) :)
<desrt> wait until next release :)
<desrt> nvidia is gonna phase out cards nice and gradually in order that we are required to keep 10 different legacy patches
<desrt> *packages
<ajmitch> hopefully nouveau will be a little bit further along by then :)
<ajmitch> I'm happy to go without 3d for awhile
<desrt> hopefully nvidia will be funding nouveau by then
<ajmitch> hah
<ajmitch> you can hope
<desrt> i wouldn't "hah" too hard
<desrt> there will come a point where nouveau will look like a rather attrative alternative to continuing to maintain their binary cludge
<ajmitch> though their binary kludge is meant to be unified across platforms (somehow)
<desrt> i wonder to what extend that's actually true
<Amaranth> a really awesome abstraction layer?
<Amaranth> all their functions are named __nv00000005
<ajmitch> given the differences in features, I wonder
<desrt> anyway... fun conversation but now i've got to go shoot myself in the head
<desrt> cheerio.
<Amaranth> what, more gnome-panel stuff? ;)
<hugomelo> BenC, I sent you a new proposal
<hugomelo> BenC, please, read it
<jamesh> doko: I don't suppose you've had a chance to look at that python-subversion bug?
<doko> jamesh: sorry, not yet. just verified that I still see it with 1.4.3 on ubuntu
<Hobbsee> what would be the opinion on puttign 915resolution in main, and maybe installing it on the cd?
<jamesh> Hobbsee: it should get obsoleted soon
<jamesh> by the new intel driver modesetting branch
<Hobbsee> jamesh: that's soon.  this is now.
<StevenK> WBy what?
* Hobbsee should relaly try that branch again
<jamesh> StevenK: the new version of the Intel driver does not use the BIOS for mode setting
<jamesh> so you don't need to patch the modes in the video bios if they are wrong
<StevenK> Is soon before Fiesty?
<jamesh> and it should work on systems without a PC video bios
<Hobbsee> well, preferably.
<jamesh> StevenK: probably not
<jamesh> keithp's demo of his work at linux.conf.au was pretty impressive
<StevenK> Then maybe we want to promote 915resolution for Feisty, and then demote it back for Feisty+1?
<StevenK> Hrm, I've been meaning to finish watching Keith's LCA talk.
<StevenK> That's the "we've managed to get the video driver autodetecting all the time" ?
<jamesh> well, he did say that having it detect VGA plug/unplug wasn't really desirable with current laptops
<jamesh> since it essentially chewed up a watt of power to have the corresponding hardware on
<StevenK> So you get it to start detecting when you hit the video change button?
<jamesh> maybe
<ajmitch> a watt, just for that?
<jamesh> ajmitch: the VGA hardware takes about that much power, yes
<jamesh> ajmitch: it needs to be on to detect if a monitor is plugged in, but is usually off because it isn't needed
<Amaranth> so
<Amaranth> i've got this ati package that i _think_ makes it possible to suspend/resume with compiz running
<Amaranth> but i don't own ati hardware
<Amaranth> anyone wanna test? :)
<Amaranth> it's just a patch from upstream git, i'm not going to break your video card :)
* StevenK doesn't own any ATI hardware.
<Burgundavia> sadly my ati hardware is at my gfs house
<AndrewB> Hmm I am looking at https://wiki.ubuntu.com/Testing/InstallMethods and things look easy.. only where do I document this information to?
<StevenK> Burgundavia: All the more reason to visit her?
<Burgundavia> it is 11pm at night
<StevenK> Heh
<StevenK> "No no, I'm not here to see you, I want my laptop."
<Burgundavia> I have my laptop
<Burgundavia> my desktop is my ati machine
<StevenK> I was guessing what contained ATI hardware.
<Amaranth> anyway, debdiff is attached to bug 90740 if someone wants to test it
<ubotu> Malone bug 90740 in xserver-xorg-video-ati "gtk-window-decorator corruption after resume from sleep" [Undecided,In progress]  https://launchpad.net/bugs/90740
<sladen> StevenK: the -modesetting driver is in universe
<dholbach> good morning
<fabbione> cjwatson:    * Add scsi-firmware to cdrom and hd-media images. <- does that propagate to netboot too?
<pitti> Good morning
<Hobbsee> hey pitti!
<tepsipakki> fabbione: oh, you assigned 96764 to Colin, but I marked it as dupe of 94786. I'll assign that instead :)
<Burgundavia> tepsipakki: it was you that sent me that "group" hack awhile back, no?
<tepsipakki> pam_group?
<ajmitch> Burgundavia: what did it do?
<Burgundavia> let me dig through my work email
<tepsipakki> oh
<tepsipakki> don't remember, sorry :)
<Burgundavia> basically it assigned ldap users to local groups, such as cdrom, etc. so that they go access to them
<tepsipakki> so it was pam_group
<fabbione> tepsipakki: ok please don't mess it up.
<Burgundavia> tepsipakki: i thought it was you
<tepsipakki> Burgundavia: yep.. so it's working for you?-)
<Burgundavia> I haven't put it into product due to an office move and my other hat, marketing, eating up too much of my time
<Burgundavia> oh, and an asterisk server that believes uptime should be measured in hours
<ajmitch> heh
<ajmitch> looks like pam_group will need packaged
<ajmitch> or not
<Burgundavia> hey, it is 2 year old cvs code running on White Box EL 3
<tepsipakki> it's included
<tepsipakki> ajmitch: ^^
<ajmitch> part of standard pam, how useful
<tepsipakki> heh
<ajmitch> yeah, apt-cache search didn't give me anything, I thought it would have been an additional module :)
<Burgundavia> ajmitch:  you are now on the planet
<ajmitch> lucky me
* ajmitch looks for the vile lies & slander
<ajmitch> hm, it's not really a new tool, it's just one where I'm trying to fix the UI & functionality
<Burgundavia> if it isn't in production yet, it is new
<ajmitch> true
<Burgundavia> work with your marketing person now, ajmitch :)
<ajmitch> hah
<Burgundavia> oh, btw, is that code in bzr/git yet
<Burgundavia> ?
<ajmitch> sure
<ajmitch> doesn't the spec link to it?
<Burgundavia> same repo
<Burgundavia> ?
<Burgundavia> morning jono
<ajmitch> I'll push the latest to the ubuntu-dev copy of it
<ajmitch> hey jono 
<Amaranth> tepsipakki: the debdiff in bug 90740 fixes the bug according to the reporter, just need someone to upload
<ubotu> Malone bug 90740 in xserver-xorg-video-ati "gtk-window-decorator corruption after resume from sleep" [Undecided,In progress]  https://launchpad.net/bugs/90740
<tepsipakki> Amaranth: ok, thanks
<tepsipakki> Amaranth: uploaded
<Amaranth> awesome, thanks
<Amaranth> that's two huge compiz-related bugs fixed today :)
<cjwatson> fabbione: netboot never needed that in the first place; you don't need scsi-firmware in the initrd to get more udebs from the network
<Burgundavia> cjwatson: you don't work in the london office, do you?
<cjwatson> Burgundavia: no
<anti_pop> did you notice that "nv" and "nvidia" is broken for most nvidia users at the moment (correct me if i am wrong)
<tepsipakki> anti_pop: why should nv be broken?
<Burgundavia> bugger. I need to get a hold of Chris Kenyon. I was supposed to have a phone conversation with him today and it is getting close to 2 am her
<cjwatson> experience suggests that when commuting to London it's very rare for me to manage to get in before 10:00, and that involves waking up around 6:00
<anti_pop> http://ubuntuforums.org/showthread.php?t=394549
<anti_pop> https://launchpad.net/ubuntu/+bug/96833
<ubotu> Malone bug 96833 in Ubuntu "Blank screen with the latest nv drivers" [Undecided,Confirmed]  
<Burgundavia> right
<anti_pop> latest upgrades broke that for me
<Burgundavia> I have seen English traffic and am glad I don;t live there
<Mithrandir> Burgundavia: see privmsg
<Burgundavia> got it
<tepsipakki> anti_pop: there hasn't been an update of nv since the beta
<fabbione> cjwatson: hmm ok.. i will check again because IIRC i saw the warnings there too..
<anti_pop> but something concerning xorg or x or whatever i think
<cjwatson> fabbione: netboot doesn't have disk drivers in the initrd, in general.
<ajmitch> Burgundavia: ah, you linked to the images on my system directly, in your blog post?
<Burgundavia> ajmitch: of course I did. I can fix that, if your machine is busy dying right now
<ajmitch> Burgundavia: it's interesting seeing so many hits on it
<ajmitch> a couple of hits every few seconds
* ajmitch isn't noticing lag, but it's on my dsl line
<fabbione> cjwatson: yeps.. i still want to recheck tho.. it won't cost you anything :)
<Burgundavia> ajmitch: when I linked an image on my home server to something on the UWN, I got hits all night. Unfortunately I couldn't sleep because the hdd was too noisy
<ajmitch> Burgundavia: they're only a few KB
<Amaranth> those screenshots were taken when compiz was running :)
<tepsipakki> anti_pop: eh, that bug reporter has nvidia options in the conf
<Amaranth> ajmitch: oh, and that's some awesome stuff there
<anti_pop> i had not and its not working
<ajmitch> Amaranth: hm, how can you tell? ;)
<tepsipakki> anti_pop: a log would be nice
<Amaranth> ajmitch: no window decorations
<Amaranth> gnome-screensaver needs to do a little extra work or something to get the decorations too
<ajmitch> heh
<anti_pop> tepsipakki, ok i edit my xorg to "nv" (atm "vesa") and post which log (sorry, im not that used to stuff like that)
<Amaranth> iirc it makes an incorrect assumption about the way it should work but actually has code to do the right thing in there
<Amaranth> so it's just a matter of making it realize it needs to use it
<tepsipakki> anti_pop: ok, /var/log/Xorg.0.log
<tepsipakki> anti_pop: and your xorg.conf too
<anti_pop> but i wont be able to go to a terminal when using nv
<tepsipakki> how so?
<tepsipakki> anti_pop: you can't change the virtual terminal? (ctrl+alt+F1)
<anti_pop> when i boot with xorg.conf containing "nv", it ends up in a black screen, and im not able to lauch a terminal by alt+ctrl+F1
<anti_pop> so i'd have to change to "vesa" again, and that would overwrite the logs, right ?
<Chipzz> anti_pop: ctrl-alt-backspace should kill your X?
<anti_pop> doesnt
<tepsipakki> anti_pop: true, but the old log would be Xorg.0.log.old
<anti_pop> ok
<ajmitch> Burgundavia: 533 hits so far
<ajmitch> seems that planet is popular
<anti_pop> then ill reconfigure xserver-xorg and use nv and reboot and then post the log
<tepsipakki> anti_pop: just for amusement, try moving xorg.conf aside and see what happens
<anti_pop> uh
<anti_pop> ok
<pitti> doko: this small hack http://pastebin.ca/411815 is required to make pycentral work with fakechroot; do you think it is too evil to be uploaded to feisty proper?
<doko> pitti: don't see a reason not to upload; does it still work without fakechroot?
<pitti> doko: the normal case is that the os.unlink fails because fn2 doesn't exist
<pitti> doko: I'll do a few more tests, of course, but so far yes (due to except: pass)
<doko> ok
<anti_pop> tepsipakki, i did the following
<anti_pop> putting my xorg aside, restarted x -> blackscreen, not able to go to terminal
<anti_pop> dpkg-reconfigured to "nv", rebooted (wrote down time to identify correct log) -> blackscreen, no terminal..
<anti_pop> reconfigured to vesa, im in x again
<pitti> doko: yep, works fine in all cases here; I added a few printfs to the 'except:' clause, and it's properly caught and pass'ed
<pitti> doko: so, you are fine with me uploading this?
<doko> pitti: sure
<pitti> doko: thanks
<anti_pop> in which folder do i find xorg.0.log or whatever its called ?
<zyga> anti_pop: /var/log/
<anti_pop> does this folder contain only files from actual boot ?
<pitti> anti_pop: #ubuntu, please; and no, it has logs from previous boots as well
<anti_pop> pitti, some guy in here requested a log, i try to do that and will leave
<pitti> anti_pop: oh, ok; you don't need to leave, don't worry; it's just our attempt to keep the channel free of support questions :)
<tepsipakki> anti_pop: attach it to that bug
<anti_pop> ok i think i did find the right log and will do so
<giangy> 'morning
<pitti> Mithrandir: do you remember approving gs-esp 8.15.4 for feisty? (I'm currently processing the outstanding package sponsoring from Till)
<pitti> Mithrandir: oh, nevermind, that's already in feisty
<Mithrandir> pitti: yes, I did
<mooey> pitti: is the apport retracing service working at the moment?
<pitti> mooey: it should work again, yes; I need to re-tag some bugs which were untagged, but not retraced due to chroot breakage tonight
* pitti will do that now
* Mithrandir keeps thinking it's wednesday
<mooey> pitti: ah, excellent :-) theres a few bugs that failed listed in bug 96903
<ubotu> Malone bug 96903 in apport "apport retracing service is not retracing bugs" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96903
<pitti> Mithrandir: mind you, summer time is +1 hour, not +1 day :-P
<Mithrandir> pitti: indeed
<pitti> mooey: yep, exactly those that my current script figured out
<mooey> pitti: thanks, all retraced now :)
<pitti> mooey: oh, already?
<mooey> pitti: all of the i386 bugs, yep :)
<cjwatson> yow, raid tests in vmware are hard on the disk space
<fabbione> cjwatson: eheheh
<cjwatson> maybe I should just get a 200 squillion gigabyte drive for that machine
<fabbione> cjwatson: you will endup like me today with that setup :)
<cjwatson> should only cost about 5 pence these days
<Mithrandir> it's probably cost you about one beer.
<fabbione> cjwatson: if you have room, i can ship you my SAN with tons of FC-HBA controllers :)
<cjwatson> actually, if I got two of them I could find out if that BIOS does dmraid
<Mithrandir> fabbione: houses in the UK doesn't need that kind of heating.
<fabbione> Mithrandir: i didn't specify it needs to be at home :) just space :)
<maswan> Mithrandir: sure they do, they haven't discovered insulation yet. ;P
<Mithrandir> I didn't specify "home", I said "house".
<Mithrandir> :-P
<fabbione> ROFL
<tepsipakki> fabbione: sorry to disturb you, but in xorg changelog I saw that you made a special case for elographics. Could you take a look at bug 89590?
<ubotu> Malone bug 89590 in xorg "Feisty doesn't recognize 17" LCD screen" [Medium,Confirmed]  https://launchpad.net/bugs/89590
<fabbione> tepsipakki: i think you can remove that special case safely now
<tepsipakki> fabbione: woohoo :)
<fabbione> let me check again
<tepsipakki> please do
<tepsipakki> in that bug the reporter has a chipset which matches that special case
<fabbione> tepsipakki: yes i see
<fabbione> i suggest you do this way:
<fabbione> if we hit the special case.. try to xresprobe or whatever is called now
<fabbione> if there are data coming from xresprobe then skip the special case
<fabbione> if there are no data, use the special case
<fabbione> the other solution is to remove the special case completely, but it kind of sucks because it was the only touch screen monitor we could configure out of the box :)
<fabbione> anyway your call.. i don't care either way
<fabbione> that special case has been there since dapper i think
<tepsipakki> yes
<tepsipakki> I'll think about it
<fabbione> if you remove it, make sure to change dexconf too
<fabbione> IIRC the special case was handled there too
<fabbione> to create the touch screen input stanza
<tepsipakki> yes I saw that
<dholbach> ogra: I looked into bug 92648 - there are some questions you (or LaserJock) need to answer first
<ubotu> Malone bug 92648 in edubuntu-docs "no menu item for About Edubuntu" [Medium,Needs info]  https://launchpad.net/bugs/92648
<ogra> questions ?
* ogra looks
<dholbach> ogra: or rather 'open points'
<ogra> two items is fine, we dont need to hide our inheritance ...
<dholbach> ok :)
<dholbach> i'll upload it then
<ogra> whats the other "open point" ?
<dholbach> you just need to create the desktop file
<ogra> ah, k
<dholbach> ogra: gracias
<ogra> its there, jordan hanst given me the final package yet
<dholbach> ok
<ogra> *hasnt
<ogra> btw, all my icons from gdm are gone in edubuntu ? 
<ogra> what did chnage? 
<ogra> (with the most recent update)
<dholbach> kwwii should know
<ogra> oki
<dholbach> i was merely the upload bitch
<ajmitch> hah
<mneptok> dholbach: yes, but you're *our* upload bitch.
<kwwii_> lol
<ogra> hey kwwii 
<ogra> so
<ogra> in my gdm config i never defined a gtkrc ... did you change the gtkrc of the Human theme ? 
<kwwii> ogra: nope, no change in anything in the normal Human theme
<kwwii> ogra: all I added was a gtkrc for HumanCircle and that line in HumanList
<ogra> hmm
<ogra> why would that break my gdm which uses a totally different theme ? 
<kwwii> ogra: no idea ;-(
<ogra> i dont use and Human ...
<kwwii> ogra: what exactly is wrong?
<kwwii> ogra: and which theme are you basing yours on?
<ogra> edubuntu uses the Edubuntu Colrs theme, which didnt change sice two releases
<ogra> all icons in the gdm menu are missing here
<kwwii> then I would suggest adding that line to the top of the gtkrc ;-)
<kwwii> and point it to the icon set you want to see there
* mneptok pops some corn to watch the big fight
<ogra> hmm, but why does gdm need it suddenly
<ogra> thats what concerns me ... i'm fine wih adding a line at the top of my gtkrc, i just want t know why :)
<fabbione> ogra: it's called evolution
<fabbione> more features.. more regressions :)
<ogra> fabbione, dont get mail apps in the game please :P
<kwwii> ogra: that line was in the Human theme already, I have no idea when it was added
<ogra> login managers are weird enough :)
<kwwii> ogra: all I did yesterday was to fix that same problem in the other two themes
<ogra> kwwii, ok, i'll look and die dumb :)
<mneptok> fabbione: i noticed Evolution usually has 3x the regressions for features, while evolution (small e) seems to have a somewhat better ratio.
<fabbione> mneptok: agreed.. and it takes longer to spot the errors.... like 100000 years from monkey to computer nerds
<pochu> Mithrandir: there seems not to be any i386 image in cdimage.u.c, for more than one hour, are they being built?
<cjwatson> pochu: I'm on it already
<cjwatson> soyuz bug
<pochu> oh, ok :)
<TheMuso> Is the fact that there is no consoles in the beta a bug, or is that intensional?
<TheMuso> s/there is/there are/
<Treenaks> it's a bug, I think
<Treenaks> if you boot it without the splash, you see there's a parse error in the /etc/event.d/tty* files
<TheMuso> Treenaks: Ah ok.
<cjwatson> TheMuso: known bug, fixed post-beta
<TheMuso> cjwatson: Thought as much, thanks.
<TheMuso> cjwatson: DId you by chance see the brltty bug I reported? Give me a sec and I'll get the bug number.
<cjwatson> no
<TheMuso> bug 91894
<ubotu> Malone bug 91894 in brltty "Brltty doesn't properly load when attempting to use serial braille display on live CD." [Undecided,Unconfirmed]  https://launchpad.net/bugs/91894
<cjwatson> meh
<cjwatson> TheMuso: fixing, thanks
<TheMuso> cjwatson: No problem.
<gnomefreak> is the dpkg problem known? sudo dpkg --configure -a returns dpkg: unknown option -o
<Hobbsee> gnomefreak: i cant reproduce that
<gnomefreak> i wasnt able to till this morning
<gnomefreak> Hobbsee: do you have anything waiting to be configed?
<gnomefreak> thats odd
<gnomefreak> now it works
<Hobbsee> gnomefreak: nope
<fabbione> ajmitch, slomo, siretart: ping?
<ajmitch> fabbione: pong
<fabbione> ajmitch: are you ok with a UVF exception for bzr-gtk_0.15.1.orig.tar.gz in universe?
<gnomefreak> Hobbsee: http://pastebin.ca/411955
<Hobbsee> odd
<gnomefreak> seems to only happen when there are errors with dpkg
<ajmitch> fabbione: bugfix release?
<fabbione> ajmitch: it's required to work with the new bzr that's making its way to the archive now
<fabbione>   * New upstream release
<fabbione>   * Bumped Depends on bzr to 0.11
<fabbione>   * Fixed Description in debian/control to include all commands
<ajmitch> right, looks sane
<fabbione> ok thanks
* ajmitch just had to grab the source
<fabbione> (btw i am only sponsoring this package for Etienne)
<fabbione> but i figured i asked before messing up
<fabbione> or Mithrandir would have killed me :P
<ajmitch> heh
* fabbione takes off for a bit
<gnomefreak> Hobbsee: i filed a bug anyway because IMO it should still error for -a not -o
<mvo> cjwatson: in the meta-packages we seem to not enfore a kernel. is that a deliberate decision?
<lexual> is there an ubiquity irc channel?
<asac> could someone please NEW firefox?
<Hobbsee> lexual: cjwatson is hte main person on it
<Fujitsu> asac: It isn't NEW, surely...
<asac> firefox-libthai
<ajmitch> Fujitsu: new binary package
<asac> is new bin package
<Fujitsu> Ah.
<Mithrandir> asac: I can do it
<lexual> cjwatson: is it possible to start ubiquity, and provide which mirror to use for /etc/apt/sources.list ?
<asac> Mithrandir: cool. thanks ... hope this is all for now then :)
<Mithrandir> asac: is it intentionally that firefox-libthai doesn't depend on firefox?
<asac> ups wtf
<Mithrandir> I'll be fine with accepting it without that fix, but it looks wrong.
<Mithrandir> (accepted)
<asac> will fix it ... thanks for moving in.
<cjwatson> mvo: yes.
<cjwatson> lexual: you may be able to preseed the mirror in the same way you'd preseed the alternate installer (see the installation guide on help.ubuntu.com) but it's otherwise entirely undocumented and untested
<cjwatson> lexual: channel is #ubuntu-installer, BTW
<TheMuso> Mithrandir: When you get a chance, I reported bug 91868, to fix an accessibility bug for the live CD. If you could look at it and merge the fix, that would be great. Thanks.
<ubotu> Malone bug 91868 in casper "Magnifier does not start from accessibility menu due to incorrectly referenced file." [Undecided,Unconfirmed]  https://launchpad.net/bugs/91868
<Mithrandir> sure
<bddebian> Heya
<cjwatson> argh, trying to reproduce bug 80938 is hurting my brain
<ubotu> Malone bug 80938 in ubiquity "MASTER: do_remove BrokenCount assertion can fail" [Medium,Confirmed]  https://launchpad.net/bugs/80938
<_ion> Please excuse my ignorance, but what's this "MASTER:" i'm seeing in front of some bug titles?
<cjwatson> informal convention to help maintainers remember which instance of frequently-reported bugs to dup new reports against
<cjwatson> I picked itt up from the mozilla team
<_ion> All right.
<cjwatson> pochu: i386 images available now, at least for Ubuntu
<pochu> cjwatson: cool, thanks!
<Hobbsee> that's a great idea!
<cjwatson> it's useful on packages with lots of bugs
<xhaker> doko, Keybuk any of you available to talk just a bit about GSoC work?
<doko> xhaker: sure, whats the matter?
<xhaker> Would you have access to the applications in google already? if not i could explain in a query
<xhaker> *i can*
<asac> mpt: ever done mozilla triaging?
<mpt> asac, I did it for three years (I was a QA contact at b.m.o)
<asac> mpt: cool ... then i don't understand why you don't like in progress for upstream submitted bugs.
<mpt> because In Progress means "Don't worry about trying to fix this one, someone's already working on it"
<asac> mpt: yeah ... but that's the truth ... (you should take care that upstream doesn't forget)
<mpt> I suppose Ubuntu Firefox is a special case, though, not being Free Software
<mpt> so even if someone came along with a fix for you, you'd send them upstream anyway
<asac> mpt: remember ... usually nobody comes along for firefox et al ...
<mpt> true
<asac> if one can fix firefox bugs et al they go upstream
<asac> so ... "in progress" for us :)
<asac> which means: mozilla team members should regularaly take care that upstream doesn't forget
<asac> but move the bug from confirmed radar
<asac> which means: "This needs work ... and info on what work is needed is available"
<asac> mpt: all i want to say is:
<mpt> This is my fault, again
<asac> launchpad is not a one thing fits all 
<mpt> A long time ago, I was supposed to split "Rejected" into "Not a Bug" and "Not For Us"
<mpt> where "Not For Us" for a distro would mean "we're not going to fix it here, go upstream"
<mpt> and "Not For Us" for upstream would mean "it's not our problem, go to the distro"
<StevenK> mpt: The problem there is that it changes meanings depending on context. Surely Launchpad would prefer to be consistent?
<mpt> so you'd be able to use "Not For Us" instead of "In Progress" for bugs that you weren't actually ever going to fix yourself
<asac> yeah ... but "not for us" means (as you said about in progress" we don't care
<asac> which is not true
<asac> we want to help users to get a point upstream
<asac> so we should take care that it gets attention ... from time to time
<mpt> StevenK, it would be more consistent than the current situation. (That doesn't necessarily mean it would be a good idea.)
<StevenK> But still changes meanings depending on context.
<StevenK> Well, it does and it doesn't.
<mpt> In both cases it would mean "This is a problem, but it isn't our problem"
* StevenK is confused and tired.
<mpt> Another example is an app that crashes because of a bug in a library
<StevenK> mpt: Perhaps you need to ignore my tired goings on. :-)
<mpt> no, they're interesting
* mpt should really be asleep too
* StevenK is waiting for a rebuild of his desktop machine to finish.
<mpt> Maybe it should be called "Elsewhere" instead...
<mpt> but then eventually I'd like an advanced search operator called "elsewhere", so that could be confusing
<StevenK> Rejected with an explantion is just as good, surely?
<mpt> so you could search for "status:confirmed elsewhere:fixed" to find fixes that you can pick up (e.g. from another distro)
<StevenK> "This is not a bug, bugger" status => Rejected. "This is a problem, but now ours, go talk to $NICE_PEOPLE over there." status => Rejected
<StevenK> s/bugger/bugger off/
<mpt> StevenK, the difference between "Not a Bug" and "Not For Us" search-wise is that "Not a Bug" would not show up in search results by default (like "Rejected" doesn't now)
<StevenK> Where as Not For Us would?
<mpt> but "Not For Us" bugs *would* show up, if they were also open anywhere else
<mpt> because that would indicate they were still a valid problem
<StevenK> My problem is Not For Us keeps reminding me of Debian's buildd network
<zakame> hmmm, which package controls /dev/mapper/* ?
<StevenK> zakame: Feisty or Edgy?
<mpt> StevenK, I'm not familiar with that
* mpt reads http://www.debian.org/devel/buildd/wanna-build-states
<StevenK> mpt: Ah. The Debian buildd network has a concept of Not-For-Us. Stuff that the arch in question doesn't have to bother about building, for example, grub on sparc or such like.
<asac> mpt: i just want to emphasize that while you (launchpad team) might think that you know the single best way to do things, you probably don't.
<asac> StevenK: No-For-Us ... is not for U.S. 
<StevenK> It'd be nice if LP grew something like that, but less manual.
<asac> ah :)
<mpt> asac, sure, and I'm not criticizing you at all, I'm trying to work out how Launchpad hasn't fit your work, so I can figure out how Launchpad might improve
<asac> mpt: will you be in spain?
<mpt> asac, not that I know of, alas
<asac> hmmm ... ok
<mpt> It would be good to sit down and chat about how you do things
<mpt> and how Ubiquity bugs are handled
<mpt> and Xorg bugs
<mpt> etc
<asac> mpt: definitly.
<Mithrandir> mpt: it would be good if LP was better for the release manager too.
<asac> mpt: i think the approach will be: allow individualization of bug tracker by driver team or something
<mpt> asac, maybe, but that would remove a fair chunk of the point of sharing a bug tracker in the first place
<mpt> which is that you can be notified when a bug has been fixed elsewhere
<Robot101> has anyone else seen cupsd start ~50 dbus-daemons?
<mpt> whether or not elsewhere is using Launchpad themselves
<mpt> and then grab the fix from them, and save yourself effort that way.
<asac> but what has this to do with package states?
<mpt> Because if you have custom statuses, how does Launchpad know which ones count as fixed?
<asac> i see that this is upstream integration feature ... imo the states from upstream are mapped pretty well atm.
<mpt> Yes, but what if upstream is using Launchpad? :-D
<asac> yeah ... we could agree on a set of final states (fixed states)
<mpt> That's a possibility
<asac> i think the problem here are the intermediate states
<asac> e.g. states that drive the workflow
<asac> simple packages just go from unconfirmed -> confirmed -> fixed ... others might have various steps in between
<mpt> or let people checkbox which of their statuses count as Fixed for the purposes of sharing (e.g. Fix Committed, Fix Verified, Fix Uploaded...)
<asac> probably ... but as i said ... we could have a minimal set of states that are common
<asac> i think nobody has a problem with Fix Released for instance
<mpt> oh, yes they do ;-)
<asac> imo it would help if we could allow teams just to introduce substates
<asac> e.g. in launchpad we have unconfirmed -> needs info -> confirmed -> In progress -> Fixed
<asac> now teams can say ... I want to refine state Needs Info for me
<mpt> or just have Open, Rejected, and Fixed, and everything else is tags
<asac> yeah ... however tags should then be associated with states as well
<StevenK> mpt: Speaking of tags ... launchpad needs to hide tags that are not referenced by any package.
<mpt> StevenK, known bug
<asac> -> so substates again
<mpt> but thanks
<StevenK> mpt: Ah, but is it reported? :-)
<asac> so some tags are substates and some are something else
<asac> imo that would mix concepts
<mpt> StevenK, bug 59154
<ubotu> Malone bug 59154 in malone "Don't show all tags on the bug listing page" [Medium,Confirmed]  https://launchpad.net/bugs/59154
<StevenK> Ah, nice
<asac> does it show any tags at all?
<asac> i haven't seen any ;)
<mpt> Only if you click the grey "Tags" bar
<asac> bug 59154 is one of the most important feature for me I guess
<asac> of course its not that important ... misinterpreted summary :)
* Hobbsee wonders if her message to ubuntu-devel got moderated
<neuralis> Hobbsee: the nvidia message made it through
<Hobbsee> neuralis: great.  i havent seen it yet
<mpt> asac, thanks again for your comments, they're very thought-provoking
<Hobbsee> ah, here it is
* mpt -> sleep
<asac> mpt: night
<mpt> (see bug 36059 if you're interested)
<ubotu> Malone bug 36059 in malone ""Rejected" should be split into "Not a Bug" and "Not For Us"" [Medium,Confirmed]  https://launchpad.net/bugs/36059
<asac> mpt: maybe lets talk about this tomorrow again .... i think it will take some time to get a common understanding of what is needed and what could be done to make launchpad the best ever :)
<asac> mpt: or later today? where are you based?
<cypher1> is Qt associated with KDE ?
<Hobbsee> ....
<StevenK> In as much as as GTK+ is associated with Gnome.
<tepsipakki> mjg59: ping, wacom
<mjg59> tepsipakki: Hi
<tepsipakki> howdy
<tepsipakki> mjg59: I'm looking at the various bugs about wacom, device naming et al
<tepsipakki> mjg59: I merged a new wacom-tools hoping that it might get past UVF, would you like to take a look?
<mjg59> tepsipakki: Sure. Can I see the debdiff?
<tepsipakki> yes, I'll put it somewhere first
<mjg59> Thanks
* dholbach hugs tepsipakki
* dholbach hugs mjg59 too
<_ion> pitti: Hmm, i just noticed something. The amd64 port of the nvidia driver doesn't seem to support every device the x86 port with the same version number supports. Additionally, in the amd64 port the device id '0000' is listed. The easiest fix to the first problem would be to generate the lists within the linux-restricted-modules source package, and '0000' can simply be ignored by nvidia_supported.
<pitti> _ion: I agree
<pitti> _ion: let's see what BenC thinks about integrating those scripts into l-r-m proper, to get nice modaliases
<BenC> pitti: I forgot to answer that email, but I'm all for it
<pitti> BenC: yay
<_ion> Very nice
<BenC> anything to make your life as easy as you've made mine :)
* dholbach hugs _ion
<_ion> benc: If you decide to include the 96xx driver in addition to the 71xx and 97xx drivers, the nvidia_supported script included in my patch already supports that. One just needs to list all the nvidia modules sorted by their version numbers in a decreasing order, something like sh nvidia/nvidia_supported .../nvidia/nv-kernel.o nvidia .../nvidia-96/nv-kernel.o nvidia_96 .../nvidia-71/nv-kernel.o nvidia_71 (whereas currently it is ...
<_ion> ... .../nvidia/nv-kernel.o nvidia .../nvidia-legacy/nv-kernel.o nvidia_legacy)
<_ion> My card happens to be among the ones that 97xx doesn't support anymore. :-)
<tepsipakki> mjg59: ok, needed to test it actually builds.. two debdiffs here: http://users.tkk.fi/~tjaalton/wacom/
<mjg59> tepsipakki: So the first is just the version update, the second is your fixes?
<tepsipakki> the first has it all
<mjg59> tepsipakki: Ah
<tepsipakki> or do you prefer it otherwise=
<tepsipakki> ?
<mjg59> No, that's fine
<mjg59> tepsipakki: Couple of things - we don't need setserial any moe
<mjg59> tepsipakki: And it's still /dev/wacom
<mjg59> Is that deliberate?
<tepsipakki> no.. where?
<mjg59> The init script
<tepsipakki> oh, do you think it could be /dev/input/wacom for serial and usb?
<tepsipakki> that was just copied from the old version
<mjg59> Arguably, yeah
<mjg59> Then the X setup would need fixing as well
<tepsipakki> yes
<mjg59> But then there'd be a chance of USB stuff just working
<tepsipakki> what a drag
<tepsipakki> :)
<Riddell> Mithrandir: no opinion on k3b UVFe yet?
<tepsipakki> mjg59: are the wacom-tools needed by the driver, in general? In the new version it's the driver which has the udev-rules.. but then again wacom-tools has the initscript..
<cypher1> is not there a Qt C++ UI compiler available in repos ?
<Riddell> cypher1: question for #kubuntu (but they're in the libqt4-dev and qt3-dev-tools packages)
<cypher1> Riddell, thanks!
<Mithrandir> Riddell: sorry, I totally forgot.  Can you prod me tomorrow during the day?
<tsmithe> pitti, are you around?
<Riddell> Mithrandir: ok
<Riddell> mvo: get my software-properties questions?
<pitti> tsmithe: hello
<tsmithe> pitti, when you rejected wired, which pdfs were you referring to? i ran over the tree, and could only find ./src/portaudio/docs/portaudio_icmc2001.pdf ./src/portaudio/src/hostapi/asio/Callback_adaptation_.pdf  and ./src/portaudio/src/hostapi/asio/Pa_ASIO.pdf, none of which i thought were included, as the sources built using the system's copy of portaudio. i may be wrong, but i'm a bit confused
<pitti> tsmithe: right, those
<pitti> tsmithe: right, but we cannot ship them in the source package without, well 'source'
<mvo> Riddell: let me check
<tsmithe> pitti, ahh. right
<tsmithe> i'll dfsg it, then
<pitti> tsmithe: i. e. inclusion not in terms of binary packages, but the orig.tar.gz
<tsmithe> and i guess i'll need an exception as well
<tsmithe> right?
<pitti> tsmithe: exception?
<tsmithe> as universe is new package frozen, is it not?
<Mithrandir> it is, yes.
<mvo> Riddell: I got two mails about the dist-upgrader, nothing about software-propoerties. when did you send it?
<tsmithe> ok. i don't get any bonus points as i had uploaded a bad version before the deadline, do i?
<mjg59> tepsipakki: wacom-tools is needed for tablet PCs at the moment
<mjg59> tepsipakki: Hm. I guess the initscript could be moved into the driver.
<Riddell> mvo: err yeah, that's what I ment, ignore me, my brain is funny yoday
<Riddell> today
<gnomefreak> pitti: is need-powerpc-retrtace down?
<pitti> gnomefreak: yes
<pitti> gnomefreak: it hanged in dpkg --unpack for godknowshowlong
<gnomefreak> ah ok and that is right tag right?
<pitti> gnomefreak: I stopped it and I rebuild it with the latest fixes as we speak
<pitti> gnomefreak: need-ppc-retrace
<gnomefreak> ah ok
<pitti> gnomefreak: we just had the same discussion with seb128 in #u-desktop
<gnomefreak> oops :(
<gnomefreak> sorry im not in there
<pitti> gnomefreak, seb128, dholbach: so, let's agree to ppc vs. powerpc
<gnomefreak> ppc
<pitti> powerpc is the canonical one, but ppc tag was there first
<gnomefreak> its easier to remember/type
<dholbach> we have <dholbach> 5 ppc, 7 powerpc
<dholbach> but i don't mind either way
<seb128> I don't care either way
<tepsipakki> mjg59: ok, thanks
<pitti> ok, then let me remove the 'transform dpkg --architecture powerpc to ppc' special case and use powerpc
<gnomefreak> truthfully me neither
<dholbach> pitti: retrace both :)
<seb128> pitti: WFM
<gnomefreak> :)
<pitti> dholbach: new special case :)
<gnomefreak> ok what one won? powerpc?
<pitti> gnomefreak: yes
<gnomefreak> ok cool those are tagged
<gnomefreak> its only feisty right?
<pitti> if I am to choose, I'm all for fewer special cases
<gnomefreak> i agree
<tepsipakki> mjg59: um, there is a newer upstream (0.7.6.4), it should fix at least a gimp crasher.. I'll build that too
<mjg59> tepsipakki: Good plan
<pitti> gnomefreak, dholbach: powerpc retracer is back to live, better than ever
<dholbach> pitti: you ROCK
<gnomefreak> ty pitti 
<_ion> pitti: Apparently there's actually something from nVidia with the PCI device ID 0000, and it only seems to exist on amd64 hardware, so it was not a mistake for the amd64 driver to list it.
<Keybuk> _ion: nvidia seem to use that for subsystem ids of their bridges
<_ion> Ok
<Riddell> infinity: any idea what's happened to kde4libs 3.80.3-0ubuntu2 on amd64?  it hasn't hit the archive yet despite building 22 hours ago
<cjwatson> probably stuck in failed-to-move
<cjwatson> aye, I'll resurrect it
<cjwatson> Riddell,infinity: done
<Riddell> cjwatson: cool, thanks
<PhinnFort> is the konsole-alpha (which allows real transparency in Konsole) planned to be included in feisty's version of konsole?
<giangy> PhinnFort: ask in #kubuntu-devel
<PhinnFort> ok
* PhinnFort was thinking up a really sarcastic comment, until he noticed the 'k'
<giangy> gh :)
<_MMA_> Hello guys. Ubuntu Studio is in the process of building our disks. We have a custom sound theme that conflicts with ubuntu-sounds. I noticed that a depend of ubuntu-sounds was GDM and a depend of ubuntu-sounds is ubuntu-desktop. This means if we wanted to use the GDM from Ubuntu we would have to pull Ubuntu-desktop and all that comes with it.
<_MMA_> As of now it looks like our only options to rebuild GDM without the ubuntu-sounds depend or see if the ubuntu-sounds depend could be removed from Ubuntu's GDM. Should I just post to the ML about this?
<supervillain> I think you need to create your own sound-theme package, and replace ubuntu-sounds build-depends requirements
<supervillain> I mean, gdm's requirements
<_MMA_> We have. Thats not the issue. In order to use GDM it depends on "ubuntu-sounds". Then that pulls "ubuntu-desktop"
<_MMA_> We arent using the "ubuntu-sounds" nor the  "ubuntu-desktop" packages.
<zyga> mvo: hey
<zyga> mvo: did you make any decisions?
<BenC> pitti: ping
<mvo> zyga: no, sorry. I'm busy with the release upgrader right now
<pitti> BenC: gnip
<zyga> mvo: okay, let's postpone this for +1 then
<zyga> we'll do it properly by then
<BenC> pitti: with the pci id lists produced, how does restricted-manager contend with multiple drivers matching a device?
<pitti> BenC: the current scripts take care to assign it to the 'prefered' driver
<pitti> BenC: e. g. if both nvidia and legacy support a given device, it is put into the nvidia list
<BenC> pitti: Ok...is there a plan to handle upgrades from edgy->feisty for cases where they need to drop down to new-legacy, or is that going to be a release note sort of thing?
<mvo> zyga: ok, this may mean we have to manually fix the gcc case
<pitti> BenC: I discussed this with mvo, we might come up with a plan and update-manager/restricted-manager magic to handle this case
<mvo> BenC: the release upgrader + release notes seems to be the only way to do this (at least that I can think of)
<mvo> bug #96486 is about this problem
<ubotu> Malone bug 96486 in update-manager "u-m should automatically install nvidia-glx-legacy if hardware requires it" [Medium,Confirmed]  https://launchpad.net/bugs/96486
<BenC> anything I need to do to ease this, or just drop the new stuff in...any info you'll need from me once this gets into the archive?
<zyga> mvo: not necessairly, as I said I have made full scan of main so if you agree we can just use 'old' current data for universe and use the new scanner for main, restricted and multiverse
<zyga> the new scanner works fine with g++ case
<mvo> BenC: what worries me is that people who not use the upgrader will be bitten by this. so solving this on a packaging level somehow would be really good, but I don't think that this is possible given the nature of the packages
<mjg59> mvo: I can't think of any way for it to be possible
<mjg59> We simply have no mechanism for expressing those dependencies
<BenC> mvo: The only thing I know to do for this case would be to leave nvidia package as 9631, and force people with new cards to install nvidia-new or something
<mvo> and we can't fold nvidia and nvidia-glx into one package of course
<BenC> people who are not supported by 9631 wont have an upgrade issue
<mvo> nvidia and nvidia-legacy of course
<mvo> hm, renaming is a interessting idea, how feasible would this be?
<pitti> mvo: it would be totally cool to merge both packages, and have the postinst detect which one is needed
<BenC> we could have nvidia (9631), nvidial-legacy (7xxx) and nvidia-new (97xx)
<pitti> BenC: that would only aggravate the problem in the future
<mvo> pitti: that might be good though, then we have some more time to deal with the issue :)
<BenC> the future looks bleak no matter how you slice it
<mjg59> Mm. I guess installing and then dpkg-diverting stuff based on PCI ID would be possible
<mjg59> If utterly insane
<mvo> evil, but ...
<BenC> mjg59: You thinking of including 9631+97xx in nvidia package and use magic to handle which one to use?
<_ion> nvidia-glx Provides: driver-pci-10de-0040, driver-pci-10de-0041, ...  nvidia-glx-legacy Provides: driver-pci-10de-0020, driver-pci-10de-0021, ... ;-)
<pitti> _ion: argh, no
<_ion> pitti: Note the smiley
<mjg59> BenC: Yeah
<pitti> _ion: oh, right
<pitti> now that l-r-m will ship the modaliases, postinst detection is relatively easy
<BenC> that would handle the current case and make things easier in the future for sure
<mvo> it sounds good too me if we can make it work reliable and it would help people upgrading in the more traditional way
<BenC> we could just build the nvidia.ko module based on boot-up detecting in l-r-m-c init script
<mvo> (which I expect will be a lot of people still)
<_ion> benc: That would be neat.
<BenC> we already link it on boot anyway, so adding detection and another stack of objects to link would be easy
<pitti> BenC: and I guess the diversion magic in the postinst would become quite messy
<mvo> BenC: is that enough? are/usr/lib/xorg/modules/libglx.so etc the same for nvidia-glx and -legacy?
<BenC> pitti: with that method we don't need diversions
<doko> do we have a common function, which prints out the name of the currently running video driver?
<pitti> BenC: for the libGL.so stuff?
<BenC> oh, libs...
<pitti> doko: I didn't find any
<BenC> we could use alternatives and set them in the script
<pitti> doko: however, the question 'which is the video driver that you need' is relatively easy to answer
<_ion> Perhaps /usr/lib/xorg/modules/drivers/drv_nvidia.so or whatever it was could be a link to one of drv_nvidia_{71xx,96xx,97xx}.so, and the link would be updated on bootup. The libGL stuff would be handled in same fashion.
<BenC> _ion: right, using alternatives to keep it package friendly
<pochu> heno: hi :) can you take a look at bug 97022? thanks ;)
<ubotu> Malone bug 97022 in Ubuntu "dasher should be added to assistive technology preferences " [Undecided,Unconfirmed]  https://launchpad.net/bugs/97022
<heno> yep
<doko> pitti: just wanting to set some environment when I find fglrx or nvidia running; of course a lsmod | grep -E '^(fglrx|nvidia)' is a simple minded solution
<pitti> doko: which should actually work, because you cannot modprobe them without xorg.conf using them
<mvo> BenC: what bug should I subscribe too keep myself updated on this?
<BenC> pitti: Ok, I'll try to have this nvidia combined package done by Friday (with a kernel upload) using alternatives to decide which one to enable
<pitti> carlos: ah, new langpacks ready from today; so these should be good?
<carlos> pitti: not yet, I still need to do some changes
<pitti> BenC: they'll use the brand new modalias lists?
<pitti> carlos: alrighty
<BenC> pitti: Yes
<pitti> cool
<pitti> BenC: you rock!
<BenC> pitti: I feel dirty :)
<pitti> tkamppeter: ping
<mvo> BenC: thanks a lot for taking care of the nvidia issue :) will you followup on ubuntu-devel? or should I do that?
<heno> pochu: done (rejected)
<_ion> benc: Does my patch seem to have any problems?
<BenC> mvo: I already did
<pochu> heno: thanks :)
<BenC> _ion: what patch?
<_ion> benc: The one i emailed. It generates the modules.alias override lists from the modules.
<mvo> thanks!
<wick2o> afternoon
<BenC> _ion: Ah, haven't checked it closely yet, but will this evening
<_ion> benc: All right.
<asac> mdz: you want to keep translate application & get help online in firefox menu for feisty?
<mdz> asac: most likely, yes.  at some point (perhaps UDS?) you ought to have an in-depth conversation with the Rosetta folks about what's necessary to get the server side worknig
<mdz> asac: is there a compelling reason to remove it (something other than the server side not being ready yet)?
<asac> afaik get help online is disabled for other apps as well now?
<asac> We could disable it for now and enable it in an update in case rosetta supports firefox at some point
<tkamppeter> pitti, pong
<asac> mdz: main reason would be to reduce possible user confusion :)
<tkamppeter> Some GNOME or XDG menu experts around here?
<tkamppeter> Where are menu entries saved when the user changes something with the menu editor (System -> Preferences -> Main Menu)?
<tkamppeter> Problem is bug 86893, the user seems to have a menu entry for HP Toolbox which is not from the HPLIP package.
<ubotu> Malone bug 86893 in hplip "[Feisty]  Clicking on HPLIP Toolbox in gnome menu does nothing" [Medium,Fix committed]  https://launchpad.net/bugs/86893
<zyga> tkamppeter: look for .local
<mdz> asac: er, it is?  it should not be
<zyga> tkamppeter: then check out what's there
<mdz> asac: it certainly is enabled here; is it not working on your system?
<asac> mdz: get help online?
<mdz> asac: oh, you mean specifically Get help online.  that's been removed from the generic menu stuff, but the hardcoded apps still seem to have it
<asac> mdz: so i think i can drop it as well for now :)
<mdz> asac: there's no question about firefox and rosetta; it needs to be supported
<mdz> asac: if it requires an update to enable it, I guess that's reasonable
<mdz> since it's likely to have a security update at that point anyway
<asac> ok ... so i will drop it for now. As soon as we have rosetta support we can switch it on.
<asac> mdz: you can bet on that :)
<tkamppeter> zyga, thank you very much.
<zyga> tkamppeter: no problem
<zyga> tkamppeter: you can find more information about this at freedesktop.org
<zyga> this is defined there
<tkamppeter> There is one problem (bug?) with the menu editor: If I only look into the properties of a menu entry without changing it, there is already a ~/.local/share/applications/*.desktop file created, which hides the system's *.desktop file and so prevents the user from getting access to an updated menu entry.
<tkamppeter> pitti, are you still there?
<pitti> tkamppeter: yes, partly
<tkamppeter> pitt, you wanted to talk with me?
<pitti> tkamppeter: can you please fix the file conflict in foo2zjs?
<tkamppeter> pitti, the new foo2zjs which I gave you for upload does not contain mscompress any more.
<pitti> tkamppeter: the current upgrade breaks because mscompress is installed as a dependency, but foo2zjs already ships that package
<pitti> s/package$/file/
<pitti> tkamppeter: i. e. mscompress is unpacked before foo2zjs is updated
<fabbione> Unpacking mscompress (from .../mscompress_0.3-2_i386.deb) ...
<fabbione> dpkg: error processing /var/cache/apt/archives/mscompress_0.3-2_i386.deb (--unpack):
<fabbione>  trying to overwrite `/usr/bin/msexpand', which is also in package foo2zjs
<tkamppeter> s/mscompress/msexpand/
<fabbione> pitti: ah you were just saying the same
<pitti> tkamppeter: the actual bug (shipping mscompress in /usr/bin by an unrelated package) is not reversible any more, so we now need a Conflicts/Replaces: on mscompress
<pitti> fabbione: right
<fabbione> i just noticed :)
<pitti> tkamppeter: right, msexpand
<tkamppeter> pitti, how can I solve this situation, I cannot change a package which is already on the user's systems?
<pitti> tkamppeter: mscompress now needs to Conflicts:/Replaces: foo2zjs (<< the current version)
<tkamppeter> This will make the update of mscompress trigger foo2zjs also being updated to the current version (the one without msexpand)?
<pitti> tkamppeter: no, it won't force the upgrade, and it doesn't need to
<pitti> tkamppeter: since mscompress and older foo2zjs really conflicted, this needs to be done anyway
<pitti> tkamppeter: hm, wait; it doesn't really help either
<pitti> tkamppeter: no, it does; (for upgrades which pull in mscompress)
<pitti> mscompress can hardly be installed already, so that's fine
<tkamppeter> So, pitti, I will set this conflict in the mscompress package then.
<pitti> tkamppeter: thanks
<pitti> this package could do with a rebuild anyway
<tkamppeter> But, pitti, did you really move it into main already? My mirror still pulled it from Universe.
<pitti> tkamppeter: today; mirrors usually need a day to catch up
<pitti> mscompress |      0.3-2 | http://de.archive.ubuntu.com feisty/universe Packages
<pitti> mscompress |      0.3-2 | http://archive.ubuntu.com feisty/main Packages
<tkamppeter> pitti, this package is not maintained upstream any more, so it is only rebuilt if someone complains about something in it, and no one at Ubuntu is really the maintainer of this package.
<tkamppeter> pitt, Germany seems to be faster than Portugal.
<pitti> tkamppeter: NB that de.ubuntu is still universe, too
<tkamppeter> Now I see, the other was archive..., the master server.
<zyga> I just noticed that rsync to archive.ubuntu.com asks me to register my mirror
<zyga> what is the purpose of registering a private mirror that is not publicly available?
<zyga> (I cannot even give anyone a mirror URL)
<mooey> which package has the nvidia restricted driver in it?
<pitti> mooey: nvidia-glx (libraries) and linux-restricted-modules (kenerl module)
<mooey> pitti: thanks
<seb128> mooey: do you want to open a bug about a card not supported after upgrade? because there is already a zillion of those
<Amaranth> please forward all nvidia bug reports to the black hole called nvnews forums ;)
<mooey> seb128: no sir, just reassigning bugs out of 'Ubuntu' :-)
<seb128> mooey: k
<mooey> it was to do with resolutions not being supported in newer drivers
<wick2o> I'm tring to update a ubuntu 6.06.1 install cd so i dont have to apt-get update at the end of the install...Is it as simple as downloading the new packages onto the cd and deleteing the old ones? perhaps updateing a symlink to the kernel dir to get an updated kernel as well?
<wick2o> i already have a working remaster using the instructions on the wiki
<gnomefreak> mvo_: you have a second?
<gnomefreak> mvo_: was ubuntu-restricted-extras not built for i386?
<mvo_> gnomefreak: it should be 
<mvo_> gnomefreak: looks ok to me
<gnomefreak> someone on i386 kernel gets the following error 
<gnomefreak> Ubuntu restricted extras cannot be installed on  your computer type (i386)
<mvo_> mpt: could you please proof-read http://paste.ubuntu-nl.org/12378/ ? its for peple that have nfs-imports but no nfs-common installed (that worked in edgy, dapper but does not work in feisty anymore). 
<mvo_> gnomefreak: can you please run "sudo apt-get install --simulate ubuntu-restricted-extras" and tell me the output (pastebn) 
<gnomefreak> its not my pc that had issues though
<gnomefreak> when he gets back if im still here ill have him run it on his -386
<mvo_> gnomefreak: the message in g-a-i is bad. I have seen the message when the real reason was that the package was uninstallable for some reason
<mvo_> gnomefreak: thanks, that would be cool. he can mail me the output 
<gnomefreak> ok he just got back
<gnomefreak> it wont install on -generic for him either :)
<mvo_> could someone please proof-read http://paste.ubuntu-nl.org/12378/  (and give good suggestions)
<mvo_> gnomefreak: the output of the apt-get command would be good :)
<gnomefreak> hes running it 
<gnomefreak> mvo_: http://www.pastebin.ca/412604
<gnomefreak> i havent looked yet
<mvo_> gnomefreak: can you please ask him to put his /etc/apt/sources.list to a pastebin?
<gnomefreak> i am
<gnomefreak> hes going on about maybe us mirror doesnt have it and it should 
<mvo_> gnomefreak: thats possible (unlikely, but possible) 
<gnomefreak> hes using weird mirrors
<gnomefreak> http://ftp.osuosl.org/pub/ubuntu/ didnt have it but us.archive.c does
<gnomefreak> i wish people would use the archive mirrors
<gnomefreak> it installs fine with us.archive.com sorry to bother you.
<mvo_> gnomefreak: ok, that is settled then. thanks
<gnomefreak> thank you
<LaserJock> is there a channel for Ubuntu SoC stuff yet?
<tepsipakki> what's wrong with launchpad?
<tepsipakki> I mean
<tepsipakki> it timed out
<pochu> tepsipakki: down, #launchpad
<LaserJock> tepsipakki: it's not feeling well
<tepsipakki> of course
<pochu> I have 500 and 502 errors everytime
<tepsipakki> just when I should ask advice from upstream :)
<kwwii> launchpad is down for a bit but they are on it
<pochu> LP is back :)
<JonRob> hi, I was interviewing Mark Shuttleworth the other day and he mentioned that there's a boot parameter that allows you to install ubuntu using only free software - but i can't find it documented anywhere, anyone know what it is?
#ubuntu-devel 2007-03-28
<pochu> hi Mithrandir :) if you have a moment, can you please review bug 97182? Thanks in advance and good night!
<ubotu> Malone bug 97182 in liferea "[UVFe]  liferea 1.2.10" [Undecided,Unconfirmed]  https://launchpad.net/bugs/97182
<Sp4rKy> hi
<Sp4rKy> somepeople who works on the auto update gnome plugin ?
<maxamillion> with the addition of the easy codecs and such, are there any complications with upgrading from edgy (I was under the impression that some of the packages have been renamed or dummied by meta packages)
<Burgwork> maxamillion: this is not really a uspport channel
<Burgwork> try #ubuntu+1
<ajmitch> hi Burgwork 
<Burgwork> hey ajmitch
* ajmitch wonders if we can get mit kerberos 1.6 into feisty+1
<ajmitch> hopefully it'll get into sid soon, since it's in unstable now
<maxamillion> Burgwork: this isn't a support question, i am aware of the different channels ... i just figured upgrade issues due to a package naming scheme altercation or restructure might be on topic in a devel channel
<Burgwork> asking about issues of upgrading are a support question
<maxamillion> Burgwork: and i was wondering the reportings of a developer on the topic
<Burgwork> if you run into an issue, file a bug
<ajmitch> Burgwork: btw the hit count on those authtool images is > 11K now :)
* ajmitch didn't realise planet was viewed by so many
<Burgwork> yep
<Burgwork> I need a blog with comments turned on
<maxamillion> Burgwork: no, i need to be able to upgrade a large number of computers on a college campus, this isn't a "try and find out" situation ... i am asking if there was a structural change in the packages that have to do with the codec feature change that might give an issue with upgrading (which i don't plan to do until feisty is stable) .... its just a question
<ajmitch> most useful part of krb5 1.6 that I saw, is an LDAP KDB plugin
<Burgwork> maxamillion: a large upgrade. Given most of the computers are likely the same, I would simply try a computer
<maxamillion> Burgwork: and i don't feel it would be something that could be answered by anyone but a devel ... or possibly a motu
<Burgwork> it is a goal to have computers upgrade easily and bug if they don't
<Burgwork> as such, you merely need to test it
<maxamillion> fair enough
<Burgwork> even if I told you there were no issues, I would still test it
<Burgwork> as I have no idea what custom software you have installed
<Burgwork> usually that is the stuff that messes up upgrades
<_ion> benc: Seems like i managed to modify the restricted modules themselves (*.mod.c, which are then built to *.mod.o and linked to *.ko on bootup) in the l-r-m debian/rules so that they list PCI IDs accurately. I'll test a bit more after sleeping. Since i'm modifying a *generated* file (*.mod.c), i don't think there should be any license problems.
<BenC> _ion: ok
<_ion> benc: The result is that e.g. 'modinfo nvidia' shows the correct list.
<_ion> Good night. 
<BenC> _ion: It also means that udev will autoload the nvidia kernel module, which may not be what we want
<mpt> asac, New Zealand
<Amaranth> BenC: I thought the nvidia kernel driver was mostly harmless if you don't use the X driver
<BenC> Amaranth: it taints the kernel
<Amaranth> well, yes
<mjg59> And fucks power management
<Amaranth> even if it's not being used?
<mjg59> "Oh, I'm going to poke registers now!"
<mjg59> Yes
<mjg59> Hateful thing
<Amaranth> ick
<Amaranth> go go nouveau
<desrt> god
<Amaranth> i can't believe they still haven't fixed the problems with textures
<Amaranth> it even breaks on VT switch
<desrt> you think they could have just uploaded a new version of the single specific piece of evo that was actually affected
<Amaranth> told them about it, they said they thought it was already fixed but would look at it
<Amaranth> that was in november...
<jamesh_> Amaranth: obviously you don't matter.
<Amaranth> I guess not
<Amaranth> nvidia hates bling!
* mpt tries to figure out what an "NFS import" is
<Amaranth> because, you know, having more people actually have a use for your hardware is horrible
<jamesh> Amaranth: maybe if you bought 100 Quadros, they might care more
<fabbione> morning
<LaserJock> hi fabbione 
<ajmitch> hi 
<Ademan> who develops libdvdcss2? the first 150 google hits looked like tutorials on how to install it in ubuntu as opposed to a project page...
<mjg59> It was part of the videolan project at some point, I believe
<RAOF> I think it still is.  It hasn't changed much recently (as in the last couple of year) though.
<Ademan> i'm just getting rather frustrated that certain dvds refuse to be played
<RAOF> I think there's actually a newer DVD copy protection which isn't broken by libdvdcss2?
<Ademan> most likely
* RAOF seems to remember the acronym MCA?
<torkel> Ademan: http://www.videolan.org/developers/libdvdcss.html
<Ademan> appreciated torkel.  What then is libdvdcss2? just a different naming scheme for the package? (iirc incompatible versions had to have the version number on the actual package?)
<Ademan> wow.... latest entry in the changelog was 2005 ....
<RAOF> Oh, yeah.  It's pretty much stable :)
<Ademan> heh, well there's no alternative for decrypting dvds is there?
<LaserJock> I could be totally wrong but I thought gstreamer had a plugin for it that wasn't libdvdcss
<Ademan> i'll take a look
<Ademan> also what are the legal implications of using libdvdcss?  i was digging around, and at least wikipedia seemed to suggest taht you can't play ANY encrypted dvds on ANY computer, how then, was i able to play my dvds on windows media player way back when?  Did microsoft pay a fee or something for that?
<RAOF> Ademan: Yes, microsoft (or rather, the DVD playing software company) paid a fee.
<Ademan> that's pretty messed up...
<RAOF> (It's actually one of the reasons why the original Xbox didn't have DVD playback without the remote - a significant part of the cost of the remote was licensing all the necessary stuff)
<RAOF> Ademan: See "I can patent what you're thinking" :(
<Mithrandir> Ademan: I wouldn't recommend asking random people on IRC for legal advice, and any implications of libdvdcss depends on where you live.
<Ademan> Mithrandir: true, but i'm making the assumption that most people in here are either from america, australia, canada or the uk, where i assume these sorts of laws are similar
<superm1> has there been any known legal battles related to libdvdcss2 yet?
<RAOF> superm1: You mean, apart from the huge "DVD John" lawsuit?
<Ademan> no, but i don't think any commercial entity has been distributing libdvdcss2 yet
<Ademan> i mean, it's not in universe or multiverse is it?
<RAOF> No.
<Ademan> probably for good reason
<superm1> RAOF, i didn't realize that there was a DVD john lawsuit, i just knew of him
<RAOF> Because, at least for USA, it's pretty much the *definition* of the something illegal under the DMCA :)
<Ademan> RAOF: libdvdcss2? or what DVD john was doing?
<RAOF> libdvdcss2
<RAOF> Although also what DVD John was doing.
<RAOF> Incidentally, wasn't he sued *twice* in Sweden?
<torkel> RAOF: why should he have been sued in Sweden?
<Mithrandir> torkel: because people from the US have trouble distinguishing between European countries and misspell our names? :-P
* RAOF kinda lumps the top of Europe together, and calls it "Sweden" :)
<RAOF> Actually, I'd just forgotten where he actuall came from, and Sweden seemed a reasonalbe candidate.
<Ademan> lol
<torkel> Mithrandir: or they still believe that we are one country...
<Mithrandir> torkel: yeah, that only changed a hundred-odd years ago so it's clearly reasonable.
<Amaranth> RAOF: It was Norway :)
<RAOF> Amaranth: :-\
<Amaranth> btw, jon is a pretty cool guy :)
<Amaranth> Mithrandir, torkel: I don't know where they are but I know they exist ;)
* Amaranth sucks at geography, in general
<pitti> Good morning
<Hobbsee> heya pitti!
<Mithrandir> morning pitti, Hobbsee 
<Burgundavia> morning pitti, Hobbsee, Mithrandir
* Hobbsee hugs Mithrandir, pitti and Burgundavia 
<ajmitch> hi pitti, Mithrandir 
<Hobbsee> heya Mithrandir, Burgundavia
* Mithrandir bounces
<Hobbsee> why are you bouncing, Mithrandir?
<pitti> hey Mithrandir, Burgundavia, ajmitch
* pitti hugs Hobbsee back
<Hobbsee> :)
<Mithrandir> Hobbsee: just general happiness
<Hobbsee> Mithrandir: fair enough
<Burgundavia> pitti: has asterisk ever be considered for main before?
<Mithrandir> Burgundavia: yes, he's not happy with it unless somebody takes responsibility for it.
<Burgundavia> Mithrandir: ah. What were the specific issues?
<Mithrandir> general complexity, AIUI.
<ajmitch> lack of reponsible person to jump in & fix bugs?
<Burgundavia> ok
<Burgundavia> it currently only has 4 bugs filed against it in LP
<Mithrandir> asterisk: MainInclusionReportAsterisk (requires dedicated maintainer, possibly in conjunction with a spec)
<Mithrandir> is what it says
<Mithrandir> and the longer comment is MartinPitt: This package is complex and vulnerability-prone enough to require someone who knows the package well and commits to maintain it for a longer term. If there is an approved Ubuntu specification that requires this package, then I will reconsider, but for now I rather want to not burn our hands with it.
<Burgundavia> right, found it
<Burgundavia> ok, I looked right at that and didn't see it when I searchef ro it
<poningru> hmm
<dholbach> hellas
* pitti hugs dholbach 
* dholbach hugs pitti back
<RAOF> pitti: About bug #95814 again:  I un-duplicated it then re-added the need-amd64-retrace tag.  The apport-retrace service has removed the tag, but still hasn't generated a stacktrace.
<ubotu> Malone bug 95814 in banshee "[apport]  banshee.exe crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95814
<RAOF> Is there anything else I should do, or just wait for Banshee to crash again and file a whole new bug?
<pitti> RAOF: let me look into the log
<RAOF> Thanks.
* pitti restarts the i386 retracer which exception'ed out on the LP downtime
<pitti> RAOF: ah, it became a victim of a package installation bug that I fixed yesterday; can you please try again?
<pitti> RAOF: I'll watch the log, and if it still fails, I'll investigate
<RAOF> As in, re-add the tag?  Certainly.
<pitti> RAOF: right; thanks, and sorry for the inconvenience; still lots of bugs to fix :/
<dholbach> tepsipakki: do you know if there are any complaints about i810 spinning cpu with cairo apps? I'm asking because jokosher upstream asked me, when I filed bug 96441
<ubotu> Malone bug 96441 in jokosher "timer updates use too much CPU" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96441
<RAOF> That's OK.  I'm not sure if the stacktrace will help me at all, anyway.  I just know that a stacktrace containing nothing but () in ?? won't help me, either :)
<siretart> Mithrandir: could you have a look at bug #91676? is the debdiff okay for feisty?
<ubotu> Malone bug 91676 in wpasupplicant "wpa_supplicant crashes in: wpa_supplicant_dbus_notify_state_change (wpa_s=)" [Medium,Needs info]  https://launchpad.net/bugs/91676
<Mithrandir> siretart: looking
<Mithrandir> siretart: you've used and tested it a bit yourself?
<tepsipakki> dholbach: there is a bug about general sluggishness.. you could try downgrading libx11 and see if that makes it better
<sabdfl> racebetween mscompress and foo2js been reported?
<pitti> sabdfl: yes, and fixed already
<sabdfl> thanks pitti
<siretart> Mithrandir: I'm currently using the 0.6 branch, but I'm going to test it on my girlfriends notebook. I wasn't able to reproduce the crasher myself
<dholbach> tepsipakki: i've had the problem for quite a while now - not sure if downgrading libx11 would help - it's generally fine, it's just this one case that makes jokosher unusable for me :-/
<siretart> Mithrandir: the update I'm proposing is to update to the latest version of the stable branch
<siretart> the 0.6 branch is the experimental one
<Mithrandir> siretart: yes, I understood that.  Do you have the upstream changelog somewhere?
<siretart> Mithrandir: http://librarian.launchpad.net/6917891/changelog.diff
<tepsipakki> dholbach: do you use EXA?
<dholbach> tepsipakki: do I use it if it's not mentioned in xorg.conf?
<Mithrandir> siretart: looks good to me, go ahead.
<tepsipakki> dholbach: no :)
<dholbach> tepsipakki: ok
<siretart> k thanks
<tepsipakki> dholbach: see bug 88815
<ubotu> Malone bug 88815 in xorg-server "Sluggish rendering since xorg 7.2 update" [Medium,Confirmed]  https://launchpad.net/bugs/88815
<dholbach> tepsipakki: I think I had the problem before (jokosher not keeping up with recording)
<RAOF> pitti: That worked, thanks.  Man, mono stacktraces aren't particularly informative :/
<tepsipakki> dholbach: you mean before 7.2 landed?
<dholbach> tepsipakki: yeah
<pitti> RAOF: indeed, see https://wiki.ubuntu.com/ApportMonoCrashes
<dholbach> kwwii: are these icons wrong:
<dholbach> /usr/share/icons/Human/scalable/devices/gnome-dev-trash-full.svg
<dholbach> /usr/share/icons/Human/scalable/devices/gnome-dev-trash-empty.svg
<kwwii> dholbach: nope, those and the CDs seem to be correct
<kwwii> and exist as SVGs
<kwwii> dholbach: but it is a bigger problem than that
<kwwii> dholbach: it appears to use the 48x48 icons and then scale them up
<dholbach> kwwii: why does it work nicely with the 'folders'?
<kwwii> dholbach: ahhhh, that would be because 48x48 is the biggest pixmap version that exists
<kwwii> dholbach: not sure I get you on that 
<dholbach> kwwii: if I scale folders they scale nicely
<dholbach> kwwii: it uses the svg there
<dholbach> ahhhh
<dholbach> could it be this:
<dholbach> [48x48/filesystems] 
<dholbach> Size=48
<dholbach> Context=filesystems
<dholbach> Type=Scalable
<dholbach> in /usr/share/icons/Human/index.theme ?
<kwwii> dholbach: I think so, I am going to try removing it and see what happens
<_ion> benc: The nvidia module *already* has aliases that match to *all* nVidia VGA cards. I'm just making them more accurate.
<dholbach> kwwii: change to Fixed and be sure to either remove /usr/share/icons/Human/icon-theme.cache or run sudo gtk-update-icon-cache /usr/share/icons/Human
<seb128> you need to "sudo touch /usr/share/icons/Human" before running the update
<kwwii> dholbach: hrm, that did not appear to change anything
<kwwii> dholbach: freaky man...I have no idea why nautilus is doing that
<kwwii> dholbach: but it does not use any of the SVGs it appears...either that or it prerenders them and then uses a smaller version
<kwwii> dholbach: but when you create the cache it only packs the pngs into it, or?
<kwwii> dholbach: it cannot be rendering the svgs as it takes only a few milliseonds to create that cache file
<dholbach> kwwii: it uses the svgs too
<dholbach> kwwii: i can scale a folder to a huge size and it looks nicely
<kwwii> dholbach: yeah...here too..but in the information pane in nautilus it refuses to use them it appears
<dholbach> hmhm
<dholbach> did you restart nautilus or use ctrl-r to repaint?
<kwwii> I was testing it by loggin in as a different user
<seb128> kwwii: pane probably uses 16x16
<kwwii> seb128: it appears to use 48x48 
<seb128> weird
<kwwii> seb128: do you know if that is hardcoded somehow?
<seb128> pane using 48x48, no way
<seb128> no, it's not
<kwwii> I think it uses 48x48 because it only looks sharp at that size
<seb128> they use the gtk_icon_theme API
<seb128> how do I reproduce the bug?
<kwwii> open nautilus and change the pane on the left from places to information
<seb128> ah
<seb128> $ strace -e open nautilus ~/Desktop 2>&1 | grep icon | grep desktop
<seb128> open("/usr/share/nautilus/ui/nautilus-desktop-icon-view-ui.xml", O_RDONLY|O_LARGEFILE) = 21
<seb128> open("/usr/share/icons/Human/16x16/places/gnome-fs-desktop.png", O_RDONLY|O_LARGEFILE) = 21
<seb128> open("/usr/share/icons/Human/48x48/emblems/emblem-desktop.png", O_RDONLY|O_LARGEFILE) = 23
<seb128> open("/usr/share/icons/Human/16x16/emblems/emblem-desktop.png", O_RDONLY|O_LARGEFILE) = 21
<seb128> 
<seb128> looks like it's using "/usr/share/icons/Human/16x16/places/gnome-fs-desktop.png",
<seb128> ah no
<kwwii> seb128: try going to the trash with that
<seb128> there is 2 icons in the pane
<kwwii> the trash icon and the CD icon exist as SVGs, so it should use those, no?
<seb128> right, trying to figure what it's doing
<seb128> kwwii: I've no svg trash icon
<seb128> is it supposed to be part of the current theme?
<dholbach> seb128: /usr/share/icons/Human/scalable/devices/gnome-dev-trash-{empty,full}.svg ?
<kwwii> dholbach: hehe, you are quicker than I :-)
<seb128> $ strace -e open nautilus trash: 2>&1 | grep trash
<seb128> open("/usr/share/icons/Human/16x16/places/user-trash.png", O_RDONLY|O_LARGEFILE) = 24
<seb128> open("/usr/share/icons/Human/16x16/places/user-trash.png", O_RDONLY|O_LARGEFILE) = 24
<seb128> open("/usr/share/icons/Human/48x48/places/user-trash.png", O_RDONLY|O_LARGEFILE) = 24
<seb128> open("/usr/share/icons/Human/48x48/status/user-trash-full.png", O_RDONLY|O_LARGEFILE) = 28
<seb128> open("/usr/share/icons/Human/16x16/status/user-trash-full.png", O_RDONLY|O_LARGEFILE) = 28
<seb128> 
<seb128> it looks for user-trash
<dholbach> ok
<seb128> and user-trash-full
<dholbach> i'm happy to rename them
<seb128> I think that's the new spec naming
<seb128> no?
<dholbach> icon-theme pain
<kwwii> that would only make it miss the icon in other places, or?
<seb128> kwwii: we need symlink from one name to the other so it works for apps using the old and new naming
<dholbach> seb128: we should rename them
<kwwii> dholbach: but still the other icons do not exist as SVGs...is there any chance of finding some source files for those?
<dholbach> kwwii: no, the SVGs were created separately - don't ask
<seb128> confirmed
<seb128> sudo cp ./scalable/devices/gnome-dev-trash-full.svg scalable/places/user-trash-full.svg
<dholbach> seb128, kwwii: thanks for figuring that out
<kwwii> dholbach:  ;-)
<seb128> with that the trahs full icon is all nice
<dholbach> nice
<dholbach> yooho
<seb128> dholbach: np
<dholbach> kwwii: I have the feeling we have to rename a bunch of those svg files in that directory
<seb128> you might want to consider the symlink also
<seb128> because there is apps around still using the old naming
<dholbach> seb128: it will automatically get generated
<seb128> rock&roll then ;)
<dholbach> user-trash will generated 5 other symlinks inclunding gnome-dev-*
<seb128> using naming-utils?
<dholbach> yes
<seb128> k
<dholbach> just not the other way round :9
<seb128> ah ok
<kwwii> dholbach: for feisty+1 we should look into using only the new naming scheme, or?
<dholbach> kwwii: sure, I even wrote a script to rename the icons - could be that I need to look into fixing it again
<dholbach> kwwii: or hand it over to you
<dholbach> :-)
<kwwii> hehe :-)
* dholbach hugs kwwii
* kwwii hugs back
<kwwii> ahhh, you can almost smell the love in the room
<dholbach> exactly
<seb128> why for feisty+1?
<seb128> Do we want blurry icons for feisty? ;)
<kwwii> lol
<kwwii> guess not
* ogra wonders where his kezmap is gone since the last upload
<ogra> s/upload/update indeed
<pitti> ogra: pc105/us FTW :)
<ogra> meh
<ogra> i want mz german one back
<ogra> grrr
<Mithrandir> qwertz ftw!
<ogra> *my
<ogra> xorg.conf is fine, /etc/default/console-setup seems ok as well ... but no win
<shawarma> ogra: Gnome might override it.. Is it broken at the gdm login prompt, too?
<ogra> hmm, i didnt check ...
<pitti> ogra_: System -> Einstellungen -> Tastatur?
<ogra> so it is a gnome thing then ....
<shawarma> 11:46 < pitti> ogra_: System -> Einstellungen -> Tastatur?
<ogra> seb128, do zou know anzthing about lost kezmaps 
<shawarma> ogra: LOL
<seb128> ogra: list when?
<seb128> lost
<seb128> new install? update?
<ogra> update
<seb128> of what package?
<ogra> heh, about 247 packages, dont ask which ... but i have the right map in gdm ...
<seb128> gconftool -g /desktop/gnome/peripherals/keyboard/kbd/layouts
<fabbione> pkl_: ping?
<tkamppeter> Is here some gnome crasher expert around? There is a 64-bit-only crasher which many users have reported: bug 91218
<ubotu> Malone bug 91218 in gnome-cups-manager "MASTER: [apport]  gnome-cups-manager crashed with SIGSEGV in g_signal_emit_valist()" [High,Confirmed]  https://launchpad.net/bugs/91218
<ogra> i didnt update since last herd ... until zesterdaz
<tkamppeter> It has 13 duplicates.
<ogra> ogra@edubuntu:~$ gconftool -g /desktop/gnome/peripherals/keyboard/kbd/layouts
<ogra> [de     nodeadkeys,us   intl] 
<ogra> looks fine to me
<Mithrandir> ogra: does "setxkbmap de" fix it?
<ogra> ah, yes
<ogra> thanks, feels much better to have the y in the right place :)
<seb128> ogra: does it happen again after a new login?
<ogra> i'll try
<ogra> seb128, yes
<seb128> ogra: could you try to downgrade libxklavier to 3.1?
<ogra> sure
<ogra> hmm, only 3.0 in the archive
<ogra> seb128, would that do it as well ?
<dholbach> LP should have some more versions
<seb128> ogra_: should be fine
<seb128> dholbach: LP has all the source versions but not the binaries, no?
<dholbach> I think it does
* dholbach looks
<ogra> i was as well having the impression it only has source ...
<cjwatson> LP has the binaries too if available
<seb128> cjwatson: "if available"?
<cjwatson> if built
<shawarma> seb128: if they built properly.
<seb128> ah
<seb128> they are not one https://beta.launchpad.net/ubuntu/+source/libxklavier/3.1-0ubuntu1
<cjwatson> follow the "Builds of ..." links
<seb128> you have download links for the .dsc the .changes and the tarball
<cjwatson> e.g. https://launchpad.net/+builds/+build/308300
<dholbach> yeah, it has them
<seb128> ah ok
<seb128> I've been tricked by the nice LP UI again ;)
<seb128> cjwatson: thank you
<tepsipakki> was there a console version of update-manager?
<cjwatson> then "Resulting binaries" as beta.lp hides it by default
<seb128> tkamppeter: I'll try having a look later
<ogra> seb128, 3.0 fixes it
<seb128> ogra: https://beta.launchpad.net/+builds/+build/308300/libxklavier11
<seb128> ok
<seb128> so it's a 3.2 regression
<seb128> could you try with 3.1 to be sure?
<seb128> I'll ping svu about it
<pitti> hmm, when gdm is running I cannot use ctrl+alt+fn any more; is that just me?
<seb128> ogra: could you open an libxklavier bug with gconftool -R /desktop/gnome/peripherals/keyboard/kbd attached?
<seb128> pitti: https://launchpad.net/bugs/97060
<ubotu> Malone bug 97060 in gdm "Can't switch VT from GDM" [Undecided,Unconfirmed]  
<cjwatson> how did wow, how did gdm manage to break that?
<seb128> good question
<iwj> Yay!  udevd --verbose output for a case where bug 75681 happened!
<ubotu> Malone bug 75681 in mdadm "boot-time race condition initializing md" [High,Confirmed]  https://launchpad.net/bugs/75681
<seb128> the weird things is that it was happening on my laptop and not my desktop some time ago
<pitti> argh, switch off != logout  /me hates this logout dialog
<seb128> I'll need to try again on my desktop
<pitti> seb128: ah, thanks for the gdm bug pointer
<seb128> np
<seb128> pitti: maybe set /apps/panel/global/upstream_session
<seb128> pitti: that's the "2 normal dialog" way from upstream
<seb128> you might like it better ;)
<pitti> seb128: ah, I just need to look more carefully :)
* pitti hugs seb128 
* seb128 hugs pitti back
<ogra> seb128, bug 97342 for you
<ubotu> Malone bug 97342 in libxklavier "keymap support regression between version 3.1 and 3.2" [Undecided,Unconfirmed]  https://launchpad.net/bugs/97342
<seb128> ogra: danke
<pitti> seb128: indeed, that upstream default looks pretty ugly, too, but at least it's clearly separated
<pitti> s/, too//
<iwj> pitti: Would you care to formally approve https://wiki.ubuntu.com/MainInclusionReportSlModem ?
<pitti> iwj: oh, sure
<pitti> iwj: thanks for the derootification, that makes me happy :)
<pitti> iwj: shall I move it to restricted right away?
* pitti assumes 'yes' and changes override
* ajmitch wonders if that would support his modem in the laptop
<pitti> mvo: hm, displayconfig-gtk's 'test' with a slightly lower resolution and no other changes just wrecked X and forced me to reboot :/
<pitti> mvo: I want to take a look at the xorg.conf mangling code
<pitti> mvo: how stable/tested is this?
<mvo> pitti: the test changed your original xorg.conf? that sounds like a evil bug. it should write a temp xorg file
<pitti> mvo: no, it didn't
<pitti> mvo: my screen went black, ctrl+alt+fn didn't help either
<mvo> pitti: the xorg rewrite code is used in guidance as the default kbuuntu mangling thing. its should be well tested
<pitti> mvo: xorgconfig.py seems to be pretty isolated (no unusal imports)
<pitti> thus I ponder stealing it and using it in r-m
<Mithrandir> doko: there's something broken in OOo on amd64; see bug 93758
<ubotu> Malone bug 93758 in openoffice.org-amd64 "Openoffice excessive memory useage" [Undecided,Confirmed]  https://launchpad.net/bugs/93758
<mvo> feel free
<pitti> I just get too many bug reports about using debconf and not supporting custom xorg.conf
<mvo> pitti: if you want to copy it, I can puslish my "upstream" bzr branch. that is the svn import of the releavent files that I keep up-to-date
<pitti> mvo: in the long term, the best would probably be to split this into a separate packge which guidance, displayconfig-gtk, and r-m use
<mvo> pitti: I talked with upstrema about this already and suggested the same. but they want to concentrate on the release and do the split after the release
<mvo> pitti: maybe we could convince them with a patch though .)
<pitti> right, that's fine
<pitti> for Feisty, just copying the file WFM
<tkamppeter> seb128, thanks.
<seb128> np
<pitti> mvo: urgh, it changes whitespace and case heavily
<iwj> pitti: Yes, thanks.
<doko> Mithrandir: should be fixed with the next upload
<Mithrandir> doko: ok, great. :-)
* StevenK wonders what is taking imaze so long to build, and why it hasn't registered a build on amd64.
<Mithrandir> StevenK: soyuz has done some strange stuff tonight, cprov is looking at it.
<StevenK> Right.
<tkamppeter> doko, pitti, WDYT about turning on browsing/broadcasting in CUPS by default (see bug 68256)?
<ubotu> Malone bug 68256 in cupsys "kde: Openoffice doesn't see remote cups printers, just generic printer" [Medium,Confirmed]  https://launchpad.net/bugs/68256
<pitti> tkamppeter: not for Feisty any more; for that we need to rework the Gnome print dialog to clearly separate browsed from local printers
<tkamppeter> pitti, is it not easier and with less risk to break anything to change 3 or 4 lines in cupsd.conf than doing changes on the gnome-cups-manager which will disappear in Feisty+1?
<tkamppeter> gnome-cups-manager is crashing enough currently.
<pitti> tkamppeter: changes on g-c-m? It can already enable browsing with a single click
<tkamppeter> You told "rework the Gnome print dialog" and this looked like you were thinking about modifying g-c-m in some way.
<pitti> no, libgnomeprintui
<tkamppeter> is libgnomeprintui not one of the dieing thingies, too? Is it not on the way to be replaced by the GTK 2.10.x printing infrastructure?
<pitti> right
<pitti> that then
<tkamppeter> So we should only fix the crashers for Feisty: bug 91218, bug 95137, bug 83647, bug 79077
<ubotu> Malone bug 91218 in gnome-cups-manager "MASTER: [apport]  gnome-cups-manager crashed with SIGSEGV in g_signal_emit_valist()" [High,Confirmed]  https://launchpad.net/bugs/91218
<ubotu> Malone bug 95137 in gnome-cups-manager "[apport]  gnome-cups-manager crashed with SIGSEGV" [Medium,Confirmed]  https://launchpad.net/bugs/95137
<ubotu> Malone bug 83647 in gnome-cups-manager "crash while editing panel" [Undecided,Needs info]  https://launchpad.net/bugs/83647
<ubotu> Malone bug 79077 in gnome-cups-manager "Adding new printer failed on Ubuntu 6.10 Amd64" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79077
<tkamppeter> and then let g-c-m and libgnomeprintui RIP.
<pitti> yep
<tkamppeter> And I think switching defaults of a program is no danger for the Feisty release. Many users have probably already turned on broadcasting (including me) and they did not report bugs about something going wrong with it...
<tkamppeter> ... and turning broadcasting off again is as easy as turning it on in Edgy, via the button in the g-c-m you mentioned, and the web interface has such a button, too.
<doko> tkamppeter: could you have a look at bug 83950 ?
<ubotu> Malone bug 83950 in openoffice.org "feisty openoffice crash" [Undecided,Needs info]  https://launchpad.net/bugs/83950
<tkamppeter> doko, for me it looks like the following: OOo is reading out information about page sizes and margins from the printer's PPD file. It polls the PPD file through the CUPS API (I hope so) and parses it. Now some PPD files (especially manufacturer-supplied ones, unfortunately) are not 100% Adobe-compliant (check with cupstestppd) and it seems that OOo does not handle this problem gracefully. Bug is in OOo, OOo must be more tolerant on not 
<tkamppeter> so perfect PPDs or at least not crash in such a case (and Brother should make better PPDs).
<seb128> ogra: could you reply to the comment on the libxklavier bug?
<tkamppeter> pitti, still there?
<pitti> tkamppeter: yes, I am
<tkamppeter> what about switching browsing/broadcasting on by default?
<pitti> tkamppeter: <pitti> tkamppeter: not for Feisty any more; for that we need to rework the Gnome print dialog to clearly separate browsed from local printers
<pitti> tkamppeter: the issue is that otherwise it is way too easy to fool people to print to a different printer than they intend to
<pitti> because the print ui doesn't tell them apart
<tkamppeter> Yes, printerdrake is clearly putting them into two tabs.
<pitti> g-c-m has different icons for them, but that's not the point
<pitti> the point is the gnome/KDE printer dialog in applications
<tkamppeter> You mean the print dialogs in the apps?
<pitti> they need to make a difference between "This is a locally configured printer that I can trust" and "This is a remote printer that could be anything"
<tkamppeter> So I should talk with the OpenUsability group which is working on the common grand unified print dialog about this issue?
<pitti> tkamppeter: that would indeed be nice
<pitti> since eventually the world will move to the xdg dialogs
<seb128> what xdg dialogs?
<TheMuso> mvo: Is ubuntu-restricted-extras maintained in bzr?
<seb128> the GTK API is all new and I doubt GNOME moves to anything else
<tkamppeter> Yes, their dialogs will end up as XDG/Portland dialog.
<Riddell> isn't the point that xdg just pops up the appropriate gnome or kde dialogue?
<Riddell> one dialogue for both seems like something you'll never get agreement on
<tkamppeter> Pitti, will you be on the LinuxTag in Berlin? There will be the next meeting of the OpenUsability Printing GUI team, I am organizing it.
<pitti> I'm not sure yet
<tkamppeter> It is sponsored by the Linux Foundation.
<tkamppeter> Ridell, it will be the following:
<tkamppeter> The OU people will design a dialog layout which will be implemented once with Qt/KDE and once with GTK/GNOME.
<ogra> what is http://search.ubuntu.com ? thats where yelp sends me, the server refuses connections
<Riddell> tkamppeter: good luck to them :)
<ogra> Burgwork, ^^^ (ar any other docteam member)
<ogra> *or
<tkamppeter> Depending on whether the user's desktop is KDE or GNOME the appropriate dialog will be used, independent of whether the app is KDE or GNOME.
<tkamppeter> So digikam started in GNOME will show the GNOME flavor of the printing dialog (and of all other dialogs handled by Portland).
<mooey> what is responsible for mounting usb disks? triaging a bug where a single usb disk shows up twice, i need to file it against the correct package
<Keybuk> cjwatson: installer question if you've got a mo?
* Keybuk has got stuck
<Keybuk> I can't seem to do anything but cancel the install at this point
<mvo> TheMuso: no, its not maintained in bzr
<TheMuso> mvo: Thanks. Just wanted to be sure before I do anything with it.
<mvo> TheMuso: what do you plan to do with it?
<TheMuso> mvo: A bug was filed to update the java packages to java6. It was marked as a bytesize/packaging bug for MOTU people.
<TheMuso> SO I'm sponsoring the upload.
<TheMuso> Unless you'd rather take care of it?
<mvo> TheMuso: good point, please do it!
<TheMuso> mvo: Ok will do.
<Keybuk> oh, wow, it unblocked
<Keybuk> cjwatson: so, err, the "Migrating Users and Settings" thing can take a very long time to run <g>
<cjwatson> Keybuk: fixed post-beta - it was running depmod
<cjwatson> (don't ask, it was a daft bug)
<ogra> Keybuk, i just recently got a patch for usbfloppy support in ltspfs (a udev rule addition) and was wondering why we dont handle these from udevs files already ...
<cjwatson> try upgrading os-prober and running through it again - bet it'll be faster
<cjwatson> if it isn't, poke evand :)
<Keybuk> cjwatson: ok :p
<Keybuk> ogra: -v please
<ogra> +ACTION=="add", SUBSYSTEMS=="usb", DRIVERS=="usb-storage", \ 
<ogra> +     ATTRS{interface}=="FLOPPY", KERNEL=="sd*", \
<ogra> +     RUN+="/bin/sh -c '/sbin/modprobe ide_floppy; /lib/udev/add_fstab_entry %k auto'"
<Keybuk> cjwatson: not really worried, if it's fixed, I was just making a new test install for fixing some bugs
<Keybuk> ogra: ?
<ogra> thats what i got ... i find the modprobe from a rule particulary ugly ... so i didnt accept it for now
<Keybuk> why is ide-floppy loaded?
<Keybuk> that's for ATAPI/PATA floppy devices
<ogra> it creates a floppy device instead of sdX
<ogra> right, thats why i didnt accept it 
<Keybuk> bet it doesn't
<Keybuk> ide-floppy makes hd* devices
<Keybuk> sd* is right for a usb floppy device
<ogra> doesnt ide floppy make fd devices as well ?
<Keybuk> no
<Keybuk> fd* devices are only the standard PC floppy thing
<ogra> ah, ok
<ogra> well, the automounter in ltspfs needs to recognize its a floppy to handle it like one :)
<Keybuk> that's just a ltspfs automounter bug then :p
<ogra> well :)
<ogra> indeed 
<ogra> nobody of the devs has usbfloppies apart from the one i have which BenC didnt get working with the kernel ...
<iwj> I have a usb floppy.
<ogra> a working one ? 
<iwj> How should a floppy be handled differently compared to a USB stick ?
<iwj> Yes.
<iwj> Well, it worked last time I used it.
<TheMuso> I also have a USB floppy if testing/info is needed.
<ogra> the unmounting in ltspfs is handled differently .... 
<iwj> ogra: How/why ?
<ogra> TheMuso, not this release cycle anymore
<ogra> it would be a fairly big change for a new feature :)
<TheMuso> ogra: Ah ok.
<Treenaks> did something change in edgy to make suspend buttons suddenly work? I've had to help two colleagues whose "screensaver" buttons (as defined in gnome-keybinding-properties) suddenly triggered suspend..
<ogra> iwj, well, the floppies we handled until now dont get plugged inh on the fly for example, they are handled as static devices ... usb floppies are rather something hybrid between floppy and usbstick ... the automounter only sees it as usbdisk
<ogra> so we dont get the right icon for example ... 
<Keybuk> ogra: bet you 5 that there's no insert notification <g>
<ogra> there might be technical drawbacks as well, but thats sbalneav land, he's doing the floppy part in ltspfs
<ogra> Keybuk, on usbfloppies there is ... if you plug in the usb ...
<iwj> Keybuk: No, I think you get the medium change stuff.  SCSI certainly has stuff to allow that and ISTR it showing up.
<Treenaks> ogra: not if you poke a disc in to the drive? (like USB memory cards into a cardreader.. that works)
<ogra> Treenaks, if udev gets a trigger it will ... 
<Keybuk> iwj: probably depends on the device
<Treenaks> probably depends on the hardware
<Keybuk> usb devices are usually no expense spent
<ogra> ltspfs only works through udev and a cdrom monitor 
<cjwatson> Keybuk: well, it's possible that something else is taking time
<cjwatson> Keybuk: so I'd like to know that the os-prober fix is enough
* cjwatson fixes two honking big classes of ubiquity bugs
<pochu> Mithrandir: re: liferea (bug 97182 if you can) :)
<ubotu> Malone bug 97182 in liferea "[UVFe]  liferea 1.2.10" [Undecided,Unconfirmed]  https://launchpad.net/bugs/97182
<Mithrandir> pochu: approved.
<Mithrandir> pochu: note that since liferea is in main, the correct procedure is to subscribe ubuntu-release, not motu-uvf
<pochu> I haven't subscribed them, but thanks!
<pitti> mvo: that works surprisingly well, and it would fix about 15 bugs in r-m (including duplicates)
<pitti> mvo: I have an -xorgconf branch now which uses that kdeguidance python module
<pitti> mvo: would you be willing to give it a quick test with your ati card?
<pitti> seb128, ogra: would you have a few minutes to test a new r-m? I changed it now to modify xorg.conf directly, and also to restore it cleanly
<seb128> pitti: sure
<pitti> mvo, seb128, ogra: http://people.ubuntu.com/~pitti/tmp/restricted-manager_0.15_all.deb
<seb128> pitti: do you have a bug open about r-m UI being frozen while synaptic is running?
<pitti> seb128: no, I don't
<pitti> seb128: right, I should fix that as well
<seb128> k, I'll open that then ;)
<pitti> seb128: thanks
<seb128> np
<pitti> seb128: I guess I just need to execute it asynchronously, and do some wait(timeout)/gtkmainiteration loop
<seb128> pitti: yeah, or just make the synaptic window transient for it
<seb128> rather than the loop
<mvo> there is a transient-for option in synaptic
<seb128> brb
<pitti> mvo: what does that mean?
<pitti> mvo: after all, subprocess.communicate() blocks until synaptic has finished
<pitti> so there's no main loop in r-m during that time
<mvo> pitti: if you want to fix that, run a thread with the communicate()
<mvo> pitti: transient-for means that you can't move the install-window of synaptic under the r-m window
<pitti> mvo: well, a wait() with a timeout seems easier
<pitti> mvo: aah; that would be nice as well
<mvo> pitti: thats ok too
<pitti> mvo: how do I specify that? does it expect a PID?
<mvo> pitti: a xwindow id, you get it with GtkWindow.Window.xid 
<mvo> pitti: restriction-manager seems to work fine here with the ati
<pitti> mvo: xorg.conf looks sane?
<mvo> pitti: yes
<pitti> mvo: diff -wir /var/cache/restricted-manager/ati.oldconf /etc/X11/xorg.conf
<pitti> mvo: cool, thanks
<pitti> seb128: wb
<seb128> re
<seb128> works fine 
<seb128> and it fixes the Load "glx" dropping
<mvo> pitti: http://paste.ubuntu-nl.org/12493/
<pitti> seb128: right, due to the more clean restoring
<pitti> seb128: great
<pitti> seb128: diff -wir /var/cache/restricted-manager/ati.oldconf /etc/X11/xorg.conf  <= looks sane?
<pitti> seb128: erm, not -wir, but -wiu
<seb128> I did copy xorg.conf and diff it
<seb128> after enabling fglrx it looks the same with s/ati/fglrx
<seb128> and lot of spacing changes
<seb128> and desactiving fglrx brings it back exactly in the state it was before using it
<Mithrandir> seb128: are you doing syncs or are you done for the day with them?
<seb128> Mithrandir: I've not done them yet, I was going to do that soon
<pitti> seb128: right, the spacing and capitalization changes are ugly; I already fixed some in the xorgconf.py, but it's far from perfect yet
<Mithrandir> seb128: great, then I'll leave the one I was going to do myself for you (nfs-utils)
<pitti> seb128: however, it doesn't really matter
<seb128> Mithrandir: ok
<pitti> seb128: thanks for testing! I think I'll release this to the world then
<seb128> pitti: wasn't fglrx supposed to use Composite or something?
<pitti> seb128: s/use/disable/, right?
<seb128> it didn't add the no Composite option
<seb128> ok
<seb128> it didn't do it
<pitti> seb128: right, that was the magic that dexconf did before, I have to add that manually now
<pitti> seb128: I'll look into that
<seb128> ok
<seb128> pitti: https://beta.launchpad.net/ubuntu/+source/restricted-manager/+bug/97399 BTW
<ubotu> Malone bug 97399 in restricted-manager "UI not updated while synaptic is running" [Undecided,Unconfirmed]  
<pitti> mvo: ^ you have to fix that as well in your config
* pitti grabs a pizza before, bbl
<seb128> pitti: enjoy
<mvo> pitti: what config? Composite option?
<tkamppeter> With which motivation is it decided whether a tool goes into the "Administration" or into the "Preferences" sub menu of the "System" menu? For example I think that "Printing" (gnome-cups-manager) should go into "Administration"?
<seb128> tkamppeter: admin are mainly tools requiring sudo
<seb128> gnome-cups-manager would probably be better placed in admin though, right
<tkamppeter> "Printing" requires the privileged user for adding and removing queues, sudo for turning on/off Browsing/Broadcasting, and any user can set his personal default options with it.
<tkamppeter> seb128, I think it really belongs into "Admin".
<_MMA_> seb128: Thanx for the GDM fix. ;) bug 97197
<ubotu> Malone bug 97197 in gdm "GDM depends on ubuntu-sounds" [Wishlist,Fix released]  https://launchpad.net/bugs/97197
<seb128> _MMA_: np
<seb128> _MMA_: are you Cory?
<_MMA_> Yep
<tkamppeter> seb128, one should perhaps look through all the entries of the "Administration" and the "Preferences", as probably something got messed up there while these menus did not exist because they were replaced by the Control Center.
<seb128> _MMA_: ok, I don't need to reply to your mail then ;)
<_MMA_> seb128: I sent the email to you before I remembered I could just file a bug.
<seb128> tkamppeter: those menus were the same in edgy
<_MMA_> Yeah np.
<seb128> _MMA_: BTW, do you work on exaile?
<seb128> _MMA_: if you have an interest to the package would be nice to subscribe to it on launchpad ;)
<_MMA_> No. I use it and am active in their channel. No packaging or dev.
<seb128> I've noticed there was quite some crashes unconfirmed there
<tkamppeter> seb128, then the problem perhaps already occured in Edgy, but I do not remember whether it was the case.
<seb128> _MMA_: ok, if you know some upstream and can get somebody to subscribe on launchpad ... there is quite some bugs with stacktraces there, might be useful to them
<seb128> _MMA_: https://beta.launchpad.net/ubuntu/+source/exaile/+bugs
<_MMA_> cool.
<seb128> _MMA_: to subscribe: https://beta.launchpad.net/ubuntu/+source/exaile/+subscribe
<tkamppeter> seb128, perhaps we should simply move over the inadequately placed tools then so that it gets correct in Feisty.
<_MMA_> I think their actually about to push out .2.9.
<seb128> tkamppeter: yeah, sure, do you have other gnome-cups-manager changes planned?
<seb128> tkamppeter: or should I do an upload just to fix the category?
<seb128> _MMA_: k, cool
<tkamppeter> seb128, there is bug 91218, and Daniel Holbach is currently doing investigations on it (see last comments). This is a show stopper which needs to be fixed.
<ubotu> Malone bug 91218 in gnome-cups-manager "MASTER: [apport]  gnome-cups-manager crashed with SIGSEGV in g_signal_emit_valist()" [High,Confirmed]  https://launchpad.net/bugs/91218
<_MMA_> seb128: Ill talk to its dev "synic" today and see if he will sign up on Launchpad.
<seb128> _MMA_: rock on, thank you ;)
<_MMA_> np
<seb128> tkamppeter: yeah, there is no patch for that one yet, we will do an another upload if required
<seb128> tkamppeter: do you have a bug about the admin menu thing?
<seb128> tkamppeter: I'll fix it now, just to know if there is a bug to close
<tkamppeter> seb128, no, it was simply that I have observed it in the last weeks when I did some testing on g-c-m.
<seb128> ok
<pitti> mvo: right, composite doesn't get disabled ATM
* Keybuk tries to remember what else he wanted this vmware instance for
<tkamppeter> pitti, I have added a comment to bug 68256 now, telling about the need of the printing dialogs to tell whether a printer is local or remote.
<ubotu> Malone bug 68256 in cupsys "kde: Openoffice doesn't see remote cups printers, just generic printer" [Medium,Confirmed]  https://launchpad.net/bugs/68256
<pitti> thanks
<tkamppeter> I have not closed the bug, because the user reported that he sees the broadcasted printers with kprinter but not with OOo, do you have an idea whether that happens?
<pitti> hm, no; maybe kprinter has some custom method of detecting them
<tkamppeter> I remember that one can access a remote CUPS server with kprinter directly (like the CUPS tools do when one chooses a server via client.conf), but for that feature the user really has to enter a remote CUPS server into the kprinter configuration. I have asked the user whether he did so.
<pitti> tkamppeter: right, but that's normal IPP printing; the question was about automatically seeing them via browsing, right?
<seb128> doko: do you know about openoffice.org-soikko?
<seb128> doko: bug #96969
<ubotu> Malone bug 96969 in openoffice.org-soikko "Should be removed before feisty, removed from debian too" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96969
* Keybuk so just read that as openoffice.org-sudoku
<tkamppeter> pitti, yes, I only want to know whether everything behaves as designed (in this case I will reject the bug), as if the user did not do any configuration changes both kprinter and OOo should show the same printer list.
<danohuiginn> can I persuade anybody here to review a patch for me? bug 57067
<ubotu> Malone bug 57067 in python-mysqldb "UnicodeDecodeError: 'ascii' codec can't decode certain bytes " [Undecided,In progress]  https://launchpad.net/bugs/57067
<tepsipakki> seb128: that's a valid request for what I know
<seb128> tepsipakki: ok
<tepsipakki> soikko is the old and nonfree version of a spellchecker for Finnish
<tepsipakki> voikko is far superior
<mjr> dunno if it's superior, but at least it's maintained and free ;)
<seb128> tepsipakki: bug closed, thank you
<tepsipakki> mjr: proved my point ;)
<Keybuk> stupid LP question time
<Keybuk> ...how do I link to an upstream bug for a package where there's no upstream product registered?
<seb128> you register the product first and then link it
<danohuiginn> Keybuk: AIUI,you need to register a package through https://launchpad.net/products/+new
<Keybuk> damn
<Keybuk> that means I end up owning yet another thing :-/
<seb128> Keybuk: or get kiko to register the product for you, that's what I do ;)
<seb128> I think kiko told me you don't have the product you register previous time I asked him
<seb128> s/don't have/don't have to own/
<Keybuk>  module-init-tools doesn't use Launchpad to track its bugs. If you know this bug has been reported in another bug tracker, you can link to it; Launchpad will keep track of its status for you.
<Keybuk> ?|
<Keybuk> I KNOW THAT, I just gave it a Bugzilla URL
<pitti> mvo, seb128: http://people.ubuntu.com/~pitti/tmp/restricted-manager_0.15_all.deb updated for the Extensions/Composite section
<Keybuk> (no wonder nobody files bugs upstream; damn! that was hard work)
<seb128> pitti: testing
<pitti> seb128: is bug 97402 with 0.15?
<ubotu> Malone bug 97402 in restricted-manager "indicates that a reboot is required even after an xorg restart" [Undecided,Unconfirmed]  https://launchpad.net/bugs/97402
<seb128> pitti: yes
<pitti> seb128: hmm, xorg restart loaded the kernel module?
<seb128> pitti: ok, kernel module doesn't work on my box
<seb128> fglrx works fine without it though
<seb128> just without DRI
<doko> seb128: ok with me =)
<pitti> right
<pitti> seb128: may that be a consequence of not disabling composite?
<seb128> might be
<seb128> I need to try again
<pitti> seb128: new 0.15 disables composite now, maybe that helps
<seb128> I don't think so though
<pitti> seb128: if a real reboot makes it work, then we can just close this, probably
<seb128> well, I'm using fglrx
<seb128> it should not tell me than a reboot is required
<seb128> it should say it's activated no?
<seb128> the update works fine and disable composite as expected BTW
<pitti> if you disable it, then you'll need a reboot, too
<pitti> seb128: ah, thanks
<seb128> why?
<seb128> I did restart xorg
<pitti> seb128: that won't unload the module, right?
<seb128> ok, for you fglrx = using the kernel module
<seb128> for me it's xorg using the fglrx driver
<pitti> seb128: I agree that this could be better, but I think it's not such a big deal for now
<seb128> the module doesn't work on my desktop as said
<pitti> ah
<seb128> oh, I didn't consider it a big deal
<seb128> I just file bugs
<seb128> I think it's "trivial" importance
<seb128> (we don't have anything between wishlist and low though)
<seb128> feel free to close it and blaming it on fglrx module not working on my box, that's fine with me ;)
<seb128> I just though the xorg driver detection was buggy
<seb128> I didn't think about the kernel module
<pitti> seb128: no, I'll keep it as low
<pitti> I just wanted to find out what happened exactly
* pitti hugs seb128, thanks for all the testing
<seb128> np
* seb128 hugs pitti back
<seb128> pitti: for information, that's the message I was having when I tried to load the fglrx some time ago: "kernel: [19204.817731]  [fglrx:firegl_init_module]  *ERROR* firegl_stub_register failed"
<pitti> urgh
<seb128> pitti: nothing due to r-m ;)
<pitti> seb128: unfortunately I do not know how to detect the currently running X driver; testing the kernel module is the best I have so far
<carlos> cjwatson: ping
<cjwatson> carlos: hi
<seb128> pitti: WFM
<carlos> cjwatson: hi
<pitti> seb128: xorg.conf determines what you want (enabled/disabled), whereas the 'status' displays what's currently running
<seb128> pitti: it's probably ok in 95% of the cases anyway
<pitti> seb128: you don't happen to have an idea about that?
<carlos> cjwatson: I just saw your email about ubiquity strings. Are you including debian-installer .po and .pot files inside a .deb package now?
<seb128> pitti: yeah, I grep Xorg.0.log usually to know what I'm running, but that's hacky
<pitti> import X11; X11.get_running_driver() :)
<pitti> maybe some xprop or so
<cjwatson> carlos: no, no changes there
<Mithrandir> given that you can easily use more than one driver, that's slightly hard
<seb128> pitti: don't bother with that, it's low importance
<carlos> cjwatson: ok, then I need to do an upload by hand, as usual to allow translators to translate it in Launchpad
<carlos> cjwatson: I did it a couple of days ago
<cjwatson> carlos: I haven't uploaded my changes yet
<carlos> I wonder whether this change was already there at that time or is something new done today
* carlos talks about people.ubuntu.com/~cjwatson/installer-po
<Mithrandir> heno: shouldn't bug 68419 be fixed now?
<ubotu> Malone bug 68419 in Ubuntu "Ubuntu/Kubuntu 6.10 (Edgy) disctree says it is 6.06 " [Undecided,Confirmed]  https://launchpad.net/bugs/68419
<cjwatson> carlos: like I say, I haven't uploaded my changes yet. Don't expect to see them anywhere
<carlos> ok
<cjwatson> carlos: I'll try to remember to let you know when I do
<carlos> please, ping me once people.ubuntu.com is done so I can refresh Rosetta version
<carlos> cjwatson: ok, thank you
* Keybuk discovers, quite by accident, that there are rather a lot of bugs assigned to him and/or milestoned
<zul> oops
<Seveaz> Keybuk, so much for holiday ;)
<Keybuk> heh, it's more that I reached a point about three months ago where I receive more LP bug mails per hour than I am actually capable of *reading* in an hour
<Keybuk> so I haven't read them at all in a long time
<bddebian> Heya
<heno> Mithrandir: it is yes, have marked it Fixed now
<tkamppeter> pitti, you told in bug 91218 that the package should be built with "DEB_BUILD_OPTIONS=noopt,nostrip debuild -us -uc -b". This is rather complicated and the next one will forget to do it. Can these options also be set somewhere in debian/rules or debian/control?
<ubotu> Malone bug 91218 in gnome-cups-manager "MASTER: [apport]  gnome-cups-manager crashed with SIGSEGV in g_signal_emit_valist()" [High,Confirmed]  https://launchpad.net/bugs/91218
<pitti> tkamppeter: DEB_BUILD_OPTIONS is a standard environment for Debian source packages
<pitti> tkamppeter: it is *absolutely* not meant to be specified in debian/rules
<pochu> heno: shouldn't bugs in https://bugs.beta.launchpad.net/ubuntu-iso-tests/+bugs be closed, as beta has already been released?
<pitti> tkamppeter: oh, wait, you want to build the pacakge with -O1 instead of -O2 or so? Please use CFLAGS
<heno> pochu: indeed, would you like to close them or shall I?
<pochu> heno: doesn't the script do it?
<pochu> I can do it then
<pochu> will be just a minute
<heno> pochu: no, that's still manual
<pochu> heno: done
<ogra> pitti, r-m seems to work ok for me ... now i only need to find out why my screen goes white with compiz ...
<pitti> ogra: great, thanks for testing
<pitti> ogra: NB that fglrx does not support composite
<ogra> with the ati driver indeed
<ogra> with fglrx it doesnt even attempt to use desktop-effects
<pitti> mvo: hm, say I have a gtk.Dialog object; it doesn't have a Window, nor a xid attribure
<pitti> attribute, too
<mvo> pitti: gtk.Dialog.window.xid should work (make sure that the dialog is realized() before)
<mvo> window is the GdkWindow that belongs to the GtkWindow
<pitti> mvo: oh, "window", you said "Window"
<pitti> mvo: indeed, window exists, it's just None at the time when I call it
<pitti> mvo: yay, works now; thank you!
<mvo> pitti: great! 
<mvo> pitti: if its None, you can use realize()
<pitti> mvo: what's the synaptic argument for that? --help does nto display it
<mvo> pitti: --parent-window-id
<pitti> gorgeous
<_ion> benc, pitti: You've got mail. :-)
<pitti> will read in a minute, brb
<_ion> Nothing acute.
<pitti> _ion: FYI, I just uploaded r-m 0.15, a real killer release :)
<_ion> pitti: Yay
<ogra> pitti, it doesnt fix compiz for me ... no killer release !
<pitti> ogra: bah
<ogra> it should secretly fix the world at least :)
<_ion> pitti: With l-r-m built with the patch i emailed, i can simply remove all automatically generated files from /usr/share/restricted-manager/modalias_override and it Just Works.
<pitti> _ion: yay
<pitti> _ion: so the l-r-m changes will 'override' the internal .ko modaliases, so that modinfo fglrx just DTRT?
<pitti> _ion: indeed, just reading your mail. well done!!
<_ion> pitti: Yeah. The .ko files are built with the alias listings overwritten. I managed to implement it without much ugliness.
<_ion> (Just some ;-) )
<tkamppeter> seb128, when you are building gnome-cups-manager to move it into the Admin menu, can you build it with -O0 in the CFLAGS (at least for 64-bit), this probably fixes bug 91218. See last comments there.
<ubotu> Malone bug 91218 in gnome-cups-manager "MASTER: [apport]  gnome-cups-manager crashed with SIGSEGV in g_signal_emit_valist()" [High,Confirmed]  https://launchpad.net/bugs/91218
<iwj> root@samual13:~# grep sda /proc/partitions 
<iwj>    8     0  488386584 sda
<iwj> root@samual13:~# dd if=/dev/zero of=/dev/sda count=1
<iwj> dd: writing to `/dev/sda': No space left on device
<iwj> WTF?
<seb128> tkamppeter: no, we want to fix the bug, not to hide it like that
<_ion> pitti: This xorgconf stuff looks neat.
<pitti> _ion: indeed, and it fixes a whole lot of important bugs (I hope it doesn't introduce too many new ones); but after all, this code is in use for quite some time
<dieman> iwj: would another log for 75681 help you?
<iwj> dieman: Err, perhaps, if you can provide all of the info I've asked Aurelien for.  But don't go out of your way to get it.
<Mithrandir> heno: cheers
<iwj> One log of it going wrong is massively superior to none :-).  Another log is mostly for if you think your problem is different to Aurelien's.
<unimatrix9> hello there again, hows it going?
<pitti> evand: ping
<unimatrix9> feisty fawn beta 1, running an test ( great job , is very very polished )
<iwj> Dammit, I need this SATA to work not to go bizarrely wrong.
<evand> pitti: pong
<unimatrix9> found one bug : the Ubuntu device database collection does not work ( might be normal becuase its an beta 0 ?
<pitti> evand: I just read a first test of feisty beta by c't, a very famous German computer magazine (http://www.heise.de/open/artikel/87242)
<unimatrix9> beta 1..*
<pitti> evand: they mentioned the migration assistent :)
<mvo> pitti: is it a good review?
<pitti> evand: however, it didn't do anything for both a German WinXP and a German Edgy
<pitti> mvo: pretty short, but positive
<evand> pitti: There was actually a bug filed about this.  I made a mistake in assuming that "Documents and Settings" doesn't get translated like its subdirectories do.  I'm working on this for the next upload.
<evand> pitti: Thank you for pointing it out though.
<pitti> evand: ah, so it's indeed an i18n problem
<evand> indeed
<pitti> evand: great to hear that it's being fixed; thank you!
<evand> oddly enough the Spanish copy of Windows XP I have has "C:\Documents and Settings".  Apparently the German versions do not.
<pitti> evand: is there a way to find that folder without knowing the name?
<evand> pitti: Indeed, the registry.  It shouldn't be too hard to fix.
<pitti> evand: I faintly remember having seen 'Dokumente und Einstellungen' on my mother's laptop
<pitti> evand: oh, if there's a registry key pointing to it, that sounds find
* pitti hugs evand, thanks
<evand> pitti: no problem
* iwj reports bug 97457
<ubotu> Malone bug 97457 in linux-source-2.6.20 "sil3114 sata inexplicable ENOSPC" [Undecided,Unconfirmed]  https://launchpad.net/bugs/97457
<Keybuk> *giggles* at the tragedy of Bug #77366
<ubotu> Malone bug 77366 in udev "Kubuntu automounter doesn't mount Discworld II cds" [Low,Unconfirmed]  https://launchpad.net/bugs/77366
<kylem> ...
<Keybuk> SafeDisc thingy
<bettsp|school> What's the debian command to write a patch? There's a command that'll spawn a shell, let you edit the source, then save out your changes as a patch
<kylem> that's hilarious
<kylem> bettsp|school, dpatch
<thom> dpatch-edit-patch
<bettsp|school> kylem,thom: Thanks
<bettsp|school> I'm trying to make a patch for Nautilus to fix the small name column bug
<mvo> could some native speaker please review http://paste.ubuntu-nl.org/12523/ ?
<cjwatson> bettsp|school: this stuff depends on the package you're patching
<iwj> mvo: Sure.
<cjwatson> bettsp|school: for nautilus, it's cdbs-edit-patch
<iwj> `Play' or perhaps `play back', rather than `playback'.
<mvo> play sounds better I guess, changed
<iwj> And I think both big sentences should be reversed.
<iwj> Hmm, perhaps not the first one, but it might benefit from a comma.
<iwj> `To play media files, corresponding ...'
<cjwatson> perhaps "suitable" rather than "corresponding"?
<iwj> `The search will also include software not officially supported [by/in]  Ubuntu'
<cjwatson> or in fact "You need to install suitable codecs to play media files."
<iwj> Or `... software not part of the officially support Ubuntu' or some such.
<iwj> cjwatson: Much better.
<iwj> And `This search'.
<iwj> `This search will also include software which is not officially supported'.
<pitti> bettsp|school: nautilus doesn't use dpatch, that won't work
<iwj> But don't we search first and ask questions later and if not why not ?
<pitti> bettsp|school: cdbs-edit-patch will probably do
<mvo> iwj, cjwatson: http://paste.ubuntu-nl.org/12525/
<mvo> better?
<mvo> iwj: we got bugreports that a progress window out of the blue and this window with the codecs is confusing.
<mvo> iwj: so the idea was to ask nicely first so that people know what will happen. i think thats fine given that the amount of codecs that get installed is rather limited, so you don't see this question very often
<iwj> IC
<glatzor> hi mvo
<iwj> That text is better.
<mvo> iwj: thanks for your review
<iwj> NP
<mjg59> iwj: Does fdisk fail with ENOSPC as well?
<iwj> Yes, well, it doesn't tell you the errno value.
<iwj> And mdadm complains that the device is too small.
<iwj> cfdisk and fdisk complain that they can't read it, after opening it and getting EOF.
<iwj> (Looking at strace.)(
<iwj> Dammit, you crappy program, coredump!
<glatzor> iwj: thanks Ian for polishing
<exoide> Hi, can someone give me some reference about the .symtab section in an ELF file?
<glatzor> mvo: do we already know at the time when the dialog is shown if we can support the file?
<mvo> glatzor: yes, we know that we can
<mvo> glatzor: I commited the latest version of the question to bzr, I have a appointment now and will be back in ~30-45min
<glatzor> mvo: fine. I am going out running too
<mvo> glatzor: have fun
<glatzor> mvo: good luck for your appointment - sounds so seriously :)
<mvo> glatzor: it is!
<iwj> mjg59: Any ideas ?  It seems quite bizarre to me.  I would think it was some kind of large disk overflow bug except that that would presumably happen to everyone and I can't seem to find any trace of it.
<mjg59> Nothing that springs to mind
<mjg59> There's no odd jumpers on it?
<iwj> mjg59: It's got the `limit to 1.5Gb/s' jumper fitted.
<mjg59> Shouldn't make any difference
<iwj> That's what I thought I :-).
<iwj> The thing is, it shows up just fine with its proper size in /proc/partitions.
<mjg59> Nothig in dmesg when it returns that?
<iwj> No.
<iwj> My kernel is somewhat out of date.  -10.17, and most recent is -13.21.
<mjg59> Doubt it makes a difference, but checking the latest would probably help
<iwj> I'll do an update and see if it helps ...
<kylem> iwj, try bs=512
<iwj> 0+0 records in
<kylem> cool
<iwj> 512 would be 256kib.
<Amaranth> pochu: we need to work in shifts on compiz bugs or something :)
<pochu> Amaranth: I want day shift ;)
<Amaranth> haha
<Amaranth> pochu: if an apport backtrace has a compiz-extra plugin at the top reassign it to compiz-extra
<pochu> Amaranth: we have a ton of crash dups, I'll take a look this evening
<Amaranth> pochu: and then forget it ever existed ;)
<pochu> hehe
<pochu> we can assign it to whoever uploaded it to the repos :)
<ogra> mdz, ??
<Amaranth> well, hopefully it won't be in the repos
<mdz> ogra: yes?
<ogra> mdz, ltsp-client-builder.udeb is included in d-i since it exists
<ogra> its just not selected by default
<mdz> ogra: I don't think that contradicts my email; was it unclear?
<pochu> Amaranth: it's already in (universe)
<ogra> mdz, you want a menu entry on the Cd menu ? your mail says we should include ltsp-client-builder.udeb and enable it ... part one is done  ...
<ogra> oh, wait ... server CD ...
<ogra> ignore me
<Amaranth> pochu: right, hopefully i can get it removed :)
<mdz> ogra: maybe I misunderstand.  it is part of the installer seed for edubuntu, not for ubuntu
<pochu> Amaranth: oh, cool :)
<mdz> but we want the functionality in both
<ogra> it is in ubuntu as well (since you added it), i dont know about the server CD
<ogra> you once added the ltsp bits to ubuntu ... when i wrote ltsp-client-builder it was automatically added to d-i's menu ...
<ogra> as long as nobody removed it without me knowing it should still all be there and you should be able to build an ltsp server in the expert install by manually selecting it
<mdz> ogra: I do not think the udeb is even on the CD
<ogra> hmm
<ogra> then it got removed, i'm sure it was in edgy
<mdz> ogra: and the packages aren't, so the entire desktop would need to be downloaded
<mdz> ogra: we're talking about enabling the turnkey experience during installation; i know the pieces are there, but they need to be connected
<ogra> mdz, right, for server thats true ... but the regular ubuntu alternate should have everything
* ogra checks the ubuntu seeds
<mdz> ogra: the ubuntu installer seed, which is shared with all Ubuntu CDs (including the server) does not include the ltsp udeb
<ogra> mdz, but ship includes ltsp-server-standalone and ltsp-client
<mdz> ogra: those are just packages, nothing to do with the installer
<ogra> hmm, why was i under the impression that puls the udeb in ... silly 
<ogra> right, then it needs to be added to the installer 
<iwj> This constant update-initramfs is _painful_.
<ogra> yeah, we should have a queueing mechanism 
<Mithrandir> iwj: just implement dpkg triggers! :-)
<iwj> Right.
<Mithrandir> "just"
<iwj> Go to debian-dpkg and argue about the spec.  I'll probably repost it in a week or so after the svenl thing has died down a bit.
<_ion> Ignore complaints and just implement it. :-)
<iwj> Yeah, but then I get complaints afterwards about how I did it wrong.
<iwj> Eg, update-info.
<iwj> Yay!  It has updated the initramfs.  Now all it needs to do is ... update the initramfs.
<iwj> But I have to go and catch my train or I won't get to go climbing.
<iwj> TTFN everyone.
<cjwatson> ogra: adding it to the Ubuntu installer seed should be safe, yes
<ogra> well, you will likely need the -i396 image as well, that might be the bug drawback for the common alternate
<ogra> s/bug/big/
<ogra> i can make a small change that it automaticaly falls back to -generic, but you will get probs on several clients then i guess
<cjwatson> problems worse than it not installing at all? :)
<ogra> well, not booting worst case
<cjwatson> using base-installer's kernel detection would be good, although it may be too late for that
<ogra> like locking up in usplash or something ...
<ogra> well, we can spec it for feisty+1 
<cjwatson> it should be entirely possible to detect whether -generic will work and Just Do It Damnit :-)
<ogra> i'l put that on my list
<cjwatson> I wrote that interface in base-installer, so I'm happy to help you with that
<ogra> well, it owuld be possible i guess from the tftp side :) 
<ogra> but you would still need the right fallback kernel then :P
<cjwatson> obviously, yes
<ogra> obviously the right fix would be to have the kernel switch on and off the features we need on demand ;)
<ogra> without dpkg involved anywhere :)
<cjwatson> ogra: there's plenty of room on the server CD; no reason not to include the -386 kernel there
<ogra> well, you need a desktop as well for ltsp
<ogra> then you use up all the space
<cjwatson> true
<ogra> we should have a cut down gnome for such cases ...
<ogra> but cutting it down will make it loose functionallity :(
<superm1> BenC, ping
<BenC> superm1: pong
<superm1> BenC, just wanted to see if you had gotten a chance to look over the lirc patch, or if there was anything that you wanted me to change with regard to it. i've got a little time to kill right now if need be
<BenC> superm1: Not yet, I've been working on some other things, but I should be able to get to it by the end of the week
<superm1> BenC, alright sounds good :)
<shawarma> Is there any way to make gdb save a core file representing the current state of a traced application, ie. dumping the traced application's core?
<Chipzz> hrrrrm
<Chipzz> maybe killing the app with a SIG11?
<DarkSun88> Hi all
<shawarma> Chipzz: Nah, that just gives me back the gdb prompt.
<shawarma> Chipzz: I can make gdb dump its own core, but that's not quite what I'm after. :-)
<cjwatson> shawarma: gcore
<shawarma> cjwatson: Great! That's it. Thanks.
<cjwatson> (short for generate-core-file)
<shawarma> cjwatson: Did you remember that one or did you find it in the online help? I've been looking for 10 minutes and couldn't spot it.
<cjwatson> I looked it up
<cjwatson> 'info gdb' C-s core C-s C-s C-s ... and see:
<cjwatson> * Core File Generation::        Cause a program dump its core
<cjwatson> may just have been luckier at searching than you
<shawarma> cjwatson: Oh, of course it's in info. Thanks, RMS!:-(
<shawarma> cjwatson: Clearly. Well, thanks a bundle!
<cjwatson> while as the man-db maintainer I obviously prefer man pages, in some cases I am resigned to my fate
<jcole> does the new ubuntu installer populate the debconf database properly?
<_ion> Windows Help for the win
<cjwatson> though actually I think the gdb documentation is a fairly good example of where man pages get rather too long and unstructured
<cjwatson> jcole: "new" in what sense, and "properly" in what way?
<shawarma> cjwatson: I suppose that's true. I still can't spot it in the online help, though. Strange. It's a much more useful command than most of the silly ones they actually describe there. :-)
<cjwatson> shawarma: appears to be under 'help files'
<cjwatson> I often find gdb's online help to be rather hard to navigate though
<jcole> cjwatson: well, the edgy gui installer didn't update debconf values for stuff like mirror/suite, mirror/http/hostname, mirror/http/directory, passwd/username, partition recipe, etc.
<jcole> cjwatson: we do installs in our company and utilize the debconf db to configure a system
<shawarma> cjwatson: So it does. My gdb-fu is seriously lacking today.
<cjwatson> jcole: I would much appreciate you filing bugs about that sort of thing
<cjwatson> this is the first I've heard of it
<cjwatson> some of those are not ones that d-i copies over either, though
<cjwatson> hmm - actually, no, don't file a bug in this case :) d-i doesn't copy any of those debconf questions to the installed system, so I don't see why ubiquity should
<jcole> cjwatson: sure it does
<cjwatson> not to the main debconf db
<jcole> cjwatson: oh yeah, we use "debconf-get-selections --installer"
<cjwatson> it copies across its own database to /var/log/installer/cdebconf/
<cjwatson> jcole: ok, well, I can't promise everything, but if you file a bug I may be able to arrange for some of those to be recorded
<cjwatson> putting them in /var/log/installer/cdebconf/ would be kind of wrong though, as ubiquity doesn't (yet?) use cdebconf
<cjwatson> so might need to hack debconf-get-selections too
<jcole> cjwatson: maybe something like "debconf-get-selections --ubiquity"
<cjwatson> no, I'd just make --installer DTRT
<cjwatson> I don't really approve of other things having to be hacked explicitly for ubiquity - makes it harder to get patches accepted
<jcole> time for lunch
<damg> where does gnome-app-install fetch half of its i18n-stings from? I'm trying to translate the app, but half of the installer-specific strings are not in the po file ...
<jwendell> seb128, i got trouble with gdm-ubuntu4
<jwendell> seb128, it won't accept any key from keyboard
<seb128> jwendell: what sort of trouble?
<seb128> I doubt it's gdm
<jwendell> seb128, i was unable to type my login or password
<seb128> the update is ubuntu-sounds Depends changed to Recommends
<shawarma> damg: It's probably in Rosetta.
<shawarma> damg: (on launchpad)
<jwendell> seb128, even ctrl alt f1 worked
<seb128> ?
<damg> shackan, thank you, I'll investigate it
<seb128> jwendell: didn't work you mean?
<jwendell> seb128, the only thing working is ctrl alt backspace
<jwendell> seb128, yep did not
<seb128> the ctrl-alt-f<n> not working is a known bug
<seb128> the keyboard not work is likely xorg bug
<seb128> what else did you update?
<jwendell> seb128, i dropped patch 90---- and everything worked
<seb128> gdm code didn't change
<seb128> that patch is not new 
<seb128> weird
<seb128> jwendell: I would say it's a coincidence
<seb128> could you try updating gdm to the official version again?
<jwendell> seb128, i dropped that patch, rebuild, and installed new package and it worked
<seb128> could you try to build a version with the patch
<seb128> I doubt it's it
<seb128> it's only an xioerror hack
<jwendell> seb128, your latest upload (ubuntu3) included that patch, right?
<seb128> which has been dropped
<seb128> latest is ubuntu4
<seb128> which changes the Depends on ubuntu-sound to a Recommends
<jwendell> but ubuntu4 only changed control file...
<seb128> right
<seb128> 0ubuntu3 is some days old
<seb128> do you update daily?
<cjwatson> Riddell: could you please look at bug 86175?
<ubotu> Malone bug 86175 in ubiquity "[kde-ui]  username_error_reason widget is misplaced" [High,Confirmed]  https://launchpad.net/bugs/86175
<jwendell> seb128, yep, but i got this version (ubuntu3) only today
<cjwatson> Riddell: I've just been fighting with Designer for about half an hour trying to get it such that the error message will actually be visible, and haven't been getting very far
<seb128> jwendell: weird
<cjwatson> Riddell: you can test it by entering a username with capital letters in it
<seb128> jwendell: you have the only one who complained about that and I don't get how to patch could break your keyboard
<jwendell> seb128, i did this update early morning, around 12h i did another update (ubuntu4), and now i restarted my laptop and couldn't log in
<seb128> jwendell: could you try to build a patched version and see if you get the bug again?
<seb128> maybe something in xorg went wrong
<jwendell> seb128, i've made a ubuntu5 package. it's enough to downgrade to ubuntu4 ?
<seb128> yep
<jwendell> seb128, i'll test with gdmxnest
<seb128> ok
<jwendell> seb128, it's saying that i have a newer version, how to force? (apt-get)
<seb128> jwendell: apt-get install gdm/feisty
<seb128> or =2.18.0-0ubuntu4
<jwendell> seb128, i'll restart
<jwendell> seb128, let me explain what happened:
<jwendell> i installed NX, and had to add the line '/usr/XN/lib' into /etc/ld.so.conf
<jwendell> seb128, so, gdm, or X was linking to that libs, not system libs
<jwendell> seb128, i noticed that when i was installing my ubuntu5 package. dpkg told me something about a function not found on that lib
<jwendell> seb128, weird, no?
<seb128> not really
<seb128> that's why you should not install things out of the packaging system :p
<jwendell> :)
<seb128> not due to the gdm patch then, good ;)
<jwendell> seb128, seems to be ldconfig prioritize that dirs found on /etc/ld.so.conf
<jwendell> seb128, yep, good :)
<gnomefreak> shouldnt epiphany home page be a ubuntu one not a kubuntu one?
<_ion> Hi BenC. Have you perhaps had a chance to review the third patch i sent?
<MaTRiKaTiON> hi
<lamont> so how does one tell network-mangler to leave the machine the hell alone?
<lamont> other than apt-get remove --purge network-manager?
<lamont> on the bright side, it didn't trash /etc/network/interfaces at install like it used to
<lifeless> rm /etc/dbus-1/event.d/25NetworkManager ?
<lamont> lifeless: the purge took care of that too... :-)
<lamont> otoh, an upgrade would probably recreate that file, no?
<lifeless> well you asked for alternatives :)
<jcole> lamont: lol, i had a hell of a time the other day trying configure my network due to the "helping" of NetworkManager
<lifeless> dpkg-divert my riend, dpgk-divert
<lamont>  dpkg-divert --list | grep ^local
<lamont> local diversion of /usr/bin/gnome-session to /usr/bin/gnome-session.real
<lamont> local diversion of /usr/bin/totem to /usr/bin/totem.real
<lamont> local diversion of /usr/lib/totem/totem-mozilla-viewer to /usr/lib/totem/totem-mozilla-viewer.real
* lamont gets out a big rock
* lamont feels a little bit guilty about gnome-session
<jcole> lamont: dpkg-divert --add --rename --divert $1.mydivert $1
<lamont> I wouldn't need that if there were a way to tell gnome session 'start this, and don't start anything after that until it exits'
<Burgwork> lamont: upstream is completely rewriting gnome-session, so if you want to get input in, now is good time
<lamont> jcole: --local as well
<lamont> Burgwork: venue?
<lamont> that is, where should I go to put in input?
<Burgwork> checking
<lamont> that's what my gnome-session does: run one thing, once that's done, exec gnome-session.real
<tepsipakki> lamont: put 'exit 0' in /etc/default/NetworkManager{,Dispatcher}
<lamont> tepsipakki: that's  just vile...
<tepsipakki> how so :)
<Burgwork> lamont: this appears to be it http://live.gnome.org/SessionManagement
<ogra> lamont, jus do the purge now and wait until Mithrandir has fixed it ... then find out how the new flag for /e/n/i is called
<ogra> its a known issue he's working on
<lamont> ogra: thanks
<gnomefreak> has apt/synaptic/adept so on patched for geforce4 cards and feistys nvidia yet?
<ogra> lamont, alternatively you can bring up your static interfaces manually *after* NM has connected anything 
<gnomefreak> 97xx stopped support for geforce4 cards that is leaving alot of people X-less
<mvo> gnomefreak: no, that will most likely be handled inside the nvidia-glx package itself
<ogra> but you have to do it every login indeed
<gnomefreak> ok cool
<stratus> ogra: a co-worker cooked up l18n for s-c-p (should be integrated with tcm by us soon), interested?
<ogra> stratus, talk to cbx33 please, he maintains it ... i'm only the upload bitch and fix bugs 
<stratus> ogra: oh will do, ok.
<ogra> stratus, you should also have a look at python-ltsp 
<ajmitch> hi stratus 
<ogra> i plan to develop some gui tools on top of it in feisty+1
<ogra> and i plan to merge it with python-tcm
<ogra> so you have all server and user actions you will ever need in ltsp in one python module
<stratus> ogra: really interesting stuff.
<stratus> ajmitch: hey!
#ubuntu-devel 2007-03-29
<enyc> I have changed the. status tags on bugs 78005 77485 ... was this right for me to do this as per the new MOTU-SRU policy?
<ubotu> Malone bug 78005 in qpsmtpd "[SRU]  request: dapper:qpsmtpd fix for bug #72602" [Undecided,Fix committed]  https://launchpad.net/bugs/78005
<enyc> I'm a little confused whom is now supposed to do the release- upload.... or how I do it....
<enyc> Please let me know what todo ?? [??] 
<enyc> (note that both bugs have now passed the ">=7 days aging and >=2 'worksforme' requirements!
<enyc> )
<enyc> next-step suggestion needed please ;-)
* enyc thinks... error!
<andre_pl_> i seem to still be plagued by this bug: https://launchpad.net/ubuntu/+source/udev/+bug/53923 with the tifm 5-in-1 media card reader. 
<ubotu> Malone bug 53923 in udev "Texas Instruments Card reader (8039) not working" [Medium,Confirmed]  
<andre_pl_> but its apparently fixed.
<andre_pl_> wait, no its not. Lol.
<andre_pl_> how can I help to fix it?
<Chipzz> andre_pl_: I guess most developers are asleep now; but you may get more response on #ubuntu-kernel (just a wild gues without looking at the bug)
<sladen> andre_pl_: confirm your experiences in the bug report
<sladen> andre_pl_: they'll get recorded there, but will just scroll past here :)
<andre_pl_> sladen: thanks
<Chipzz> sladen: you can disregard my last comment about hal and the nvidia driver and suspend btw :)
<sladen> andre_pl_: when it comes to eventually doing a test it's important to know who can test the result
<sladen> Chipzz: I didn't see it in IRC hilights, was it on launchpad?
<Chipzz> yeah, launchpad
<Chipzz> made it last week
<sladen> Chipzz: okay, I'll get to it in-time, but if the comment isn't correct/is now out of date, can you comment again so that we know what the status quo is
<Chipzz> sladen: thanx for the comments and hints in that bugreport btw :)
<Chipzz> I will, but not now ;)
* Chipzz going to sleep in a few minutes
<fabbione> morning
<sladen> just, getting, light
<thoreauputic> Just wanted to say - Feisty is looking great! Congrats to all ... :-)
<Mithrandir> lifeless: is there any reason why opensync is a few versions behind upstream?
<ajmitch> hi Mithrandir 
<manchicken__> Anybody know what "ubuntu-linux.withishow.com" is all about?
<ajmitch> yet another planet ripoff?
<ajmitch> there are a couple I've seen
<manchicken__> It looks like they're trying to syndicate stuff from the ubuntu planet, and then comment on blogs to attract people to their advertising.
<ajmitch> back later
<Mithrandir> hiya Andrew.
<pitti> Mithrandir: FF-wise, would you be ok with me adding a --confirm switch to debcommit? (see mdz's mail re bzr package maintenance)
<Mithrandir> pitti: sure
<pitti> Mithrandir: hmm, if I touch the package anyway, I guess I'll also include requestsync, to get rid of another long-standing low-priority TODO item
<Mithrandir> sure
<tuxcrafter> good day eveyone
<lifeless> Mithrandir: I suck ?
<lifeless> or azeem does. Or we both do.
<lifeless> the theory is that azeem and I are co-maintaining the suite. However it seems to have panned out that I maintain libopensync* and he maintains the plugins and gui.
<Mithrandir> ook
<Mithrandir> I have a personal interest in getting my phone to sync with evo, you see, and I think the newer upstream versions fixes that.
<Mithrandir> tepsipakki: regarding the ndiswrapper UVFe.. it's a fairly big diff which is hard to review due to the traceexit => exit changes (and other similar ones).  Do you have any reports from people running your latest package and where it works for them?
<lifeless> Mithrandir: I have a 'anyone can NMU' policy on all my packages.
<lifeless> Mithrandir: so if you ahve the time, upload away. It will want an ABI change though, I'm pretty sure upstream fucked the current release of the plugins et all across the recent version releases.
<Mithrandir> lifeless: it'd require a motu-uvf exception too, so I'm trying to get somebody else to do it.
<lifeless> Mithrandir: haha
<tepsipakki> Mithrandir: not yet, but as you can see, most of the changes are in driver/ which isn't used in ubuntu
<tepsipakki> the driver is in our kernel
<Mithrandir> tepsipakki: point.
<tepsipakki> and that is already 1.38, it's just a matter of updating the utils
<Mithrandir> hurrah, I get to review somebody else's perl code.
<carlos> pitti: Hi, would you like to try latest fesity export?
<azeem> lifeless: there's the problem that opensync-0.22 or so has some different database format, so users need to remove parts of their ~/.opensync
<carlos> pitti: it should have the weird new line chars removed completely
<azeem> huh, opensync-0.22, my terminal is acting up
<carlos> pitti: I did it also for the other distros
<pitti> carlos: I already dist-upgraded today
<carlos> dist-upgraded?
<Mithrandir> azeem: just make the tools notice it and run opensync --reset (or the equivalent) when they detect the older database format?
<pitti> carlos: current daily langpacks are from 20070327 timestamp
<carlos> so you pushed yesterday tarball?
<pitti> carlos: no, the daily ones on people
<pitti> I didn't upload them to feisty yet, since you asked me to wait
<seb128> hi carlos
<seb128> carlos: did you do the french translations change yet? ;)
<azeem> Mithrandir: that's the second problem, the GTK GUI "tool" currently in feisty is rotten and not really usable
<azeem> a first step would be to use the one from unstable, but I wasn't sure whether this is still possible
<carlos> seb128: no, I hadn't time, I was finishing the cleanup and run out of time to do that, but I plan to request it today
<Mithrandir> azeem: kitchensync or multisync0.90 you mean?
<pitti> carlos: oh, there's a 20070328 tarball from 2 o'clock today; that's the good one now?
<carlos> pitti: would be possible to force a refresh now?
<azeem> multisync0.09
<Mithrandir> kitchensink is maybe the kde one?
<carlos> pitti: yeah
<carlos> I had to do some fixes so it was built later than expected
<pitti> carlos: sure; I usually build them in the afternoon, but I'll crank up one now
<azeem> Mithrandir: yes, and AFAIK nobody packaged an opensync-enabled kitchensync until now
<carlos> pitti: thank you
<seb128> carlos: ok, thank you, let me know when it's done
<carlos> seb128: sure
<seb128> cool
<azeem> but maybe somebody from kubuntu did in the meantime, I haven't checked in a while
<pitti> carlos: oh, in fact it's already running; I forgot, I build them at 0800 rookery time
<carlos> but those are for Edgy, Hoary and Dapper, isn't them?
<Mithrandir> azeem: http://www.in.fh-merseburg.de/~jahn/opensync-0.21/pool/main/o/opensync-integration-kitchensync/ isn't it?
<pitti> carlos: no, I build dailies for feisty, too
<carlos> oh, so you always use an old Feisty package
<carlos> ?
<azeem> Mithrandir: yes
<lifeless> azeem: yeah
<azeem> hrm right, Matthias did it in the meantime, could've guessed
<lifeless> azeem: its why I haven't packaged it, I know it needs testing
<lifeless> and doco and stuff
<dholbach> hello
<siretart> hallo dholbach 
<dholbach> hey siretart
<dholbach> how's it going?
<siretart> oh, thanks. 
<tuxcrafter> i got a very anoying bug here, i am testing openoffice 2.2 in feisty and my odt documents from v2.1 are not opened the same in 2.2 how does this come, i mean odt is a open standard and should be backwards compatible?! do you feisty users have the same problem?
<tepsipakki> if someone would like to test the new upstream intel driver (1.9.93 aka 2.0rc3), here it is: http://users.tkk.fi/~tjaalton/xorg72/new/
<tepsipakki> that's xserver-xorg-video-intel
<tepsipakki> modesetting-branch merged in
<StevenK> Mithrandir: When you have a sec, I'm curious why the 1.4-12build1 upload of imaze didn't register a build on amd64 or ia64.
<tepsipakki> it needs the new server -3ubuntu6 I just uploaded, but a deb is available from the url
<Mithrandir> StevenK: might be a fallout of yesterday's hiccups; I'm running the queue builder again and we can see if that helps.
<Mithrandir> StevenK: ah, it's in PaS
<Mithrandir> does it work and run on amd64/ia64?
<StevenK> Hrm. I know it builds and installs fine.
<tuxcrafter> bye
<Mithrandir> mail infinity or lamont to get PaS updated in Debian and we'll pick it up.
<StevenK> On amd64, anyway, since I'm too cheap to buy an Itanic :-P
<Fujitsu> StevenK: I was going to ask how you'd tested that :P
<StevenK> Fujitsu: There's always merkel.debian.org. For me, anyway.
<Fujitsu> You and your evil uber-powers.
* StevenK smirks.
<Mithrandir> hm, no, that's just imaze-xview.
<Mithrandir> I can't read.
<StevenK> Mithrandir: xview is in the archive for amd64.
<Mithrandir> StevenK: I don't know, I'll have to ask cprov.
* StevenK nods.
<doko> ARGH!!! feisty shuts down my laptop way too often due to "critical" temparature
<StevenK> doko: Where critical is it might make the desk slightly warm? :-P
<Treenaks> doko: open it up,remove dust :)
<Lure> azeem, Mithrandir: I can work on kitchensync update if you will do opensync upgrade
<geser> StevenK: as you uploaded xview with amd64 support, does it work without the patch from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320155 ?
<ubotu> Debian bug 320155 in xview "xview: amd64 support" [Wishlist,Open]  
* Lure is also not happy to not be able to sync his phone
<Mithrandir> Lure: opensync is in universe, so it'd require motu-uvf approval, not ubuntu-release approval, but I would be quite happy if somebody did the work to make it work.
<Lure> Mithrandir: afair, we need to package it as debian is not on latest, right?
<Mithrandir> yes.
<Mithrandir> Lure: but you'd be better off starting talking to motu-uvf to see if they think it's worth it.
<Lure> Mithrandir: will check this first, the problem is it is hard to discuss it as nobody has tried it to confirm the benefits
<Lure> Mithrandir: I can probably try it now, that bluetooth is fixed in kubuntu ;-)
<_ion> pitti: "Yo inicie efectos del escritorio y me marco que no tengo el composite habilitado y luego marco el error."  yeah, thanks a lot for the bug report! ;-)
<pitti> _ion: comprehende, amigos?
<Mithrandir> "Tango and Composite makes my Luggage report an error".
<pochu> _ion: I started desktop-effects and it told me I don't have composite enabled, and after that there was an error ;)
<_ion> pochu: Hehe, thanks. The bug report *did* contain apport info, which explained everything, though, so i was just joking.
<pochu> _ion: you could told it before :p
<pochu> however, it wasn't a great effort, since my spanish is great :)
<tepsipakki> eh, why do we have ndiswrapper-1.1 in main?
<pitti> tepsipakki: it's on the kill list
<tepsipakki> pitti: groovy
<pochu> well, it was a great effort, because my enghish isn't :(
<pitti> tepsipakki: bug 92622
<ubotu> Malone bug 92622 in ndiswrapper-1.1 "[REMOVE]  Please remove ndiswrapper-1.1 from archives" [Undecided,Confirmed]  https://launchpad.net/bugs/92622
<tepsipakki> pochu: new, working intel driver available
<_ion> pochu: Sorry for causing extra work. :-)
<pitti> tepsipakki: I just wante to wait for the last reverse dependency to be fixed
<tepsipakki> pitti: ok
<tepsipakki> just looking at the list of ndiswrapper bugs
<pochu> tepsipakki: cool! :)
<tepsipakki> removing -1.1 would fix bug 59983, I think
<ubotu> Malone bug 59983 in ndiswrapper "ndiswrapper in edgy broken" [Low,Confirmed]  https://launchpad.net/bugs/59983
<Mithrandir> pitti: there doesn't seem to be any reverse deps on ndiswrapper-1.1's binaries?
<pitti> Mithrandir: right, because it was fixed recently (see bug trail)
<tepsipakki> no low hanging fruits left there, it seems
<Mithrandir> ahkay.
<Mithrandir> tepsipakki: 59983 is one of those where I think we'll just have to work around in the update manager
<tepsipakki> guess so
<janimo> pitti: hi, is there a guideline in naming locales, in particular in the mozilla-firefox-locale packages? When is it recommenede to us lo_LO vs lo ?
<janimo> pitti: as there are locales which are specific to a single country but still use the longer form (hu_HU, ro_RO) while other the simpler (sk, af)
<pitti> janimo: the longer ones are mainly for hysterical raisins
<janimo> pitti: what I am confronted with is, that there's a ro.xpi for ff 2.0 and it uses the ro locale all over, but teh current packaging stub have ro_RO
<pitti> janimo: just to save us from renaming the existing packages yet again
<pitti> janimo: for new languages, we should use whatever upstream uses
<janimo> pitti: ok, I file a bug on mozilla-firefox-locales-all and attach the ro.xpi, is that the procedure?
<pitti> janimo: you don't need to attach it if upstream has it
<pitti> asac: ^ we should update m-f-local-all to 2.0.0.3, right?
<pitti> janimo: ^ or just file a general bug about that
<pitti> ugh, it's still at .1
<janimo> pitti: I am not sure it's in upstream firefox, I think it's provided asa separate extension. I'll check though
<pitti> janimo: in this case, attaching it is fine
<dholbach> ogra: will we get dia 0.96-final?
<dholbach> ogra: it seems to fix bug 93303
<ubotu> Malone bug 93303 in dia "Program Dia crashes when deleting a diagram object" [Medium,Confirmed]  https://launchpad.net/bugs/93303
<pitti> _ion: hm, did you see bug 93209? yet another missing ID
<ubotu> Malone bug 93209 in restricted-manager "Fails to detect Nvidia 3D driver" [Medium,In progress]  https://launchpad.net/bugs/93209
<pitti> _ion: hm, current package does not have 'manual' lists any more, does it?
<opi> guys, can you point me to the person who owns ubuntu-*.org DNS servers? We're moving our servers and need small change in IN A records. :)
<opi> Smurfix was the BOHF in 2004, but I renember his server went down and the DNS moved somewhere
<highvoltage> opi: you can reach the admins on #canonical-sysadmin
<opi> highvoltage: oh! Thanks!
<highvoltage> opi: any time
<kwwii> dholbach: btw. I commited another session splash last night (fixed a small problem)
<dholbach> kwwii: uploaded
<kwwii> dholbach: excellent, thanks :-)
<dholbach> de rien
<_ion> pitti: % modinfo -F alias nvidia | grep 01D8
<_ion> pci:v000010DEd000001D8sv*sd*bc03sc*i*
<_ion> pitti: Perhaps that was one of the IDs the amd64 port doesn't support, or something.
<pitti> _ion: hmm, that's with your new l-r-m patch-of-doom?
<pitti> _ion: aah, that's entirely possible; I generated it on amd64
<pitti> _ion: thanks
<_ion> pitti: Yeah, but the list is exactly the same as the modules.alias.override list generated from the 9631 x86 driver.
<ajmitch> hi
<_ion> pitti: Yeah, the amd64 port indeed doesn't list 01D8, whereas the x86 port of both 96xx and 97xx list that.
<pitti> _ion: I changed the bug accordingly
<_ion> pitti: It would be a huge pain to maintain both x86 and amd64 lists in the restricted-manager package. We probably should just wait until l-r-m generates the listings.
<pitti> _ion: right, that's what I wrote in the bug
<_ion> pitti: Btw, if it's ever needed to add manual entries, they would go to something like /usr/share/restricted-manager/modalias_override/nvidia.manual. The filename doesn't matter, but i think it's good to add '.manual' to manually edited files.
<pitti> ah, great
<pitti> well, I hope that this entire crack will soon disappear at all from r-m ;)
<_ion> Yeah. :-)
<_ion> /usr/share/restricted-manager/modalias_override/ipw3945.manual probably needs to stay, though.
<_ion> since it doesn't seem to be a kernel module, but some kind of a daemon.
<pitti> ah, right
<ogra> dholbach, yes, i'm on it, the documentation is horribly broken, wroking on a patch here 
<dholbach> ogra: ok
<ogra> somehow the xml is messed up 
<pochu> if any archive-admin can take a look at bug 98532 :)
<ubotu> Malone bug 98532 in liferea "[UVFe]  Liferea 1.2.10b" [Undecided,Unconfirmed]  https://launchpad.net/bugs/98532
<pitti> pochu: nothing to do for archive admin
<pochu> sorry, release-admin :)
<pitti> pochu: if you want a sync, please turn this into a sync request and get UVF exception approval from Mithrandir 
<pochu> it's not a sync, since it's not in debian
<pitti> ah, ok
<pochu> but an uvf exception, yes :)
<Mithrandir> pochu: that's not "admin" at all, it's "ubuntu-release" or "the release team". :-P
<pochu> hehe
<Mithrandir> anyway, looks sane, approved
<pochu> so you or cjwatson should look at it, as the LP team page says :)
<pochu> Mithrandir: cool, thanks :)
<azeem> Mithrandir: I filed https://bugs.launchpad.net/ubuntu/+source/multisync0.90/+bug/98545 now for multisync0.90
<ubotu> Malone bug 98545 in multisync0.90 "[UVFe Sync Request]  multisync0.90 0.91.0-3" [Undecided,Unconfirmed]  
<Mithrandir> azeem: cheers.  I think it would make sense to get an approval for the whole suite, not just multisync.
<azeem> Mithrandir: well, the rest isn't packaged yet, this one has been in unstable for a while
<dholbach> ogra: dia 0.96.1 is out
<dholbach> ogra: brown paper bag release
<ogra> meh
<ogra> ok
<ogra> thanks dholbach 
<dholbach> de rien ogra
<_lemsx1_> in Feisty when i choose to switch to another user (local) the computer goes to a black screen and the switch never happens
<_lemsx1_> this is an ATI card running fglrx driver. i'll try in another computer to see if there is a difference
* _lemsx1_ is connected as lemsx1 as well
<pitti> lemsx1|gone: I noticed the same on nvidia
<pitti> lemsx1|gone: one user had compiz, the other didn't
<lemsx1|gone> pitti: ahh, so it's not the card
<pitti> probably a composite bug in X.org
<lemsx1|gone> pitti: no compiz used here
<lemsx1|gone> pitti: did you try turning off composite? in my case it's explicitly off since fglrx doesn't support it
<pitti> lemsx1|gone: no, I didn't
<lemsx1|gone> pitti: i wonder under what package this bug should be filed
<pitti> lemsx1|gone: xorg-server AFAICS
<lemsx1|gone> pitti: ok. i see that there are two X processes running. one on :0 and another on :20
<john> Hello. I am running Feisty, and i would like to report a bug again "Disk Usage Analyzer" aka baobab. Launchpad doesn't allow me to report said bug on the gnome-utils section. So where can i do that?
<lemsx1|gone> pitti: if you login via ssh and kill gdm and the X processes, the machine hard-locks and you have to press the button to reset it
<lemsx1|gone> john: try #ubuntu-bugs
<cjwatson> pitti: should bug 71560 be milestoned for 7.04 final? even just some kind of "this crash will take a while to process - do you want to proceed" heuristic might help, if that's what it takes
<ubotu> Malone bug 71560 in apport "Crash information collection depletes resources, clogs up and crashes system" [Medium,Confirmed]  https://launchpad.net/bugs/71560
* lemsx1|gone is really gone
<john> thanks
<pitti> cjwatson: it already has that jumping progress bar; it usually should take less than a minute, but for the guy in the last comment it took 40 minutes or so; I don't have an idea how to predict that
<cjwatson> size of core dump?
<pitti> cjwatson: I could just limit the core dump to, let's say, 500 MB; that should help already
<pitti> cjwatson: but TBH I'm rather inclined to disable crash interception for the final release completely
<pitti> we neither have the retracing nor the triaging capacity for the flood of crashes in feisty stable, nor will we fix most of the crasher bugs in stables
<Keybuk> really?
<cjwatson> mm, somebody asked about that on the QA call last night
<Keybuk> I would strongly advocate having it enabled
<pitti> and for high-prio bugs we can still ask users to enable it again locally
<Keybuk> a friend has been much happier with feisty simply because apps don't just vanish, and she at least sees that dialog
<Keybuk> (she nearly always clicks "No")
<cjwatson> if it's easy to switch back on, I'd be in favour of disabling it by default
<pitti> it's on today's meeting agenda
<Keybuk> not to mention that sometimes you don't know there's been a crash
<pitti> cjwatson: it's changing /etc/default/apport back to enabled ATM
<cjwatson> I don't see why we can't say "an application crashed; do you want to do something about it?" without expensive core processing
<pitti> in feisty+1 we might have automatic dup detection and better malone handling and all that
<cjwatson> even in the typical case, what is it doing for that less-than-a-minute before it says "something crashed"?
<pitti> cjwatson: would be theoretically possible
<cjwatson> it should be SIGSEGV -> kernel writes core -> inotify -> dialog surey
<cjwatson> surely
<pitti> cjwatson: it reads the report and unpacks the core along with that; I know that this is suboptimal, but takes some invasive code changes to fix
<pitti> oh, the 'less than a minute' I alluded to was the gdb/dpkg processing
<pitti> for displaying the initial notification it just needs to read the file in /var/crash
<pitti> this entire process could do with some optimization and some rewriting of the lower-level classes, but that's not something I would do for feisty final
<cjwatson> perhaps a quick approach would be to simply notice that the file is there and (by default) display a notification before spending time reading it
<cjwatson> presumably even just reading (and parsing?) it can be pretty slow and memory-intensive for large core dumps
<pitti> right
<pitti> but in that case I like the idea of limiting the core dump size better
<pitti> if even merely writing/compressing the dump lasts 10 minutes on that user's machine
<cjwatson> that would have the benefit of simplicity, although I'd have thought that 500MB is too big
<pitti> since at that time we cannot really display any UI
<cjwatson> can it be related heuristically to free memory available?
<cjwatson> I suspect that in that user's case apport is running into swap trying to parse the crash dump and then the system starts thrashing
<pitti> cjwatson: certainly, yes
<cjwatson> and in that case, we're turning the situation from the random user's perspective from "it crashed. bugger. ok, restart it and worry about it later" to "it crashed. bugger. oh, now my system is unresponsive."
<cjwatson> which is suboptimal :)
<Keybuk> pitti: why does it need to "read" the file?
<Keybuk> can't it just mmap it?
<pitti> Keybuk: it's RFC822/base64 encoded
<Keybuk> heh
<pitti> however, due to the way we sort the fields, it would be enough to just read the top
<pitti> Keybuk: but as I said, merely writing the crash report when the crash itself happens already triggers that trashing problem
<Keybuk> sure, but at that point, they've clicked "Report Problem" so they're gonna expect some work
<Keybuk> no?
<cjwatson> it's three minutes from the crash to the initial dialog, not 10
<Keybuk> the computer is visibly playing pong
<pitti> Keybuk: no, when the crash happens, not when the UI pops up
<Keybuk> why does it do it then?
<cjwatson> oh, sorry, apparently nobody said it was 10 and I just misread something
<pitti> Keybuk: it needs to turn the kernel's stdin into a compressed report in /var/crash
<cjwatson> Keybuk: I think it's building it all in memory and then writing it out
<pitti> so, I think from all the optimizations that would be possible, the only thing that would be reasonable for feisty is to cap the core size to the free memory
<cjwatson> the core dump size limit would have to be in kernel_hook
<pitti> right
<cjwatson> can we notify the user that the crash happened, but that they didn't have enough free memory to deal with the crash?
<cjwatson> at least for Keybuk's "you don't know there's been a crash" thing
<pitti> cjwatson: yes, we could make the UI check for that case (no CoreDump in /var/crash/foo.crash)
<cjwatson> perhaps a CoreDumpSuppressed key in the report or something, and then teach frontends to avoid filing bugs about that
<cjwatson> can't just be lack-of-CoreDump because python crashes don't have that
<cjwatson> CoreDumpTooBig
<pitti> cjwatson: right, that's already taken care of; I meant lack of core dump for signal crashes
<cjwatson> ok
<cjwatson> so, going back, can I milestone this bug for 7.04 and summarise this conversation?
* pitti updates the bug accordingly
<cjwatson> ah, you're doing it
<cjwatson> thanks
<pitti> thanks for the discussion
<pitti> cjwatson: done; I'll file a separate bug about the optimization steps mentioned above (for feisty+1)
* pitti uploads restricted-manager of the day and is glad that bug reports have reached the level of discussing icon consistency now
<Keybuk> rofl
<_ion> pitti: :-)
<jwendell> any openoffice maintainer here?
<Seveas> doko is :)
<jwendell> doko, could you take a looh at bug 75478? It seems to be trivial to fix
<ubotu> Malone bug 75478 in openoffice.org "No shortcut to OpenOffice::Draw" [Medium,Confirmed]  https://launchpad.net/bugs/75478
<doko> jwendell: no, works as designed. https://wiki.ubuntu.com/MenusRevisited
<jwendell> doko, i don't understand why we have shortcuts for calc, write, etc... but none for draw. That wiki page does not explain this
<kwwii> my guess would be that nobody uses the paint program to draw pics except for those needed in  the other OO apps
<sn-> my guess is as openoffice is a office clone, it acts similar to the way ms office used to
<sn-> which i believe didn't have a seperate shortcut for the draw package, instead opened through whichever app you were using
<lemsx1> hello all. just wanted to add that switching users works perfectly fine on Intel graphic cards
<lemsx1> maybe the issue has something to do with ATI's and nvidia's only
<jsgotangco> lemsx1: pretty much
<pitti> lemsx1: it usually works for me as well, I just saw it once, ever
<jsgotangco> pitti!
<pitti> hi jsgotangco
<pitti> seb128, carlos: there, fresh new feisty langpacks, candidate for an official upload; wanna test?
<carlos> pitti: sure!
<carlos> pitti: daily snapshot repositories?
<seb128> without the french changes then? :/
<pitti> carlos: yep
<seb128> pitti: will test sure
<carlos> seb128: no, sorry
<pitti> seb128: -v ?
<carlos> seb128: but I will try to get a new tarball with that for tomorrow, not sure whether pitti would be able to use that, though
<pitti> seb128: I can mangle the french ones manually
<seb128> pitti: GNOME translator complained that they work go to /dev/null so carlos is going to do some rosetta magic to use upstream translations when available
<carlos> pitti: it depends on Rosetta export data
<carlos> maybe we could delay the French one until tomorrow
<pitti> seb128: ah, so it's not something I could fix by changing a couple of po files in the source?
<pitti> carlos: we can also update the French one tomorrow again
<seb128> pitti: no, it's "rosetta taking over nice translated with outdated broken ones"
<seb128> pitti: ok, let's do that
<seb128> update french again tomorrow
<pitti> seb128: updating four packages won't hurt anyone tomorrow
<pitti> seb128: and I'll update them again at least once, don't worry
<seb128> pitti: ok, cool
<carlos> ok
<carlos> I will handle everything to get it done today
<seb128> thank you
<lemsx1> pitti: usually works but lately is not working? that used to work for me on Dapper/Edgy
<izi_> pitti: i just uploaded a new patch for bug #97726 (you're martin right ?)
<ubotu> Malone bug 97726 in restricted-manager "Restricted Drivers Manager's "computer restart" icon is not consistent with other restart icons" [Low,Confirmed]  https://launchpad.net/bugs/97726
<pitti> izi_: splendid! thanks
<pitti> izi_: yes, I am Martin Pitt
<izi_> pitti, ok :)
<_ion> (There's the 'whois' command in your IRC client, too. :-) )
<izi_> sure
<bddebian> Heya
<_ion> benc: Any comments about the third patch? :-) I realized that i should have put the change_module_aliases script under debian/. Should i send a new patch to change its location?
<mvo> Riddell: my modification to make the kde dist-upgrader use kde debconf seems to work. we just need to ensure that libqt-perl is installed (is that default?)
<Hobbsee> mvo: it appears that...if a user upgrades while the proposed updates repository is enabled, they'll end up with an orphaned copy of app-install-data-commercial because edgy 6.3 > feisty 6
<Hobbsee> mvo: known?
<mvo> Hobbsee: no, good that you report it!
<StevenK> It's still probably an issue because 6.2 is in edgy-updates
<Hobbsee> mvo: right.  getting the original person to report it :)
<Hobbsee> mvo: will you just bump the version number, or do you have other stuff to add?
<Hobbsee> mvo: if it's just bumping the version number, i could probably do it, and give StevenK something to do with his new shiny upload powers
<Hobbsee> (to give you time to focus on other, mroe complicated stuff)
<Keybuk> Holy X Crash! Nvidia Man!
<seb128> dholbach: do you know why Tango theme inherit on crystalsvg?
<pitti> hey, it's not long any more until we will get the 100.000th bug report
<dholbach> seb128: because that's the 'desktop independent thing' - you can use it in kde too
<dholbach> so it can fall back to crystal
<dholbach> (for them)
<seb128> dholbach: it breaks the evolution icon
<dholbach> oh?
<dholbach> how so?
<seb128> dholbach: upstream install its own to hicolor
<seb128> and crystal is used before
<seb128> so we get the crystal one on the Human theme
<seb128> which is ugly
<dholbach> if you have crystal installed
<iwj> siretart: See my comment on bug 75681.  Aurelien managed to get some informative but unfortunately not sufficient debug info.  I've asked him and you for some more.
<ubotu> Malone bug 75681 in mdadm "boot-time race condition initializing md" [High,Confirmed]  https://launchpad.net/bugs/75681
<dholbach> seb128: hm, what do you suggest?
<seb128> dholbach: get a nice evolution icon to Human or Tangerine? ;)
<dholbach> seb128: ok, which icon is that?
<seb128> evolution
<tkamppeter> Anyone here who has a printer from HP?
<seb128> tkamppeter: I've an HP deskjet
<seb128> dholbach: dpkg -L evolution-common | grep icon
<tkamppeter> If so, please go to bug 98520 and follow the steps in my "CALL FOR TESTING" (2nd posting).
<ubotu> Malone bug 98520 in hplip "Feisty UVF ER: New HPLIP 1.7.3 release fixes lots of bugs" [Medium,Needs info]  https://launchpad.net/bugs/98520
<seb128> ok
<tkamppeter> seb128, thanks in advance.
<tkamppeter> Any other volunteers?
<siretart> iwj: sorry, I was on a buisness trip on monday and tuesday, and have managed to keep up with the mail backlog this morning. I'll test and provide the info this evening
<siretart> I had to deal with a lawer regarding REVU as well, but at least he was pretty kind
<siretart> iwj: you might be interested that since some weeks I don't obseve my raid devices coming up in degraded mode anymore (this was rather sporadic that time as well, though). what I'm rather observing is that only one of four raid devices "come up" automatically. `udevtrigger` does fix things for me however, and I can continue booting with CTRL-d
<Hobbsee> siretart:  a lawyer regarding REVU?
<Mithrandir> hiya Hobbsee 
<Hobbsee> hey Mithrandir!!!!
<siretart> Hobbsee: yes, someone uploaded a package with a cracked licence key inside
<siretart> Hobbsee: they asked me to have it removed from revu + google cache
<Hobbsee> siretart: fun.....
<pitti> siretart: hm, maybe REVU should have a robots.txt
<siretart> pitti: it does have now
<jcapote> anyone know where i can get the gnome.applet module for python?
<Hobbsee> siretart: that person now got banned from REVU?
<siretart> Hobbsee: I'm still waiting for him to answer my email
<lamont> pitti: is langpack stuff you or doko?
<pitti> lamont: me
<pitti> lamont: hello!
<lamont> oo.o/ia64 is giving ia64 livecd fits
<lamont> rather, the lack of oo.o binaries,  which get sucked in by task:ubuntu-desktop
<pitti> lamont: I cannot parse that, sorry
<lamont> task ubuntu-desktop pulls in oo.o pieces (lang pack depends on oo.o english help or some such??) and so the livecdfs build fails
* lamont grabs the exact error
<doko> lamont: get a bigger CD ;-P
<lamont> the longterm fix is to actually port oo.o to ia64, but the trampolines require someone with painfully intense knowledge of C++ vs C calling conventions, and assembly for the architecture in question...
<lamont> The following packages have unmet dependencies:
<lamont>   openoffice.org-help-en-us: Depends: openoffice.org-writer but it is not installable
<lamont> actually.... WHY IN THE HELL DOES oo.o-help DEPEND on OO.O binaries?
<lamont> doko: ^^???
<doko> lamont: because you need -writer to get it working
<lamont> vi doesn't work?
<siretart> isn't the -help package just data?
<doko> lamont: it's a db4.x database
<lamont> dropping that depends would allow ia64 to have a livecd (without oo.o, mind  you)
<lamont> and oo.o-writer is in task ubuntu-desktop itself, no?
<siretart> I had the impression that it was common practice to have -data packages to recommend the 'base' package rather than depend in order to break circular dependencies
<lamont> Task: ubuntu-desktop, kubuntu-desktop, edubuntu-desktop
<pitti> Keybuk: wrt. apport core dump size limit, do you agree that MemFree+Cached-Writeback (in /proc/meminfo) is a reasonable size?
<doko> siretart: but then people complain that help is broken, if -writer is not installed
<lamont> siretart: oo.o-help-en-us isn't a dep of -writer
<pitti> lamont: we could just drop language-support-en from the ia64 seed
<lamont> that means making it and the oo.o-help packages arch-any instead of arch-all
<lamont> otherwise the task install cataches them
<lamont> catches, even
<pitti> lamont: ah, true that
* lamont considers uploading an openoffice.org-writer-ia64-dummy meta package
<pitti> lamont: erm, it is already
<siretart> doko: that's why there is the recommends. we have a spec to have 'Recommends' to be installed by default, after all
<pitti> lamont: ubuntu-meta produces arch:any binaries for that reason
<Keybuk> pitti: yeah
<lamont> pitti: any arch_all package that is in Task ubuntu-desktop makes us lose
<siretart> doko: if people are deliberatly not installing recommends, they shouldn't complain here, imo
<lamont> rather, in task: ubuntu-live
<lamont> see oo.o-h-e-us
<Lutin> glatzor: ping
<lamont> Mithrandir: any objections to me creating an oo.o-writer dummy package that is Arch: ia64?
<lamont> iz big huge crowbar
<doko> pitti: install language-support-xx doesn't create the C locales; wasn't this fixed sometime?
<doko> lamont: the dummy package seems to be the best solution IMO
<pitti> doko: urgh, no, seems to have slipped
<lamont> doko: anything besides oo.o-writer that you know I need?
<pitti> some java maybe?
<cjwatson> Mithrandir,seb128,pitti: FYI, I'm reviewing the glassfish/glassfish-bin/netbeans/imq/sunwderby cluster in NEW - feel free to ignore it
<pitti> ah, nice
* pitti tries to pronounce sunwderby and then tries to release the knot in his tongue
<cjwatson> I assumed it was sun-dub-ill-yew-dar-bee
<cjwatson> or der-bee, I guess, since they're USian
<doko> cjwatson: dholbach will happily assist ;-p
<thom> ew, derby 
<doko> lamont: need for what?
<lamont> to satisfy other *^*^80 oo.o-$mumble  dependencies that are in my way. :0)
<doko> lamont: I don't know of any other.
<dholbach> doko: ?
<iwj> siretart: Only one of four raid devices come up ?  Err, but surely you only need one to boot from.  Or do you mean one of the four components ?
<iwj> siretart: Anyway, thanks for your effort to provide info.
<Riddell> mvo: libqt-perl isn't default in edgy no
<LaserJock> I need an archive admin, there's a problem with a broken SRU in edgy-updates
<pitti> LaserJock: in the queue, or released?
<LaserJock> released
<pitti> LaserJock: how broken?
<pitti> LaserJock: there's little that an archive admin can do, apart from waving through an updated package
<LaserJock> well, as far as I can tell it's an archive issue
<LaserJock> I did an SRU for python-imaging
<LaserJock> but I got a couple reports of people not being able to upgrade
<LaserJock> I *think* the issue is that one of the binaries moved from Universe to Main for feisty
<Mithrandir> lamont: feel free.
<Mithrandir> cjwatson: yay, thanks.
<LaserJock> the bug reports I got so far are bug #96729 and bug #98550
<ubotu> Malone bug 96729 in python-imaging "updating asks to install python-imaging which would break the system." [Undecided,Needs info]  https://launchpad.net/bugs/96729
<ubotu> Malone bug 98550 in python-imaging "python-imaging-tk dependency problems in kubuntu-edgy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/98550
<pitti> LaserJock: hm, the package has always been in main
<LaserJock> pitti: source package yes, but I think python-imaging-tk was in Universe for dapper/edgy
<LaserJock> but it's in Main for Feisty
<pitti> python-imaging-tk | 1.1.5-10build1 | edgy/universe | amd64, i386, ia64, powerpc, sparc
<pitti> python-imaging-tk | 1.1.5-10ubuntu1 | edgy-updates/universe | amd64, i386, ia64, powerpc, sparc
<pitti> python-imaging-tk | 1.1.5-10ubuntu1~prop1 | edgy-proposed/universe | amd64, i386, ia64, powerpc, sparc
<lamont> openoffice.org-ia64-dummy_1.0_source.changes uploaded
<pitti> LaserJock: it seems fine within edgy
* LaserJock scratches head
<LaserJock> ok
<pitti> LaserJock: maybe broken apt-get or so? e. g. md5sum mismatch on edgy-updates/universe or so?
<LaserJock> pitti: well, one guy was using dselect, the other looks like he was using aptitude
<mvo> Riddell: hm, not ideal
<pitti> $ dpkg -I python-imaging-tk_1.1.5-10ubuntu1_i386.deb|grep Depends:
<pitti>  Depends: python-imaging (= 1.1.5-10ubuntu1), [...] 
<pitti> hmm
<pitti> LaserJock: apt-cache policy python-imaging-tk would be interesting to see from those guys
<LaserJock> pitti: ohhhh, I think I found something
<LaserJock> pitti: one of the guys has edgy-updates turned on for Main but not Universe
<pitti> that would be it
<mvo> Riddell: well, if libqt-perl is installed it will use the proper kde frontend now
<LaserJock> pitti: phew, I thought I somehow busted Edgy
* pitti hugs LaserJock 
<LaserJock> I did test installs/upgrades and rechecked the deps and I just couldn't figure out what was going on
<bddebian> suuuuure ;-)
* LaserJock doesn't hug bddebian 
<bddebian> :-(
<LaserJock> yeah, you better be :-(
<LaserJock> ;-)
* poningru hugs bddebian 
<bddebian> :) Hi poningru
<poningru> yarr
<bddebian> back in a bit..
<bddebian> Freakin' meetings :-(
<poningru> thesaltydog: where are you from?
<thesaltydog> rome- italy
<poningru> there is a local 'pub' here called ' the salty dog'
<poningru> nm
<thesaltydog> nm = New Mexico?
<poningru> hehe never mind
<poningru> but I am in gainesville florida
<thesaltydog> gimme the wensite of that pub!
<thesaltydog> s/wensite/website
<poningru> not sure they have one
<poningru> but let me look
<poningru> its a hole in the wall where all the grad students go
<poningru> dirty hole in the wall
<thesaltydog> :-)
<poningru> http://www.saltydogsaloon.com/
<thesaltydog> thank you! bye
<poningru> hehe cya
<Lutin> glatzor: is there a reason to make webboard depend on python2.4 rather than 2.5 in feisty ?
<Lure> Mithrandir: should this be milestoned for release - bug 91009?
<ubotu> Malone bug 91009 in wireless-tools "wireless-tools / wireless extension version mismatch" [Undecided,Confirmed]  https://launchpad.net/bugs/91009
<Mithrandir> Lure: quite possibly.
<kwwii> dholbach: did you see https://launchpad.net/ubuntu/+source/human-icon-theme/+bug/96497
<ubotu> Malone bug 96497 in human-icon-theme "Evolution icons are wrong" [Wishlist,Unconfirmed]  
<kwwii> dholbach: I have absolutely no idea why it is looking/finding a file in crystalsvg
<dholbach> kwwii: yes, that's cause because tango falls back to crystal and gnome
<kwwii> I think that the problem is that before it used the "email" icon from tango
<kwwii> ahhhh, now I get it
<dholbach> it's the "desktop environment independent thing" of tango
<dholbach> we'd probably need a nice icon in human or something
<dholbach> that'd just fix it
<dholbach> evo ships its own in hicolor
<kwwii> dholbach: and which one is better/which one do we want to use?
<dholbach> but normal icon themes are considered before hicolor
<kwwii> the tango email icon seems to be the one we were using in edgy
<kwwii> at least, that is the one that I saw
<kwwii> well, I'll pick one and perhaps touch it up a bit and add it to the human theme
<kwwii> dholbach: thanks for the info
<dholbach> that's probably the easiest
<dholbach> kwwii: i only know because seb128 asked me about it earlier already
<kwwii> ;-)
<carlos> pitti: I just started a new lang pack export with the French changes asked by seb
<MisterN> hi. may i ask some question about SSP and its use in Ubuntu?
<pitti> carlos: ah, great
<MisterN> i'll just ask and see if i get ignored :D
<MisterN> is stack-protector/SSP really necessary when you have NX?
<kylem> most people don't have NX.
<MisterN> well SSP is default on x86-64, too. there, all processors should have it. right?
<kylem> istr no.
<MisterN> "istr"?
<kylem> i think a few revs of Pentium 4 with em64t are missing it.
<kylem> 'i seem to recall'
<MisterN> :/
<keescook> MisterN: it's all about making things harder.
<keescook> MisterN: without SSP, an attacker could still leverage an attack that doesn't execute the stack
<keescook> MisterN: imagine them using code snippets from the running program to setup system calls via a long chain of stack return locations.
<MisterN> the question is whether it is worth it
<MisterN> but i understand that systems without NX need to be supported
* keescook nods
<keescook> I think it's worth it even with NX processors.  :)
<MisterN> i was not so pleasantly surprised when i learned about an hour ago that all my programs are compiled with ssp enabled by default
<Mithrandir> MisterN: why not?
<MisterN> because that makes benchmarking my own programs harder
<MisterN> i don't, for example, fear buffer overflow attacks in some obscure coding contest entry :)
<Mithrandir> then use -fno-stack-protector.
<wick2o> afternoon
<MisterN> well i think that NX alone would be good enough. but as it's not portable...
<keescook> MisterN: if you're curious about why SSP is still needed with NX, I recommend reading through http://www.suse.de/~krahmer/no-nx.pdf
<MisterN> keescook: well the safest is just not having buffer overflows :)
<Mithrandir> sure, and I would like to get rid of global warming too.
<MisterN> well i suspect that my own code has any buffer overflows :)
<LaserJock> Mithrandir: really? it's kinda chilly here right now ;-)
<_ion> benc: Online? :-)
<BenC> _ion: always :)
<_ion> benc: Sorry to bug you, but is there something in the third patch i sent that i should fix?
<BenC> _ion: Haven't looked yet, I think I'll get back to nvidia in a few hours
<_ion> benc: Alright.
<_ion> benc: I probably should have put the change_module_aliases under the debian directory.
<_ion> s/under/script under/
<mjg59> Hm. The lists.ubuntu.com archives don't seem to be updating?
<pochu> they're laggy :)
<mjg59> 3 days laggy?
<carlos> pitti: do you have 5 minutes?
<Adri2000> Mithrandir, doko: is it possible to fix MoM please? it's not been updated for ages...
<Mithrandir> Adri2000: can you ask me during my workday, please?  Or just send me an email.
<LaserJock> Adri2000: you need MoM output?
<Adri2000> LaserJock: yes
<Adri2000> Mithrandir: I already asked Keybuk a while ago, he said it was a problem with some debian mirror... so he should be aware of that, but I can send a mail if you want
<Mithrandir> Adri2000: thanks.
<david> anyone use gspca for webcam?
<elmo> mjg59: yes, 3 days laggy.  pipermail is a hideous evil piece of crap
<Mithrandir> david: yes, why?
<elmo> the stupid thing has a 2.4Ghz opteron dedicated to just doing archiving and it can't keep up right now - we're look at options, but I'm probably going to disable ubuntu-bugs archiving soon
<Mithrandir> fsvo use, at least.
<david> I can't get the controls to work. driver works and I can see image.
<Mithrandir> elmo: ouch; is it doing it on demand or out of cron?
<david> in kopete the autobright option does nothing as the other bright,cnt,color ctls...
<elmo> Mithrandir: it's a daemon
<Mithrandir> elmo: you can try turning that off and just having it deliver to mboxes which you generate nightly or every four hours or something; pipermail supports that with just minimal changes.
<Mithrandir> (until you switch to lurker or mhonarc or whatever)
<elmo> Mithrandir: I don't want to break archiving for the entire site
<elmo> and transitioning is non-trivial
<Mithrandir> ok
<david> the only control that works is the automatic color correction checkbox.
<Mithrandir> david: let me see that mine still works; which tool are you using to capture?
<david> kopete
<david> or camorama
<Mithrandir> the color/hue/white balance ones doesn't work for me, but constrast and brightness work just fine
<Mithrandir> (using camorama)
<david> can you tell me what your cat /sys/module/gspca/parameters/autoexpo show
<glatzor> Lutin: No, I don't think so. I am surprised that it was actually used by somebody :)
<david> Mithrandir: can you tell me what your cat /sys/module/gspca/parameters/autoexpo shows
<Mithrandir> david: 1
<glatzor> Lutin: I haven't found the time to look at for quite some time or release a later version - although there are many changes for it in my local bzr tree
<david> Mithrandir: Do you know how to send params to the module?
<Lutin> glatzor: ok, so it should work with python2.5 as is ? (look at bug #96842 and bug #844)
<ubotu> Malone bug 96842 in webboard "[apport]  webboard-applet crashed with ImportError in <module>()" [Undecided,Confirmed]  https://launchpad.net/bugs/96842
<ubotu> Malone bug 844 in rosetta "WordPress  export MO is not working (dup-of: 214)" [Medium,Fix released]  https://launchpad.net/bugs/844
<ubotu> Malone bug 214 in rosetta "Getting system error while generating .mo file" [Medium,Fix released]  https://launchpad.net/bugs/214
<Lutin> err bug #96844
<ubotu> Malone bug 96844 in webboard "[apport]  webboard crashed with ImportError in <module>()" [Undecided,Confirmed]  https://launchpad.net/bugs/96844
<Lutin> glatzor: this can be fix by either stick to python2.4 or moving to python2.5, so I wanted to know what you think is the best
<Mithrandir> david: what do you want me to do?
<david> Mithrandir: Just wanted to know if you knew how to send parms to the module. Sort of manual config the driver.
<siretart> iwj: I hope https://beta.launchpad.net/ubuntu/+source/mdadm/+bug/75681/comments/79 contains all information you need
<ubotu> Malone bug 75681 in mdadm "boot-time race condition initializing md" [High,Confirmed]  
<iwj> siretart: Thanks must go have food talk to you later
<siretart> iwj: enjoy your meal!
<sladen> BenC: what was that commit you did a while back for i965 DRM?  I've just noticed that on this i915 I have no direct rendering rendering or Xv
<Lutin> glatzor: still here ?
<glatzor> Lutin: yes, had to make a phone call :)
<glatzor> wait, I will look at those bugs
<glatzor> Lutin: hm. I think I will reply tomorrow.
<glatzor> You are subscribed to the bugs?
<BenC> sladen: userspace or kernel side problem?
<Lutin> glatzor: basically the bugs are caused by dependancies on python2.4 whereas it's executed with python2.5
<sladen> BenC: should I expect to be seeing some mention of 'dri' or 'drm' in lsmod?
<mjg59> Yes
<glatzor> Lutin: basically there should be no reason against using python2.5
<Lutin> glatzor: ok, cool
<Lutin> glatzor: if you want to fix the package the package when you have some time, feel free to do it (and un-assign me ;) )
<Lutin> glatzor: otherwise, just tell me and I'll fix it
<pitti> carlos: pong
<carlos> pitti: hi
<carlos> pitti: did you see any error like with previous language packs related to the weird new line char?
<pitti> carlos: not yet, but it's been a while since I saw such an error
<carlos> I think you said it was in Feisty
<pitti> right, maybe two weeks ago or so
<carlos> pitti: would be helpful if you could try to reproduce it with new language packs
<kwwii> pitti: just added a comment to bug #96510 , we are using the wrong icon in the menus for apport I think
<ubotu> Malone bug 96510 in ubuntu-artwork "Report a problem icon doesn't match other icons" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96510
<pitti> carlos: I can just grep for those characters
<pitti> kwwii: oh, thanks
<carlos> pitti: don't worry, I can do it myself
<kwwii> pitti: does that seem right to you?
<kwwii> pitti: although sabdfl liked the one we are using now
<pitti> kwwii: in fact, the icon in the context menu is not the apport one, but the stock gnome warning
<kwwii> ;-)
<pitti> kwwii: anyway, this is a bug against apport, so reassinging it with some guidance where I should change what is appreciated
* pitti is an artwork illiterate
<kwwii> pitti: hrm, then let's wait to change it
<pitti> kwwii: in today's meeting we'll discuss about entirely removing it from the final release anyway
<kwwii> pitti: hehe, that would solve the problem very well indeed :-)
<carlos> pitti: btw, The spanish language pack doesn't seem to be broken
* carlos -> out
<carlos> good night!
<MisterN> n8
<pitti> bye carlos
<Lutin> seb128: could you have a look to the debdiff attached to bug #92538 when you have some time ?
<ubotu> Malone bug 92538 in libgpod "python-gpod should depend on python-eyed3" [Undecided,In progress]  https://launchpad.net/bugs/92538
<seb128> Lutin: I'll have a look, not now though, I'm in the middle of a meeting
<Lutin> seb128: ok, np. thanks
<ajmitch> morning
<dholbach> hi ajmitch
<siretart> is bug #98739 for acpi-support or for the kernel?
<ubotu> Malone bug 98739 in Ubuntu "Module acerhk is not loaded" [Undecided,Unconfirmed]  https://launchpad.net/bugs/98739
<_ion> seb128: A couple months back, we had a short discussion about the compiz/beryl 'state' plugin allowing one to create rules that define the default brightness for various windows. Here's a screenshot that should demonstrate what it's good for: http://johan.kiviniemi.name/pictures/screenshots/beryl_per_window_brightness/original
<seb128> _ion: either I'm using my windows and want them with a normal light or I'm watching a movie and not doing something else
<seb128> that's doesn't look something we need
<mjg59> siretart: Right now there's no good way to fix that
<mjg59> It's certainly not an acpi-support issue
<seb128> _ion: I get what it's doing though ;)
<siretart> mjg59: oh? I thought acpi-support had some infrastructure to do notebook specific fixes
<siretart> mjg59: actually, I told nobse to file that bug. the actual fix looks rather easy to me
<mjg59> siretart: acpi-support handles acpi. acerhk bangs hardware directly.
<siretart> mjg59: just to understand the issue, why is ibm-acpi loaded automatically on thinkpads?
<mjg59> Because it can precisely determine whether something is a Thinkpad or not
<sladen> siretart: the default of acerhk is to assume it Acer type XYZ.  Which is wrong.  The default should be to fail loading without a definite positive match
<sladen> siretart: so it's not even possible to "try attempting to load acerhk regardlessly", as it'll just end up screwing the hardware
<siretart> sladen: any idea how to have this fixed in the mid-term?
<fabbione> Mithrandir: rm something is ok for who knows what to look for.. that's not disabling a service in a nice way..
<Mithrandir> fabbione: people who have configured IPv6 statically are power users.
<Mithrandir> if you want to provide patches which add IPv6 support to NM, please, but it's not a blocker in any way.
<fabbione> Mithrandir: not necessarely..
<fabbione> Mithrandir: it might not be a blocker.. it's still a regression.. 
<Mithrandir> fabbione: I haven't said it's not a regression, I've said it's not something I care about for the release.
<sladen> siretart: needs to be done in the kernel module, and have the module exit instead of default (actually a fairly small change)
<Keybuk> we have hundreds of thousands of regressions every time we make a release
<Keybuk> we only care about breaking those things we previously cared about
<Keybuk> (ie supported)
<Keybuk> we have never supported ipv6
<fabbione> Keybuk: FYI: ipv6 is in main and therefor supported
<Keybuk> (if we did, we would have high-level tools to configure it and use it!)
<siretart> sladen: so this bug should be reassigned to the kernel, then?
<fabbione> Mithrandir: right.. it's still a regression
<Keybuk> fabbione: that means it's security supported
<cjwatson> "regression" is something to pay attention to but it is not a big stick that trumps everything else. The release manager still has discretion
<Keybuk> not that we care about it
<sladen> siretart: yes, bit if you do that, can you mark it low-priority, it's not a regression in any way
<fabbione> Keybuk: also.. if we were introducing that many regressions we wouldn't be here at the Nth release
<Keybuk> see the number of bugs with launcher icon paths changing
<sladen> *blink*
<Mithrandir> fabbione: I feel like I'm repeating myself.  Yes, it's a regression.  No, it's not something which will be fixed for the release.  If you want to fix it, please send patches for it.
<Mithrandir> and with that, I'm off to bed.
<fabbione> Mithrandir: sure.. good night.. 
<sladen> WONTFIX
<maswan> fabbione: if you want to fix it, please look at my recent bugs on the trouble I've had in actually getting a statically configured ipv6 working. :)
<cjwatson> wontfix is wrong
<cjwatson> wontfix != not-for-this-release
<Keybuk> fabbione: seriously, I'm sure NM upstream would welcome IPv6 patches
<sladen> (I'm with Mithrandir on this one)
<fabbione> maswan: i removed NM.. problem solved.. 
<maswan> fabbione: I had a really hard time getting it to not autoconf on bootup
<Lure> Mithrandir: it would make sense to make network-manager-gnome only Recommends (already done for kubuntu-desktop and knetworkmanager)
<Lure> Mithrandir: this will allow removal
<Mithrandir> Lure: yes, it would.  Feel free to fix.
<Lure> Mithrandir: do not know how (Riddell does this for me in Kubuntu) ;-)
<fabbione> maswan: i am talking about NM messing up my ipv6 setup... what are you talking about?
<cjwatson> mm, I wasn wondering that earlier too
<cjwatson> was
<heno> tkamppeter: I posted a request for printer testing in the forums: http://www.ubuntuforums.org/showthread.php?t=396588
<heno> quite a few feisty users there
<maswan> fabbione: Oh, sorry, perhaps you don't read comments on your old bugs.
<cjwatson> any core dev can do that by changing "network-manager-gnome" to "(network-manager-gnome)" in the ubuntu.feisty seeds
<fabbione> maswan: give me a reference please :)
<Keybuk> tkamppeter: random Q; HPLIP doesn't do anything for my HP printer, is that deliberate?
<fabbione> maswan: i can't possibly remember everything
<Keybuk> it's a HP LaserJet 1018
<maswan> fabbione: I will, digging it up.
<maswan> (... if only I can manage to navigate)
<maswan> fabbione: https://launchpad.net/ubuntu/+bug/7091 is mostly what I was talking about
<ubotu> Malone bug 7091 in Ubuntu "IPv6 module is not loaded early enough" [Low,Needs info]  
<sladen> cjwatson: s/ \* network-manager-gnome/ * (network-manager-gnome)/ ?
<fabbione> maswan: ehhe ok.. now i understand..
<Keybuk> maswan: it's a bug that it's automatically loaded at all
<Keybuk> it should be blacklisted by default until people want it
<Keybuk> since it breaks nastily for people without ipv6
<fabbione> Keybuk: no it breaks only for people with broken hardware
<maswan> Keybuk: Oh? I've never had any problems with it though.
<Keybuk> fabbione: which is most of the world
<cjwatson> fabbione: considerably more people than those who actually use IPv6
<Keybuk> cheap DSL routers that most people use can't do IPv6
<Keybuk> and since there are only 2 goats that have a direct IPv6 connection, we care more about the real world
<fabbione> Keybuk: cheap DL routers that don't follow RFC
<fabbione> s/DL/DSL
<fabbione> not even for ipv4
<fabbione> that's why ipv6 break
<Keybuk> who cares?
<maswan> Keybuk: the ammounts of hits I get for updates via ipv6 says slightly more than 2 goats
<maswan> but yeah, it's less than 10%
<fabbione> Keybuk: we do.. given some recent movements towards IPv6 from some big fat govs
<maswan> less than 1% I mean
<Keybuk> we seriously don't
<Keybuk> if someone pays us to do ipv6, we'll care
<cjwatson> it doesn't seem at all inconceivable that we could avoid ipv6 being loaded for people without IPv6 addresses while still loading it for those who do
<Keybuk> if someone joins core-dev and patches everything for ipv6, and fixes all the bugs, we'll care
<fabbione> Keybuk: do you realize that 99.9% of the stuff in main already support ipv6?
<cjwatson> I don't think "ipv6 loaded for everyone" is necessary to satisfy fabbione's requests
<fabbione> cjwatson: no i don't need everybody to load ipv6 at all
<Keybuk> fabbione: apparently a major feature of feisty doesn't support ipv6
<maswan> cjwatson: Yeah. Like if I have typed in an inet6 section into interfaces.
<Keybuk> and our resident ipv6 expert on staff doesn't appear to have fixed it
<fabbione> Keybuk: it's not a matter that supports.. but that it break
<cjwatson> maswan: right
<fabbione> Keybuk: if NM didn't care.. i wouldn't have minded at all.. that it breaks a working setup.. then yes i do care
<tormod> (didn't see the whole discussion, but) can NM - ipv6 trouble be related to bug #92299 (not only ipv6)?
<cjwatson> do you care enough to fix it? :-)
<ubotu> Malone bug 92299 in network-manager "network-manager breaks static configuration" [Undecided,Confirmed]  https://launchpad.net/bugs/92299
<Keybuk> fabbione: fix it then :)
<Keybuk> care = fix
<fabbione> cjwatson: i don't care about NM because on a fixed workstation doesn't make any sense to me..
<Keybuk> fabbione: you care about NM because it's part of our default installation
<Keybuk> unless, of course, you don't care about our default installation?
<maswan> Anyway, I'll poke around at these bugs that I've reported after feisty, I think caring about them _right now_ is a misdirection of effort.
<cjwatson> fabbione: <fabbione> [...]  yes i do care
<cjwatson> <fabbione> i don't care
<fabbione> Keybuk: the reason why i am arguing is because i do care of our default installation
<Keybuk> fabbione: so fix NM then
<Keybuk> care = fix
<Keybuk> not bitch
<fabbione> cjwatson: i said that i care because it breaks.. i don't care about NM as an application itself.. slightly different thing
<fabbione> cjwatson: because i don't find it of any use on something != laptop
<Keybuk> so you're saying that IPv6 isn't useful on a laptop? :p
<fabbione> Keybuk: not yet no.. i am being realistic
<cjwatson> so should the bugs about it be assigned to you or not?
<cjwatson> (I'm assuming there is a bug about n-m vs. ipv6 - haven't looked)
<fabbione> cjwatson: i filed it...
* tormod found bug #93636
<ubotu> Malone bug 93636 in network-manager "[regression]  breaks static ipv6 setup" [High,Unconfirmed]  https://launchpad.net/bugs/93636
<cjwatson> bug 93636
<cjwatson> fabbione: I think it would be appropriate to assign that bug to you. Do you disage??
<cjwatson> er, disagree?
<maswan> Some other day I can provide relative numbers on the ipv6 usage on the users that hit se.archive for package updates. But now sleep. :)
<fabbione> cjwatson: i don't know NM code base.. you are welcome to reassign.. just no idea how to fix it
<cjwatson> I'm sure somebody can help with that
<pitti> cjwatson: 'disage' is an interesting concept, though
<cjwatson> AFAIK there are no other core devs with the breadth of IPv6 experience you have
<fabbione> cjwatson: probably not, who can i bitch about NM code base then?
<neuralis> fabbione: if this is present in upstream, i can almost certainly get it fixed
<Keybuk> upstream would be a good bet
<Keybuk> they're GNOME guys, so they hang out on IRC and e-mail, etc.
<pitti> cjwatson: I emailed upstream a while ago, and he was quite responsive
<Keybuk> and are pretty responsive
<Burgwork> fabbione: one of NMs upstream is currently on irc right now
<pitti> erm, fabbione ^
<pitti> cjwatson: sorry, wrong address; it's getting late...
<fabbione> Keybuk: i am asking in our team.. not upstream :)
<Keybuk> fabbione: you don't need help from somebody in our team
* doko hides the unread O'Reilly IPv6 book he got at Debconf in Porto Allegre
<Keybuk> upstream will provide the help you need
<fabbione> neuralis: i am pretty sure it's upstream too
<Lure> Keybuk: not really if it is in debian backend (filtering out static interfaces)
<Keybuk> Lure: they'd help him fix the backend
<Keybuk> but I suspect the bug is more that it's tearing down configured IPv6 interfaces
<Keybuk> which will be more internal than that
<fabbione> it's actually only the backend
<fabbione> it seems also pretty simple to fix
<fabbione> given the way backends work
<fabbione> cjwatson: bug #98764 looks to me like we are missing modules in the installer (ide*) ?
<ubotu> Malone bug 98764 in Ubuntu "Installation of Feisty beta cannot detect disk drive on Gigabyte 965G-DS3" [Undecided,Unconfirmed]  https://launchpad.net/bugs/98764
<fabbione> actually it might be another one of those jmcron thingy
<cjwatson> fabbione: we're certainly not missing them or I'd have way more people screaming at me, but it probably can't detect his hardware
<cjwatson> fabbione: I'll look at it tomorrow
<fabbione> cjwatson: ok thanks
<fabbione> BenC: ^^^ this might be your... 
<BenC> fabbione: 70% possibility that bug is fixed by -13 kernel in repo, 99.9% possibility that it's fixed by current git
<fabbione> BenC: ok.. i will ask cr3 to test a daily
<BenC> fabbione: No chance of us missing modules for storage, since we just copy drivers/ata/ drivers/scsi/ and drivers/ide/ now
<fabbione> BenC: yes.. there is a message from d-i that's misleading.. the modprobe happens a bunch of lines above that
<fabbione> cjwatson: nevermind. that's definetely not for you
<pitti> cjwatson: FYI, I implemented that heuristic coredump capping, testsuited and uploaded now
<cjwatson> fabbione: ok, thanks
<cjwatson> pitti: neat, thanks
<tkamppeter> Keybuk: There are some HP printers which are not supported by HPLIP, especially the HP LaserJet 1000, 1005, 1018, 1020, Color LaserJet 1500, 2600n
<tkamppeter> Keybuk, more are listed on http://hplip.sf.net/
<firephoto> tepsipakki: I commented on bug 90213 and attached my xorg.log about those new intel drivers.
<ubotu> Malone bug 90213 in xserver-xorg-video-i810-modesetting "xf86-video-intel 1.9.91 (2.0 RC1) is out, and would be nice to have as the source for the xserver-xorg-video-i810-modesetting package" [Undecided,Needs info]  https://launchpad.net/bugs/90213
<tepsipakki> firephoto: oh, it was still using i2c debugging..
<tepsipakki> I'll build a new one
<firephoto> tepsipakki: ok. that explains all those messages then.
<tepsipakki> yes, I needed those
#ubuntu-devel 2007-03-30
<tepsipakki> a new driver at the same place
<tepsipakki> firephoto: ^^
<firephoto> tepsipakki: ok, i'll try it
<firephoto> tepsipakki: ok, I don't have all the debug messages now, but I noticed I couldn't just restart the X server and tty1-6 doesn't work but I can switch back to X on 7
<tepsipakki> firephoto: ok, thanks for testing
* zyga is reading what people say about command not found :-)
<zyga> it's pretty funny to go from no significant contributions in FOSS to pretty often mentioned contribution :-)
<mc44> zyga: it rocks hard! :)
<zyga> some comments are silly some are just 'wow great'
<zyga> but it clearly shows the direction I should take
<mpt> The program 'the' is currently not installed...
<_ion> zyga, mvo: Please pull the change from http://johan.kiviniemi.name/software/bzr/command-not-found/, thanks.
<_ion> Oh, mvo isn't online.
<mpt> zyga, "Make sure you have the 'universe' component enabled" suggests that the computer doesn't know whether it is or not :-)
<sladen> could people do a quick   grep vesa /etc/X11/xorg.conf   I feel that discover1 isn't always getting installed and auto-detection is failing.
<sladen> s/feel/fear/
<sladen> despite it being in ship and live, it wasn't installed here
<zyga> mpt: yeah I know - I've got it fixed already 
<zyga> _ion: pulling now
<zyga> _ion: got it, thanks 
<zyga> I'll merge it as soon as scanner and database fixes are done
<zyga> with some luck we'll get a lot better cnf once mvo is back
<wick2o> evening
<mpt> zyga, awesome
<Hobbsee> morning all
<desrt> word.
<mrsno> gud morning
<desrt> anyone here have hotmail?
<lotusleaf> haha
<desrt> i guess that's a no.
* desrt suspects hotmail of mangling utf8 and needs to test
<mrsno> i do desrt , sad to say
<mrsno> i like reading spam when im bored
<desrt> mind if i send you an email?
<desrt> (and you send me one)
<mrsno> sure
<mrsno> pm me your addy and ill send you mine
<mrsno> does it matter if i access it in thunderbird/icedove? :)
<desrt> the message must contain a  (U+0103 LATIN SMALL LETTER A WITH BREVE)
<mrsno> k
<desrt> oh bother.  freenode won't let me /msg you.  my address is desrt@desrt.ca
<mrsno> i got it 
<desrt> rad
<mrsno> did you receive mine?
<desrt> no.  perhaps you have the same problem :)
<desrt> freenode is weird about /msg
<mrsno> thesno@hotmail.com
<desrt> k
<desrt> sent.
<mrsno> into the junk, the irony :)
<desrt> hotmail = sux
<bhale> hi desrt 
<mrsno> http://paste.debian.net/24672
<desrt> unless it's microsoft-certified spam it's junk :p
<desrt> bhale; 'sup
<mrsno> the letter appears as uppercase
<desrt> mrsno; wtf!
<desrt> i see  on the page you sent
<mrsno> yep
<desrt> that's some messed up stuff
<desrt> hotmail sucks
<mrsno> indeed :)
<desrt> anyway... your  mail to me is doubtlessly stuck in my greylist
<desrt> i'll let you know later how it comes out :)
<mrsno> oh let me reply
<mrsno> sent
<desrt> the irony is that when i receive your reply back the character is in tact
<mrsno> haha
<desrt> hotmail is very stupid
<mrsno> well i checked browser and mail client, both were incorrect
<mrsno> when i sent the mail, what i typed appeared as  
<desrt> i reiceved it as &#259;
<desrt> literally
<desrt> hotmail doesn't appear to understand that html sequences aren't legit in non-html email (?!?!)
<mrsno> hotmail just seems to be good for spam, probably because they share email accounts with third parties by default, when you create an account
<zyga> anyone at cannonical around?
<Hobbsee> zyga: what for?
<zyga> I'd like someone to do a du -sh on archive.ubuntu.com for feisty
<evand> zyga: I believe it's about 250G
<zyga> :/
<evand> afaik, there's no way to separate out Feisty as everything goes into pool
<zyga> yeah I remember now, darn
<LaserJock> zyga: do you need just source? or all archs?
<desrt> it is confirmed.  hotmail = satan.
<zyga> LaserJock: all relevant arches
<Fujitsu> zyga: You can use debmirror to grab a portion of the archive.
<bddebian> heh
<desrt> *utterly broken*
<LaserJock> desrt: and that's something new? ;-)
<zyga> Fujitsu: I have all but universe
<Fujitsu> (that'll give you a total size before it downloads)
<zyga> I guess I should wait for mvo to help me out then
<Fujitsu> universe i386+all is about 11GiB.
<desrt> i had no idea that it was so utterly unaware of i18n
<Fujitsu> desrt: Why are you using it?
<desrt> i'm emailing with a friend who uses it
<desrt> it take my characters, converts them to utf8 bytes, then converts those bytes back into iso-8859-1 characters
<desrt> and when sending (text!) email back it writes those characters as &#123; type sequences
<Fujitsu> Heheh. Sounds like fun1
<desrt> -utterly- broken
<desrt> it really bothers me that people use such crap :(
<sladen> zyga: all the information you need is in the packages files
<mrsno> nn 
<g0su> hello all, sorry for this but i dont understand well launchpad is too cracy for me and the search not work well. I think than i have a error, if you can report for me :D
<g0su> hp-toolbox need qt but is not a depend in the package
<g0su>  hp-toolbox 
<g0su> error: PyQt not installed. GUI not available. Exiting.
<g0su> thanks you for all ;)
<wick2o> any jigdo experts in the house?
<THJ> i've googled for hours trying to locate a setting that lets me see icons for all my disk drives on the Ubuntu desktop, not only external ones. having found nada, and having gotten no answer anywhere other than "just make some links", i come here. do any of you know if there is such a feature? if there isn't, what part of GNOME/Ubuntu would need patching to make this possible?
<THJ> :|
<THJ> ... is there nobody here or am i being ignored?
<LeeJunFan> Anyone here who knows what package (libc6 maybe?) that I'd file a regex bug under? echo -e 'R\nr' | grep '[A-z] ' ;echo -e 'R\nr' | sed 's/[a-Z] /E;/g'
<jml> LeeJunFan: I'm not sure exactly what bug that is supposed to expose.
<LeeJunFan> jml, did you run it and get E; E;?
<jml> LeeJunFan: yes
<LeeJunFan> jml: where does E come from grepping R in a string?
<mjg59> Character collation order is locale dependent
<jml> LeeJunFan: it doesn't come from the grep at all
<jml> LeeJunFan: run the two commands separately
<LeeJunFan> okay, I see now, thanks. sry.
<LeeJunFan> shouldn't grep output a similar error on A-z as sed with A-z does though? Invalid Range?
<khermans> i figure one of the Ubuntu devs has seen this, since it is only appearing here
<khermans> (.text+0x4907): undefined reference to `__stack_chk_fail_local'
<khermans> this would be on an amd64 system, trying to link
<khermans> /usr/lib/gcc/x86_64-linux-gnu/4.1.2/32/libsupc++.a(cp-demangle.o): In function `d_demangle':
<khermans> i was able to remove other __stack_chk_fail messages with -fno-stack-protector to gcc
<khermans> however, it appears that libsupc++ could be broken?
<Dabian> I found a possible bug in the installation of fiesty; you cannot skip the import step, save by erasing Microsoft Windows - and sometimes this step goesn into a very long (endless?) loop.  I don't report this bug.
<Dabian> We were using herd5.
<dholbach> good morning
<Amaranth> hey dholbach
<dholbach> hey Amaranth
<Dabian> Not complaining .. just want to make sure you guys know. :)
<Amaranth> Dabian: afaik you can run ubiquity with --skip-migration or something
<Amaranth> Dabian: but you should try with the beta, maybe it'll work better
<Amaranth> i dunno, i don't have a window install to migrate things from
<Dabian> Amaranth : ubiquity == the install icon?
<Dabian> Neither do I.
<Amaranth> yeah
<Dabian> My friend is really fond of winXP for some reason, and don't want to get rid of it.
<Dabian> He claims that he cannot get on his university wireless net without windows.
<Dabian> Anyhow .. thanks for the hint, and I'm glad you're working at it .. the release date is aproaching :D
<fabbione> morning
<Seveas> buon giorno
<pitti> Good morning
<joejaxx> pitti: Good Morning :)
<dholbach> happy hug day pitti!
<pitti> dholbach: bugzzzzzzzzzzz!
<dholbach> HUGZZZZ :)
* dholbach hugs pitti
* pitti hugs dholbach 
<joejaxx> lol
<Mithrandir> iwj: do you have any idea about 38409 ?
* Mithrandir summons mvo
<siretart> bug #38409
<ubotu> Malone bug 38409 in lvm2 "creation of snapshots fails unpredictably" [High,Confirmed]  https://launchpad.net/bugs/38409
<Burgundavia> siretart: I see the '
<Burgundavia> "unpredictably" bit in there and cringe
<siretart> why is it only me who has to file such awful bug reports :(
* Mithrandir wonders if we should make netbase depend on update-inetd for this release.
* highvoltage wonders if that would be useful for LTSP users too
<Mithrandir> mvo: I'm going through all the milestoned bug reports now and wonder how much I should ask update-manager to fix.
<Mithrandir> mvo: like, bug 96286 which is caused by netbase no longer including update-inetd.
<ubotu> Malone bug 96286 in samba "samba didn't install on edubuntu upgrade from 610 to 704beta" [High,Confirmed]  https://launchpad.net/bugs/96286
<Mithrandir> also, good morning. :-)
<mvo> Mithrandir: good morning :)
<mvo> Mithrandir: I'm happy if you give me a list of the ones you have in mind for u-m. for the dapper->edgy upgrade u-m had quite a few hints (e.g. python transition, some printing releated problems etc). but that was not optimal because we got reports from people upgrading by other means then. 
<Mithrandir> mvo: so far, I have been opening bugs on update-manager, milestoned them and rejected the other task.
<mvo> Mithrandir: that sounds good, that means I have it on the radar
<Mithrandir> mvo: great.
<Mithrandir> mvo: do you have an opinion on 96286; I'm pondering whether to add a depends on update-inetd from netbase or just work around it in u-m
<Lutin> mvo: could you have a look at the debdiff attached bug #93721 when you have some time ? (nothing urgent)
<ubotu> Malone bug 93721 in reseed "[can-not-install]  maintainer script failure" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93721
<mvo> Mithrandir: hm, so this is a ordering problem, update-inetd gets installed. we probably need to modify samba then to ensure that it has update-inetd before its maintainer scripts run
<Mithrandir> mvo: this is the previously installed version's postrm.
<Mithrandir> so no, we can't do that.
<Mithrandir> we can add the depends on update-inetd from netbase, though.
<zyga> mvo: hey
<zyga> mvo: if you have some time maybe we could issue another cnf release?
<mvo> Mithrandir: the rational for the depends would be that update-intetd (that is marked for install in the logs of #96286) gets unpacked/configured in a earlier dpkg --unpack/--configure run? 
<mvo> Lutin: from a first glance it looks good
<Mithrandir> mvo: yes.
<mvo> zyga: sure
<zyga> mvo: it's not 100% finished yet - as usual I disabled your apt-cache magick
<mvo> Mithrandir: its a bit hacky to work around ordering problems in u-m, but give me some minutes and I can investigate it a bit more
<zyga> mvo: if you pull and take a look at the directory you'll be interested in cnf-scan-packages
<Lutin> mvo: ok
<Lutin> mvo: I'll upload it if it's ok for you
<mvo> Lutin: I don't know too much about that package but a debconf note may be ok too (or people using it on the server)
<mvo> Lutin: thanks for working on this
<mvo> zyga: does your branch only conatins changes to the extractor? or more?
<zyga> mvo: slightly more, I removed suggestions to speed things up
<zyga> mvo: there are some new translations
<Lutin> mvo: is using debconf preferred to the proposed solution ?
<zyga> mvo: bah, I'm sorry - I should have ported the apt-cache thing myself
<mvo> Lutin: I think using debconf would be better because it works well for X-less installs too
<mvo> Lutin: the solution with the update-notifer hook works only when X is installed of course
<Lutin> mvo: sure yes. I'll have a look to a debconf fix when I come back from holidays :)
<Lutin> gotta leave. see you
<mvo> bye
<Mithrandir> mvo: so, getting anywhere?
<mvo> Mithrandir: oh yes. making it a dependency of netbase has the added advantage that it will work for packages other than samba that require update-inetd, so +1 for me for this 
<zyga> mvo: please don't port that - I'll work on it
<zyga> mvo: forgive me for this confusion
<Mithrandir> mvo: ok.  Can you do that then?
<mvo> (cupsys-server, ltsp-server, tftpd)
<mvo> sure
<mvo> zyga: ok, thanks
<Lathiat> whoah
<Lathiat> fabbione: Who's decision was it to actually blacklist IPv6 by default on feisty?
<fabbione> Lathiat: see the changes to ifupdown too..
<Lathiat> url?
<fabbione> Lathiat: the combo of changes will fix 2 problems in one go
<fabbione> Lathiat: it's on feisty-change mailing list
<fabbione> same as where you saw the other change
<Lathiat> nah i saw the other change in the bug
* Lathiat looks
<fabbione> Lathiat: it solves 2 problems in one go...
<Mithrandir> mvo: how hard will 86296 be to fix?
<Lathiat> fabbione: hrm was that *just* uploaded? can't see it on the feisty-changes archives (im not subscribed)
<fabbione> Lathiat: as 35 minutes ago
<fabbione>  ifupdown (0.6.8ubuntu3) feisty; urgency=low
<fabbione>  .
<fabbione>    * ifupdown.nw: modprobe ipv6 before configuring it.
<fabbione>    (Closes LP: #7091)
<Nafallo> fabbione: this will break my autoconf, right?
<fabbione> so basically if you have an ipv6 interface configured in interfaces, you will get ipv6 loaded
<mvo> Mithrandir: netbase uploaded
<Lathiat> right, but ipv6 autoconf wont work?
<mvo> bug #86296
<ubotu> Malone bug 86296 in synaptic "synaptic needs to reopen to read new proxy settings" [Low,Confirmed]  https://launchpad.net/bugs/86296
<Mithrandir> mvo: thanks.
<mvo> Mithrandir: not very hard, I just need to sit down and do it. but the list of bugs that I targeted is rather long unfortunately :/
<fabbione> Lathiat, Nafallo: yes that's the only fallout for which you add iface foo inet6 manual in interfaces and everything will work as before or remove the blacklist
* Lathiat ponders
<Mithrandir> mvo: I know it is.. :-/
<fabbione> i am looking for somebody in ubuntu-doc to add it to the release notes
<fabbione> there is no other way to make everybody happy
<Nafallo> fabbione: ipv6 in /etc/modules might work?
<fabbione> and i have been pondering this all night
<Lathiat> i do not consider this an ideal solution
<Mithrandir> mvo: I'll remove the milestone, then
<Lathiat> but im not sure there really is an "ideal" solution
* Lathiat mumbles something about stupid hardware manufacturers
<Lathiat> i could write better DNS code in my sleep
<Nafallo> Lathiat: make all ISPs implement IPv6 overnight ;-)
<Lathiat> Nafallo: ISPs implementing ipv6 has *NOTHING* to do with it
<fabbione> Lathiat: there is no solution.. and in ages that the problem was there nobody come up with an ideal solution
<mvo> Mithrandir: oh, its fine to keep it. is priority low anyway IIRC
<Lathiat> Nafallo: its stupid hardware manufacturers writing bogus DNS implementations
<mvo> Mithrandir: I will try to get to it
<fabbione> Nafallo: you just need to read what i just wrote... 
<Lathiat> Nafallo: that when you query for ipv6 records start returning silly results
<Lathiat> Nafallo: like 0.0.0.1, or just plain timing out
<fabbione> Nafallo: either remove the blacklist or configure interface properly.. it can't be that difficult :)
<Lathiat> fabbione: its not, but it should just freaking work :P
<Lathiat> i wonder if we can make the resolver not try AAAA records if theres no default route
<Nafallo> fabbione: hehe. will do. but now I actually has to do something :-P
<Lathiat> i guess thats kindof a complicated solution
<Mithrandir> mvo: thanks.
<fabbione> Lathiat: pointless.. you might be using IPv6 on local net.. you  might access DNS on the local net and not even routing trough the default
<fabbione> so please stop worring about it.. if you use ipv6 you know what to do..
<fabbione> and spend your energies to help me fixing NM instead to not freakout on ipv6 interfaces
<Nafallo> :-)
<Lathiat> NM freaks out on ipv6 interfaces?
<fabbione> Nafallo, Lathiat: when i said i did spend the night pondering.. i was not kidding
<Nafallo> *nods*
<fabbione> Lathiat: bug #93636
<ubotu> Malone bug 93636 in network-manager "[regression]  breaks static ipv6 setup" [High,Unconfirmed]  https://launchpad.net/bugs/93636
<fabbione> Lathiat: when an interface has dhcp on ipv4 and static on ipv6, NM goes "eh what!?!?"
<fabbione> Lathiat: and kill ipv6
<Lathiat> heh
<shawarma> When do the daily CD images get built?
<cjwatson> shawarma: http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/etc/
<cjwatson> er
<cjwatson> shawarma: http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/etc/crontab
<shawarma> cjwatson: UTC?
<pitti> Riddell: kde4pim> what is an index.cache.bz2? how is it generated? (in terms of 'prefered form of modification')
<Riddell> pitti: it's generated from the *.docbook files
<pitti> Riddell: ah, ok, so that's fine
<cjwatson> shawarma: London time, I think, so BST
<shawarma> cjwatson: Excellent. Thanks.
<tepsipakki> a lot of people use the mail interface of lp.net, but it can't handle attachments
<tepsipakki> so they are lost
<mvo> Mithrandir: about #95325 - this will break the upgrade for people using apt-get/aptitude. I expect that a lot of people upgrade their servers this way
<Mithrandir> mvo: we went over this for weeks in Debian; it's a bug in php and there's absolutely nothing apache2 can do about it.
<Mithrandir> (we being infinity, thom, I, peterS, vorlon)
<mvo> Mithrandir: ok, that is bad. I will release note it then. 
<Mithrandir> mvo: thanks.
<mvo> Mithrandir: what is the debian bugnumber for this (out of interesst)?
<Mithrandir> mvo: most of it is in irc logs, but http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390823 has a bit of thoughts on it.
<ubotu> Debian bug 390823 in apache2-common "apache2-common cannot be purged." [Serious,Closed]  
<mvo> Mithrandir: is that the workaround you recommend: "rm -f /var/lib/dpkg/info/apache2-common.postrm." ?
<Mithrandir> mvo: no, the workaround is to remove php[45]  before upgrading apache.
<mvo> Mithrandir: so before the actual upgrade, remove php[45] , upgrade, reinstall php[45] ?
<_ion> Hi mvo
<_ion> mvo: Did you receive my MemoServ message?
<Mithrandir> mvo: that ought to work, yes.
<mvo> Mithrandir: thats very evil and has the potential to screw up quite badly within the apt cache. is that really the only way?
<mvo> _ion: no
<Mithrandir> mvo: the problem is php[45]  depends on apache2-common's ABI without declaring that.
<_ion> mvo: Hm, ok. Anyway, there's a small change at http://johan.kiviniemi.name/software/bzr/command-not-found/
<mvo> _ion: thanks, commited
<_ion> Thanks
<zyga> _ion: is that the patch you sent me yesterday?
<_ion> zyga: Yes.
<zyga> _ion: I don't know zsh much so I'm not going to be able to help you :/
<iwj> Mithrandir: re bug 38409.  No, I don't have 
<ubotu> Malone bug 38409 in lvm2 "creation of snapshots fails unpredictably" [High,Confirmed]  https://launchpad.net/bugs/38409
<iwj> any particular opinion - I haven't investigated it.
<iwj> I think this is another consequence of udev being BAD.
<Mithrandir> iwj: it's milestoned for release, could you have a look at it?
<iwj> Yes, of course.
<Mithrandir> thanks.
<iwj> I'll see if I can come up with a workaround perhaps.
<Mithrandir> yes, that'd be good.  Would you mind assigning it to yourself too?
<iwj> Done.
<Mithrandir> cheers
<doko> pitti: please process openoffice.org-l10n in NEW (new openoffice.org-help-pt package) and adjust language-whatever-*
<pitti> doko: NEWed five minutes ago
<doko> pitti: thanks
<pitti> doko: added dep in langpack-o-matic bzr, will upload later
<doko> hrm, the openoffice.org build on i386 was only started at 6:30, will need another 5h to build
<mvo> Mithrandir: I would rather rewrite/replace the apache2-common maintainer script prior the upgrade than messing with the cache. is that an option? my understanding is that the maintainer script failing is causing the trouble, once the upgrade is complete, the ABI issue should be resolved due to the upgrade, no?
<pitti> Mithrandir: myspell-ro source uses arch/any instead of arch-all, but slipped through source NEW with that; I filed a bug; can I reject the binaries and wait for the new verssion? or will that screw up something and I rather leave them in the queue until the new version is uploaded?
<Mithrandir> pitti: rejecting binaries work (but nobody is notified about it).
<Mithrandir> mvo: why would you need to mangle the cache?
<pitti> Mithrandir: right, I notified janimo with the bug report
<mvo> Mithrandir: there are some assumptions in the upgrader that the ugprade will be one apt operation. if it first removes php, upgrades installs it later, then that breaks these assumptions. its not terrible hard to fix, but I would rather want to use some alternative approach. plus the fun of checking if the upgrade actually produces the same result when I take some things out and in again later
<Mithrandir> mvo: the problem here is a missing dependency, you could, maybe, possibly work around it by first stopping apache2, then removing the prerm and postrm then upgrade, but you would need to test this properly.
<mvo> Mithrandir: the missing dependency is not a package dependency but the ABI dependency that you talked about earlier? (sorry, I'm not familiar with php/apache packages)
<Mithrandir> mvo: no.  libapache2-mod-php5 in edgy depends (as in, an ABI dependency) on apache2-common, but fails to Depend on apache2-common, the package.  This is a bug.  libpache2-mod-php5 in feisty depends and Depends on apache2.2-common.
<ogra> Mithrandir, is your NM fix planned before herd6 ? i'm getting a lot of complaints that ltsp doesnt work so if it takes longer i'd like to unseed NM for herd6
<Mithrandir> mvo: if you upgrade libapache2-mod-php5 without first upgrading apache2-common, it will fall over.  If you first install apache2.2-common without removing libapache2-mod-php5, the upgrade falls over.
<Mithrandir> ogra: herd 6 isn't happening, but yes, it's planned for before then.
<ogra> Mithrandir, isnt happening ? why is that ? i thought of it as our RC 
<Mithrandir> ogra: no, release candidate is something else.  RC happens in two weeks; herd 6 was planned for the Thursday in 6 days.
<ogra> ah, k
<ogra> good 
<Mithrandir> Keybuk: about bug 75830, why isn't this feasible to fix for release?
<ubotu> Malone bug 75830 in upstart "Starting of the getty" [Low,Confirmed]  https://launchpad.net/bugs/75830
<Keybuk> Mithrandir: because there's no easy way to fix that
<Keybuk> it needs an upstart feature that's not yet finished
<Keybuk> and since it's not a regression from edgy, I don't see why it has to be release critical now
<Mithrandir> Keybuk: ok, fair enough, I'll de-milestone it then
<cjwatson> the regression Matt commented on is due to logd being turned off, I think
<cjwatson> it's a regression in the system sense, but not a regression in upstart code, IYSWIM
<Keybuk> Mithrandir: unfortunately the "quick kludgy fix" would be worse, it'd kill getty at random points
<Keybuk> cjwatson: a dapper->edgy regression
<Mithrandir> cjwatson: point.
<cjwatson> Keybuk: what's http://librarian.launchpad.net/6893723/edgy.png then?
<Keybuk> cjwatson: the boot messages are probably on tty8 :p
<Keybuk> (or hidden by logd)
<cjwatson> Keybuk: which is just what I said!
<Keybuk> oh, sorry
<Keybuk> missed that
<Keybuk> the bug matt milestoned was about something else
<Keybuk> the fact that getty was started before rc.local
<cjwatson> oh, so mdz hijacked the bug? :)
<Keybuk> ok
<Keybuk> yes. mdz hijacked a different bug
<Keybuk> ok
<Keybuk> the logd problem *is* on my list of things to fix before release
<Keybuk> let me file a bug and milestone *that*
<cjwatson> Keybuk: um. mdz's screenshots seem to document the same problem though
<cjwatson> the screenshot filed in the original report was that getty was being started before rc2 had finished
<cjwatson> you can see atd and crond being started after getty, as well as rc.local
<Keybuk> cjwatson: the original screenshot was without "quiet"
<cjwatson> and mdz's screenshot is basically the same
<cjwatson> server boots without "quiet", IIRC
<Keybuk> yeah, but the screenie in zigi's bug was just to demonstrate the point
<Keybuk> his bug was really that rc.local got started after getty
<cjwatson> ah
<Keybuk> it was one of those "talk on IRC, he files bug to remind me" things
<Mithrandir> Keybuk: can you update the summary of the bug to indicate that, then?  It's not a very good summary as-is.
<Keybuk> yes
<Mithrandir> thanks
<Keybuk> ok, filed and milestoned bug #98955
<ubotu> Malone bug 98955 in upstart "logd not running" [Undecided,Unconfirmed]  https://launchpad.net/bugs/98955
<Mithrandir> seb128: about bug 72814; can I either assign it to you or has it been fixed?  It's marked fix committed and has been that for a week.
<ubotu> Malone bug 72814 in liboil "Crash at login" [Low,Fix committed]  https://launchpad.net/bugs/72814
<Mithrandir> Keybuk: thanks a lot. :-)
<seb128> Mithrandir: I'll fix it right now
<Mithrandir> thanks
<Keybuk> Launchpad needs an ESP extension so I can easily dump mental bug state into it
<seb128> np
<Mithrandir> pitti: would it make sense to remove a bunch of langpacks when we're not close to release so it's a bigger chance that we can get random people to test daily ISOs?
<Mithrandir> to avoid it being oversized.
<pitti> oh, are we again? I'll take a look and remove them
<Mithrandir> at least slightly, I think
<pitti> 703M 2007-03-30 12:28 feisty-alternate-amd64.iso
<pitti> hmm
<Mithrandir> I was thinking more as a general way of avoiding the problem for dailies.
<pitti> Mithrandir: ah, you mean when we start feisty+1? yes, that would make sense
<Mithrandir> pitti: yes, and immediately after each array^Wcolony^Wflight^Wherd.
<pitti> right
<ogra> can someone explain to me what /etc/init.d/loopback does that /etc/init.d/networking doesnt do as well ?
<ogra> why do we have a second script fo the loopback interface that we also handle in /e/n/i ?
<ogra> err
<ogra>  /e/i/n
<tepsipakki> it's handled early
<ogra> it doesnt bring up lo for me btw
<ogra> (loopback)
<ogra> if i disable /e/i/n i dont have lo even though loopback is run
<Keybuk> ogra: eh?
<Keybuk> loopback brings up the lo device
<Keybuk> the ifup calls in the udev rules bring up hardware devices
<ogra> i just found the problem ...
<Keybuk> and networking brings up "anything else" (virtuals, ppp, etc.)
<ogra> (this was on an ltsp client) 
<Keybuk> loopback is done early, since having 127.0.0.1 is often "useful"
<ogra> hmm, actually no ... does it need anything else than /var/run/network being writable for that ? 
<Keybuk> /var/run is a tmpfs, so it's always writable
<ogra> i know
<ogra> but the rest of my thin client isnt
<Keybuk> right
<Keybuk> loopback only uses /var/run
<ogra> so does it need anything else ? 
<ogra> ah
<ogra> hmmm
<ogra> weird, S01mountkernfs.sh should care for that ... and it does, else i'd not have a lot of other stuff working that uses /var/run
<Keybuk> what's the problem?
<Keybuk> lo not being configured?
<ogra> yes
<Keybuk> does the /var/run/network directory exist?
<ogra> it is there if i enable networking which i usually dont on thin clients
<ogra> yes
<Keybuk> do you have the following in /etc/network/interfaces: ?
<Keybuk> auto lo
<ogra> yes
<Keybuk> iface lo inet loopback
<Keybuk> -- 
<ogra> thats created by the ltsp script during chroot creation
<Keybuk> (err, you didn't actually wait for me to give you the text before you said "yes")
<Keybuk> when does "lo" show up?
<ogra> its the identical text every ubuntu has ;)
<ogra> never if i disable S40networking
<ogra> its only set up by this script it seems ...
<ogra> loopback has no effect at all 
<ogra> it works if i run it from the consile though
<ogra> *console
<Keybuk> kooky
<ogra> i'd guess for a race anywhere, but there is only /var/run
<ogra> which is proven to be there and writable ...
<ogra> me moves around the bindmounter script for the other dirs ... 
<ogra> aha ... that solves it ... intresting
<ogra> rw_dirs="/var/lib/xkb /var/log /var/spool /var/tmp /tmp /var/lib/discover /etc/console-setup" ... must be using one of these as well
<ogra> meh ... silly ... 
* ogra found it
<highvoltage> ogra: something needs to be added to rw_dirs?
<ogra> highvoltage, no
<Keybuk> ogra: do tell
<ogra> somehow the filling of /e/n/i is done by ltsp-client-setup instead of ltsp-client-builder
<ogra> so it is empty at the point where loopback runs if l-c-s isnt run before
<ogra> which is totally silly, we dont need to create that entry for lo dynamically we need it there anyway
<spacey> any idea if there any plans for new and up to date kernel for dapper?
<pochu> spacey: do you mean a new upstream kernel, such as 2.6.20?
<spacey> yes
* ogra moves it to the right script now ... and disables /e/i/n in thin clients again ...
<pochu> spacey: then no
<spacey> dapper is getting a bit cripled because of missing drivers
<pochu> then you can report a bug, and the kernel can be patched
<pochu> or even better, you can submitt a patch ;)
<spacey> hehe, i'll guess i file some bug reports then next week
<Mithrandir> Keybuk: do you have any idea about bug 73425, both why it's milestoned and what bad effects it could have?
<ubotu> Malone bug 73425 in udev ""unable to create db file" warning if the device is normally placed in a subdir (input, devmapper, etc.)" [High,Confirmed]  https://launchpad.net/bugs/73425
<Keybuk> Mithrandir: I haven't worked out the bad effects yet
<Keybuk> but it's definitely a symptom of a nasty bug in udev
<fabbione> Mar 30 13:21:52 daltanius NetworkManager: <debug info>^I[1175253712.330171]  nm_system_device_get_system_config (): using dhcp: type: iface name: eth0  
<fabbione> Mar 30 13:21:52 daltanius NetworkManager: <debug info>^I[1175253712.330349]  nm_system_device_get_system_config (): nextdev type: iface name: eth0  
<fabbione> Mar 30 13:21:52 daltanius NetworkManager: <debug info>^I[1175253712.330553]  nm_system_device_get_system_config (): found ipv6 entry  
<Keybuk> and is quite easy to fix, and fixed by the general udev update I'm working on
<fabbione> WHWHWH
* fabbione wins
<Keybuk> Mithrandir: I certainly think it could result in the udev db missing information for devmapper devices
<Mithrandir> Keybuk: ok, so it might be what's causing problems for the snapshotting and such?
<Keybuk> snapshotting?
<Mithrandir> https://bugs.beta.launchpad.net/ubuntu/+source/lvm2/+bug/84672
<ubotu> Malone bug 84672 in lvm2 "[feisty]  failures when creating snapshots "in use: not deactivating"" [High,Confirmed]  
<Mithrandir> ogra: can you please provide the requested trace on bug 97342?
<ubotu> Malone bug 97342 in libxklavier "keymap support regression between version 3.1 and 3.2" [High,Unconfirmed]  https://launchpad.net/bugs/97342
<Keybuk>   /dev/mapper/lvm2|systemvg|alternate-edgy-i386: open failed: No such device or address
<Keybuk> that's just because the | will be an _ :)
<ogra> Mithrandir, oh crap, i totally forgot about that one, thats for reminding
<fabbione> Keybuk: i filed a bug about the | _ thingy already
<ogra> s/thats/thanks
<Mithrandir> ogra: cheers
<kwwii> dholbach: I think I have seen bug reports like #70213 ... do you know what the problem is?
<ogra> mdke_, hey, des seb128's last upload fix edubuntu-docs ? 
<ogra> *does
<mvo> Mithrandir: I seem to be unable to reproduce the apache/php upgrade issue here in a chroot or in vmware. even with the same ordering it seems (http://paste.ubuntu-nl.org/12909). is there more to do to reproduce the issue?
<busfahrer> Excuse me, is the default Ubuntu kernel preemptive?
<pitti> busfahrer: no, just CONFIG_PREEMPT_VOLUNTARY
<busfahrer> pitti, what does that do?
<pitti> I'm not sure, please look into the kernel help for that
<busfahrer> OK, thank you
<Mithrandir> mvo: from memory, something like: debootstrap an edgy chroot.  Install apache2 + libapache2-mod-php5.  download the relevant binaries from feisty, run dpkg -i on them; it ought to blow up.  If not, try installing just apache2.2-common and apache2-mpm-prefork from feisty.
<Mithrandir> mvo: it might work by accident.
<mvo> Mithrandir: thanks. unfortunately it does seem to work by accident here so its hard to verify that any fix I come up actually works. but I will try some more to make it blow up
<Mithrandir> mvo: could u-m do anything to preseed 91814?
<mvo> bug #91814
<ubotu> Malone bug 91814 in openssl "libssl0.9.8 config asking me 'which services should be restarted to make them use the new lbraries?'" [Medium,Confirmed]  https://launchpad.net/bugs/91814
<mvo> Mithrandir: the postinst uses db_reset if that is not a problem it might be possible (also currently u-m does not pre-seed anything)
<Mithrandir> mvo: hm, that would be a problem.  Does u-m set any environment variable or such?
<Mithrandir> if so, we could make it skip that question if RUNNING_UNDER_UPDATE_MANAGER is set
<mvo> Mithrandir: not yet, but thats of course trivial
<Mithrandir> mvo: I'm thinking aloud about possible solutions, if you have better ideas, I'm open to that.
<mvo> Mithrandir: is there a point in restart other than in the case when the upgrade fixes a security issue?
<pitti> mvo: with php security updates, we already point out the need of restarting apache in the uSN
<mvo> Mithrandir: I was wondering if we should just skip it and (re)enable it for security updates
<Mithrandir> mvo: that might be an idea, yes.
<Mithrandir> it's the security bit, but for distro upgrades you should really just reboot.
<mvo> *nod*
<Mithrandir> pitti: how does apport hooks work?  Can you make one to fix bug 94911?
<ubotu> Malone bug 94911 in usplash "ship apport ignore hook for usplash BIOS code crashes (SIGTRAP within vesa_setmode->LRMI_int->run_vm86)" [Medium,Confirmed]  https://launchpad.net/bugs/94911
<pitti> Mithrandir: certainly
<Mithrandir> pitti: thanks. :-)
* pitti adds another bug to his pending pile
<directhex|work> against which package should i file a bug if update-initramfs is missing out an important module needed for booting?
<Mithrandir> I just did it
<Mithrandir> directhex|work: depends; usually initramfs-tools
<directhex|work> Mithrandir, okay. wondered whether another package contained data used to determine what to include
<Mithrandir> directhex|work: other packages can request bits they think should be included, but in general, it's initramfs-tools
<directhex|work> i've finally gotten automated installation of our critical infrastructure going, but it involved rebuilding d-i with an unreleased kernel image and an initrd workaround in the postinst script
<Mithrandir> mvo: ok, so let's disable it for release and then reenable it after release?
<mvo> Mithrandir: yes, that sounds like a good course of action
<Mithrandir> mvo: I'll get somebody to do that, then.  You have enough other bugs. :-)
<Mithrandir> mvo: could I hog you a little bit more?
<mvo> Mithrandir: sure, I have give up on #95325 for now, I seem to be getting nowhere anyway
<Mithrandir> mvo: about bug #97046, who would be a good person to assign it to?  You?
<ubotu> Malone bug 97046 in language-pack-ro "[apport]  update-manager crashed with ValueError in c2py()" [Medium,Unconfirmed]  https://launchpad.net/bugs/97046
<mvo> Mithrandir: "Ubuntu Romanian Translators (ubuntu-l10n-ro)" (I just assigned it). maybe mailing ubuntu-translators would be good as well
<Mithrandir> mvo: ok.  If it's not fixed in time, we just need to disable that translation or string.
<mvo> right
<mvo> Mithrandir: if search could be easier in rosetta I would fix it myself probably 
<Mithrandir> mvo: you have about half a trillion bugs milestoned; do you have a grand plan for how to get all of them fixed? :-9
<Mithrandir> s/9/)/
<mvo> Mithrandir: skip sleeping
<pitti> mvo: you can download the po file, edit it, and upload it again as a workaround
<mvo> Mithrandir: the trouble is that everything that  has the word "upgrade" in the report lands at my table
<Mithrandir> mvo: it looks like we might need to allocate more resources or look at whether all of the bugs are critical?
<mvo> Mithrandir: more resources would be very good, espeically for the upgrade issues that happen on the server (quagga, samba, apache)
<mvo> Mithrandir: I had hoped for the ubuntu-server team to help here
<Mithrandir> server stuff will hopefully get better in feisty+1 at least, yes.
<Mithrandir> have you mailed them and asked for help?
<mvo> no, just aksed on irc so far. mailing is probably a better option
<mvo> well, and assigning bugs of course :)
<mvo> Mithrandir: do we have more resources to allocate ?
<seb128> ogra: you speak about the yelp upload? it should
<kwwii> dholbach: just commited to HumanIcons a fix for #96497
<ogra> seb128, yay 
* ogra hugs seb128 
* seb128 hugs ogra back
<ogra> :)
<seb128> ogra: any other desktop change you need for edubuntu?
<ogra> not atm, no ....
<Mithrandir> mvo: we'd have to take them from something else, I don't have a line of developers standing by who can be sent into action, no. :-)
<ogra> should all be fine ... 
<seb128> cool
<mvo> Mithrandir: unfortunately :)
<ogra> seb128, i'm a bit worried that i didnt have any icons in my gdm until i added a gtkrc for my edubuntu theme, dont we have any fallback in gdm if something is missing ? 
<ogra> (its fixed for edubuntu, but others might run into it as well)
<Mithrandir> mvo: bug #73463; do you think this is feasible to fix for the release?  It looks more like something we might want to get in for feisty+1 to me.
<ubotu> Malone bug 73463 in update-manager "update-manager refuses to upgrade from apt-proxy" [Undecided,Confirmed]  https://launchpad.net/bugs/73463
<mvo> Mithrandir: let me update it, it should work for edgy->feisty in the basic case, I just wanted to give it a test first before I close the bug
<mvo> (or an additonal one)
<Riddell> pitti: the kubuntu dist upgrade patches in edgy-proposed don't have any problems, (and current update-manager version fixes the last significant issue in dist-upgrade tool), should I be ok to upload to -updates?
<Mithrandir> mvo: ok.  if it works in the easy case, feel free to milestone it as later or remove the milestone.
<dholbach> kwwii: super
<dholbach> bug 70213
<ubotu> Malone bug 70213 in gnome-cups-manager "Status icon doesn't support transparency." [Low,Confirmed]  https://launchpad.net/bugs/70213
<dholbach> kwwii: that's not a problem of the icon itself, but the code in most of the cases
<kwwii> dholbach: so should I ping tkampeter about this?
<seb128> ogra: not that I know
<dholbach> kwwii: yeah, might be an idea
<kwwii> dholbach: cool, will do
<dholbach> kwwii: looking at h-i-t
<seb128> kwwii: I don't think he's much of a GNOME hacker
<seb128> kwwii: I'll have a look at the transparent icon thing, I've to do a gnome-cups-manager upload anyway
<kwwii> seb128: excellent, thanks :-)
<seb128> np
* kwwii hugs seb128
* seb128 hugs kwwii
<shawarma> What happened to the i386 daily images?
<Mithrandir> shawarma: soyuz bug.
<Mithrandir> we're working on fixing it.
<shawarma> Mithrandir: Cool. 
<shawarma> Mithrandir: Might the show up later today (if you're testing your fix anyway) or will I have to wait unti tomorrow?
<saispo> seb128: thanks ;-)
<Mithrandir> shawarma: if Colin gets around to uploading a new d-i today, I can certainly roll new images to test.
<seb128> saispo: np ;)
<shawarma> Mithrandir: That would be excellent. I'm waiting for a kernel fix that I think renders Ubuntu uninstallable in qemu.
<mvo> carlos: is https://beta.launchpad.net/ubuntu/+source/language-pack-ro/+bug/97046 actually a rosetta problem with the plural-forms in the header?
<ubotu> Malone bug 97046 in language-pack-ro "[apport]  update-manager crashed with ValueError in c2py()" [Medium,Unconfirmed]  
<shawarma> Mithrandir: And I'm debugging an issue in the installer => deadlock. :-)
<Mithrandir> shawarma: i386 works; amd64 doesn't, IME with qemu lately.
<shawarma> Mithrandir: At least ubuntu-server fails on my qemu (host amd64, guest i386). It can't access neither the emulated hard drive nor the cdrom.
<cjwatson> doko: would you be able to help mvo with a few upgrade bugs?
<Mithrandir> shawarma: hm, ok.
<shawarma> Mithrandir: I used to have an old feisty daily image around that worked fine, but I upgraded it to see if another bug was fixed.
<shawarma> Mithrandir: And now it's b0rken. Which qemu are you using? The one in feisty?
<doko> cjwatson, mvo: sure
<Mithrandir> shawarma: yes.
<Mithrandir> shawarma: at least -desktop i386 worked for me earlier today.
<mvo> doko: #45761 would be quite nice
<cjwatson> doko: thanks a lot
<shawarma> Mithrandir: I could try that instead. that would sure narrow it down.
<shawarma> Mithrandir: You are using kqemu, right?
<Mithrandir> shawarma: I don't think kqemu supports cross-arch emulation
<shawarma> Mithrandir: that's all it does on amd64, actually. :-)
<shawarma> Mithrandir: It's documented somewhere. I was as surprised as you apparantly are.
<Mithrandir> shawarma: oh, ok.  Then I don't think I was, no.  Not on that host.
<shawarma> Mithrandir: amd64 guests on amd64 hosts with kqemu is still experimental. i386 guests on amd64 hosts with kqemu otoh is just fine.
<mjr> that's nice to know. Should try it then at home, since it was freed :)
<shawarma> mrj: precisely.
<carlos> mvo: yeah, that's a duplicate
<carlos> and should be used with the new language packs that martin has in daily snapshots
<cjwatson> asac: is it just me or is rendering way faster with curent firefox?
<cjwatson> not that I'm complaining :)
<mvo> carlos: when will we see updated langaguage packs that this is fixed in?
<cjwatson> s/curent/current/
<carlos> mvo: new uploads should have it fixed
<carlos> if they test daily language packs from Martin we could confirm it's fixed
<mvo> carlos: could you please mention that in the bugreport and mark the bug as fix commited?
<carlos> sure
<shawarma> Mithrandir: Er... Isn't the installer kernel the same on the ubuntu-server images as on the desktop images? 
<cjwatson> yes
<mvo> carlos: thanks!
<shawarma> Then I don't see why the desktop image would do any better. Well, I'll se when it's done downloading.
<carlos> mvo: done, set as duplicated
<carlos> mvo: it's not fix released because it depends on a language pack update
<pitti> Riddell: not sure, I didn't yet fight through all the gazillion replies in that thread, but I did see a lot of error reports
<cjwatson> shawarma: ubuntu-server will typically install a different kernel on the target system, but the installer kernel's the same
<Riddell> pitti: the error reports are either for the 3.5.6 backports (which didn't exist at the start) or for the upgrade tool itself (which as I say are all fixed)
<mvo> carlos: but its fixed commited, because it wil lbe part of the next langpack upload?
<carlos> it's fixed committed because Launchpad has the information fixed so new exports has everything fixed (or at least, it should)
<carlos> now, it should be propagated to ubuntu's archive
<pitti> Riddell: ok; I defer to your judgement here
<pitti> Riddell: at least the sheer number of replies proved that there was heavy testing
<Riddell> yes, I've been quite pleased by the number of testers
<dholbach> kwwii: uploaded
<_ion> benc: Any comments about the evil patch yet? :-)
<wick2o> anyone know which ubuntu channel is best for remastering cd help?  Not the livecd.  I have a dapper 6.06.1 LTS that i hate to apt-get update after the install, ive downloaded all the new packages and replaced the old ones witD[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[C[C[C[C[C[Ch the new ones on my cd. (even the kernal update)
<wick2o> crap, sorry for te [D's
<wick2o> cat on my keyboard
<wick2o> apt-get dist-update that was
<wick2o> but now the install is broken, wont find my nic, cant partition the harddrive
<wick2o> not sure which package went wrong or where i screwed up
<wick2o> the remastered install cd works perfectly before i tried to update the packages
<geser> pitti: re bug ##96712: it was first a sync request for feisty, then expanded to the other releases and on wednesday synced for feisty. What's the best practise to handle such cases?
<pitti> bug 96712
<ubotu> Malone bug 96712 in ekg "several vulnerabilities" [Low,In progress]  https://launchpad.net/bugs/96712
<pitti> geser: I already handled it
<pitti> geser: i. e. unsub'ed u-archive and retitled the bug
<shawarma> cjwatson: Precisely. But the problem I'm having is with the installer kernel. Weirdness.
<geser> pitti: so nothing wrong from me regarding this bug?
<pitti> geser: it was fine
<shackan> i love
<_ion> What should be done about bug #94239, btw?
<ubotu> Malone bug 94239 in atool "Current version may cause files to be deleted inadvertently" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94239
<_ion> It has been fixed in a new upstream release.
<Keybuk> iwj: ping?
<lemsx1> great, ipv6 was completely turned off now?
<asac> cjwatson: i dropped a patch that might do that yeah :)
<asac> read changelog
<asac> cjwatson: so a first fruitful outcome of patch approval :)
<lemsx1> this is why ipv6 is disabled now: modprobe: WARNING: Not loading blacklisted module ipv6
<Keybuk> hmm
<Keybuk> doesn't that spam the syslog?
<Keybuk> repeatedly?
<cjwatson> asac: yeah, I'd noticed the comment about the xft clipping patch
<doko> mvo: any other upgrade bugs
<mvo> doko: bug #95325 <- I looked into this one this morning without much success
<ubotu> Malone bug 95325 in update-manager "PHP5 breaks apache update" [High,Confirmed]  https://launchpad.net/bugs/95325
<mvo> doko: I'm unable to reproduce the bug here but it seems to affect quite a few people
<mjg59> elmo: Is there something up with the lists.ubuntu.com archive processing?
<Keybuk> keescook: ping
<fabbione> lemsx1: no it's not. read the bug comments.. all of them.
<Keybuk> siretart: ping also
<siretart> Keybuk: huh?
<Keybuk> siretart: you're listed as affected by bug #84672
<ubotu> Malone bug 84672 in lvm2 "[feisty]  failures when creating snapshots "in use: not deactivating"" [High,Confirmed]  https://launchpad.net/bugs/84672
<siretart> anyone please fix gmane :/
<siretart> Keybuk: yes. Though I cannot access the machine right now (I'm at work)
<siretart> but it's my workstation at hoem
<Keybuk> ok
<Keybuk> let me know when you can access it
<Keybuk> I have some updated packages for you to try
<siretart> this evening, in about 4h I think
<siretart> shall I test something?
<Keybuk> yes
<Keybuk> would you prefer source or binaries?
<siretart> source, I think, since I'm on amd64
<Keybuk> ok
<fabbione> lemsx2: are you also lemsx1?
<lemsx2> fabbione: yes sir
<fabbione> <fabbione> lemsx1: no it's not. read the bug comments.. all of them.
<fabbione> (re ipv6 disabled)
<Keybuk> siretart: http://people.ubuntu.com/~scott/packages/
<fabbione> you can still use ipv6 without any problem..
<lemsx1> fabbione: i did read all of them. i added a note at the end
<Keybuk> siretart: compile both sources, and install all the binaries
<siretart> wow. udev 108 eh? ;)
<siretart> Keybuk: sure, will do tonight, thanks a lot for these!
<lemsx1> fabbione: i agree with you guys. it's a fight not worth fighting since there is no much time to get all the stuff iron out. users who do use ipv6 will find their way to re-enable it
<fabbione> lemsx1: your solution is just wrong.. see you didn't read or understand
<lemsx1> fabbione: i just re-enabled it here and it works fine
<fabbione> lemsx1: i patched ifupdown to do to the right thing
<fabbione> lemsx1: if you have a configured ipv6 in interfaces, it will come up without any problem
<mjg59> fabbione: Tone, please
<lemsx1> fabbione: that only works if you have ipv6 ips defined statically in /etc/network/interfaces
<Keybuk> siretart: happily SuSE are on the same bug-fix-to-release drive as us :p
<fabbione> lemsx1: or just use iface foo inet6 manual
<lemsx1> fabbione: exactly. i read that
<siretart> Keybuk: the changelog of devmapper sounds promising!
<fabbione> lemsx1: or use iface lo inet6 loopback
<fabbione> lemsx1: all valid sintax to load ipv6 properly or remove the blacklist
<lemsx1> fabbione: i did read that. but i was relying on my link-local IPs for SSH
<fabbione> lemsx1: this fixes the problem for everybody.. people that have broken hw or want ipv6
<lemsx1> fabbione: blacklisting the module disabled the link-local ipv6's
<fabbione> lemsx1: you still get link local if you do what i said
<lemsx1> fabbione: i understand. i just removed it from the blacklist file
<fabbione> lemsx1: or add an instance in interfaces
<fabbione> both work
<Keybuk> Mithrandir: did you get affected by that bug as well?
<lemsx1> fabbione: now, if ipv6 is set with link-local IPvs, why would that use that IP to go to an external DNS server to resolv IPs? can't this be solved by somehow not using link-local IPvs for that?
<siretart> actually, the udev changelog sounds promsing as well. I'll test them ASAP (read: this evening)
<lemsx1> fabbione: like a patch to the kernel or something?
<fabbione> lemsx1: the problems are broken routers (like D
<fabbione> meh
<fabbione> lemsx1: the problems are broken routers (like ADSL routers) or broken DNS that can't cope with AAAA queries
<fabbione> even if done on ipv4
<fabbione> that makes the ipv6 timeout look really bad
<fabbione> even when ipv6 is still not doing anything
<Keybuk> fabbione: quick Q re: bug #92162
<ubotu> Malone bug 92162 in udev "untrusted chars removed from symlink targets (or might be that devmapper names are made to be untrusted)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92162
<fabbione> you can do a dig AAAA $record on an ipv4 only machine
<fabbione> that's what really breaks for people
<Keybuk> you say you have /dev/mapper/a|b|c, but the symlink target is to a_b_c ... do you also happen to have a /dev/mapper/a_b_c ?
<fabbione> lemsx1: so to the end of the story, the only way to be still RFC compliant is to load ipv6 only on user request
<fabbione> lemsx1: and this way we solve all the problems.. if you have a better solution i am all hear
<_ion> So my IPv6 is going to get broken for the second time during the development of feisty? :-)
<_ion> (No problem if i just have to modify a config file to get it working)
<fabbione> _ion: nope.. i am fixing NM to cope with that too
<fabbione> just cleaning the patch right now
<_ion> I have dynamically configured interfaces. There is a router advertisement daemon running in my network.
<fabbione> _ion: can you show me your interfaces file?
<_ion> fabbione: auto lo
<_ion> iface lo inet loopback
<fabbione> not here.. in /msg
<_ion> That was it.
<fabbione> _ion: just add: iface lo inet6 loopback
<fabbione> _ion: that will do
<_ion> fabbione: All right, thanks.
<lemsx1> fabbione: queries for AAAA records happen automatically from, say, Firefox even when ipv4 is the only protocol enabled (ipv6 disable)?
<fabbione> lemsx1: no, that won't happen.
<fabbione> lemsx1: AAAA queries are done only when ipv6 is loaded
<fabbione> lemsx1: dig can do it no matter what because you specifically asks for it
<fabbione> lemsx1: the resolver in glibc won't do AAAA if ipv6 is not loaded
<lemsx1> fabbione: i see
<_ion> fabbione: I changed inet to inet6 and ran ifdown lo; ifup lo. It says SIOCDIFADDR: Cannot assign requested address, SIOCSIFADDR: File exists, Failed to bring up lo.
<lemsx1> fabbione: there is no simple solution for this. but how does Vista or MacOS X do it?
<fabbione> _ion: i didn't say to change but to add
<lemsx1> fabbione: a patch to glibc to understand link-local IPs?
<fabbione> lemsx1: i dunno about Vista, but my MacOS install doesn't configure ipv6 automatically
<lemsx1> fabbione: like: if ! address =~ /^fe80::.*$/
<_ion> fabbione: Actually, first i tried adding it. I got the same error.
<fabbione> _ion: gimme a sec to check..
<fabbione> lemsx1: what would that accomplish?
<fabbione> _ion: do you have N-M installed?
<lemsx1> fabbione: i'm thinking that no DNS lookups should happen if you don't have a global-link ipv6 address. especially if you have link-local IPs (for now)
<_ion> fabbione: Yes.
<lemsx1> fabbione: that's the only thing that's slowing down the connection for the users in that bug
<fabbione> lemsx1: why? i can still do an ipv6 lookup to resolve a link-local on a local net
<fabbione> _ion: ok just one minute please..
<fabbione> _ion: i need to help my wife for a bit.. i will look at it as soon as i am back
<fabbione> _ion: it smells like a bug in ifupdown
<iwj> Keybuk: Hi.  Sorry, I wasn't paying attention to IRC ...
<keescook> Keybuk: pong
<lemsx1> fabbione: indeed. but this is why this is such a fundamental problem. the reason why ipv6 was disabled is because some users with bad routers or DNS servers cannot resolve AAAA records quick enough. it works for everybody else (all of us in private LANs or behind corporate firewalls with real network equipment, Cisco and so on)
<maswan> FYI: out of the unique IPs for dists/*/main/*/Packages.bz2 downloaded from se.archive so far today, 2% came in over ipv6
<lemsx1> fabbione: but, disregard ipv6 for now. you guys are busy in much more important things
<lemsx1> fabbione: i'll just re-enable it locally and post it online so other users can find a way to re-enable that themselves
<Keybuk> keescook: hi
<keescook> Keybuk: hiya!
<Mithrandir> Keybuk: no, I'm not affected by the lvm2 bug.
<Keybuk> keescook: you're listed as the reporter of #84672
<Keybuk> keescook: I have some packages I'd like you to try, to see whether they help
<keescook> Keybuk: I'm happy to help!
<Keybuk> keescook: http://people.ubuntu.com/~scott/packages/
<Keybuk> please compile both sources, and install the resulting binaries
<Keybuk> and see whether they make a difference
<keescook> Keybuk: you got it; one sec
<keescook> Keybuk: will the udev package install sanely, or will I need to reboot?
<Keybuk> keescook: it'll install; kill the running udevd, and run /sbin/udevd --daemon again to start the new one
<keescook> Keybuk: okay; I'll downgrade my lvm2 to get rid of my hack.  ;)
<iwj> OMG WTF I'm an idiot
<iwj> ./etc/udev/rules.d/65-persistent-storage.rules:KERNEL=="md*", ACTION=="add|change", PROGRAM="watershed -i udev-mdadm true", GOTO="persistent_storage_path_uuid"
<Keybuk> iwj: hmm?
<iwj> Oh, bug 75681.
<ubotu> Malone bug 75681 in mdadm "boot-time race condition initializing md" [High,Confirmed]  https://launchpad.net/bugs/75681
<iwj> Very very silly of me.
<Keybuk> well, firstly that rule shouldn't be in that file
<keescook> Keybuk: were you able to reproduce the snapshot failures?  because I can't reproduce it now.  :P
<Keybuk> keescook: yes, and I was able to cure them by that change
<Keybuk> keescook: it cures them for you too?
<Keybuk> iwj: what's the fix?
<keescook> Keybuk: I must be missing the race atm, because I downgrade my lvm2 away from my hack (before trying your stuff) and I can't make it fail.  I'll keep trying
<Keybuk> keescook: :-/
<keescook> ah-ha, it's because updatedb is running which makes enough IO noise.  I'll wait a bit
<iwj> Keybuk: Well, I need to figure out what I was thinking (what was I thinking??) and then do whatever it was in some sane way.
<Keybuk> iwj: I couldn't work out what that rule was trying to achieve at all
<keescook> Keybuk: okay, reproduced.  :)  now trying fix....
<iwj> Keybuk: I think it's trying to block processing of the rest of the rules until mdadm has finished.
<mvo> cjwatson: is the installer fixed so that it writes out /dev/cdrom entries in /etc/fstab instead of /dev/{scd?,hd?} ?
<iwj> But it's completely bogus because it invents a spurious mdadm execution.
<iwj> Which it then turns into a no-op and everything is not done.
<keescook> Keybuk: not sure if it matters, but got warnings during initramfs regen:
<keescook> cp: cannot stat `/etc/udev/rules.d/25-dmsetup.rules': No such file or directory
<siretart> iwj: btw, was my udev debug output helpful to you?
<Keybuk> keescook: hmm, does that file exist?
<iwj> siretart: Yes, thank you.
<siretart> \o/ :)
<keescook> Keybuk: strangely, it does
<iwj> Quite so.  *bangs head on wall*  It's very very silly of me.
<Keybuk> iwj: right, and I couldn't work it out because you have watershed run by 70-mdadm.rules anyway
<Keybuk> (which has the wrong filename...)
<Keybuk> keescook: or was it from the first of multiple initramfs regens?
<keescook> Keybuk: I get a warning during snap creation, but it seems to work
<keescook>   Rendezvous with udev timed out for 'systemvg-edgy_chroot-real'; stat failed: No such file or directory
<iwj> Keybuk: wrong filename> How so ?
<keescook>   Logical volume "edgy-mongoose2" created
<cjwatson> mvo: the installer just uses whatever device nodes are created by udev and for which vol_id says ID_CDROM=something
<Keybuk> iwj: 70-* is for user symlink creation ... which that rule doesn't do
<keescook> Keybuk: it happened during both initramfs updates when dpkg -i'ing the new .debs
<cjwatson> mvo: I can see if there's some way to kludge it into preferring /dev/cdrom ...
<iwj> I have no other files 70-* here.
<Keybuk> exactly
<iwj> Maybe you're thinking of 60-symlink.rules.
<iwj> Eh ?
<Keybuk> did you read /etc/udev/rules.d/README ?
<iwj> Well, I have 70-lvm and 70-mdadm.
<Keybuk> right, both of those filenames are wrong
<mvo> cjwatson: that would be good, I currently work on the code that will convert existing /etc/fstabs to point to /dev/cdrom
<iwj> You think it should be in 80 ?
<Keybuk> iwj: yes, 85-something
<iwj> I think in practice it doesn't make any different but I'll change them.
<cjwatson> mvo: /dev/cdrom isn't guaranteed to be right though, if e.g. you have two CD-ROM drives and are installing from the second one
<keescook> Keybuk: running update-initramfs -u after the .deb updates runs fine.  I assume the file is still in a .dpkg-new state?
<cjwatson> mvo: that's why the installer doesn't rely on it
<Keybuk> keescook: probably
<iwj> The point of PROGRAM="..." there is to prevent processing of md* event B from continuing until the mdadm that caused B has finished.
<keescook> Keybuk: okay, so that leaves me with a pause followed by the "Rendezvous with udev timed out" warning (but the lv does appear)
<Keybuk> keescook: hmm
<Keybuk> keescook: how are you running this btw?
<Keybuk> clearly I haven't quite got the same test case as you
<Keybuk> iwj: that's what I don't understand -- why that matters
<iwj> Because otherwise mdadm fights with the other copy of itself.
<keescook> Keybuk: here's an lvs dump and the snapshot creation output: http://paste.ubuntu-nl.org/12952/
<iwj> And also other programs (vol_id) start accessing the md device before it's ready.
<iwj> It's all a bit of a kludge (like most of this stuff in udev).
<Keybuk> keescook: what's in /dev/mapper?
<Keybuk> iwj: persistent-storage ignores md devices
<Keybuk> so that doesn't matter so much
<iwj> No persistent-storage no longer ignores md devices because it shouldn't.
<Keybuk> yes, it should
<iwj> Ie, we're supposed to look for filesystems in them etc.
<Keybuk> see the long thread on hotplug-devel
<iwj> hotplug-devel ?  I'm not on that list ...
<keescook> Keybuk: -> privmsg
<Keybuk> persistent-storage isn't about "Looking for filesystems", it's about making /dev/disk
<Keybuk> which we don't need for md devices at this point
<mvo> cjwatson: right. I should probably change the cdrom mehtod in apt to use udev to figure out what to mount somehow. but too late now for feisty
<iwj> 65-persistent-storage is the thing that runs vol_id to set ENV{ID_FS_TYPE}
<Keybuk> which isn't used by any later rules <g>
<cjwatson> mvo: definitely avoiding relying on /dev/cdrom would be lovely ...
<iwj> Yes it is, it's used by 70- (to be 85-) {lvm,mdadm}
<Keybuk> (and in fact isn't even used by *that* rule)
<iwj> So for md* devices we skip most of persistent-storage.
<Keybuk> ok, so that's a bug -- you're relying on the persistent storage rules to decide whether or not to run a program later
<Keybuk> you should just run vol_id again
<iwj> No, because persistent-storage is what creates (for example) by-uuid.
<iwj> And if you wanted to mount your root fs by uuid then that's needed.
<Keybuk> yes
<iwj> So if you have an md device you need to run persistent-storage to check to see if it needs a by-uuid link.
<Keybuk> which is broken for various reasons inside the kernel
<Keybuk> so disabled
<Keybuk> the kernel md maintainer is working on fixing it
<iwj> Err, what ?
<Keybuk> see the long thread on hotplug-devel
<iwj> reference ?
<Keybuk> hotplug-devel
<Keybuk> mailing list
<iwj> I'm talking about the uuid of the contained filesystemk.
<iwj> Err, what, just recently ?
<Keybuk> the contained filesystem won't exist if you block various bits
<mvo> cjwatson++ :)
<iwj> Block what ?  Uh ?  I just make sure we don't run vol_id until the other mdadm has finished.  Then we run vol_id and do by-uuid and whatever else (perhaps vgscan).
<Keybuk> ok, but how do you know you're being run because of another mdadm?
<iwj> The reason I put mdadm and lvm at 70 is because they really ought to be in persistent-storage but it needed to be a separate file.  Perhaps I should be arguing for 66-
<iwj> Keybuk: You don't.
<iwj> But if it's an md* addition then you definitely know you don't want to process this device until mdadm has finished.
<iwj> Any mdadm, I mean.
<iwj> The bug is that I should just take out the lock and not establish a silly noop cohort (which is grievous and I have no idea why I did it).
<Keybuk> iwj: ok, so any md-* device should block while mdadm is running?
<iwj> Yes.
<Keybuk> that's easy, create a 10-xxx.rules which does *that*
<iwj> That is, the event processing should block.
<iwj> Uh ?  Why a separate file ?
<Keybuk> mdadm should be called in 85-mdadm.rules for a block device that looks like it contains an md image
<Keybuk> iwj: because then it's much easier to maintain
<Keybuk> and that seperate file should be shipped in the mdadm package
<Keybuk> not in udev
<iwj> But persistent-storage needs to know which things to do for md* anyway.
<Keybuk> (since it only applies to people with mdadm instealled)
<iwj> Various bits of persistent-storage need skipping and other bits need doing.
<iwj> Just as for dm-*.
<Keybuk> ignore persistent storage
<Keybuk> pretend its not there
<iwj> Then you won't get your root fs mounted if it's directly on md.
<Keybuk> your stuff has to work without them
<iwj> Because nothing will create by-uuid.
<iwj> ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID}"
<Keybuk> yes?
<Keybuk> that's all persistent-storage is supposed to do
<Keybuk> make the /dev/disk symlinks
<Keybuk> it's not supposed to have wacky additional side-effects
<Keybuk> and is certainly not mandatory
<iwj> Well, but parts of it don't apply so I have to say KERNEL="md*" do some stuff.
<iwj> KERNEL="md*", GOTO...
<Keybuk> upstream have almost all of it skipped for md*
<iwj> And the md* thing is right next to devmap_name which helpfully does the same thing for dm* devices.
<Keybuk> that devmap_name is SO in the wrong place it's unbelievable
<iwj> Keybuk: Yes, I skip slightly less.
<Keybuk> at least three bugs are caused by it being there, and not earlier
<cjwatson> Erm. *Setting* the kernel name to "md*"?
<iwj> cjwatson: No, missing =./
<cjwatson> ok
<iwj> In my typing.
<iwj> Keybuk: OK, since you feel so strongly about it (and you do seem to be right about NAME= being too late) I'll move the PROGRAM=... from persistent-storage.
<Keybuk> I did write most of it
<Keybuk> and am pretty confident I was sober at the time :)
<iwj> Hmmm.  This whole setup is crazy though, ping-ponging backwards and forwards between daemons and tools and kernel.  But that's another conversation.
<Lutin> mvo: could you have a look at the debdiff bug #93721 again ? (new debdiff using debconf)
<ubotu> Malone bug 93721 in reseed "[can-not-install]  maintainer script failure" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93721
<mvo> Lutin: I will comment inline 
<mvo> Lutin: loooks good, no need to comment .) I assume you tested it ?
<Lutin> mvo: install/upgrade/removal/reinstall, I guess that's enough ?
<siretart> Keybuk: do you still want me to test your packages or are you confident with keescook results and/or the conversation with iwj?
<Keybuk> siretart: I'm confident that the race is gone, but there seems to be more problems
<superm1> cjwatson, ping
<mvo> Lutin: with/without network I guess? thats great then, thanks a lot for working on it!
<cjwatson> superm1: ?
<superm1> cjwatson, i wanted to see how you felt about bug 86358
<ubotu> Malone bug 86358 in user-setup "user-setup allows mythtv to be chosen for a username" [Undecided,Needs info]  https://launchpad.net/bugs/86358
<superm1> since you were maintainer on user-setup
<fabbione> _ion: re... sorry i had to get wife out of the door
<fabbione> _ion: testing now
<cjwatson> superm1: sure, I can add it to reserved-usernames now
<superm1> cjwatson, great, thanks :)
<cjwatson> not sure a patch was strictly needed though :)
<Lutin> mvo: on my box, it's only no-network, there must an issue with my proxy, I still need to find a tester who's got a direct connection :)
<cjwatson> (I mean, thanks, but it's probably more work to apply it than to open vi and hit o ...
<cjwatson> )
<superm1> haha
<superm1> well i guess i can say i'm in the habit of making a patch any time i make changes, no matter how simple.  silly motu people making me that way :)
<mvo> Lutin: that shound be fine, that worked well 
<Nafallo> mvo: btw. should I be able to select rsync when choosing mirror? :-)
<fabbione> _ion: my bad.. you need to add a line like: iface lo inet6 manual
<fabbione> _ion: i misread the man page for interfaces before
<Lutin> mvo: you just tested it ?
<Nafallo> fabbione: not loopback for lo?
<fabbione> Nafallo: no, what i just said
<Nafallo> oki :-)
<cjwatson> superm1: (done)
<superm1> thx cjwatson.  did you close the bug too?
<mvo> Nafallo: ehhh ... no!
<cjwatson> superm1: yes
<superm1> k great
<Nafallo> mvo: well, if I select se.archive.ubuntu.com I can choose rsync, but it failed ;-)
<mvo> Nafallo: don't do it then :p
<Nafallo> told me there was no such backend or something along those lines :-)
<mvo> Nafallo: seriously, can you please file a bug against software-properties?
<Nafallo> mvo: I will. just thought there was something you experimented with first :-)
<mvo> Nafallo: thanks :)
<iwj> Keybuk: That new udev package you were doing, is it uploaded yet and what's the version ?  Or should I go ahead and upload myself this afternoon ?
<mvo> Lutin: yes, just tested it and works with network as before 
<Keybuk> iwj: send me patches
<Keybuk> my new package is 108-0ubuntu1
<Nafallo> mvo: Bug #99060
<ubotu> Malone bug 99060 in software-properties "[feisty]  shouldn't let me select rsync" [Undecided,Unconfirmed]  https://launchpad.net/bugs/99060
<iwj> Keybuk: OK.  With or without the --suppress-syslog patch included ?
<Keybuk> without
<Keybuk> that's already included in my package
<Lutin> mvo: ok, cool. uploading :)
<iwj> Keybuk: Right.
<mvo> Lutin: thanks
<Lutin> mvo: np
<_ion> fabbione: I'll try that in a bit.
<fabbione> _ion: thanks
<fabbione> who would like to eyeball a patch to NM with me?
<fabbione> http://people.ubuntu.com/~fabbione/nm.debdiff
<fabbione> fairly small one
<Keybuk> iwj: why do you call vgck every time a devmapper device is added?
<fabbione> Mithrandir: ^^ a similar fix can be applied to fix the other one for alias ifaces
<iwj> Keybuk: Because it might be a nested lvm volume or something crazy like that
<Keybuk> iwj: but that command only seems to be a consistency check
<Keybuk> which will block if that vg is currently being modified
<Keybuk> e.g. if you're making a snapshot
<Keybuk> and actually results in udev never completing the rule for the snapshot devices
<iwj> Keybuk: Oh, sorry, yes, that's the blocking thing.
<Keybuk> "the blocking thing" ?
<iwj> It's there to stop other things opening the device while the lvm stuff is still fiddling but I think it's in the wrong place.
<Keybuk> you can't block them!
<Keybuk> because the lvm stuff fiddling with it might be *WAITING* for it
* iwj tries to remember how this was all supposed to work ...
<iwj> RUN+= happens after the device is made and so forth so I must be wrong about what it was for.
<Keybuk> yes
<Keybuk> after the single device is made ...
<Keybuk> but you have no idea what order lvm might be waiting for the devices in
<Keybuk> it might make, e.g. vg-snap, vg-snap-cow, vg-snap-real
<Keybuk> but wait for vg-snap-real, vg-snap-cow, vg-snap
<iwj> Yes.
<Keybuk> so, just to confirm
<Keybuk> the vgck is there so that you can't try and use the volume group while it's locked
<Keybuk> ?
<Mirv> hi... would someone have a bit of a time to do a new upload of bluez-gnome, since dholbach got it a bit wrong (mostly because of my complicated instructions)?
<Mirv> https://bugs.launchpad.net/ubuntu/+source/bluez-gnome/+bug/95796 - get 0.6-1ubuntu1 sources, add second to last patch on top of it with patch -p1, then drop the last patch (03) in debian/patches and there'd you have a correct upload
<ubotu> Malone bug 95796 in bluez-gnome "Desktop item translations not shown" [Medium,Fix released]  
<Keybuk> iwj: there's definitely something a little kooky going on
<iwj> Keybuk: No, my best current theory is that I was having a brainstorm when I wrote this crack.
<Mirv> now in -ubuntu2 there's a patch that adds itself among else :)
<iwj> The watershed -i yada true thing is crackbrained too.
<Keybuk> what I'm seeing (bug #84672) is this:
<ubotu> Malone bug 84672 in lvm2 "[feisty]  failures when creating snapshots "in use: not deactivating"" [High,Confirmed]  https://launchpad.net/bugs/84672
<iwj> Yes, that might be responsible.
<Keybuk> - lvcreate -s spawns a whole bunch of new devmapper devices
<iwj> Indeed.
<Keybuk> - each of those watersheds on vgck (which is blocked by the running lvcreate)
<Keybuk> - and the first device it happens to be waiting for never actually happens
<Keybuk> (until the timeout finishes)
<mvo> does anyone here has a system that is upgraded all the way back from warty? I would be interessted in /etc/sudoers and /etc/group
<Keybuk> it could be as simple as udev hitting a child limit
<iwj> Keybuk: I'm going to go and stare at this some more and try to figure out what, if anything, I might have been thinking.
<Keybuk> oh
<Keybuk> *I see*
<Keybuk> lvm RENAMES one of the devices!
<Keybuk> so you get events for dm-1 (vg-snap), dm-2 (vg-snap-cow), dm-3 (vg-snap *again) and then a change on dm-0 (vg-lv)
<Keybuk> followed by a remove of dm-1 (vg-snap) and an add of dm-1 (vg-snap-real)
<Keybuk> udev won't process the second remove/add while the first add is blocked
<iwj> There's going to be trouble in any case if lvm wants to make a device and then delete it again right away because vol_id and so on will be opening it.
<Keybuk> iwj: vol_id shouldn't touch it since there's been no change/dm-0 yet
<iwj> Err, no, actually vol_id is PROGRAM= so happens before device node.
<iwj> I'm still at a loss to explain this vgck rule.
<Keybuk> I seriously think that trying to do "WAIT! zis device is not ready yet!" through tricks in udev rules is wrong
<iwj> Unfortunately there doesn't seem to be a better way.
<Keybuk> sure there is
<Keybuk> fix the kernel to emit a ready event or something
<iwj> Err, IC, yes.
<iwj> I mean obviously I agree.
<Keybuk> (which is what I understand to be happening)
<Mirv> I now included there a new .tar.gz with which you could take apt-get source bluez-gnome and just replace the debian/patches contents with the .tar.gz contents - it includes the modified 01 patch and the two new patches 02 and 03
<iwj> Keybuk: Is there a way for a program to inject a udev event ?
<Mirv> (if anyone is interested, otherwise I'll wait for dholbach, but he probably went already to spend weekend etc)
<iwj> I mean, a random user program tell udev `here have this event and process it' ?
<iwj> Because we really don't want to be running all of this crap for the innards devices for lvm snapshots (and that kind of thing).
<Keybuk> iwj: udevsend
<Keybuk> which, err, vanished a while ago
<Keybuk> heh
<iwj> We could have udev ignore the kernel event and have lvm send a `now process this' when it was ready.
<Keybuk> a program can echo the event to the uevent file under /sys for the device
<Keybuk> udev ignore which kernel event?
<iwj> Have udev ignore all dm* and md* events.
<iwj> And make new events up in userland in the lvm tools and mdadm.
<Keybuk> you wouldn't want it to ignore dm-* events, because you need to name them :)
<Keybuk> but yes, we should ignore them from the purposes of trying to use the device node
<iwj> No, you have the lvm tools make the device nodes and specify the name and so on.
<Keybuk> and have a hammer events
<doko> pitti, seb128, Mithrandir: openoffice.org (i386) should be in binary NEW; please process and promote to main. 12h build time ...
<pitti> doing...
<iwj> That avoids all of this silliness where we try to move functionality from lvm to udev for no good reason.
<iwj> But this is all feisty+1.
<Keybuk> udev maintains /dev
<Keybuk> lvm should not be trying to do that itself
<iwj> Keybuk: Why not ?
<Keybuk> making dm-* nodes from udev makes sense
<iwj> I don't think so but I hate udev.
<Keybuk> this is evident :)
<iwj> It adds extra complexity - now the lvm tools need to synchronise and we have that crappy spin.
<iwj> And you have n code paths (udev not running, udev running, udev not installed ...)
<Keybuk> udev is always running
<iwj> Hah.
* Adri2000 needs help with http://librarian.launchpad.net/7055523/buildlog_ubuntu-feisty-i386.libclass-trait-perl_0.22-2ubuntu1_FAILEDTOBUILD.txt.gz, no problem in pbuilder...
<iwj> Anyway, this is all pie in the sky.
<iwj> OK, so to make this work we do somehow need to suppress udev's processing of dm* devices except when lvm wants it done.
<iwj> How about: we invent a flag file which if it exists indicates that the device is supposed to be processed.  vgchange touches this file but other things don't.
<iwj> Actually, vgchange only wants to touch this file when run from udev.
<Keybuk> let's talk about this post-feisty
<iwj> OK, but we need to do something for now.
<Keybuk> no, right now all we need to do is remove vgck
<Keybuk> that's sufficient
<iwj> Will that solve it ?
<seb128> Adri2000: Provides are not versionned
<Keybuk> (along with the fix to devmapper)
<Keybuk> yes
<Keybuk> it won't "solve" something trying to use the udev event to do something with the dm device
<Keybuk> but since nothing does anything with those, it's not an immediate problem
<seb128> Adri2000: looks like libtest-simple-perl is already available due to perl-modules
<iwj> The vol_id and by-uuid stuff does something with the dm* device.
<Keybuk> and tbh, I'm not sure it ever will be a problem -- since whatever it tries to do will fail repeatedly until the last one when it'll work
<iwj> And is essential.
<Keybuk> iwj: we don't use uuid for dm devices
<Keybuk> since they have fixed names
<iwj> Err, point.
<seb128> Adri2000: so the >= doesn't work
<Keybuk> and those would work anyway
<Keybuk> since vol_id would repeatedly fail
<Keybuk> and then the last one would work
<iwj> Keybuk: So you need to change
<iwj> KERNEL=="dm-*", ACTION=="add|change", PROGRAM="devmap_name %M %m", NAME="mapper/$result", GOTO="persistent_storage_identify"
<iwj> to skip to the end instead.
<Keybuk> iwj: I already have a fixed devmapper package
<Keybuk> that installs a 25-dmsetup.rules instead
<Adri2000> seb128: so I just remove the "(>= 0.62)" and it should work then?
<iwj> Oh, just a moment, md-on-dm.
<Keybuk> md is what I'm about to test next
<seb128> Adri2000: yeah, or just drop the Build-Depends if perl-modules is already there
<Keybuk> afaict, so far, this stuff stacks happily
<iwj> Keybuk: You run vol_id on dm* things still ?
<Keybuk> lvm-on-dm-on-lvm works
<Adri2000> perl depends on perl-modules which depends on libtest-simple-perl, so yes I should be able to remove completely this B-D, thanks seb128
<iwj> Right, so you must do.
<seb128> Adri2000: np
<Keybuk> yeah, was testing it
<Keybuk> the first couple of add/change events fail a bit
<Keybuk> but eventually you get a change event that works
<iwj> And lvm doesn't try to delete devices while udev stuff is looking at them (contrary to previous reports) ?
<Keybuk> does it matter if it does?
<Keybuk> they'll just error
<iwj> That bug has reports of lvm failing because it can't remove the device because something has it open.
<iwj> We don't mind the other things failing but if lvm wants to make temporary devices and remove them again we have to stop them from being vol_id'd etc.
<Keybuk> for feisty, I'm inclined to just allow one level of stacking :)
<Keybuk> no lvm-on-dm or md-on-dm :p
* Nafallo growls a bit at Keybuk *
<Nafallo> ;-)
<Keybuk> Nafallo: if you're doing it today, you are doing by hand
<Keybuk> so that'll continue to work quite happily
<Nafallo> Keybuk: :-P. I hate that I have to break=premount though :-)
<iwj> Keybuk: You mean no md-on-md I take it.
* Nafallo has LVM on MD * 2 :-)
<iwj> But the difficulty is  lvcreate -s  creates some dm* and then deletes it; our vol_id has to run on the dm* because it might be an md and without that then md-on-lvm wouldn't work.
<iwj> That is it might be an md component and only vol_id can tell.
<Nafallo> is there any fundamentaly different between using dm* and md*?
<iwj> Uh ?
<Keybuk> I can't replicate that at the moment
<Keybuk> I have vol_id running on dm-* events
<Keybuk> (I think)
<Nafallo> can't we just run vol_id om md*?
<Keybuk> yup, definitely do
<Keybuk> and it's fine
<Keybuk> haven't had an "in use" error yet
<iwj> Keybuk: Put sleep 2 in lvm just before the bit where it deletes the device and sleep 10 in vol_id ?
<Nafallo> but then again. Keybuk will fix this bug for me now ;-)
<iwj> I hate this kind of thing.  It's such a PITA
<iwj> sleep 2 in libdevmapper delete call just before the ioctl perhaps.
<Keybuk> that works fine
<Keybuk> because udev blocks on vol_id
<Keybuk> so lvm doesn't get to delete the node just yet (it's blocked on udev because it's waiting for a later node to appear)
<Keybuk> when vol_id finishes, udev processes the remove event, then the add event
<Keybuk> which lets lvm continue
<Keybuk> (and udev runs vol_id again)
<Keybuk> it's exactly the same block that caused the vgck to *fail* :p
<Keybuk> but this way round it's doing the right thing
<iwj> What a crapshoot.
<iwj> Fair enough.
<Nafallo> :-)
<Keybuk> actually, from reading the code, this is exactly why lvm does it this way round
<Keybuk> it issues all of the individual requests it needs to, and waits for the one it knows will complete last
<Keybuk> (since things probably have polled /dev/mapper in the past, or insane things)
<Keybuk> the bug is explained because the devmapper patch was fluffed
<Keybuk> and it never waited for udev :p
<iwj> Did I mess that up as well ?  I was having a good day.
<iwj> Was that the week I had the bidding war over this house perhaps ?
<iwj> Keybuk: Can you try deleting  PROGRAM="watershed -li udev-mdadm true"  from  KERNEL=="md*", ...  in persistent-storage.rules ?
<iwj> I think this conversation has convinced me it was just wrongheaded and should be ditched.
<iwj> Along with the vgck.
<Keybuk> *nods* will see whether that helps
<iwj> I think it will fix 75681.
<iwj> Provided it doesn't break mdadm totally which is what I'm about to try.
<iwj> Oh yay update-initramfs.
<Nafallo> bug 75681
<ubotu> Malone bug 75681 in mdadm "boot-time race condition initializing md" [High,Confirmed]  https://launchpad.net/bugs/75681
<Nafallo> ooh. nice! :-)
<Keybuk> iwj: in vmware, nobody can hear you scream ;)
<iwj> 75681 is so stupid it's unbelievable :-/.
<iwj> Well, I suppose I should count today as a good day since at least I found my earlier mistake.
<Keybuk> I need to buy a *really* big disk, so I can store vmware images on it
<Keybuk> "this is a feisty machine with cryptroot-on-LVM-on-MD"
<mvo> Keybuk++ the disks tend to fill up rather quickly with lots of snapshots
<pitti> according to baoab, vmware images take 70% of my /home partition :)
<Mithrandir> sladen: are you planning on uploading to fix bug 69225?
<ubotu> Malone bug 69225 in hotkey-setup "Fix to make hotkey-setup working with Compaq Evo N620c" [Low,Confirmed]  https://launchpad.net/bugs/69225
<iwj> Eeech, lilo is writing one byte at a time to my flash stick, and calling fdatasync each time.
<iwj> Yay!  Infinite loop of udev events!
<Keybuk> iwj: how did you get that?
<Nafallo> iwj: be happy. I get a loop of my RAID0-swap on boot. tells me it can't create it since the disks are added to it already or something to that extent :-)
<Keybuk> is swap-on-lvm-on-md sane or silly?
<Nafallo> Keybuk: silly. swap-on-md though... ;-)
<poningru> lol
<Keybuk> heh
<iwj> swap-on-lvm doesn't seem so mad really.
<iwj> After all if you make your whole disk be lvm then where are you going to put the swap ?
<Keybuk> *wails* WHY DO PEOPLE *DO* THIS?! :p
<Keybuk> disk, filesystem, easy
<Keybuk> disk, lots of wibbly wobbly poorly interacting bits of undermaintained software, filesystem
<Keybuk> BAD
<Nafallo> Keybuk: lol
<sharms> I have seen no problems with LVM
<sharms> and all the servers I manage use LVM, so they must be doing something right
* Keybuk tries to work out what the mdadm-raid and lvm init scripts are for
<Keybuk> since if I delete them, everything still works
<Keybuk> oh, hmm, not quite works
<Nafallo> sharms: not running feisty, are they? ;-)
<iwj> Nafallo: disks already added> Yes, exactly that.
<Nafallo> iwj: hehe. that's my current showstopper aswell :-)
<iwj> Nafallo: I can boot happily if I do the udevtrigger dance in the initramfs by hand.
<Nafallo> iwj: pkill mdadm and cat /proc/mdadm shows stuff is already up though :-P
<iwj> Oh, happiness.  My symptoms have gone away.  Dammit!
<Nafallo> lol
<Nafallo> good for you ;-)
<iwj> Well, that means I can't fix yours, doesn't it :-(.
<Nafallo> and since it's my router I can't talk to you next time it happens, since I won't have Internet :-)
<iwj> Nafallo: Does it do it for you every time or only sometimes ?
<Nafallo> every time I break=premount
<sharms> Nafallo: ha they are all suse
<Nafallo> if I try to just boot it I end up with sd: added sdg and a freeze ;-)
<iwj> Nafallo: Can you capture /u from   udevd --verbose --suppress-syslog >>/tmp/u 2>&1 &  for me ?
<iwj> I mean, would that be easy ?
<iwj> I mean /tmp/u.
* iwj greps the source to mdadm for `already' and remains unenlightened.
<Nafallo> I write it down until next reboot :-)
<iwj> Err, OK.  I was hoping to nail this dammit.
<Keybuk> hmm
<Keybuk> iwj: so, removing that line isn't enough
<iwj> Indeed.
<Keybuk> now what happens is that the event for md-* runs vol_id, but is unable to see an LVM partition there
<iwj> Hum.
<iwj> mdadm is probably still fiddling with it.
<siretart> well, Keybuk's packages improved things for me a bit: I now have all raid volumes up automatically, but for lvm, it still needs the manual udevtrigger dance 
<Keybuk> siretart: yup, that's exactly what I'm seeing too
<sladen> Mithrandir: uploaded
<Nafallo> lol. sudo asked me if I was on drugs :-)
<iwj> Keybuk: I'm going to add that crappy blocking thing back but this time without the stupid null cohort.
<siretart> Nafallo: everyone should have 'Defaults insults;' in their /etc/sudoers ;)
<iwj> That will stop it running vol_id until mdadm has finished.
<iwj> I hope.
<Keybuk> iwj: what would that rule look like?
<siretart> huh?
<iwj> KERNEL=="md*", ACTION=="add|change", PROGRAM="watershed -li udev-mdadm true", GOTO="persistent_storage_path_uuid"
<iwj> But your watershed doesn't have the -l option.
<Keybuk> what does -l do?
<siretart> during boot, there is some initscript stating "Generating udev events for MD arays...." <- what's this? isn't that supposed to happen in the initramfs?
<iwj> Take out lock but do not join or become a cohort.
<siretart> it hangs for me a looooooooong time
<Keybuk> siretart: that's the mdadm-raid init script
<Keybuk> the effects of which is what we're trying to do inside udev rules :p
<siretart> hm. I cannot interrupt it with Ctrl-C. thanks to upstart, I think
<Keybuk> oh aha!
<Keybuk> damn that was obvious
<Keybuk> iwj: no need for the lock
<Keybuk> md only emits the "change" event when it's finished
<Keybuk> (looking at the source)
<Keybuk> and there's a udev bug; ACTION!="add|change" doesn't work
<iwj> Uh, in what way doesn't it work ?
<Keybuk> it's always true, fwict
<iwj> And ACTION=="add|change" is correspondingly always false ?
<Keybuk> no, == seems to work
<Keybuk> the | bit isn't expanded for !=
<iwj> Err I think the blocking is needed for a different problem.
<Nafallo> hmm. I'll hope you nail the bugs so I can test later and see if it fixed all of mine :-)
<iwj> That is, the processing of the change event ought to deal with running vol_id again at the right time.
<Keybuk> it will, won't it?
<iwj> But if you run mdadm at the wrong time it seems to get into this loop.  At least that's what I suppose is happening.
<iwj> Keybuk, right if you avoid the bug you just mentioned :-).
<Keybuk> so, err, I think this is actually working right now
<iwj> Have you ever seen Nafallo's repeating `disks already wossnamed' ?  I've seen it once.
<Keybuk> "ever" ? no
<iwj> And what's your theory about the cause ?
<Keybuk> since today is the first time I've ever played with md/lvm :p
<iwj> Keybuk: I mean, in any of your tests.
<Keybuk> what's the message, and where does it happen?
<Nafallo> essentially, I run scripts/local-top/mdadm from-udev
<iwj> I've only seen it in the initramfs.  I didn't write the message down but it was something like `md2: cannot start, already has disks'.
<Nafallo> scripts/init-premount/udev
<Nafallo> sometime in there most often md0 starts spitting what iwj wrote over and over again until i pkill mdadm :-)
<Keybuk> kooky
<Nafallo> then it continues, and when finished I manually check /proc/mdstat :-)
<Keybuk> no, not seen that yet
<iwj> Can you remember the exact message ?  I've tried grepping the mdadm source but obviously my search term is wrong.
<Nafallo> Keybuk: come visit me then. reproducible every time, and Sweden starts to get warmer ;-)
<Nafallo> we don't have logging that early I guess? :-/
<iwj> Nafallo: You can edit the script that starts udevd to capture the log.  --verbose --suppress-syslog >>/tmp/some-logfile 2>&1
<Nafallo> found it in dmesg :-)
<Nafallo> [   73.890000]  md: array md0 already has disks!
<Nafallo> [   74.180000]  md: array md0 already has disks!
<Nafallo> [   74.430000]  md: array md0 already has disks!
<siretart> is there any way I can abort the mdadm-raid init script? it still hangs (now 15minutes)
<iwj> Binary file ./lib/modules/2.6.20-13-generic/kernel/drivers/md/md-mod.ko matches
<Nafallo> UGH
<iwj> Well my lock thing didn't cause any damage.
<Nafallo> hmm
<iwj> http://www.chiark.greenend.org.uk/~ian/d/watershed-lockonly.patch
<iwj> Plus in persistent-storage.rules
<iwj> KERNEL=="md*", ACTION=="add|change", PROGRAM="watershed -li udev-mdadm true", GOTO="persistent_storage_path_uuid"
<iwj> (should probably be in 10-wedge-mdadm.rules or something)
<iwj> http://www.chiark.greenend.org.uk/~ian/d/watershed is the executable (source is the udev-nosyslog nearby with the watershed-lockonly.patch applied).
<iwj> You should be able to just copy that into /lib/udev and edit your rules.
<iwj> I take it you're not in a position to do a test any time soon ?
<Keybuk> ACTION=="add|change", GOTO="persistent_storage_start"
<Keybuk> GOTO="persistent_storage_end"
<Keybuk> seems to work :p
<iwj> *snort*
<iwj> But we still have this `already has disks' problem.
<siretart> iwj: I'd love to test your watersched patch, I'm still blocked by that init script :/
<iwj> Err, what init script ?
<siretart> mdadm-raod
<siretart> raid
<Keybuk> just remove it
<iwj> /etc/init.d/mdadm-raid ?
<siretart> seems so. 
<iwj> And what does it do ?  Wedge ?
<siretart> hm. I could try booting an older kernel to disable it
<siretart> * Generatig udev events for MD arrays
<Keybuk> why is mdadm called repeatedly in initramfs?
* Nafallo wgets binary
<iwj> Keybuk: Because only mdadm knows whether the device just arrived is the one we wanted.
<Keybuk> right, I mean why are there multiple initramfs scripts for it
<Keybuk> seems to be one in init-premount, one in local-top
<Nafallo> init-premount?
<Keybuk> *AND* it's run from udev rules
<Keybuk> ah
<Keybuk> no, I bet the output in init-premount is from udev calling mdadm
<iwj> I don't see an init-premount one.
<_ion> fabbione: iface lo inet6 manual worked, thanks!
<Keybuk> isn't all that initramfs stuff un-needed now?
<iwj> scripts/local-top/mdadm is (now) supposed to be idempotent.  I chose to keep it with the same name since it has basically the same contents.
<Keybuk> what does it do?
<iwj> So what happens is it runs once at boot and does nothing and then later udev runs it.
<iwj> It's the thing which actually assembles the raids.
<Keybuk> udev doesn't run that though
<siretart> gnarf. still happens with older kernel. searching for a dapper livecd
<Keybuk> eh?
<iwj> Keybuk: Yes, it does:
<Keybuk> udev assembles the raids, no?
<Nafallo> nafallo@ogre:~/tmp$ ls /usr/share/initramfs-tools/scripts/local-top/
<Nafallo> mdadm  mdrun
<Nafallo> do I need both? :-)
<iwj> Nafallo: No.
<iwj> But mdrun checks whether mdadm exists so you can keep it.
<Keybuk> iwj: isn't that why udev calls mdadm?
<iwj> Keybuk: No, it's _how_ udev calls mdadm.
<Nafallo> hehe
<iwj> 70-mdadm.rules:SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="linux_raid*", RUN+="watershed -i udev-mdadm /scripts/local-top/mdadm from-udev"
<Keybuk> that's not the line I have here
<Keybuk> that exists in the file, but it's commented out
<iwj> You're looking in /etc/ on your live system, aren't you ?
<Keybuk> err
<Keybuk> sorry
<Keybuk> wrong filesystem
<Keybuk> :p
<iwj> There's a comment explaining the strange seddery.
<Keybuk> any particular reason that it needs to run a magic script, and not just mdadm -As ?
<iwj> mdadm -As does a wrong thing.
<Keybuk> (since we only run the latter in the real filesystem to assemble raids)
<iwj> Well, several wrong things.
<iwj> In particular it tends to bring things up degraded and it activates everything, not just what you wanted for your root fs.
<fabbione> _ion: no problem at all
<Keybuk> iwj: why don't we use the same script in the real filesystem?
<iwj> Arguably it's slightly wrong in /etc/ on the real system too but the old paradigm has been broken.
<iwj> Because the scripts/local-top thing is welded to the initramfs.
<iwj> It doesn't work at all outside it.
<Keybuk> ah ok
<iwj> It was a struggle to get it to work even outside the initramfs init script, and just under udev.
* Keybuk finishes for the day
<Keybuk> brain getting achey
<Keybuk> will resume this monday morning with fresh coffee
<iwj> Keybuk: very wise.  I'll hang on here for a bit longer and see what Nafallo reports.
<Dabian> Ehehehehe?
<Nafallo> iwj: okey, /lib/udev/watershed replaced and 65-persistent-storage.rules poked. anything more? :-)
<Dabian> There is a command for fiercely fawn to skip the failing import.   I got the command yesterday, but apparently I forgot to write it down. :(
<Dabian> Wrong channel, sorry.
<siretart> ok, damn init script disabled, now see if I can boot to test iwj's binary
<iwj> Nafallo: Can you paste the md line(s) from your persistent-storage.rules just to check ?
<iwj> siretart: Wait.
<iwj> siretart: Firstly, what was wrong with that init script ?  I mean, what were the symptoms ?
<sladen> Mithrandir: if I changed the seed, do I nee to regerenate the -meta and upload that?  (1st time I've done a change to the seed)
<Nafallo> KERNEL=="md*", ACTION=="add|change", PROGRAM="watershed -li udev-mdadm true", GOTO="persistent_storage_path_uuid"
<iwj> And secondly my watershed binary is there to support the -l option in persistent-storage.rules.
<iwj> Nafallo: Looks good.
<iwj> Thanks.
<siretart> 19:55:06 < siretart> during boot, there is some initscript stating "Generating udev events for MD arays...." <- what's this? isn't that supposed 
<Nafallo> oki, reboot then :-)
<Nafallo> brb
<iwj> siretart: The important thing is not to have  watershed -i udev-mdadm true  (NB -i wrong, -li right but needs my new binary)
<siretart> iwj: first, I need to get my system booting at all again, so I can actually regenerate the initramfs
<iwj> siretart: Err, IC.  Sorry I missed that.  But it should be harmless.
<siretart> atm, it hangs without any particual message :/
<iwj> siretart: IC.
<iwj> Oh, lovely.
<iwj> And you blame this init script which you are now disabling.  I follow now.  That seems sensible.
<siretart> last message is a successful fsck of the rootfs
<iwj> Oh.
<Mithrandir> sladen: yes.
<iwj> Now I don't understand any more.
<siretart> neither me
<iwj> S20checkroot.sh comes before S25mdadm-raid
<siretart> booting dapper livecd again
<siretart> ha!
<iwj> So if mdadm-raid is the problem it should at least mention it's starting.
<siretart> now (after about 3mins), I get "Rendezvous with udev timed out for 'lvm2|hades_stripe|chroot_edgy
<iwj> Ahhhh.
<siretart> stat failed: No such file or directory
<iwj> Did you leave a udev running from the initramfs ?
<siretart> I didn't kill it
<iwj> That's the problem.
<iwj> You must kill it.
<iwj> Before letting it boot.
<siretart> aha? ok, I'll try
<iwj> That's why all my recipes say `pkill udevd'.
<iwj> This timeout is very annoying but the design is IMO fundamentally wrong and I have to persuade Keybuk that the device nodes should be made by lvm and raid things.
<siretart> I know that the system is later restarting udev, but why is it harmfull?
<iwj> siretart: No, the problem is that it _doesn't_ start udev in the real system because the initramfs one is still going.
<iwj> And then it's sort of like you don't have a udevd.
<siretart> ok. I pkill'ed udevd now, and it still hangs.
<iwj> Damn.
<iwj> Whose udevd package are you using ?
<siretart> I think I'll reenable the init script, just to chec
<iwj> I don't think that will help.
<siretart> http://people.ubuntu.com/~scott/packages/ <- that one
<iwj> siretart: Hmm.  I haven't looked at that.
<iwj> Nafallo is using the stock one and some edits I directed him to make.
<iwj> Would you care to try that too ?
<siretart> sure
<iwj> You'll lose some of the fixes of course.
<iwj> OK, just a mo.
<iwj> You still need the --suppress-syslog feature.
<siretart> as soon as I manage to get a root shell on my system :/
<iwj> If you kept the one I asked you to use earlier, reinstall that.
<iwj> Right.
<iwj> I have to say sorry, btw.  At least part of this problem was a very stupid mistake by me.
* sladen mmms.  Is germinate /supposed/ to crash during update
<siretart> no need to be sorry. I'm very happy that you're looking at this problem at all!
<siretart> the concept of this new asyncronous udev/mdadm setup is facinating, the fact that it breaks something which worked in debian, dapper and edgy is unfortunate :/
<iwj> Yes.  Quite so.
<iwj> But I have to say that it only worked for some people before.
<siretart> uh? in what cases did it break before?
<iwj> It was always broken in theory and the proportion of people where it was going to break was going up.
<iwj> siretart: If nnyour 
<iwj> Um, I mean:
<iwj> Depending on the stacking order of your various lvm md and crypto devices, and your types of underlying device, things would happen in the wrong order.
<iwj> I never managed to reproduce those races either but then hardly any of these races ever seem to happen to me despite my best efforts to contrive them.
<siretart> damn. booting an i386 livecd results in not beeing able to chroot into an amd64 system. obviously :/
<desrt> oops.
<iwj> Nafallo has been away a long time ...
<Dabian> Is it true I can earn money writing software for ubuntu?
<Burgwork> Dabian: yes, although this is not the best venue for that discussion
<sladen> Dabian: yes, lots of people do.
<Dabian> Well .. if it could put food on the table and pay my rent and gas and so .. I'd be happy ... earning a living by writing free software is a long time dream of mine.
<Dabian> Is it possible to make a living - or is it more like charity than actual payment?
<Dabian> Like .. "here's a dollar .. not a fee, but a token of appreciation of the work you did."
<somerville32> Some people get paid a salary to work on Ubuntu
<fabbione> Dabian: http://www.ubuntu.com/employment
<siretart> iwj: no chance. it seems that I really have to wait 14 (volumes) * 180 secs (timeout) to have my system probably booted :/
<siretart> oh, pressing sysrq-I seems to make me able to get a rootshell!
<siretart> interesting
<iwj> Can you see a udev running ?
<zyga> hello
<siretart> iwj: no, there is no udevd running
<siretart> hmmmm
<siretart> starting it by hand
<sladen> Dabian: generally you need to find an employer, or other line of work (consultancy) that brings in enough money and "sponsors" work on Free Software.  Be that Canonical, by being self-employed, or some other company/setup.
<sladen> Dabian: mostly this is done by selling "services" around a particular improvements and having paids often directly relate to new features
<iwj> siretart: That's weird since S10udev is supposed to start it.
<siretart> iwj: there's something really weird with keybuk's packages
<siretart> there are device nodes in  /dev/mapper, but not in /etc/$VG/$LV 
<siretart> hmmm
<siretart> iwj: where can I download your udev packages again?
<siretart> I seem to have now a system where I can rebuild my initramfs again
<cjwatson> Dabian: re your question a day or so ago, yes, there were some known hangs in migration-assistant - Evan's working on them in response to reported bugs. In the meantime 'ubiquity --no-migration-assistant' should work around them
<iwj> siretart: http://www.chiark.greenend.org.uk/~ian/d/udev-nosyslog/
<iwj> But I should stop for the weekend really and have some dinner and stuff.
<iwj> Sorry to leave you hanging ...
<siretart> iwj: have a good meal!
<Nafallo> iwj: there is no /tmp/u when finally booted :-P
<iwj> Thanks.  (Yay!  Now my production machine doesn't boot either.)
<Nafallo> haha
<iwj> Nafallo: Err, you have to copy it from the initramfs's /tmp to the real filesystem somewhere, before you exit the initramfs.
<Nafallo> dooh
<Nafallo> --suppress-syslog didn't seem to work either :-P
<Nafallo> log_priority=err maybe? :-)
<Nafallo> oki, I'll try that :-)
<siretart> why does mdadm postinst regenerate the initramfs for all installed kernels? hrmpf
<siretart> okay, now rebooting with feisty's udev, to see that I get some 'known' state back
<siretart> iwj: if you haven't left yet, I'm now ready to shred^W try out things
<iwj> siretart: (not here but:) The thing to try is: install the udev from my url above, then copy the watershed binary from http://www.chiark.greenend.org.uk/~ian/d/ into /lib/udev and edit the line in 65-persistent-storage.rules to say
<iwj> KERNEL=="md*", ACTION=="add|change", PROGRAM="watershed -li udev-mdadm true", GOTO="persistent_storage_path_uuid"
<iwj> Note additional `l'.
<iwj> watershed -li not watershed -i
<siretart> iwj: ok. this should fix things or help with diagnostics?
<iwj> Fix things hopefully.  ha ha ha
<iwj> Oh, also, get rid of the vgck from the 70-lvm.rules.
<iwj> Delete that whole line.
<siretart> commenting out is okay as well, I assume
<iwj> Yes.
<siretart> regenerating now
<siretart> rebooting now
<siretart> iwj: symptoms: md volumes are up and running, no lvm
<siretart> iwj: udevtrigger starts lvm
<iwj> Damn.  I suppose I need that damn log then but you'd best wait since it's lots of effort to gather.
<iwj> But I really must go now.
<iwj> ttfn and have a nice weekend.
<siretart> system boots fine without killing udevd
<siretart> iwj: cu!
<Nafallo> http://home.nafallo.info/bugs/udev.txt
<Nafallo> iwj: ^
<Nafallo> seems I didn't even have to pkill anything this time :-P
<Nafallo> mvo: "Runing partial upgrade"
<mvo> Nafallo: is that good or bad?
<Nafallo> mvo: that should be Running :-)
<mvo> Nafallo: *cough* thanks
<Nafallo> np :-)
<Lure> any core-dev to sponsor bug 94353 upload?
<ubotu> Malone bug 94353 in gtk-qt-engine "[feisty]  Some packages include files in usr/local or opt" [High,Confirmed]  https://launchpad.net/bugs/94353
<sladen> ^^one line fix  diff at http://librarian.launchpad.net/7078782/gtk-qt-engine.debdiff
<tepsipakki> do we have bug #100k by the morning? place your bets :)
<ubotu> Malone bug 100 in rosetta "uploading po file overwrites authors list" [Medium,Fix released]  https://launchpad.net/bugs/100
<tepsipakki> hah
* mvo will do a upgrade test/mass filing now to ear the price :p
<reitblatt> bug 20775 has been marked as fixed upstream since Jul '06
<ubotu> Malone bug 20775 in glibc "libc6's printf and fprintf don't return -1 on closed stdout/stderr." [Medium,Confirmed]  https://launchpad.net/bugs/20775
<reitblatt> any reason it isn't fixed in Feisty yet?
<pochu> tepsipakki: the morning where? :p
<tepsipakki> pochu: here of course :)
<tepsipakki> now it's midnight
<Nafallo> aha. the IRC-morning... :-P
<Nafallo> must be UTC ;-)
<tepsipakki> heh
<tepsipakki> lure, sladen: I wonder why our gtk-qt-engine uses cdbs
<tepsipakki> it isn't much of a "merge" if the build environment is differs totally from debian
<mvo> Riddell: still here? did you commited all your changes to software-propoerties? it looks like the final changelog update is missing in the bzr repository
<mvo> Riddell: or maybe forgot a final push?
<tepsipakki> sladen: you can push that fix yourself? it's trivial and I've hit it myself (some stupid machines I've seen have /usr/local as read-only NFS)
<Lure> tepsipakki: imbrandon said he will look into it shortly...
<tepsipakki> Lure: cool
<sladen> Lure: it looks sane to me, and I don't see it making it any worse.  Ideally it could do with building locally to check that it definately doesn't leave anything behind
<Lure> sladen: I have tested in in pbuilder and am running it here w/o problems
<Lure> sladen: and nothing is installed  in /usr/local anymore
#ubuntu-devel 2007-03-31
<danohuiginn> any of you folks have time to review a patch? bug 57067
<ubotu> Malone bug 57067 in python-mysqldb "UnicodeDecodeError: 'ascii' codec can't decode certain bytes " [Undecided,In progress]  https://launchpad.net/bugs/57067
<sladen> Lure: is imbrandon doing it?
<keescook> Lure: I tested and uploaded it too.  :)
<imbrandon> keescook, beat me
<imbrandon> ;)
<keescook> :)
<mdke> ogra: depends on your definition of "fix", but it adds an entry to the main yelp menu when edubuntu-docs is installed
<lamont> dear gaim, please stop &*(%)*$^(&)%*_ taking focus on startup.  kthxbye
<imbrandon> jdub, ping ( is the config/* for planet.u.c in a bzr branch ? )
<mdke> see wiki:PlanetUbuntu
<imbrandon> mdke, yea i konw that, as far as feeds , i mean more like the config/members/index.html.tmpl refrenced in the config.ini not in a normal checkout
<mdke> right, the bzr branch doesn't have that in it
<imbrandon> right, thats what i was wondering if that was avail in another branch
<mdke> you can ask Spads about getting hold of a copy
<imbrandon> k cool, i dont know Spads but i'll try to ping/email him
<imbrandon> thanks mdke 
<mdke> unlikely that jeff still knows, tbh
<imbrandon> true , i just wasent sure who would short of you/corey/newzum
<andrewski> is there a way to get back a crash report ubuntu was submitting to launchpad? i left the launchpad page open for about 10 hours before actually submitting it and it came back "page not found". i'm hoping the crash report is stored locally?
<jmg> hey all
<jmg> i need some specialist X help
<Burgwork> jmg: this isn't really a support channel
<jmg> #ubuntu-motu pointed me here
<Burgwork> right
<Burgwork> is this something to do with development of Ubuntu?
<jmg> and i know
<cjwatson> andrewski: should be in /var/crash/
<jmg> the fine line between development and configuration
<Burgwork> right
<Burgwork> it is pretty quiet, so shoot
<cjwatson> I think if you 'sudo touch' it then the crash reporter might try again? not sure though
<andrewski> cjwatson: and there it is. cheers! :D
<cjwatson> you're welcome
<andrewski> cjwatson: lol, the touch idea totally worked! awesome!
<stdin> shouldn't the "Help -> Report Bug..." feature go to launchpad.net, not bugs.kde.org?
<poningru> gaah no opers?
<poningru> we need someone in #ubuntu
<Fujitsu> poningru: -> #ubuntu-ops
<Fujitsu> Or call !ops in #ubuntu
<poningru> we did
<poningru> no one is here
<TheMuso> c
<TheMuso> ugh
<reitblatt> latest update killed the "Access IBM" key on my thinkpad =/
<sanzky> hi, does anyone knows if there are any XML database servers in the ubuntu repositories?
<Burgundavia> sanzky: huh?
<sanzky> a xml database, like exist for example
<sanzky> http://exist.sourceforge.net/
<Hobbsee> sanzky: see #ubuntu - this is not a support channel.  apt-cache search xml database might bring something up.
<sanzky> is it possible to suggest new packages for ubuntu ? if I am not a dev ?
<Hobbsee> sanzky: yes, info is linked off http://wiki.ubuntu.com/MOTU
<Burgundavia> sanzky: yes
<Hobbsee> iirc
<sanzky> thanks
<jcole> when i connect using ssh on feisty, it takes forever... is this known? or a problem?
<jcole> "ssh {server}"
<jcole> "ssh localhost" took almost 5 minutes
<jcole> once i'm connected, all is fine
<LaserJock> jcole: wow, ssh looks fine for me
<jcole> LaserJock: this is strange to me
<jcole> $ time ssh localhost
<jcole> real    2m11.307s
<jcole> i wonder if it's that gnome network manager trying to activate my wireless card
<jcole> "sudo ifconfig eth0 down" did the trick but the gnome network manager keeps bringing it back up!
<jcole> nm-applet
<jcole> apt-get remove --purge network-manager-gnom
<jcole> MUCH better
<jcole> ssh is slow on feisty -> http://ubuntuforums.org/showthread.php?t=377212
<poningru> waah?
<Amaranth> i've got a debdiff attached to bug 89786 that should fix it, looking for someone to sponsor the upload
<ubotu> Malone bug 89786 in desktop-effects "Desktop-effect does not enable cube" [Medium,In progress]  https://launchpad.net/bugs/89786
<jcole> poningru: fresh install of feisty (used to have edgy on here) and ssh is awful slow... it maybe the way feisty does networking or something
<fabbione> jcole: i have noticed something similar but only after logging in .. it did look like network-manager was switching between interfaces (i have 3 that all resolves and get the same IP from dhcp)
<poningru> hmm havent noticed anything
<poningru> here
<fabbione> jcole: so ssh into one iface, nm switch and bam
<jcole> fabbione: ya, once i'm logged in, all is well... it's just that 5 minute wait to connect
<fabbione> jcole: can you check if you have more than one instance of dhcp client running for the same interface
<fabbione> ?
<fabbione> (with nm installed)
<jcole> $ ps -ef | grep dhcp
<jcole> dhcp      5069  4918  0 18:16 ?        00:00:00 /sbin/dhclient -1 -lf /var/lib/dhcp3/dhclient.eth1.leases -pf /var/run/dhclient.eth1.pid -q -e dhc_dbus=31 -d eth1
<fabbione> jcole: with nm running?
* jcole runs nm
<fabbione> hmm ok
<jcole> fabbione: i just uninstalled network-manager-gnome to see if that would help... but it didn't... i've reinstalled and kicked off nm-applet
<fabbione> jcole: you need to remove network-manager to kill the backend
<fabbione> nm-gnome is only the applet afaik
<jcole> fabbione: ah
<^jcole> doing an "strace ssh server" i'm seeing lots of dns queries to the dns server
<fabbione> ^jcole: once you purge nm you really want to clean up and do a reboot of the machine
<fabbione> it doesn't leave the machine in a  nice status in my experience
<^jcole> fabbione: ok, rebooting
<fabbione> tho you can fix it manually by restarting the network properly
<^jcole> fabbione: it's faster now
<^jcole> fabbione: network-manager was the problem
<fabbione> ^jcole: file a bug please...
<jcole> fabbione: i'm filing a bug for network-manager right now... but i'm a bit befuddled of why removing it makes my system happy
<fabbione> jcole: i believe that nm is resetting the interface too many times.. but i can't be sure
<siretart> is the powerpc retracer down or something?
<hunger> Why was X's resolution changed?
<hunger> How do I turn it back? Or will this stay and should I adopt my fonts?
<reitblatt> hunger: this channel isn't for support
<reitblatt> try #ubuntu
<hunger> reitblatt: To noisy there and you never get a answer there. I'll just write a bugreport.
<mdke> doko: around?
<tuxcrafter> how do i use kdump effective with the ubuntu kernel
<tuxcrafter> no onethat can help?
<otavio> Hello folks. I'm having a problem with dhcp3-client on Debian and would like to check if there's any modification done on Ubuntu that could address it. 
<otavio> When using pppoe dhcp3-client is setting the default network route to the router while it shouldn't do it. dhcp-client works.
<otavio> But dhcp3-client is a dependency of systems using network-manager and then it would be a serious bug for feisty too.
<Nafallo> ouch :-/
<robertj> ajmitch: can I get a copy of the latest authtool just out of curiosity?
<GBM> Hi
<GBM> I need an IRC in Spanish
<Treenaks> try #ubuntu-es
<Nafallo> #ubuntu-es
<GBM> thanks a lot
<ded__> hi
<ded__> im new on linux
<ded__> how to execute shell command in c++ prog
<ded__> ???
<blackska1> ded_: you can invoke any program from within your program using the exec()-functions
<blackska1> more info : http://www.yolinux.com/TUTORIALS/ForkExecProcesses.html
<ded__> thanks im looking that
<ded__> thanks that was exactely what i wanted
<robertj> any thoughts on working up a spec to main libpam-smbpass a dep on ubuntu-desktop and enabled in common-password by default so that when users later install samba everything JustWorks?
<Treenaks> robertj: There are already a few specs like that afaik
<Treenaks> (mostly to do with simple business servers)
<robertj> Treenaks: sorry, I should have included the fact that I was planning on writing a Spec that actually had a chance of being implemented ;)
<Treenaks> robertj: well, you might want to improve one of the existing ones, instead of starting another one
<robertj> Treenaks: not doable
<Treenaks> robertj: just so you don't duplicate a lot of work
<robertj> Thats a go-nowhere WikiWar waiting to happen
<Treenaks> have you tried talking to the other spec-writers?
<superm1> well having two very similar specs are another war waiting to happen though
<Treenaks> if they want the same thing, it might be useful to work together
<superm1> your much better off talking with the other spec writers
<superm1> and trying to work together
<tepsipakki> does someone know if casper.log is saved during livecd-install?
<shawarma> Mithrandir: You mentioned you could install feisty in qemu.. Could you start the installer (I'm using the server CD, but any one should do), get past the point where it looks for cd-rom drives and somehow dump the dmesg somewhere, so I can see it?
<superm1> shawarma, do you need qemu in particular, I can check in virtualbox
<ProN00b> did nautilus get updated recently on edgy ?
<Mithrandir> shawarma: checking
<shawarma> superm1: It has to be qemu.
<shawarma> superm1: It's on an amd64 machine.
<shawarma> superm1: And vmware is not an option.
<superm1> shawarma, wasn't sure - since i had thought virtualbox was qemu based
<shawarma> superm1: Oh, no it's not. They share a tiny bit of code, IIRC, but that's it.
<superm1> ah ok
<shawarma> Mithrandir: I checked up on the cross-emulations thing, by the way.
<shawarma> Mithrandir: The thing is that you have to run the x86_64 emulator for kqemu to work, but inside it, you should run non 64-bit stuff.
<Mithrandir> shawarma: hm, ok
<shawarma> Mithrandir: I tried the amd64 version, which failed miserably.
<ProN00b> did nautilus get updated recently on edgy ?
<shawarma> Mithrandir: Rumour has it that Fedora seems to work, but the kqemu web page says it's experimental, so I didn't think much of it.
<Mithrandir> ProN00b: yes, a week ago.
<Mithrandir> shawarma: I'm getting horrible speed to cdimage.u.c, so I won't know for another twenty minutes if it works or not.
<ProN00b> hmm, damnit, i have to recompile it every time to retain my changes
<ProN00b> how do i get the current updated edgy source of it ?
<shawarma> Mithrandir: Quite alright. I'll grab some dinner. Thanks for doing this.
<shawarma> ProN00b: Add an appropriate deb-src line to sources.list, and do 'apt-get source nautilus'
<shawarma> ProN00b: "appropriate" == "one that matches the deb line which got you the update"
<ProN00b> hmm, does that include security ?
<shawarma> ProN00b: Yes.
<shawarma> ProN00b: We're obligated to provide the source for all our packages.
<shawarma> ProN00b: It's no different for security updates.
* shawarma wanders off for dinner
<ProN00b> hmm, ya i seem to have all deb lines mirrored with deb-src in sources.list
<ProN00b> any special way to build ?
<ProN00b> i just need to replace the "nautilus" binary
<juliux> hi all
<Mithrandir> shawarma: I can't get past the cdrom detection either; looks like some modules are missing in d-i.
<shawarma> Mithrandir: ide-generic used to suffice, I think.
<shawarma> Mithrandir: Any good ideas? Otherwise, I'll just file a bug against the kernel.
<Mithrandir> no great ideas, no.  Talk to Colin about it, he can probably tell at a glance.  Or BenC who knows the kernel well.
<superm1> BenC, any word on my lirc patch?
<shawarma> Mithrandir: Will do. Thanks a lot for trying!
<_ion> Is there a bzr branch for linux-restricted-modules development?
<shawarma> _ion: I'd expect to find it in git..
<shawarma> _ion: Try asking in #ubuntu-kernel
<_ion> Thanks
#ubuntu-devel 2007-04-01
<Chipzz> hrrrrm
<Chipzz> wiki.ubuntu.com problems?
<vorian> it would seem so Chipzz :)
<vorian> ah, working again :)
<tuna0> ok i think i found a bug
<tuna0> `dmesg` shows: BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004
<tuna0> i can reproduce the bug. where to file it ?
<tuna0> exec -n uname -r
<tuna0> 2.6.17-11-386
<tuna0> sorry!
<tuna0> :)
<bluefoxicy> Does anyone else not have sound in Feisty
<bluefoxicy> I am grepping launchpad for bugs on this.
<bluefoxicy> If I use gstreamer-properties to emit a test tone I have THAT, but everything else is silent.
<Hobbsee> bluefoxicy: sounds like a #ubuntu+1 question.  besides, ti's a sunday
<wesley> doing beta !
<Amaranth> bluefoxicy: pulseaudio
<Amaranth> bluefoxicy: asoundconf pulseaudio
<Amaranth> see if that helps
<bluefoxicy> Amaranth:  ALSA lib pcm.c:2106:(snd_pcm_open_conf) Cannot open shared library /usr/lib/alsa-lib/libasound_module_pcm_pulse.so
<Amaranth> oh, you maybe don't have all the pulseaudio packages installed
<zyga> hey everyone
<Hobbsee> hi
* Fujitsu waves.
<Mithrandir> morning all
* StevenK waves to Mithrandir.
<Hobbsee> heya Mithrandir!
<Burgundavia> hey Mithrandir
<Mithrandir> hiya StevenK, Hobbsee, Burgundavia 
<Fujitsu> Mithrandir: Can you please try a give-back of xmms2?
<Mithrandir> Fujitsu: given-back
<Fujitsu> Mithrandir: Thanks.
<Keybuk> so I have clearly *no* idea how grub or Linux determine the drive order
<Keybuk> grub seems to see 1=hd0, 2=hd1, 3=hd2, but Linux seems to think sda=2, sdb=0, sdc=1
<Keybuk> (at least I assume that's how grub sees them, it could be just that I haven't dared run install-grub :p)
<Mithrandir> Keybuk: grub sees the BIOS order; some BIOS-es reorder the drives on bootup so the boot drive is 0x80, some don't.
<Mithrandir> Linux just does them in the order the controller returns them in. :-P
<Keybuk> heh
<Keybuk> maybe the new drive is faster than the old one
<Keybuk> (s)
<Keybuk> what's now sda is the new 250GB I bought to put vmware and cd images on
<Keybuk> or maybe it's because the new drive is SATA-II ?
<tepsipakki> it's slightly annoying that nm starts the network only after I've logged in
<_ion> Wireless?
<tepsipakki> nope
<_ion> Oh. For me, it has always started wired network automatically right after the daemon has been started.
<pochu> I have my wireless broken since yesterday updates, any idea?
<pochu> tepsipakki: same here
<Fujitsu> Anybody know why lists.ubuntu.com mailing lists are being delayed by at least 1.5 hours?
<pochu> yesterday fabionne updated n-m, maybe that's the reason
<tepsipakki> I don't have the all the updates
<_ion> fujitsu: ubuntu-devel{,-discuss} are moderated.
<tepsipakki> that's the point, I can't load them since I can't login :)
<tepsipakki> feisty-changes is lagging behind a couple of _days_
<Fujitsu> _ion: Yes, but ubuntu-bugs and feisty-changes are not. They normally have a latency of a few seconds.
<_ion> fujitsu: Ok
<Fujitsu> tepsipakki: I have stuff from 2 hours ago, but I uploaded something an hour ago and it's not there.
<tepsipakki> Fujitsu: oh yes, I meant the archive
<Fujitsu> Ah, that's fairly normal.
<tepsipakki> it started a week ago
<Fujitsu> It's always been a day, as far as I know.
<tepsipakki> nope
<tepsipakki> because of the new delay I decided to join the list ;)
<Fujitsu> Heh.
<tepsipakki> makes sense anyway
<Fujitsu> feisty-changes is useful, and good to keep up to date with.
<Seveas> _ion, devel-discuss isn't moderated, that't the whole point of devel-discuss :)
<Treenaks> Seveas: that's what they WANT you to think :)
<Seveas> :p
<_ion> seveas: All right. :-)
<pitti> hi
<pitti> ugh, we are this -><- close to bug #10000
<ubotu> Malone bug 10000 in xorg "xserver-common: X crashed (signal 7) while scrolling in Mozilla" [Medium,Rejected]  https://launchpad.net/bugs/10000
<pitti> erm, 100000 ;)
<StevenK> Hah
<Hobbsee> hehe
<Hobbsee> yay, 100000 bugs!
<cjwatson_> Fujitsu,tepsipakki: the machine that's doing the archiving can't keep up (and it's a good machine - it's more the software in this case) - the sysadmins are aware of it
<Marcus_> hmm. i had several strange issues with the ubiquity user profile migration wizard on feisty.
<Marcus_> on my system i got an previous installation of slackware (which will be overwritten by ubuntu) and the migration assistant simply hangs on looking for profiles on that installation
<Marcus_> the slackware partition was reiserfs formatted
<Marcus_> i had to delete the slack partitions before ubuntu installation in order to let the migration assistant work correctly
<vprints> Hey!
<vprints> =)
<vprints> Anybody here familiar with PCSC ?
<urbs> will feisty perform better or slower on old machines compared to edgy ?
<Treenaks> that depends on what you're installing
<Treenaks> also, it's probably better to ask things like this on #ubuntu; this is a developer channel
<urbs> the plain gnome install
<urbs> no response there, but no problem, was just curious
<Treenaks> urbs: the best way to find out is to try, I guess
<linuxero> hello?
<robertj> if a loco needs 200ish disks how long would it take for them to arrive after feisty gets released?
<robertj> assuming they poked the appropriate persons
<cjwatson_> robertj: I think you'd need to ask said appropriate persons, TBH :-)
<cjwatson_> they'll have the best handle on details of likely delivery timings
<robertj> thx, just trying to get a quick guestimate, but if it be email thats needed, email it tis
<robertj> speaking of poking...
* robertj pokes ajmitch
<Enola_Gay> hi all
<Enola_Gay> If a bug status is set to "Fix released" are comments still sent to the devs and the other viewers?
<Laser_away> I think so but I'm not positive
<Enola_Gay> thx
<jdong> yeah
<jdong> they are :)
<Enola_Gay> good so there is no need for a new bug report
<Enola_Gay> thanks
<popey> is there a quick and easy guides to the process of requesting packages go from universe to main?
<Burgundavia> yes
<mc44> popey: https://wiki.ubuntu.com/MainInclusionProcess
<popey> thanks mc44 
<Enola_Gay> Is there any declaration why totem uses gstreamer instead of xine?
<Enola_Gay> It isn't able to play dvds or at least not many. Even if they are unencrypted I guess because libdvdcss doesn't help in most cases.
<Enola_Gay> Another question. Afaik libdvdcss2 is not in rep even multiverse because of law restriction but isn't the same file integrated in vlc which is in universe?
<Enola_Gay> *lib
<mr_pouit> Enola_Gay: it is deleted from vlc tarball
<Enola_Gay> mr_pouit: So vlc doesn't play encrypted dvds without libdvdcss2?
<Enola_Gay> +in Ubuntu
<mr_pouit> I think so
<Enola_Gay> I am going to check it.
<Enola_Gay> mr_pouit: No, it works fine.
<Enola_Gay> ups, only the menu
<Enola_Gay> mr_pouit: So you are right.
<Enola_Gay> thx
<mr_pouit> Enola_Gay: np ;)
<mr_pouit> Enola_Gay: but I checked, and I think it isn't removed, only disabled : vlc_confflags += --enable-dvd --without-dvdcss
<Enola_Gay> Imho Kaffeine has some big advantages too Totem since it uses xine by default.
<Nafallo> Enola_Gay: totem-xine
<Enola_Gay> Natallo but this could break something while upgrading to a new distribution version?
<Nafallo> Enola_Gay: haven't done for me. btw, first letter + tab might help if you want me to get a hilight.
<Enola_Gay> Nafallo: sorry, I know
<Nafallo> :-)
#ubuntu-devel 2008-03-24
<hmuller> Can anyone explain how or where displayconfig-gtk gets its initial settings?
<slangasek> I believe it gets it from the current xserver state
<johanbr> hmuller: If you're who I think you are, thank you for the Inspiron 1420 sound instructions. :)
<hmuller> johanbr: np, it's nice to have that and the mics working.  props to crimsun (d. chen) for getting that fixed for us.
<pwnguin> aha. i found the reason graphical boot stops early for me
<pwnguin> bug #203429
<ubotu> Launchpad bug 203429 in initramfs-tools "resume script missing functions" [Undecided,Confirmed] https://launchpad.net/bugs/203429
<Fujitsu> Hmm, should gnome-display-properties let me turn my last screen off?
<pwnguin> think of the power savings!
<j1mc> hi all - are the build logs for daily ISO builds available to look at?  i wanted to see why xubuntu iso's aren't being generated.
<slangasek> they aren't being generated because there are alternate CD test candidates waiting for sign-off from the xubuntu developers as a beta for
<slangasek> s/ for//
<j1mc> slangasek: are the test images the 3/21 images?
<slangasek> 3/22
<j1mc> http://cdimage.ubuntu.com/xubuntu/daily/20080322/  hmm
<slangasek> oh, well, I guess they failed
<slangasek> and I should look into that, thanks :)
<j1mc> thank you.  :)
<j1mc> i'll keep an eye on the daily folder, and will test when a new image is generated
<slangasek> ah, it's that darned not-sure-if-we're-up-to-date-in-universe bug again
<j1mc> slangasek: is it anything i should ping cody somerville about, or do you know what needs to be done?
<slangasek> if it's the bug I think it is, it's a build environment bug, not a xubuntu bug
<slangasek> so, let's see what happens this round
<slangasek> sorry, I should've checked for success when I posted them
<j1mc> np.  i will check on them tomorrow morning.
<j1mc> thanks for your help
<slangasek> looks like we're good this time, just by virtue of what time of day it's running
<j1mc> hm, ok.
<j1mc> thanks again.  i'll try to gather up a few testers, and we'll report our results on the QA site.  it might not be until later tomorrow until we report results there, though.
<slangasek> images are up now :)
<slangasek> adding to the ISO tracker
<j1mc> thanks.  :)
<xhaker> slangasek: hi, is there an easy answer for, why wouldn't ubuntu-restricted-extras recommend ttf-liberation instead of msttcorefonts now?
<slangasek> xhaker: not one that I know
<Fujitsu> xhaker: If you're already wanting a heap of non-free stuff, why not go with the least free option?
<slangasek> well, "why not go with the 100% guaranteed compatible option"
<Fujitsu> Why is ttf-liberation in multiverse when its description starts with `Free'?
<xhaker> Fujitsu: hahaha, that was funny :D
<Fujitsu> slangasek: That's sort of what I meant. Why go for the more free option that might not be compatible, if you want non-free stuff in the first place?
 * slangasek nods
<xhaker> well, the normal use case is for people to install ubuntu-rextricted-extras when they need support for proprietary stuff, when they don't have a choice
<xhaker> often flash player and codecs
<Fujitsu> The aim of u-r-e is to install a full suite of non-free goodness.
<xhaker> Fujitsu: let me explain, you're too fast to respond
<xhaker> Fujitsu: one of those items is the java plugin, and the dependency was changed to icedtea-gcjplugin, since java is now very much free with openjdk
<Fujitsu> Ah.
<xhaker> so you already have something free in ubuntu-restricted-extras
<xhaker> but i think it should be there for the upgraders?
<xhaker> someone should s/restricted-extras/extras/
<slangasek> as long as icedtea-gcjwebplugin is still in universe, that's probably a reasonable place to have the dependency.  Once it can be moved to main (I think the plan is to do this for intrepid), then ubuntu-desktop can probably do the job of pulling it in
<j1mc> actually, u-r-e doesn't currently pull in the java or icedtea plugin
<slangasek> j1mc: recommends: icedtea-gcjwebplugin
<Fujitsu> slangasek: Java in the default install? Not bad.
 * xhaker happy!
<Fujitsu> Speaking of Java, somebody needs to upload a new Sun Java to multiverse to fix a heap of security issues.
<slangasek> Fujitsu: I'm not speaking with any authority here, just saying that it seems to me that part of the reason to put it in main would be to install it by default :)
<Fujitsu> slangasek: Indeed.
<johanbr> Why does u-r-e recommend all those packages, rather than depend on them?
<ScottK2> johanbr: So you can removed them if you don't want them without removing the metapackage.
<xhaker> johanbr: recommends get installed by default anyway, but you might not need all of it :)
<ScottK2> metapackage recommends are installed by default.
<Fujitsu> Doesn't aptitude install all recommends by default?
<j1mc> apt-cache show ubuntu-restricted-extras | grep Recommends
<j1mc> Recommends: flashplugin-nonfree, gstreamer0.10-ffmpeg, gstreamer0.10-pitfdll, gstreamer0.10-plugins-bad, gstreamer0.10-plugins-bad-multiverse, gstreamer0.10-plugins-ugly, gstreamer0.10-plugins-ugly-multiverse, libdvdread3, liblame0, msttcorefonts, unrar
<ScottK2> Fujitsu: apt does not for other than metapackages IIRC.
<ion_> apt-cache depends ubuntu-restricted-extras doesn't show anything java-related here either. Fresh apt-get update from archive.ubuntu.com.
<slangasek> hmm? how does apt know which ones are metapackages?
<ion_> From the Section field.
<johanbr> Yes. But most metapackages don't use Recommends. If you turn off installing Recommends, installing u-r-e won't do anything.
<xhaker> looking at that list, isn't our vision to replace everything there with free counterparts?
<slangasek> oh, and apt in Ubuntu keys on that field? interesting
<johanbr> slangasek: See /etc/apt/apt.conf.d/01ubuntu
<Fujitsu> Hmm, has the default CFLAGS changed since February?
<Fujitsu> mplayer now FTBFS, and unsetting CFLAGS fixes it.
<RAOF> We now add -Bsymbolic, don't we?
<Fujitsu> THat's LDFLAGS.
 * RAOF checks his build mail.
<RAOF> Whoops, so it is.  I suck.
<Fujitsu> Do I get murdered for unsetting CFLAGS in debian/rules?
<RAOF> Fujitsu: No, I don't believe so.  I've noticed a couple of packages that unset one or more of CFLAGS, CXXFLAGS, or LD
<RAOF> LDFLAGS to fix FTBFS.
<Fujitsu> I've already unset LDFLAGS in two at the advice of upstream.
<Fujitsu> The LDFLAGS changes caused tooooo many issues.
<pwnguin> there was a wiki about the flags
 * jdong gets frustrated at crappy cflags on Handbrake
<superm1> jdong, you trying to get handbrake packaged for interpid?
<superm1> intrepid even
<jdong> superm1: I will
<superm1> jdong, haha
<jdong> superm1: I even considerd it partially for Hardy
<superm1> jdong, have you looked at it's build process?
<superm1> jdong, and all the patching it does to source packages during the builds?
<jdong> superm1: but it was 2 wks before FFe and I saw 4 or 5 motumedia packages that'd need upstream versions
<jdong> superm1: actually, overall handbrake's build process didn't look terribly bad
<jdong> superm1: sure it fetches specific versions of media libs
<superm1> jdong, yeah there's probably a good reason for that..
<jdong> superm1: but it's not like *cough* gstreamer,vlc,mplayer,*cough* don't do the same
<superm1> i won't argue though.
<superm1> if you get it in, i'll be happy
<jdong> superm1: yeah I'll try to get it in, linked against system libs, doing an update wherever necessary in Intrepid
<jdong> superm1: if that fails I plan on forking it again :)
<jdong> superm1: its x264 encoding abilities are too good to ignore
<superm1> i started to look at it shortly after school got done and started to cry when i saw all the stuff it did
<jdong> superm1: oh the build system is out.
<superm1> jdong, yeah it's the only way to get stuff "nicely" onto my touch
<jdong> superm1: that's without a doubt
<pwnguin> hmm
<pwnguin> apparently livejournal doens't like images for free
<pwnguin> that's gonna make this bootchart blog a challenge ;)
<pwnguin> jdong: you happen to have a bootchart image you'd like to brag about?
<jdong> pwnguin: http://jdong.mit.edu/~jdong/macbook/hardy-upstart-defragged.png
<pwnguin> <p class="flickr-yourcomment">
<jdong> pwnguin: keep in mind my slow laptop hd speed
<pwnguin> oops
<jdong> but I don't think 19s is bad :)
<pwnguin> heh
<pwnguin> well, you've only got to beat my 23
<jdong> pwnguin: well I win then :)
<jdong> pwnguin: go upstart :D
<pwnguin> thats the point here
<pwnguin> ive documented several easy fixes that will mostly succomb to entropy
<jdong> https://code.edge.launchpad.net/~uphackers/uphack/uphack-tools I'm starting to work on an auto-upstart converter :)
<pwnguin> ah
<pwnguin> even more informative ;)
<jdong> I've confirmed it to half boot but I need to add the TTY jobs
<jdong> meh but first I need to finish my homework :)
<pwnguin> ah, the last day of spring break here
<emgent> night gang, i go to sleep
<poningru> halp
<poningru> I think either NetworkManager or NetworkManagerDispatcher cant get my localtime and hence is hanging on connection to an authenticated wifi
<poningru> actually come to think of it to anywifi
<poningru> and then any connection there after
<poningru> http://paste.ubuntu-nl.org/60824/
<poningru> strace of networkmanager
<poningru> I attached it when it was starting to connect
<poningru> to my wpa2 psk ap
<poningru> then the repetition stuff comes in when I pluged in my cat5 and clicked on wired from nm
<poningru> the repeater stuff towards the end
<poningru> the output from networkmanager dispatcher was similar
<poningru> except the end stuff
<poningru> I'm running a bcm94311MCG rev 02 card
<poningru> oh and nm-applet is like http://paste.ubuntu-nl.org/60827/
<poningru> ALWAYS
<poningru> so I dont know wtf is going on
<poningru> ... I guess that was a bug report...
<ScottK> poningru: Make sure you've got the latest hal installed.
<poningru> checking
<poningru> through the repos or trunk?
<poningru> HAL package version: 0.5.11rc2
<poningru> I think thats the latest
<poningru> ScottK^^^
<poningru> dpkgreconfiguring hal
<superm1> can anyone think of an init script that properly uses udevsettle at the moment?
<poningru> ok trying to reconnect to wifi... or should I restart? I think hald got restarted by the dpkg-reconfigure
<superm1> or udevadm better yet
<poningru> superm1: iscsi iirc
<poningru> hold on
<poningru> yes
<superm1> would you mind posting it so i dont have to hunt down the source package?
<poningru> /etc/init.d/open-iscsi does
<poningru> err ok sure
<superm1> thanks a bunch :)
<poningru> oh pastebin it?
<poningru> or to a bug?
<superm1> pastebin
<poningru> kk
<superm1> i'm just trying to fix another package that i think i mis-used it before
<superm1> and didn't realize
<poningru> http://paste.ubuntu-nl.org/60828/
<superm1> awesome thanks alot
<poningru> well obviously udev aswell but... you know
<superm1> yeah.
<slangasek> poningru: contents of /var/log/syslog are probably going to be more useful than an strace of n-m
<poningru> ooh thanks
<slangasek> could you also try /etc/dbus-1/event.d/25NetworkManager restart?
<slangasek> (I'm not sure that upgrading hal will fix a network-manager that's gotten itself into a wedged state)
<poningru> trying
<poningru> hmm hold on
<poningru> :( no diff
<poningru> I tried dpkg-reconfiguring NetworkManager which restarted it and NetworkManagerDispatcher
<poningru> slangasek^^
<poningru> oh on an IRC proxy thats why it looked like I didnt disconnect
<poningru> http://paste.ubuntu-nl.org/60829/
<poningru> btw
<poningru> from syslog
<poningru> the weird thing is after I do a NetworkManager restart I can connect to wired through nm
<poningru> but not ANY wifi
<poningru> even open ones
<Fujitsu> poningru: Have you restarted hal, then NM?
<poningru> no let me try
<poningru> /etc/init.d/hald right?
<slangasek> signal 11
<Fujitsu> No d.
<slangasek> poningru: you said you have hal 0ubuntu2 installed?
<slangasek> oh, you only said 0.5.11~rc2
<slangasek> poningru: we need to know the exact Debian version of hal that's installed
<poningru> Version: 0.5.11~rc2-1ubuntu2
<slangasek> 1ubuntu1 is broken. 1ubuntu2 is supposed to be fixed... ok.
<slangasek> hang on a second then, let me dig up a bug
<slangasek> bug #204868
<poningru> :) thanks
<ubotu> Launchpad bug 204868 in network-manager "NM can't use wireless networks" [Low,Triaged] https://launchpad.net/bugs/204868
<slangasek> there's a patch in there; can you rebuild NM using that patch and see if that fixes things for you?
<slangasek> (if so, I'll raise that bug back to high and re-milestone it)
<slangasek> (... and fix it, since Germany's on holiday today)
<poningru> ah!! sweet
<poningru> yeah doing that now
<slangasek> you said your wireless was broadcom?
<poningru> yeah
<poningru> bcm94311MCG rev02
<slangasek> ok
<slangasek> which wireless driver do you use, ndiswrapper or bcm43xx?
<poningru> err actually b43
<slangasek> or that one :-)
<slangasek> ok
<poningru> yeah getting the build deps
<poningru> thanks for helping with this
<poningru> could have sworn I searched launchpad
<slangasek> well, I seem to have lowered the severity of that bug report in error; sorry, there've been enough false-positive duplicates that it's been hard to sort out what's what
<Fujitsu> Anybody know off hand of any recent bugs about the kernel hanging in initramfs?
<poningru> w00t slangasek danke
<poningru> that worked
<slangasek> poningru: thanks, working on getting the fix uploaded
 * jdong sets up crackbook64
<jdong> and it's exactly what you think it is.
<jdong> x86-64 macbook Hardy, pieces of the system loopmounted over HFS+, upstart booted, and otherwise broken beyond all repair :)
<jdong> oh yeah, XFS.
<jdong> expect lots of whining and bugs soon ;-)
<Fujitsu> !jdong
<ubotu> <Hobbsee> jdong: yes, but you're FULL OF CRACK!
<jdong> :)
<jdong> 55% in 2 minutes
<jdong> this is gonna be a fun Hardy box
<poningru> lol
<poningru> I thought it was this http://www.theinternetnowinhandybookform.com/crackbook/
<milli> Fujitsu: I had a corrupted ramdisk error yesterday, with 2.6.24-12-server on my AMD64 box.  Doing a dpkg-reconfigure fixed it, but it was somewhat painful figuring out that needed to happen, given console access was needed to see what it was hanging on boot.
<milli> I'm guessing perhaps ran out of disk space the last time update-initramfs ran...  *shrug*
<Fujitsu> milli: My initramfs looks fine.
<milli> I get this though, which worries me a little...  since I'm using root-RAID...
<milli> Done.
<milli> Begin: Running /scripts/init-bottom ...
<milli> [   48.564492] mdadm[2756]: segfault at 4 rip 41751c rsp 7ffffcbf0ca0 error 4
<milli> Done.
<milli>  * Setting the system clock
<milli> but system comes up okay...
<Fujitsu> That doesn't look optimal.
<Fujitsu> I'm root-on-LVM-on-crypto.
<milli> I'm guessing auto-starting all 3 RAID arrays is what saves it.
<TheMuso_> 5~/c
<TheMuso_> ugh
<warp10> Good morning
<tbf> hmm... ENOKEYBUK
<Company> that almost looked like a real error value
<Company> but it's more than 8 letters
<Company> EKEYBUK would fit
<tbf> Company: well, just need someone to fix my libtool issues....
<tbf> Company: and keybuk was such a strong defender of this brokeness called libtool, that he offered me to debug such isses
<tbf> issues
<tbf> stupid libtool finds /opt/gnome/lib/libglib-2.0.la, but still insists in linking in /usr/lib/libglib-2.0.so
<tbf> i hate libtool
<tbf> seems its main problem is to assume the full file name, not just the base name of an .so is significant
 * Hobbsee waves
<Hobbsee> yay, u-r-e discussions
<_MMA_> Can someone take a quick look at Bug #205628? Seems users aren't in the scanner group now. Link to the forum thread might better explain the issue.
<ubotu> Launchpad bug 205628 in xsane "[Hardy] xsane reports all devices as busy." [Undecided,New] https://launchpad.net/bugs/205628
<james_w> bug #205496 seems perhaps related
<ubotu> Launchpad bug 205496 in xsane "[Hardy]Xsane needs root to operate scanner" [Undecided,New] https://launchpad.net/bugs/205496
<_MMA_> Ahh... Yeah.
<james_w> _MMA_: is the scanner option checked in Users and Groups for your user?
<james_w> if so does "scanner" show up in the output of "id"?
<_MMA_> Nope. Im reading through the other bug also.
<_MMA_> Ill mark mine as a dupe.
<james_w> ok
<james_w> do you happen to know if that option used to be activated for your user?
<_MMA_> I do knot know for sure. All I do know is that it worked.I can look at the alpha6 live disk to see if it was then look at the beta disk.
<evand> So this is probably related to a change I made to user-setup a while back (1.16ubuntu2).  According to pitti, we no longer use the scanner group.  pitti is this still the case?
<cdr> matthew barrett, are you here? :)
<james_w> _MMA_: what's the user:group permissions on your scanner device in /dev?
<james_w> the "scanner" group is used in several udev rules on my box at least.
<james_w> (non-custom rules)
<mjg59> cdr: Do you mean Garrett?
<_MMA_> james_w: Sorry. I jumped into the alpha6 live disk to look over things.
<james_w> _MMA_: no problem, do you have your scanner plugged in?
<cdr> mjg59: unless you spent the past week in the french alps, i don't think so =)
<_MMA_> james_w: yep
<mjg59> cdr: I did
<james_w> _MMA_: i don't know what the scanner node will be called, ls -l /dev/scanner might help
<_MMA_> james_w: Hmm... Tells me cannot access /dev/scanner. No such file or dir.
<james_w> _MMA_: sorry, the node is named something different then. Is there anything in /dev that looks like your scanner?
<james_w> _MMA_: or "find /dev -group scanner"
<_MMA_> Ok. That got it. "parport0" Its a USB scanner.
<james_w> so it appears as though the scanner group is still used, and so the user-setup change should be backed out.
<_MMA_> james_w: "ls -l /dev/parport0" gives me: "crw-rw---- 1 lp scanner 99" This is using the Alpha6 disk. Want me to look at the Beta disk ow an installed system?
<_MMA_> s/ow/or
<james_w> _MMA_: that should be ok I think. Confirming on the latest version would be nice, but at least we know what the problem is
<_MMA_> james_w: Ok. Of there's nothing needed from the alpha Ill go to my installed system.
<james_w> I don't see anything in udev's changelog to suggest that it has stopped using the scanner group.
<_MMA_> james_w: Not that it means anything to me but "ls -l /dev/parport0" gives me "crw-rw---- 1 lp scanner 99, 0" on an installed system. The "0" is extra vs. the live alpha.
<james_w> _MMA_: I'm not sure what that means.
<james_w> _MMA_: the scanner group is still used though, so it's the same problem.
<_MMA_> Sre.
<james_w> Did you see that someone just posted to the bug report saying that there is a fix in Debian we should take?
<_MMA_> gah. Sure.
<james_w> unfortunately they didn't say which package.
<_MMA_> I just got the email but didnt look yet.
<_MMA_> james_w: I can only guess the poster means xsane.
<james_w> _MMA_: libsane it appears.
<andersja> hi all; could someone with triaging-rights on launchpad please take a quick look at https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/198453
<ubotu> Launchpad bug 198453 in pulseaudio "PulseAudio prevents programs relying on ALSA to work correctly" [Undecided,Confirmed]
<andersja> it's a PulseAudio bug currently blocking a number of apps (incl 3rd party apps like skype) from working
<andersja> it's a quite high impact usability issue for mom&pop users: the installation of app goes fine, no warning, but when run the machine hangs completely - kernel-panic style
<james_w> andersja: if all you are looking for is someone to set the importance then #ubuntu-bugs has people who can do that.
<andersja> hard to debug for non-power-users and requires a hard reboot in some cases :-o
<james_w> _MMA_: debian/rules: Do not install the udev rules, since hal now provides dynamic ACLs on device nodes. (See hardy-hardware-detection spec.)
<andersja> james: if anyone could have a look at it with a view to fix it'd not be bad either: Hardy is supposed to be an LTS release && this is not very user-friendly
<james_w> _MMA_: from the sane-backends changelog.
<james_w> andersja: I agree, I was just wanting to point you to the best place for your query. If you want to work with someone on fixing it then here is definitely the better place.
<james_w> _MMA_: I've got to eat now, I'll keep digging after lunch.
<andersja> thanks James, I've now also dropped a line on ubuntu-bugs
<_MMA_> james_w: Ok. Odd thing is, add ing myself to the scanner group didnt work here. :(
<james_w> _MMA_: ah, that sucks.
<_MMA_> james_w: Works strait out with sudo. Get some lunch. Ill be around.
<Hobbsee> dear networkmanager, please *don't* be a bitch.  Thankyou.
<laga> Hobbsee: many people before you have asked that..
<Hobbsee> laga: networkmanager and i have had a good working relationship for multiple releases now.  i'd hate to lose that.
<laga> heh :)
<butt3rz> goodmorning all
<butt3rz> i'm a freebsd developer and am interested in this project now as i use it on the majority of my workstations -- i've read the developer documentation on the site -- where would you recommend i start contributions?
<beuno> butt3rz, there is a good mapge about this in: https://wiki.ubuntu.com/ContributeToUbuntu
<beuno> and some specific information on helping with packaging in: https://wiki.ubuntu.com/MOTU/Contributing
<butt3rz> alright, appreciated
<beuno> welcome  :)
<ScottK> It looks like my kdebase upload yesterday made artigas fall over and die.  I'd appreciate it if a buildd admin would have a look at it.
<butt3rz> also, i've been wondering about a few things and wanted to throw it by some other people -- the kernels presented by ubuntu -- those i assume (never used them) are vanilla images -- or they have a few ubuntu patches applied by the overseeing developer -- why not add prepatches and mm patches?  and say for people on the PPC platform -benh patches? -- though benh packages his stuff for everyone really since he uses debian
<beuno> butt3rz, that kind of question seems like a better fit in #ubuntu-kernel or in the ubuntu-devel mailing list
<mjg59> butt3rz: No, they're nowhere near vanilla
<butt3rz> mjg59 , well i have no idea -- like i said ive never used them -- but i appreciate the update :)
<mjg59> butt3rz: However, we don't ship anything that's not expected to be stable. -pre and -mm don't fall into that category.
<butt3rz> mjg59 , so you don't think this would make sense even as an option?
<butt3rz> i suppose if people know about them they can spend the time to patch themselves
<mjg59> butt3rz: No, because they'd be out of date before we released
<butt3rz> what do you mean? -- a full ubuntu release or release them to apt
<butt3rz> mjg59 , should i move this to ubuntu-kernel?
<mjg59> butt3rz: Feel free
<butt3rz> mjg59 , i appreciate your help :)
<butt3rz> have a good one
<james_w> _MMA_: I'm getting a little lost down in hal land, so perhaps this needs the touch of someone more experienced in that area.
<james_w> however the referenced spec states "Device ownership: Make removable USB devices (scanners, cameras, external hard disks, etc.) accessible to the user on the current foreground console instead of providing static udev rules and using group membership based access control."
<james_w> which I think should be happening here.
<_MMA_> james_w: OK. Best I can do is help troubleshoot. You have more knowledge here than I. Hopefully it can be fixed. Its like printing being broken.
<james_w> _MMA_: hal seems to have consolekit support enabled, which it appears is intended to allow you to access the scanner. I don't know how to debug consolekit to find out why it isn't setting the device to be owned by you though.
<_MMA_> james_w: I see.
<TomaszD> hello, I'd be glad if someone could point me to the package responsible for the ubuntu-modified logout/shutdown screen. I need to make some fixes in the translation.
<_MMA_> TomaszD: The GDM theme?
<TomaszD> _MMA_, well I mean the logout screen, where I can shut the computer down, suspend, hibernate, switch user or restart
<TomaszD> the big screen with buttons that don't look like buttons at all
<_MMA_> Ahh... Sorry. Im unsure if that.
<james_w> it might be gnome-panel
<TomaszD> might be, looking at it right now
<james_w> or gnome-session perhaps
<TomaszD> I'd place a bigger bet on.. yes
<TomaszD> found it
<TomaszD> it's indeed gnome-session
<emgent> hello
 * _MMA_ waves.
<sistpoty> doko: please give back haskell-http on sparc, thanks!
<mario_limonciell> keescook, ping
<keescook> mario_limonciell: hola
<emgent> hi keescook :)
<mario_limonciell> hi keescook.  I went through and triaged a majority of the bugs on lirc last night
<keescook> heya emgent
<mario_limonciell> i rolled up all the fixes into a bzr branch
<keescook> mario_limonciell: i saw all the bug mail come through.  nice :)
<emgent> E: /var/cache/apt/archives/language-pack-en_1%3a8.04+20080317_all.deb: tentata sovrascrittura di `/usr/share/locale-langpack/en_GB/LC_MESSAGES/shared-mime-info.mo', che si trova anche nel pacchetto language-pack-gnome-en
<emgent> argh
<keescook> mario_limonciell: cool, you need me to sponsor it in?
<mario_limonciell> keescook, there will probably be one or two more bugs that are going to be needing fixes, but I'm not confident that they will get done in time for hardy, so yeah could you sponsor the branch in its current state and if they get done, i'll let you know
<keescook> mario_limonciell: bazaar.launchpad.net/~mythbuntu/lirc/ubuntu/ ?
<mario_limonciell> keescook, er no.  looks like i pushed it somewhere new
<mario_limonciell> let me get you a url
<mario_limonciell> i'll have to get it into a "standard" location sometime soon :)
<mario_limonciell> https://code.edge.launchpad.net/~superm1/lirc/hardy
<keescook> mario_limonciell: all the other updates appear to be in the other URL, maybe it should be the standard location?  I'll pull yours in...
<mario_limonciell> keescook, i lost the info for the old bzr branch so i re-inited this one
<keescook> oh, heh
<keescook> mario_limonciell: I've pushed to bazaar.launchpad.net/%7Emythbuntu/lirc/ubuntu/ now, uploading in a moment...
<mario_limonciell> keescook, okay thanks
<keescook> mario_limonciell: np, thanks for all the fixing :)
<mario_limonciell> well i'm personally hoping that people start submitting the fixes upstream.  I've put notes in bugs for folks to do it, but we'll see if it really happens.  that number of patches is really starting to grow :)
<j^> loading http://www.ubuntu.com/getubuntu/countdown i get a username / password popup for www-admin.ubuntu.com
<davmor2> when is release candidate out please.  I got it down as the 17th is that still the case?
<lool> soren: I'm pushing misc fixes/features to ~lool/ubuntu-jeos/trunk; could you have a look and perhaps merge them?
<lool> soren: I wanted to ask whether you would be interested in adding support for personality setting (linux32 chroot ...) when creating 32-bits chroots from 64-bits hosts
<soren> lool: Could you be pursuaded to rebase your patch against the "refactor" branch?
<soren> lool: I'll be sending an FFe tomorrow to upload that, so that should really be the focus of development from now on.
<soren> lool: About linux32: We should certainly do that.
<lool> soren: Ah
<soren> lool: The code hasn't changed a whole lot, but it's been restructured quite a bit and a stack of bugs have been fixed.
<lool> soren: I never "rebased" with bzr; I only did it with git; do you have any pointer on how this is done in bzr?
<lool> "bzr help commands" and "bzr help rebase" didn't help
<lool> Hmm google lets me think I need an additional plugin
<lool> How a "I'll fix this in 10 minutes" session ends up eating 2 hours
<soren> lool: Oh, I was thinking about doing it manually.
<soren> lool: automatic rebasing won't do much good when the code has been refactored like that anyway.
<hron84> hi! i using reprepro / repository, and i have a problem. I tried to make an own mirror from official mirror, and i started import packages to my repo, but all universe/multiverse package landed in main category. Why? Reprepro cannot handle universe/multiverse categories? In conf/distribution I filled correctly the Components and UDebComponents lines.
<LaserJock> hron84: I think it must be a configuration problem
<hron84> LaserJock: pls wait, i pastebin my config
<hron84> LaserJock: http://pastebin.ca/955911
<LaserJock> hron84: did you set up the updates file?
<hron84> No, how can i do it? It can be a problem?
<hron84> My system isn't an ubuntu
<_MMA_> ?
<ScottK> hron84: Then you're almost certainly in the wrong place to get help.
<hron84> ScottK: and can you recommend me a good channel?
<ScottK> hron84: What kind of system are you using?
<LaserJock> hron84: I'd suggest reading  the man page or googling. I don't have a current reprepro setup, but when I did it certainly worked right, mirroring main and universe
<hron84> ScottK: I using a Gentoo Linux. I installed reprepro with no problem (compiled it from source). I want create a custom ubuntu mirror, because i have a machine somewhere without net
<ScottK> Then I'd suggest checking on the web site where you got the source for support information.
<hron84> I downloaded it from archives.ubuntu.com... it doesn't contains package-specific support infos. I known and using linux, but I don't have experience with ubuntu distro-specific things
<slangasek> but if you built it on gentoo, you didn't use the existing build-dependency support in Debian/Ubuntu to build it, you had to translate that somehow to Gentoo; that's not something that the Ubuntu community is going to provide you with support for, you're going to need to contact the upstream author
<hron84> slangasek: I have an enough knowledge to understand the dependencies an one program. I think, if i miss any dependency, it can't work as well. And, it doesn't seems as dependency problem, it seems configuration problem. But, i will find upstream author too, but i hoped, i can give some info about this problem.
<LaserJock> hron84: just google around for reprepro configurations and/or look at the man page
<jdong> WTF
<jdong> "There was an error copying the file into smb://foo/bar"
<jdong> Show more details:
<jdong> Success.
<soren> jdong: heh. I've something like that in evolution before, too.
<jdong> soren: Hardy, gvfs copying a file onto smb://
<soren> jdong: "Failure while connecting to mail.linux2go.dk: Success." I never knew quite what to make of that.
 * jdong grumbles and uses good old scp :)
<_MMA_> jdong: I get errors when coping multiple files. It will copy 7 out of 10 files then tell me I dont have permission to the folder. But after I can copy the remaining files fine. Its totally random.
<_MMA_> Using samba that is.
#ubuntu-devel 2008-03-25
<orbisvicis> if the /debian/control specifies a different package than the original/older name can i set the new/(changed name) package to 'replace' the original package, that way dependencies can be met ?
<orbisvicis> aka does the 'replaces' field in the control file work if the packages have different names ?
<slangasek> the Replaces field only makes sense if the packages have different names
<slangasek> but a Replaces field doesn't satisfy any dependencies.
<slangasek> recommended reading: http://www.debian.org/doc/debian-policy/ch-relationships.html
<orbisvicis> i guess that was an awful explanation; let me read brb
<orbisvicis> then explain better
<lifeless> slangasek: so
<lifeless> 0.6.6-0ubuntu1
<lifeless> 0.5.10+git20080301-1ubuntu2
<slangasek> ok, what wireless chipset?
<slangasek> you seem to have evaded the hal breakage, at least :)
<lifeless> 4965
<slangasek> hmmmmm, I thought there was a 4965 bug open somewhere
<lifeless> so I get online at the moment by iwconfig + nm
<lifeless> hammer iwconfig at it enough and it comes up
<lifeless> after that its fine
<lifeless> it may not be nm, but I blame nm before anything else. With historical reason :)
<slangasek> possibly "nm/kernel driver interplay", in this case; the new nm has just changed to make use of the improved kernel stack, which not all drivers support yet (incl. the iwl3945 and iwl4965 drivers we're shipping)
<slangasek> so n-m may be making some... suboptimal choices
<mjg59> slangasek: Erm. Got a bug#?
<slangasek> lifeless: you might look through https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24 to see if any of these 4965 bugs match your symptoms; otherwise, dunno
<mjg59> The only new kernel stack I can think of is the new configuration stack, which is integrated in the mac80211 stack the iwl* drivers use
<mjg59> FWIW, 4965 works solidly here
<mjg59> Though I'm using n-m 0.7
<slangasek> mjg59: the mac80211 stack used by the iwl* drivers doesn't know scan_capa
<slangasek> there's a bug number, yes
<slangasek> #200950
<mjg59> slangasek: Ah, ok. I think your summary is wrong, then :)
<slangasek> sorry :)
<mjg59> mac80211 is the stack everything is migrating to
<slangasek> yes - but we have a forked version of mac80211 in l-u-m for iwl[34]*, and that version doesn't know scan_capa.  The one in linux-image does
<mjg59> Wurgh?
<slangasek> (don't ask me why we have two different versions of mac80211, that's beyond my ken)
<mjg59> They're developed against the one in -wireless, which should always be identical or ahead of the one in -image
<slangasek> that would imply that scan_capa is going away again, that would be messy
<mjg59> I suspect it might just be the case that the stuff in l-u-m wasn't updated appropriately
<slangasek> anyway, bug #200950 is the bug
<ubotu> Launchpad bug 200950 in linux-ubuntu-modules-2.6.24 "[iwl3945] network manager not able to associate to hidden SSID (scan_capa = 0x0)" [High,Confirmed] https://launchpad.net/bugs/200950
<lifeless> that summary looks exactly accurate
<lifeless> except for the chipset
<slangasek> you have a hidden SSID?
<slangasek> feel free to update the summary then, and poke asac about adding iwl4xxx to his quirk
<vorian> slangasek: I'll fix keurocalc straight away.
<slangasek> vorian: ok, cheers :)
<vorian> :)
<orbisvicis> slangasek, thanks for the link, virtual package provides was exactly what i needed
<orbisvicis> just didnt want to debuild, then 1/2 hr later find out it actually wasnt correct
<hmuller> Anyone know if there's a method to use hal to set xserver screen properties? (instead of manually editing xorg.conf after 'autoconfig')
<slangasek> bryce: in what sense is 915resolution no longer supposed to be removed?  The conflict is still there, and my understanding is that the conflict is corret
<slangasek> correct
<slangasek> or maybe "that should be fixed" is "we should fix that"?
<bryce> slangasek: yeah I don't know exactly what the situation is there, but I *believe* that we decided if they were using -i810 in gutsy, we weren't planning on rewriting their xorg.conf to use -intel, so we should check to make sure we aren't going to cause this bug in that case
<bryce> but I'm not sure exactly what we intend to do here though, so assigned to timo to take a look at
<jdong> bryce: hmm do you have any hints on why xserver-xorg-intel on GMA950, when playing xv after suspend+resume X freezes?
<bryce> jdong: no, I was just looking at that bug report though.  I have a 945 box here, I'll have a shot at reproducing it some time this week
<bryce> jdong: if you can post a backtrace, that could be quite valuable in tracking it down
<jdong> bryce: what kind of backtrace, and how would I go about getting one?
<bryce> we've only had a limited set of xorg changes recently that could account for it, so I think it's likely we can get it figured out
<bryce> ah, see http://wiki.ubuntu.com/DebuggingXorg for details
<bryce> basically ssh into the machine after locking up, and attach gdb to the Xorg process and do backtrace full
<jdong> bryce: ah, ok I'll give that a shot the next time I have a chance :)
<RAOF> bryce: Are you aware of the proposed patch (attached to freedesktop bugzilla) for bug #194214?  I don't know enough X to really tell if it's good, but the guy sounds reasonably confident :)
<ubotu> Launchpad bug 194214 in xorg-server "Keys get "stuck" down" [High,Confirmed] https://launchpad.net/bugs/194214
<jdong> bryce: OF COURSE, when I TRY to reproduce it, it doesn't happen
 * jdong cries
<bryce> hehe
<bryce> RAOF, looking
<jdong> lol
<jdong> bryce: ok from now on, I will tell you that X crashes each time before I suspend. That seems to do the trick.
<bryce> RAOF: interesting, the patch so far looks fairly straightforward but it sounds like it's not super thoroughly tested.  I'd sort of prefer giving it more time to be tested before rolling it into hardy, but I could probably roll a .deb for people to test with meantime.  I'll put it on the todo list for tomorrow
<RAOF> bryce: I'm very happy to attach a debdiff to the bug if that's easier for you.
<bryce> oh yes that would be great
<bryce> oh, I notice people have already posted debs, excellent
<RAOF> I'm not sure which patch they're applying, though.
<RAOF> There was an initial hack patch, then the better version on freedesktop bugzilla.
<bryce> ah, then if you could also post a .deb for folks to test that would be handy too
<RAOF> Yeah, I will.  Time to update my i386 schroot.
<hmuller> on bug #194214:  I experience similar results when using emacs (keys stick) , but the rumor is that mouse events trigger this (Hardy amd64 Beta+)
<ubotu> Launchpad bug 194214 in xorg-server "Keys get "stuck" down" [High,Confirmed] https://launchpad.net/bugs/194214
<pwnguin> wow
<pwnguin> http://slashdot.org/comments.pl?sid=494944&cid=22815662
<pwnguin> (about john nagle's validator service) "This tool is regularly abused as a proxy server. At one point, somebody even built a call to it into the Debian build process because they needed to read HTTPS from some code that didn't know how to talk SSL."
<pwnguin> "(That's been fixed.) "
<pitti> Good morning
<ion_> Night
<pitti> evand, _MMA_: sane does not need the scanner group any more; dev permissions are dynamically assigned by hal now
 * StevenK tries to figure out what colour depth his X server is running in
<Mithrandir> StevenK: xdpyinfo?
<StevenK> Mithrandir: Yeah, remembered that as I hit enter. :-)
<tjaalton> what's the procedure for getting new packages (= non-existing in ubuntu) from debian? fontmatrix seems useful
<ion_> It will be done automatically for intrepid.
<tjaalton> I was referring to hardy
<ion_> Iâd guess itâs too late in the release cycle, but i donât know for sure.
<zdzichuBG> tjaalton: there a wiki page somewhere, which is called official way and is ignored by develoeprs
<tjaalton> zdzichuBG: right.. paperwork it is then
<soren> zdzichuBG: The official way is ignored by developers?
<zdzichuBG> tjaalton: there is also https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<zdzichuBG> soren: thinkfinger was requested by this page for two releases, even with links to debian packages and haven't been included in Ubuntu
<tjaalton> zdzichuBG: read that already
<sivang> hi all
<soren> tjaalton: What you need to do is file an FFe for it.
<sivang> hmm, mvo is not online
<tjaalton> zdzichuBG: thinkfinger is in ubuntu
<soren> tjaalton: When that's accepted, you just file a sync request.
<soren> tjaalton: Well... The sync request could be written as an FFe, I guess.
<sivang> does anybody know a reliable way to find out the component a package belongs to through python-apt ?
<tjaalton> seems that fontmatrix has been requested already, bug 198837
<ubotu> Launchpad bug 198837 in ubuntu "Sync fontmatrix from debian lenny or unstable" [Wishlist,New] https://launchpad.net/bugs/198837
<soren> zdzichuBG: Erm... A wiki page is not the correct way to request new packages in Ubuntu. I don't know why you think it's official.
<sivang> candidateOrigin's component attribute seems to be missing for package like distcc and alike
<zdzichuBG> soren: it was. now it states it Obsoleted and bug has to be reported in launchpad
<soren> zdzichuBG: So the page even says that it's not the right way to do it... It's hardly surprising noone is picking it up then, is it?
 * sivang waits for Michael to come online
<soren> sivang: He's on holiday.
<soren> afaik
<sivang> oh
<sivang> hi soren
<soren> o/
<zdzichuBG> soren: it was official 1-2 years ago. Instructions on wiki.ubuntu.com stated, that in order to get package in ubuntu one has to add pointers to software in this page. Apparently process changed since then
<sivang> and there nobody else who knows python-apt as good as he.. darn
<Fujitsu> soren: When's he back? I have a question for him too.
<soren> Next week.
<soren> zdzichuBG: Right. We use wiki pages to track policies and such, and bug reports to handle tasks, bugs, etc.
<soren> zdzichuBG: ...because wikis make lousy bug trackers.
<soren> zdzichuBG: Basing statements like "foo is ignored by developers" on 1-2 years old empirical data is not very useful.
<zdzichuBG> soren: and louse archive tool, too. I can't find this wiki page right now, so I will back out my statement. Sorry.
<soren> zdzichuBG: Didn't you just say that it said the page was obsoleted and all that? Where did you see that if not on the page itself?
<zdzichuBG> tjaalton: see the page I linked. Correct way to have package included in Ubuntu is described there
<zdzichuBG> soren: there was a page with long table of software, sorted alphabetically
<zdzichuBG> soren: this page was linked from https://wiki.ubuntu.com/UbuntuMainInclusionQueue or similar page
<zdzichuBG> soren: whole process involving wiki got obsoleted
<slangasek> the main inclusion queue is for getting software into main, not for getting it into Ubuntu as a whole...
<zdzichuBG> (âThis page is obsolete; please file a bug report for each package to be moved to main and subscribe [WWW] ubuntu-mir to the report.â)
<Mithrandir> zdzichuBG: I believe soren knows this, he's been contributing to Ubuntu for years.
<zdzichuBG> Mithrandir: I'm explaining myself
<soren> zdzichuBG: Basing statements about policy about A based on wikipages about B is not useful either. *Especially* when you don't even mention that when you're making said statements.
<soren> zdzichuBG: It happens to be correct, but as a general rule, I'd advise against it.
<zdzichuBG> I'm sorry, I didn't meant to offend anybody.
<soren> Hm... I happend to notice that a package called "xenman" was removed from Ubuntu with a note saying that it had been renamed to "convirt", but "convirt" wasn't sync'ed. This seems unfortunate.
<soren> Package removal is a completely manual process, is it not?
<Fujitsu> soren: Some are manually requested, but others are semi-automatically imported from Debian.
<Fujitsu> I'm not sure how semi-automatic semi-automatic is, as the archive admin processes are very secret indeed.
<soren> Non-obvious != secret
<seb128> Fujitsu: what is secret?
<seb128> Fujitsu: it's all documented on the ubuntu wiki
<Fujitsu> Ah, so it is.
<Fujitsu> So it's "asks for confirmation [for each removal]" semi-automatic.
<seb128> I don't understand the question
<Fujitsu> I'm not seeing a question.
<seb128> Fujitsu: what is your issue then, what information would you like to know but is secret?
<Fujitsu> seb128: Oh, I see you joined afterwards.
<Fujitsu> seb128: soren asked about how manual removals were.
<soren> 09:47:59 < soren> Hm... I happend to notice that a package called "xenman" was removed from Ubuntu with a note saying that it had been renamed to "convirt", but  "convirt" wasn't sync'ed. This seems unfortunate.
<soren> 09:48:20 < soren> Package removal is a completely manual process, is it not?
<seb128> ah, ok
<soren> I don't know... I guess I just expected that when a package was removed because it got a new name, the new package would be imported straight away without the need for a sync request.
<Fujitsu> I find it strange that removals were processed after the autosync was switched off.
<seb128> why? we still do cleaning
<seb128> soren: seeing the reason it's likely manual processing
<soren> seb128: That makes it even more strange why the new package wasn't synced, doesn't it?
<seb128> not really
<soren> No? Hm.. Is that how renames are usually handled?
<seb128> if you ask me now to remove something because it has been renamed I'm likely to trust you, have a quick look and do it
<seb128> soren: we get lot of ping on IRC, mails, etc, dunno about this one especially but if the request comes from somebody known and trusted it's likely to be done without a lot of checking
<Fujitsu> Isn't this why a bug trail is mandated?
<soren> seb128: Are we talking about the removal of the old package or the syncing of the new one? Or perhaps both?
<seb128> soren: any archive admin request
<soren> seb128: Ah.
<seb128> Fujitsu: well, bugs are the usually way, but we tend to try to minimize the paper work when it's not required
<seb128> Fujitsu: I tend to do quite a lot of desktop syncs when asked on IRC rather than asking them to open a bug, then go to find the bug to close it, etc
<Fujitsu> seb128: For syncs it's not so bad; the requester is generally recorded as the Changed-By.
<PecisDarbs> hi people, question about OpenOffice.org translations - how they get pulled in and how they get updated?
<tkamppeter> pitti, hi
<seb128> pawalls: hi
<seb128> pawalls: want to discuss the mounts listed by gvfs?
<tkamppeter> Does someone know if pitti already came back from easter vacation?
<seb128> tkamppeter: /whois pitti and read the away text there
<tkamppeter> seb128 thanks
<pitti> hi tkamppeter
<pitti> tkamppeter: I'll upload your packages now, don't worry :)
<pitti> tkamppeter: sorry, I was out for a bit
<asac_> lifeless: please test if the branch now associated with bug 200950 fixes your hidden connect problem for iwl4965
<ubotu> Launchpad bug 200950 in linux-ubuntu-modules-2.6.24 "[iwl3945] network manager not able to associate to hidden SSID (scan_capa = 0x0)" [High,Confirmed] https://launchpad.net/bugs/200950
<tkamppeter> pitti, it was not primarily about the stack of packages, but that I have good news for you: bug #25966 is fixed. Bugs in the individual packages get now assigned to the packages.
<ubotu> Launchpad bug 25966 in Ubuntu Hardy "NEW PACKAGE: Printer drivers for Brother needed" [High,Fix released] https://launchpad.net/bugs/25966
<tkamppeter> pitti, Now the Brother packages are ready for Jockey.
<pitti> tkamppeter: right, I read it this morning; awesome job of Saivan and you!
<pitti> tkamppeter: looking forward to Austin and discussing how to integrate printer drivers into this
<tkamppeter> pitti, should SaÃ¯vann appy for MOTU now?
<pitti> tkamppeter: he should probably collect some more experience (bug triage, bg fixing, freezes, packaging of free software and best practices, etc)
<tkamppeter> pitti, I have a question about bug 139665. In the last comment in it there is a syslog with AppArmor messages about smaba files.
<ubotu> Launchpad bug 139665 in cupsys "apparmor profile error messages" [Medium,Incomplete] https://launchpad.net/bugs/139665
<tkamppeter> For me it looks like that for Hardy this is no problem any more, as third-party backends, including smb, are excluded from AppArmor protection:
<tkamppeter> /usr/lib/cups/backend/* Ux
<tkamppeter> pitti, am I rightÂ»
<tkamppeter> pitti, am I right?
<pitti> tkamppeter: in theory yes
<pitti> tkamppeter: however, that same relaxed profile is also in gutsy-updates
<pitti> tkamppeter: so I'd ask again for his version, and whether he uses the -update packages
<tjaalton> what happened to linda? it's not installable
<pitti> tjaalton: it got removed from Debian
<tjaalton> oh..
<pitti> tkamppeter: I wouldn't mind adding some rm privs to /usr/share/samba, that doesn't hurt
<pitti> tkamppeter: depends on whether it's only through a third-party driver (and thus fixed now) or due to something built into cups itself
<Riddell> calc: whats the status of openoffice.org-l10n-en-gb ?
<tkamppeter> pitti, CUPS is not talking to Samba directly. Using CUPS as a client to an SMB server is always done via the smb backend.
<pitti> tkamppeter: hmm, which is not covered by the AppArmor profile
<pitti> so it should work
<tkamppeter> pitti, thanks. Bug closed.
<pitti> tkamppeter: hm, I just followed up with that question
<pitti> tkamppeter: but anyway, if I get a negative response, I'll just reopen it
<pitti> thanks
<tkamppeter> pitti, I am also closing 153003, as the /dev/tty problem does not break printing and the other problems are fixed.
<pitti> ah, great
<tkamppeter> bug 153003
<ubotu> Launchpad bug 153003 in cupsys "inode_permission error for cupsd on /dev/tty" [Undecided,Won't fix] https://launchpad.net/bugs/153003
<asac> any idea if dpkg-genchanges is somewhat broken at the moment? -S -si yields http://paste.ubuntu.com/6057/ for me
<asac> while it works in feisty
<asac> and works in gutsy
<ogra_cmpc> asac, do you work remotely and ahve a rinning display as asac on the same machine ?
<ogra_cmpc> *running
<asac> ogra_cmpc: no thats locally
<ogra_cmpc> dpkg-genchanges (or rather gnome-keyrig i think) does use a graphical PW prompt now
<asac> ogra_cmpc: doing the same in gutsy chroot works
<asac> ogra_cmpc: pw prompt? afaik it doesn't sign on its own
<asac> ogra_cmpc: the problem is that the orig.tar.gz is in the .changes ... even though i build with -si
<asac> i hope that its not pw related :)
<ogra_cmpc> heh, no
<ogra_cmpc> but the .changes need to know the md5 for the orig.tar,gz
<asac> ogra_cmpc: no thats the .dsc
<ogra_cmpc> so that should indeed show up there
<ogra_cmpc> hmpf
<asac> he?
<asac> it never shows up there
<asac> only in hardy
<asac> feisty, gutsy, dapper work :)
<asac> e.g. it just doesn't obey the -si flag anymore
<asac> (at least here)
<asac> ogra_cmpc: you have ralink?
<asac> can you test hidden ssid if you have a minute?
<asac> you need to remove the connection info from gconf (through nm applet "Edit Connection ..")
<ogra_cmpc> asac, you have ralink :) its in the classmate :)
<asac> ogra_cmpc: right ;)
<asac> ogra_cmpc: what do you have?
<ogra_cmpc> rt73usb
<asac> i thought you had another ralink of a different kind
 * ogra_cmpc would have said now "all classmates are the same" ... but that doesnt seem true anymore ...
<asac> ogra_cmpc: does that work out of the box?
<ogra_cmpc> but ours are at least :)
<asac> a friend complained that his rt73usb doesn't work out of the box in gutsy
<ogra_cmpc> i never tired hidden essid ... but for all other setups it works fine
<ogra_cmpc> oh, ah, eh ... gutsy
<asac> ogra_cmpc: yes. hidden essid is special.
<ogra_cmpc> no thats rather gamblinbg
<asac> ogra_cmpc: ok. so hardy is better
<asac> good to know
<ogra_cmpc> gutsy did work depending on the moon phase only
<asac> are there issues with just installing the hardy kernel in gutsy or should i advise him to upgrade?
<ogra_cmpc> hardy worked with all setups i have tried yet ... no idea about the kernel though, you will need new module-init-tools and udev additionally i think
<asac> hmm
<asac> i think he should just hit dist-upgrade
<asac> we are at beta stage after all
<tkamppeter> pitti, thanks for uploading all that packages which I have prepared the last days, now we had real bug closing fireworks. I have now also prepared hplip, see your mail.
<ogra_cmpc> asac, yeah
<ogra_cmpc> hardy is far beyond wrt ralink
<pitti> tkamppeter: indeed :) uploaded hplip, too
<sistpoty|work> pitti: please give back haskell-http on sparc, thanks!
<pitti> sistpoty|work: kicked
<sistpoty|work> thanks!
 * Hobbsee gently kicks pitti
<Hobbsee> if i give pitti back, will he clone himself?
<sistpoty|work> heh
 * pitti plops back into existence fourfold
<Hobbsee> yay!
 * Hobbsee gives pitti back again
<Hobbsee> 8, or 16 now?
<pitti> -ENOSPC on my desk
<Hobbsee> aww
<tkamppeter> pitti, thanks
<ogra_cmpc> pitti, hey, you said you like ltsp, i could send you some terminals :)
<pitti> hah, great idea
<pitti> can then someone please clone my wife, bicycle, fridge, and laptop as well?
<ogra_cmpc> you want a bike riding harem ?
<Hobbsee> with a fridge?
<ogra_cmpc> no, with fat geeky girls i guess :)
<pitti> eww
<ogra_cmpc> heh
<Hobbsee> erk.
<StevenK> No, pitti just doesn't like sharing.
<StevenK> Even with himself.
<seb128> pitti: do you have an option on whether desktop users should be in lpadmin or not?
<pitti> seb128: IMHO no
<seb128> pitti: can you add and configure printers without being lpadmin member?
<pitti> seb128: no, that needs lpadmin
<seb128> so you think desktop users should not be able to set up a printer?
<seb128> hum
<pitti> probably 'lpadmin' should have been just 'admin'...
<seb128> I'm not sure I agree
<pitti> same question as 'so desktop users should not be able to change the time zone', or install a package
 * pitti grumbles about a stale 5-a-day lock on lp bzr
<seb128> hum
<seb128> I'm not sure I agree there
<seb128> with admin rights you can break things
<seb128> but adding a printer should be no issue
<pitti> you can enable printer sharing to the world with lpadmin, or reroute known printers to somewhere else
<seb128> alright
<seb128> I'm wondering if it makes sense to have a desktop profile
<seb128> that's just useless thing, you can't do anything as a desktop user apparently
<pitti> why not?
<pitti> it's exactly what I'd give to users at an university or an office
<pitti> or my wife on my computer
<seb128> well, that's just an standard unpriviledged user then, no?
<pitti> i. e. audio, video etc. are fine, but no admin rights
<seb128> we should have user and admin
<pitti> seb128: hm, desktop user is audio/video/modem etc.
<ogra_cmpc> printer adminstration was possible before for nomal users iirc (with the older print tools)
<ogra_cmpc> but never with lpadmin
<pitti> ogra_cmpc: how?
<pitti> cupsys always required being in lpadmin to do administration
<ogra_cmpc> pitti, i could manage print jobs and add/remove printers with gnome rpint tool  if i'm not totally wrong
<seb128> pitti: alright, makes sense, I was just checking before changing, thanks ;-)
<seb128> ogra_cmpc: you were likely in lpadmin
<pitti> ogra_cmpc: I doubt that
<ogra_cmpc> hmm
<pitti> ogra_cmpc: you didn't need a password or anything, but you did need the group membership
<ogra_cmpc> and did we use that group for non admin users ?
<ogra_cmpc> i thought i remember it working with such users in ltsp
<ogra_cmpc> but i may remeber it wrongly ... you will know petter as the cups maintainer
<ogra_cmpc> heh
<ogra_cmpc> better as well
<_MMA_> pitti: The issue is bug #205496. I'm going to grab a new daily to see if the problem persists there still. My installed Hardy still has this issue.
<ubotu> Launchpad bug 205496 in xsane "[Hardy]Xsane needs root to operate scanner" [Undecided,New] https://launchpad.net/bugs/205496
<seb128> _MMA_: are you member of the scanner group or not?
<_MMA_> seb128: I did enable it yes.
<_MMA_> My 1st post in Bug #205628 shows how to reproduce.
<ubotu> Launchpad bug 205628 in xsane "[Hardy] xsane reports all devices as busy. (dup-of: 205496)" [Undecided,New] https://launchpad.net/bugs/205628
<ubotu> Launchpad bug 205496 in xsane "[Hardy]Xsane needs root to operate scanner" [Undecided,New] https://launchpad.net/bugs/205496
<pitti> _MMA_: hm, weird; you shouldn't need group scanner any more, for me it works perfectly without
<jdstrand> zul: regarding bug #204612 , I saw it the other day (but haven't tried to reproduce it)
<ubotu> Launchpad bug 204612 in nut "nut 2.2.1-2.1ubuntu1 fails to install on Hardy Heron" [Undecided,Triaged] https://launchpad.net/bugs/204612
<zul> jdstrand: just tried it here locally in my vm and I wasnt able to
<jdstrand> zul: the machine it happened on has upsmon enabled, but not upsd
<zul> jdstrand: hmm...interesting anything in the log files?
<_MMA_> pitti: It is odd. All 3 of my devices that xsane can see give me busy errors unless I open as root/sudo. This happened a little before beta. I'll see what the daily yields to try to narrow it down to a quirk on my installed system.
<ogra_cmpc> _MMA_, did you notice that ~/.sane is owned by root automatically if you run scanimage as root ? it wont be writable for your user
<jdstrand> zul: nothing out of the ordinary (grep ups /var/log/*)
<jdstrand> zul: but I can't remember quite when I saw it
<_MMA_> ogra_cmpc: I made sure to clear out any .sane folders and re-run as user.
<ogra_cmpc> ah, k
<jdstrand> (I new there was a bug and moved on :( )
<zul> jdstrand: I wasnt getting the udev messages like the user is in the bug
<jdstrand> zul: oh-- I remember I got udev failed to restart or something too
<jdstrand> zul: sorry I am not being much help here...
<jdstrand> (with specifics)
<jdstrand> zul: I was really just doing a 'me too'
<zul> jdstrand: yep I got that as well but the upload fixed that and just double checked as well
<zul> jdstrand: heh
<ScottK> doko_: For Bug #199014 (python-xml removal), only zsi remains.  bzed is looking at an svn snapshot for Debian to deal with it, but it's a non-trivial packaging effort.  zsi as is stands needs some substantial chunks from python-xml to work correctly.  I'm not going to have time to sort through it before release.
<ubotu> Launchpad bug 199014 in qm "python-xml removal: please drop/replace (build) dependencies" [Undecided,In progress] https://launchpad.net/bugs/199014
<Mirv> bryce: hi. I don't think the current approachin gnome-control-center to apply a patch (104) to a patch (101) works, the i18n seems to be as broken as earlier. the patch I gave you was supposed to be applied (so as to update the existing 101 patch), not to add as a patch...
<Mirv> bryce: could you do another upload and also test that the i18n works with a language of your choice?
<doko_> ScottK: seen.I'll at move the package into a private directory probably, so that it gets out of sys.path
<Riddell> evand: no-reboot and no minimise button changed made in kde_ui
<Riddell> evand: do let me know when ui changes like that happen so I can make them happen in kde_ui too
<Riddell> calc: thanks for the minimise issue poke ^^
<pitti> _MMA_: can you please check the ACLs of /dev/bus/usb/...?
<pitti> _MMA_: and whether ck-list-sessions has a local session for you?
<\sh> hmmm..the compile archs for wine are written in the PAS file?
<evand> Riddell: will do in the future and thanks. fwiw, both were on my TODO list.
<Riddell> evand: then I rephrase, "do let me know when ui changes like that happen so I can make sure they don't get too low priority on your TODO" :)
<sistpoty|work> pitti: please give back haskelldb on sparc, thanks!
<evand> Riddell: :)
<siretart> Riddell: do you remember the dvd playing issue you asked me last week?
<siretart> Riddell: FYI, I've filed bug #204563 about it
<ubotu> Launchpad bug 204563 in gxine "Update to gxine 0.5.901-1" [Undecided,New] https://launchpad.net/bugs/204563
<Riddell> siretart: this is gxine only?
<siretart> Riddell: I couldn't reproduce it with totem-xine, but I have to admit that I didn't have to time to test other players
<siretart> Riddell: you didn't answer my question what player you have used that time ;)
<Riddell> kaffeine and xine-ui
<siretart> ok, I'll check xine-ui this evening
<Riddell> thanks
<siretart> but for gxine, I know that the version in hardy has serious locking issues.
<siretart> do you know if the feature freeze request is missing something?
<siretart> if you have a sek to look at it only, of course
<Riddell> siretart: not that I can see, but its for the universe review team to judge
<siretart> Riddell: err, both apps are in main
<siretart> both gxine and xine-lib, that is
<siretart> (that's why I didn't bother with xine-ui too much, TBH)
<Riddell> siretart: Directory: pool/universe/g/gxine
<siretart> oh? gxine got demoted? why doesn't anyone tell me!
<siretart> :)
<Riddell> xine-lib too
<Riddell> no
<Riddell> xine-ui too
<jdong> can a core-dev look at bug 188261 for me?
<ubotu> Launchpad bug 188261 in pm-utils "[debdiff] pm-utils modunload nonfunctional" [Medium,Triaged] https://launchpad.net/bugs/188261
<jdong> It's a trivial straightforward fix
<jdong> mjg59: ^^
<mjg59> jdong: I'm not a core-dev
<mjg59> But pitti's been working on pm-utils
<jdong> mjg59: wha? really??
<Mithrandir> jdong: uploaded
<buttterz> hello, who would i talk to about committing a deb to the repository
<Lamego> probably you should start at #ubuntu-motu, I am assuming it will be an universe package
<buttterz> Lamego , hello again -- its a truecrypt wrapper.
<buttterz> Lamego , appreciated -- i'll take care of it
<calc> Riddell: ah yea :)
<calc> Riddell: also if you continue to use the live cd after doing the install it shows all the dirs from the root of the cd on the desktop
<calc> Riddell: not sure if there is a way to clean that up
<calc> anyone know how I should make this work?
<calc> LANG=es_US.UTF-8 oowriter
<calc> it gives me this:
<calc> (process:20108): Gdk-WARNING **: locale not supported by C library
<calc> (soffice:20108): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale.
<calc> then shows it in english for me anyway
<Lamego> calc, es_US ?
<ogra_cmpc> heh
<ogra_cmpc> yay for typos
<calc> Lamego: well es_MX does the same, etc
<calc> spanish US
<calc> not typo
<ogra_cmpc> thats actually existing ?
<Lamego> there is a spanish US ?
<calc> /usr/share/i18n/locales/es_US
<calc> it looks like it
<ogra_cmpc> yeah
 * ogra_cmpc hides again
<calc> even es_ES.UTF-8 gives me the error
<ogra_cmpc> calc, you did "sudo locale-gen es_US.UTF-8" before ?
<pitti> calc: locale -a shows the existing locales
<calc> ogra_cmpc: no, i thought i had made it work in the past without having to do that
<Spads> we have a locale for US Spanish?
<calc> i must have just been testing various other countries english in the past
<ogra_cmpc> es_US will be generated by the language-pack-es-base package i thik
<calc> well it works now after doing locale-gen :)
<ogra_cmpc> *think
<Lamego> you need to localcal-gen it, it is not generated by default, not if you selected an english install
<Lamego> only en_* are generated if you select an english install
<ogra_cmpc> well, all others are generated by iunstalling the $lang-base packages
<calc> now i have to remember enough spanish from school to see if this bug is fixed :-) heh
<ogra_cmpc> *installing
<calc> the bug is fixed, yipee :)
<calc> 1 down 44 new to go
<calc> is there a way to remove a locale i generated if i don't want it anymore?
<ogra_cmpc> well, --purge as option to locale-gen would wipe all of the existing ones and only newly generate the one you gave
<calc> ogra_cmpc: or can i just manually remove whatever it generated somewhere on disk?
<ogra_cmpc> no idea
<ogra_cmpc> i usually use the tools for that
<calc> looks like it creates a dir under /usr/lib/locale (sounds like a FHS violation)
<calc> yea rm'ing that dir made it go away from locale -a
<ogra_cmpc> calc, sudo locale-gen --purge en_US.UTF-8 && sudo dpkg-reconfigure language-pack-en-base
<ogra_cmpc> that will give you all en locales back and delete everything else in advance
<calc> ogra_cmpc: cool :)
<calc> now i can test various locales without causing problems :)
<calc> ogra_cmpc: local-gen --purge doesn't seem to do anything
<calc> doh nm
<ogra_cmpc>        --purge
<ogra_cmpc>               Remove all existing locales before processing.
<ogra_cmpc> :)
<ogra_cmpc> man locale-gen
<calc> i thought i had a root console but had already exited it when i ran the command
<calc> now it works :)
 * calc goes to find some caffeine
<ogra_cmpc> usually if i give lines like the above you can copy paste them :) old supporter habit ;)
<calc> for some reason doing that doesn't change the line in
<ogra_cmpc> (if my fingers didnt play tricks on me with the classmate keyboard indeed *g*)
<calc> /var/lib/locales/supported.d/local
<laga> usually i tell people to read the manual.. different school of support, i guess ;))
<calc> so if you manually add a locale with locale foo it adds it there but when you purge it doesn't update it
<ogra_cmpc> laga, 1.5years of #ubuntu tought me that ...
<calc> laga: there's not really a manual in this particular case wrt running dpkg-reconfigure on the lang pack, etc
<laga> ogra_cmpc: heh.. yeah. also the manual is often non-existant
<laga> calc: i know
<laga> i wasn't being serious
<calc> ogra_cmpc: thanks for the help :)
<ogra_cmpc> calc, well, the sudo locale-gen --purge en_US.UTF-8 should have cleared it according to the manpage
<ogra_cmpc> but you need to have a new locale as option as i understood it
<calc> ogra_cmpc: it clears out the files in /usr/lib/locales/ but didn't seem to update the static local file in /var/lib/locales/supported.d/local
<ogra_cmpc> ah
<calc> not sure if that really hurts anything or not
<ogra_cmpc> i'm not sure how the backend stuff works here, pitti would though
<pitti> calc: right, it should remove it from supported.d/local, but it's only a minor bug
<calc> pitti: ok
<calc> pitti: i don't know enough about locales to know if it was a big issue :)
<asac> TheMuso: awake still?
<LaserJock> pitti: I'm uploading a squeak package that's not going to go to source NEW
<pitti> LaserJock: what do you mean?
<LaserJock> I'm keeping the naming scheme and licensing of the current packages
<LaserJock> so it won't go to source NEW
<pitti> ah, I see
<LaserJock> but the -sources and -image packages will
<pitti> as you wish
<pitti> LaserJock: was the licensing situation clarified?
<LaserJock> do you want me to split them up so they aren't native?
<LaserJock> pitti: not terribly well
<pitti> LaserJock: if they are in Debian, they should be as close as possible to Debian; if not, it doesn't matter much
<LaserJock> pitti: the author seems to have amnesia about how he licensed his software
<LaserJock> pitti: well the debian package is an svn snapshot and will be MIT
<pitti> non-native is always better, of course, but not if it's too much trouble
<LaserJock> pitti: but the package doesn't work at all
<LaserJock> so I'm keeping the naming scheme that is used in Debian (and what we were using before) but with the stable packages
<LaserJock> for Hardy I'd rather have packages that actually work
<ogra_cmpc> ++
<LaserJock> and for Intrepid we can sync up with Debian
<LaserJock> as I'm assuming by then the package will have the bugs worked out
<ogra_cmpc> not having a working squeak for an LTS would pretty much harm us in the edu world
<ogra_cmpc> LaserJock, btw, did you ever try it on a classmate ?
<ogra_cmpc> :)
<LaserJock> no, I didn't even think about it
<ogra_cmpc> :)
<LaserJock> I guess since they use it on the OLPC it would be a good thing to try
<ogra_cmpc> i'll do as soon as we have working packages
<aguthrie> is there a reason why people still have to configure their mice manually using xorg.conf? surely it would be easy to recognize the mouse and automatically set this up so all mouse buttons work by default
<LaserJock> aguthrie: I've never heard of anybody having to do it manually
<jeromeg> LaserJock: maybe he speaks of 5 buttons mice
<ogra_cmpc> LaserJock, well, you didnt meet people with 27button mice , fingerprint reader and coffe machine included yet i guess
<aguthrie> I do
<jeromeg> i've heard some people complaining about this
<aguthrie> well, most mice have back/forward buttons today, no?
 * ogra_cmpc doesnt have one among 20 he owns
<aguthrie> I mean, I guess most people who use those are power users who could figure out how to set it up with xorg.conf...
<aguthrie> but I just don't see why the It Just Works mentality hasn't been implemented with this
<jeromeg> aguthrie: the main problem is that the config is different for almost every mouse, so it's not easy to set ;)
<ogra_cmpc> aguthrie, there is work going on in hal for such stuff
<jeromeg> there does not seem to be a standard
<ogra_cmpc> but that will still take a while (not hardy)
<aguthrie> ogra_cmpc: where can I find out more about that?
<aguthrie> jeromeg: yeah, but there are only so many mice...
<ogra_cmpc> read the HAl mailing list at freedesktop org
<aguthrie> ogra_cmpc: ok
<ogra_cmpc> X input is supposed to completely go to hal eventually
<ogra_cmpc> keyboards as well as other input devices
<ogra_cmpc> but as i said, not hardy ...
<aguthrie> hmm... looks like there was a Google SoC student working on that in summer of '07, but there doesn't seem to have been much progress since then
<Ng> win 136
<jpatrick> Ng: again? :)
<Ng> yes, I fail at IRC ;(
<ogra_cmpc> jpatrick, he wins a lot here
<ogra_cmpc> all day
<LaserJock> I need like: win $1000000
<jpatrick> ogra_cmpc: haha :)
<slangasek> pitti: thanks for the e2fsprogs upload
<pitti> slangasek: you're welcome
<alex-weej> are theme bugs good to be fixed? or is there some kind of UI freeze?
<slangasek> there is a UI freeze
<alex-weej> tooltips in murrine-human aren't using the right keyword
<alex-weej> so they appear grey and without any padding
<seb128> alex-weej: hardy will use ubuntulooks anyway
<slangasek> that would be an appropriate bug to fix, too, IMHO
<alex-weej> oh it's being reverted?
<alex-weej> actually, the Human theme on my system never changed to murrine
<alex-weej> i just keep seeing it in people's pointless screenshot tour blogs
<evand> Riddell: Do you have any more casper or ubiquity changes you'd like to get in before I send them to the buildds?
<Riddell> evand: no (I'm onto oem-config now)
<pitti> seb128: does nauttilus actually open f-spot for you if you plug in a camera?
<pitti> seb128: actually, both nautilus and g-v-m are supposed to handle it, but ATM nothing happens at all for me; for you, too?
<Riddell> evand: I did send casper to the buildds already
<zul> thom: ping (re: puppet)
<seb128> re
<seb128> pitti: I've be disconnected, did you get my reply?
<evand> ah, so you did.  OK
<slangasek> ScottK: hmm, do you have any idea what's going on with bug #192622, then?  It's been milestoned, I'm not sure whether it should be but if it should then that puts it on my nag radar :-)
<ubotu> Launchpad bug 192622 in kdesudo "[Feature Freeze Exception]New upstream release (kde4 port)" [Undecided,Confirmed] https://launchpad.net/bugs/192622
 * ScottK looks.
<ScottK> I'll have to ask.
<Riddell> slangasek, ScottK: that can be closed, we have kdesudo-kde4 now
<ScottK> Riddell: Thanks.
<ScottK> So marked
<slangasek> yay, thanks :)
<thom> zul: yo?
<zul> thom: i was looking at the puppet stuff and there is a sync request but ubuntu-archive is not subscribed was that intentional?
<tsmithe> hi. could someone take a look at http://launchpadlibrarian.net/12847770/buildlog_ubuntu-hardy-hppa.mscore_0.9.1d%2Bdfsg-0ubuntu3_FAILEDTOBUILD.txt.gz
<thom> probably not
<tsmithe> it seems that pdftk on hppa depends on libgcj6, which doesn't exist. in fact, on other architectures, pdftk depends on libgcj8-1, which does exist. what's up with hppa?
<thom> i think requestsync was bust for me
<thom> so i c'n'pd, obviously missed the sub
<zul> thom: i guess it needs to go through motu-release now as well
<thom> we really don't particularly want to ship current puppet, it's pretty bust
<zul> ah ok
<slangasek> tsmithe: what's up is that pdftk isn't up-to-date on hppa
<slangasek> so it probably had a FTBFS
<slangasek> https://launchpad.net/ubuntu/hardy/+source/pdftk/1.41-2 is bound to tell you more
<tsmithe> slangasek, yeah - http://launchpadlibrarian.net/12293105/buildlog_ubuntu-hardy-hppa.pdftk_1.41-2_FAILEDTOBUILD.txt.gz
<tsmithe> segfault in compiling
<slangasek> yes
<tsmithe> does it need a re-upload to try again? how would one debug a segfault in the build process on hppa?
<slangasek> no, you don't reupload just to make the buildd retry
<tsmithe> didn't think so
<slangasek> you talk to the porters / buildd admins
<Riddell> evand: oem-config changes committed, are you planning an upload?  I see a bunch of changes that havn't been uploaded for a couple of weeks
<slangasek> debugging -> get access to an hppa, or harrass the porters to do it :)
<ScottK> tsmithe: For hppa that's lamont
<tsmithe> ScottK, slangasek, thanks :)
<tsmithe> lamont, are you available?
<lamont> tsmithe: if it's a reproducible segv, then it's "get on a machine"
<lamont> if it's not so reproducible, well, sometimes that happens... :-(
<lamont> infinity: you wanna give back pdftk on hppa
<tsmithe> i'm not sure if it's reproducible... i don't have an hppa machine to check
<lamont> ScottK: what package did you want given back in dapper-backports again>?
<lamont> tsmithe: the simple check is to give it back and see if it does it again... == "reproducible" :)
<tsmithe> i'm not familiar with the term "to give back" ;)
<ScottK> lamont: postfix on all archs except i386.
<lamont> tsmithe: it's buildd-admin speak for "have a buildd try it again"
<lamont> (give it back to the pool of needs-build stuff)
<slangasek> lamont: we should start saying "zurÃ¼ckgeben" for clarity
<ogra_cmpc> slangasek, why did you unmilestone bug #198157 ?
<ubotu> Launchpad bug 198157 in ltsp "ltsp-update-image: /opt/ltsp/i386 is hardcoded in some places" [Medium,In progress] https://launchpad.net/bugs/198157
<tsmithe> ah right, cheers. then, if that succeeds, i could request mscore be given back?
<Trollinator> did anybody here ever write a kernel module? I can't compile my kernel module because it doesn't find the necessary include files :/
<lamont> tsmithe: well, inifinity is really the right one to abuse^Wrequest it of.
<lamont> I am occasionally willing to abuse my admin-privs for hppa stuff, but I shouldn't, so I tend not to...
<slangasek> ogra_cmpc: because the milestone list needs to be usable as a list of "these things block the release"; IMHO that one should not - please still fix it as intended, but if you don't have time, that looks to me like a fix we can live without
<tsmithe> ok, thanks. infinity, ^^ :)
<infinity> lamont: given-back.
<infinity> lamont: Of course, I doubt the ICE was transient...
<ogra_cmpc> slangasek, damned ... i should stop using it as personal TODO list then i guess :)
<slangasek> probably not, it's gcj
<lamont> tsmithe: ICE (internal compiler error) != SEGV..
<infinity> slangasek: Yeah, exactly. :/
<lamont> oh
<tsmithe> lamont, hmm ok
<lamont> gcj?  hppa?  yeah, like that's gonna work in hardy
<slangasek> ogra_cmpc: you may find https://bugs.launchpad.net/~ogra/+assignedbugs?orderby=status more useful :)
<ogra_cmpc> slangasek, but you are right, its one of these "if i manage to not forget about it" bugs
<lamont> tsmithe: failure of a java package to build on hppa/hardy is taken as a given, and certainly does not (should not) be taken as a defect in the package
<evand> Riddell: I have no additional changes, so if you want to upload it, feel free.  Otherwise I'll take care of it after I upload ubiquity.
<infinity> lamont: DOES NOT BE TAKEN!  ENGRISH BERRY HARDO!
<Riddell> evand: probably better if you do
<evand> Riddell: will do
<tsmithe> lamont, to be fair, i've never come across an hppa machine, and i doubt mscore (for which pdftk, thus libgcj8-1) will have much use there, so i'm not too worried. i just like it to be clean on the stats :)
<slangasek> infinity: say it with me: "zurÃ¼ckgeben"
<infinity> slangasek: I would, but then the Canonical.de contingent will think they've won.
<infinity> slangasek: I don't need mvo marching around in my living room and plating flags in my couch.
<slangasek> heh
<infinity> planting, too.
<slangasek> infinity: it's ok! he'll bring tea!
<lamont> tsmithe: yeah.  me too.  the issue right now is that java and hppa aren't exactly speaking to each other
<mib_t3v1a82d> Hey guys, I just wanna make sure before I file this as a bug. I have Dell D830 with Nvdia Quadro NVS 140M. After I installed the Nvidia Driver it loads in a low-resolution. Everything was uptodate
<_MMA_> mib_t3v1a82d: Try using nvidia-settings to set the res. Otherwise I still use a full xorg.conf.
<_MMA_> mib_t3v1a82d: Is this Gutsy or Hardy?
<mib_t3v1a82d> It is hardy
<mib_t3v1a82d> In Gusty it was working pretty good
<_MMA_> mib_t3v1a82d: Then #ubuntu+1 would be the best place to work this out.
<mib_t3v1a82d> Ah OK .. thanks
<evand> Riddell: can you merge your changes for casper 1.126 into trunk?  I think you forgot to bzr push.
<bryce> Mirv: actually that patch 101 comes from upstream and is autogenerated based on their git tree, so I'm trying to keep all "our" patches independent to that, so I can update patch 101 periodically as new stuff comes down the pipe, and leave our patches alone
<bryce> Mirv: but I'll redo your patch so it works properly and re upload
<Riddell> evand: let me look
<zul> slangasek: any thought on the samba ucf stuff?
<slangasek> zul: "kill me now"? :)
<zul> slangasek: heh how about reverting it?
<slangasek> zul: I don't think that's a good idea
<slangasek> this is something that's been needed for a *long* time
<zul> gotcha
<slangasek> and not having it in hardy will just mean another 5 years of config upgrade problems
<zul> yay! :)
<slangasek> anyway, I have a 3.0.28a-1ubuntu1 merge in the works, which I want to finish up and get uploaded
<slangasek> then we can look at the remaining ucf issues against a clean background
<slangasek> (grumble, need an Ubuntu samba branch, mutter)
<Riddell> evand: should be it now
<zul> slangasek: if you are too busy I could do it for you
<slangasek> zul: I'm almost done with the merge, that's the easy part
<zul> ah
<evand> thanks Riddell
<slangasek> zul: hmm, looks like one thing that will let us get a head start on the ucf stuff would be triaging of bug #206036
<ubotu> Launchpad bug 206036 in samba "package samba 3.0.28a-0ubuntu3 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/206036
<slangasek> that's almost certainly ucf-related again, and we may need more detail about pre-upgrade config contents
<Mirv> bryce: ah, I understand. but ok thanks, waiting for it.
<shaya> sort of wondering why the vmsplice() security hole hasn't been fixed in gutsy?
<shaya> nevermind, I'm an idiot
<slangasek> zul: 3.0.28a-1ubuntu1 uploading
<slangasek> (includes the fix for bug #204703, fwiw)
<ubotu> Launchpad bug 204703 in samba "usershare: insuffisant permissions for anonymous login" [High,Fix released] https://launchpad.net/bugs/204703
<LaserJock> slangasek: is removing dependencies on python-xml a release goal for Main in Hardy?
<seb128> LaserJock: I think it's a doko goal rather ;-)
<slangasek> LaserJock: uh... python-xml is in universe at this point?
<LaserJock> slangasek: right
<LaserJock> I'm trying to figure out the feasibility of doing a FFe for gcompris
<slangasek> so hopefully there are no such dependencies left in main...
<slangasek> confirmed, there aren't
<slangasek> if you're asking to add it back, that'll be a "no" then :)
<LaserJock> no
<LaserJock> I just found a Debian changelog entry saying they removed it
<LaserJock> so I don't know if they added the dep between our version and theres or ...
<LaserJock> so I guess python-xml is a non-issue
<ScottK> LaserJock: We're down to zsi as the only python-xml depends in the archive once a few syncs are done, so please don't make it worse.  We are very close ...
<LaserJock> ScottK: no, I *thought* our current package had it because Debian mentioned removing it. Apparently it was added somewhere in between
<LaserJock> ScottK: I was trying to get rid of a dep, not create one
<ScottK> LaserJock: Great.
<ScottK> Just making sure ...
<LaserJock> ScottK: np
<Mez> hmm, building a new pbuild of gutsy, dpkg segfaults setting up udev ...
<alex-weej> what's the consensus on PackageKit? nothing decisive on the LP spec https://blueprints.launchpad.net/ubuntu/+spec/package-kit so i'm wondering if there may be any interest in a policy-kit powered APT without the extra level of abstraction
<seb128> alex-weej: not a priority for what I know, it doesn't bring a lot over what we have and doesn't reply to the need anyway since it's non interactive and deb can have questions, etc
<alex-weej> all that in respect to PackageKit?
<alex-weej> or p-k APT?
<alex-weej> policy-kit APT that is
<seb128> alex-weej: I think we have other things to solve before trying to switch to a less powerful package management tool
<slangasek> heh
<alex-weej> seb128: right, but i might be able to have a go at getting something going and it gives me an excuse to learn policykit
<seb128> alex-weej: packagekit, policykit is a different topic but that's not really an apt thing
<alex-weej> basically i'm asking if it would be a good use of my time to create an APT frontend that runs over dbus
<seb128> you should speak to mvo and glatzor about it
<seb128> but what would the apt frontend talk to over dbus?
<seb128> I'm sure that mvo welcomes patches if they are not too crackfuls ;-)
<seb128> but making apt use dbus might not be that trivial
<slangasek> yes, I'm looking forward to marking dbus as Essential: yes
<slangasek> because the package manager doesn't work without it :)
<alex-weej> slangasek: i didn't say apt-get needed to be replaced
<alex-weej> it's for privilege separation more than anything else.
<alex-weej> synaptic still must be run as root
<TheMuso> asac: I'm around now.
<asac> TheMuso: thanks. i figured it out. (at least i hope :))
<TheMuso> asac: Ok.
<_MMA_> pitti: Thanx! The updates worked. Now hopfully SANE fixes my specific issue.
<LaserJock> slangasek: would actually uploading hardy documentation for Edubuntu (there is only gutsy documentation now) need a FFe?
<mario_limonciell> slangasek, it looks like gawk is suddenly gone on any DVD images generated after 2008-03-18
<tjaalton> asac: I know you are terribly busy, but could you update your nm-0.7 packages on your PPA some time?-) there's been some 3G love upstream that I'd like to try out
<asac> tjaalton: do the patches still apply?
<asac> :)
<asac> anyway, i plan to do that once i have a free minute :)
<tjaalton> asac: no idea.. I just noticed that there's been some progress upstream :)
<asac> lets see ... running  bzr merge http://bazaar.launchpad.net/~vcs-imports/network-manager/main
<tjaalton> asac: rock :)
<asac> strange .. how the hell can i get a conflict in configure.in?
<asac> i branched from the same branch and didn't touch that upstream file according to blame
<tjaalton> asac: btw, a friend of mine managed to get 0.6.6 working with a 3G card using ppp, but to fully utilize it the 0.7 should be better :)
<asac> oh shame on me ... i did touch it ;)
<tjaalton> hehe
<laga> slangasek: can you please merge rev1286 from the mythbuntu debiancd branch into mainline? http://bazaar.launchpad.net/~mythbuntu/debian-cd/mythbuntu-debiancd
<laga> slangasek: here's the launchpad interface if you prefer that: https://code.launchpad.net/~mythbuntu/debian-cd/mythbuntu-debiancd
<asac> tjaalton: it bails out like http://paste.ubuntu.com/6082/
<tjaalton> asac: damn.. thanks for trying though :)
<asac> tjaalton: and access-point.xml like http://paste.ubuntu.com/6083/
<asac> (just the first lines of course)
<asac> no idea why dbus binding tool would fail like this
<lifeless> asac: to test that branch I need to build it locally right ?
<asac> lifeless: yes.
<asac> its an all in one branch ... so no orig needed
<lifeless> ok; I'll put it on the todo :)
<asac> tjaalton: https://code.edge.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.7 the branch builds but you need a patched dbus-glib with patch from http://bugs.gentoo.org/show_bug.cgi?id=212572
<ubotu> bugs.gentoo.org bug 212572 in Ebuilds "dev-libs/dbus-glib - dbus-binding-tool ignore namespaced nodes & attributes" [Normal,New]
<tjaalton> asac: wicked, I'll try it out. thanks!
<asac> tjaalton: i added the url to the bug to the branch whiteboard
<asac> ok off for today
<Riddell> doko: which bug is used to track the gutsy-proposed upload of icedtea?
<twb> Hi, is there an ETA for new desktop-i386.iso in http://cdimages.ubuntu.com/releases/hardy/ ?  If so, what is it?  (The alpha images have disappeared.)
<doko> Riddell: #204221
<Riddell> twb: beta was last week
<twb> Riddell: where are the .iso's then?
<twb> I specifically want the casper/ubiquity .iso, not a jigdo one
<twb> *jigdo/d-i
<Riddell> twb: #ubuntu
<twb> I want a *hardy* image.
<twb> I asked #ubuntu+1 and was ignored.
<Riddell> http://www.google.co.uk/search?q=ubuntu+beta
<laga> no daily images anymore?
<mario_limonciell> http://cdimages.ubuntu.com/daily-live/
<laga> great. :)
#ubuntu-devel 2008-03-26
<Ng> jdong: could the tiny fix for #190679 sneak into hardy?
<Amaranth> bug 190679
<ubotu> Launchpad bug 190679 in pm-utils "Most recent package update breaks loading /etc/pm/config.d/*" [Undecided,Confirmed] https://launchpad.net/bugs/190679
 * Ng also generally curious why pm-utils doesn't unload network drivers like acpi-support does
<Ng> e1000 stops my laptop suspending if it's loaded at the time
<dashua> slomo, ping.
<jdong> Ng: talk to Mithrandir, I can't upload it anyway :)
<joshudson> Here's something interesting: the old procedure documentented in https://help.ubuntu.com/community/FeistyUpgradesManual almost works for upgrading fiesty to hardy
<joshudson> I have exact directions if someone can tell me where to post them
<_MMA_> joshudson: Why not edit that page?
<jdong> joshudson: you shouldn't really use the manual upgrade unless the system is already too broken to run the standard upgrader
<ScottK> Please don't
<ScottK> Please don't put instructions on h.u.c on how to do things that are explicitly not supported.
<jdong> https://help.ubuntu.com/community/HardyUpgrades
<joshudson> It draws less bandwidth then trying to upgrade version by version
<jdong> THESE are the ONLY UPGRADE PROCEDURES that should be attempted
<jdong> all others are completely unsupported
<ScottK> !worksforme | joshudson
<ubotu> joshudson: Common Sense: Just because you can, does not mean you should (and especially recommend to others). Think before you do. "Works for me" does not mean it is ok. The latest version of everything is not always useful if you aim for stability. Please see http://geekosophical.net/random/worksforme/
<jdong> you are on your own if something goes wrong before, during, or after the upgrade.
<ScottK> So please don't encourage others to go off the supported path.
<joshudson> all right, I won't
<jdong> there's a *reason* we don't support hopping upgrades. and it's not because we get ad revenue from additional bandwidth to the apt repos
<jdong> though I think that would be a great idea if we do adwords in apt-get and the revenue goes to jdong@ubuntu.com paypal.
<joshudson> lol
<ScottK> joshudson: I don't generally update the approved way and it almost always works for me, but I'd never encourage someone else to take the risks I take.
<jdong> joshudson: then again, ScottK is a core developer and you are pobably an experienced Ubuntu user yourself who isn't afraid to get your hands dirty fixing minor upgrade breakages
<joshudson> I'm not an experienced ubuntu developer
<jdong> joshudson: but others might not be, and from my experience 90% of "upgrades are broken" whining are directly caused by users not following correct upgrade procedures
<_MMA_> jdong: "we don't support hopping upgrades" I haven't had 1 Dapper->Hardy test box work. :P
<joshudson> This was my first upgrade (didn't have a GUI to try the normal procedure)
<orbisvicis> why does ubuntu have a upgrade cycle ... why not just release newer packages as they come?
<jdong>  joshudson if you read HardyUpgrades, there are command line supported upgrade paths too
<ScottK> joshudson: There's a command line option too.
<joshudson> which isn't indexed by google yet btw
<jdong> orbisvicis: because new packages often introduce changes that make them non-backwards-compatible
<lifeless> orbisvicis: many users want stability
<ScottK> orbisvicis: If you want that, just run Debian Unstable.
<lifeless> orbisvicis: others want long term stability
<lifeless> orbisvicis: and some want latest features
<jdong> orbisvicis: a rolling release distro means every time you hit the upgrade button you have NO GUARANTEE that your existing config files or apps will continue to work without tweaking config files, rebuilding custom apps, etc
<lifeless> orbisvicis: so we have releases, long term support releases, and development
<jdong> orbisvicis: think about whether or not an administrator of 70 laptops used by 300 students daily, like me, would want that....
<joshudson> I'm a rather experienced slackware user. If something broke I could probably fix it, unless it was udev.
<orbisvicis> jdong, i hadnt considered your last two statements, but i find stability an invalid argument, as users are often locked into packages with major bugs fixed in newer packages
<jdong> joshudson: slackware teaches you to explore around and fix things
<jdong> orbisvicis: then those bugs should be fixed. Frozen releases do not preclude bugfixes, we just ask bugfixes to be done as bugfixes only
<jdong> orbisvicis: in open source projects, one can choose just to apply changes to the code directly pertinent to the bugs
<jdong> orbisvicis: and as a member of the team that approves such bugfix updates, I encourage everyone to do this
<joshudson> It was also the only non-rpm distro that didn't assume the user had broadband (everything is on 2 cds. I wish the default ubuntu installs did as good a job of picking packages)
<joshudson> at least back when I started
<lifeless> orbisvicis: stability means 'no new bugs', not 'no bugs'
<jdong> orbisvicis: also, Ubuntu Backports can be used to provide new versions of stuff as long as it doesn't horribly break everything. and I am also a part of the team that approves those updates :)
<joshudson> Did any of you every try apt-get install gcc after a fresh ubuntu install and wonder why gcc didn't work?
<ScottK> joshudson: Keep in mind Ubuntu is squeezing into one CD, not two.
<orbisvicis> hmm well i like browsing hardy source (even debian) and pulling packages from them, but why not provide a tool that does this automatically as the dependencies get tedious
<joshudson> good point. Only the second cd on slackware has only kde and tex
<RAOF> joshudson: You mean apt-get? :P
<ScottK> orbisvicis: Because pakcages have to be rebuilt as the toolchain changes.
<joshudson> yeah
<joshudson> It turned out that gcc had some unstated dependency
<ion_> cjwatson: I updated the compcache packaging to use debconf to set the cache size.
<joshudson> apt-get build-dep dash works
<StevenK> It's assumed build-essential (or at least everything it depends on) is installed if you want to build things.
<joshudson> also dpkg needs dependencies of gzip, bzip and tar (found that out when trying to get dpkg working on my slackware box)
<orbisvicis> ScottK, toolchain? bison, gcc, make, etc ?
<orbisvicis> or libraries
<joshudson> ah that's why
<joshudson> build-essential wasn't installed by default and I didn't know of its existance
<StevenK> Because not everyone wants a build environment. :-)
<jdong> orbisvicis: see prevu
<jdong> orbisvicis: it's a one/two command tool for rebuilding source packages from the development release to run on the current release
<joshudson> I've been around too long. I can't even imagine not wanting a build environment
<StevenK> I can. It's called the server behind me. :-)
<joshudson> g
<joshudson> And I'd be screaming bloody murder if I discovered one of my servers didn't have it the first time I tried to compile my maintaince utils
<orbisvicis> jdong, thanks
<joshudson> (an ordinary sysadmin probably would use shell scripts but they barf on unsanatary file names)
<orbisvicis> but i dont understand what ScottK meant though
<jdong> yeah I'd rather *not* provide a build environment on a shell server :)
<jdong> that's one of those "please root me now" invitations
<jdong> might as well just add em to sudoers and save everyone time.
<joshudson> if you are stock ubuntu, uudecode is enough to "root-me-now"
<StevenK> That's news to me.
<jdong> as to me.
<joshudson> besides, some of my tools are still in assembly
<jdong> good luck making it match the regex "/usr/rbin/* rixm" :)
<jdong> ah, I love restricted shells
<ScottK> orbisvicis: Packages are compiles using shared libraries from the packages they build on.  If those shared libraries change, the packages need to be recompiled with the new version to be able to communicate properly.
<joshudson> restricted shell, ewwww
<jdong> what's wrong with a restricted shell? everything here on my machines runs in restricted contexts :)
<jdong> even this irssi I'm typing from
<jdong> 23:33 -!- Irssi: process 0 (uname -a) terminated with return code 126
<joshudson> it doesn't let the user take any advantage of writing so much as the simplest of automation scripts
<jdong> why not? they've got access to perl, python, and their shell for scripting
<StevenK> rbash by default will kick itself out of restricted mode in the shell it spawns to run shell scripts.
<joshudson> are we talking about two different things? I'm talking about rbash and its ilk
<jdong> joshudson: I use apparmor or SELinux to write restricted shell contexts
<joshudson> oh, much better
<orbisvicis> ScottK, i find that minor versions leave me a bit of leeway, and that ubuntu dependencies can take care of the rest (b/c i remove all current packages bottom up)
<jdong> joshudson: the actual shell is usually a bash or zsh type
<joshudson> I'm just accustomed to being able to edit myh .profile
<ScottK> orbisvicis: It often works.  Sometimes it doesn't.
<jdong> orbisvicis: it's not guaranteed to work and I've screwed myself over several times with that assumption in the past
<joshudson> I have no problems with most kinds of security settings on servers
<joshudson> but the fundamental problem that rbash cannot allow the user to have his own .profile is enough to make me detest it
 * orbisvicis testing the limits
<joshudson> (you see if it does, .profile can contain PATH=.$PATH)
<ScottK> orbisvicis: You are quite welcome to do that.  I use most of my Ubuntu machines for $WORK, so I have a different risk tolerance.
<orbisvicis> which brings back to full circle > stability
<jdong> joshudson: I typically don't like to play babysitter with shell accounts as it's always a game favoring the attacker...
<orbisvicis> anyway, anyone notice that linux-image rt doesnt provide CONFIG_PREEMPT_RT
<joshudson> jdong: exactly
<jdong> joshudson: this particular usecase is primarily a SFTP filesharing account on one of my lower-security VMs and giving shell access facilitates the kind of organization work needed to be done
<jdong> joshudson: I've found Apparmor has made it a lot easier for me to quickly define restricted profiles that seem fairly strong to me
<jdong> it'd probably take a kernel-level exploit like the vmsplice one, custom crafted, to break out.
<joshudson> My favorite is the /home in chrootjail trick (I spawn a sshd in the chroot jail with passwd, ping, and tracert as the only setuid binaries in the jail)
<orbisvicis> zcat /proc/config.gz | grep CONFIG_PREEMPT_RT
<orbisvicis> gzip: /proc/config.gz: No such file or directory
<jdong> orbisvicis: we don't build with config.gz in /proc, use the config files in /boot instead
<orbisvicis> gotcha
<orbisvicis> hm i shouldve known that from last time copying the config to rebuild a module
<slangasek> LaserJock: I don't believe we should need the FFe process for edubuntu documentation, no
<slangasek> mario_limonciell: there's been a change to the contents of DVD images, yes - you needed gawk?
<slangasek> mario_limonciell: we can probably get gawk added back, I think - the change is that the DVD no longer ships .debs for all of the supported seed, to make room for a much-expanded livefs with full translations
<slangasek> laga: having a look at the debiancd stuff
<Frederick> folks have anyone here ever used hibernate relational persistence for java in ubuntu? isnt there a package for it?
<twb> I notice that my Ubuntu mirror (and archive.ubuntu.com, I believe) isn't using the rred method to send pdiffs instead of having to resend the whole Packages.gz file with each apt-get update.  Is rred support on a roadmap or something?
<LaserJock> twb: I'm sure there is a spec on that somewhere
<pleaseandthankyo> can i install ubuntu edubun xunbu kubuntu at the same time?
<LaserJock> usually I think so
<pleaseandthankyo> ok installed xubuntu and and goubuntu  on top of edubuntu where are they now? and how do i load them?
<LaserJock> well, for xubuntu you just select Xfce as the Session in the login screen
<LaserJock> and yeah, probably #ubuntu is the place for these questions
<pleaseandthankyo> LaserJock what about go ubuntu
<LaserJock> well, there's not going to really be a difference between it and ubuntu that you will notice
<pleaseandthankyo> how can i load goubuntu?
<Fujitsu> pleaseandthankyo: By asking in #ubuntu.
<nxvl> Fujitsu: heh, good one
<Fujitsu> He'll be back, I'm sure.
<Hobbsee> greetings
<nixternal> greetings to you too
<slomo_> dashua: pong?
<pitti> Good morning
<Hobbsee> pitti!
<asac> slangasek: someone confirmed that iwl3945 works with hidden SSID on my NM branch. however, i saw that benc set the kernel part (scan_capa in iwl*) to fix committed.
<asac> slangasek: unfortunately he didn't drop a comment, so i am not sure if its just the latest iwl driver he committed or if he verified that it has scan_capa
<asac> slangasek: i will try to get in touch with him before uploading the ap_scan ... if it really has scan_capa we should try to not tweak the iwl chipsets
<asac> bug 200950 that is
<ubotu> Launchpad bug 200950 in linux-ubuntu-modules-2.6.24 "[iwl3945] network manager not able to associate to hidden SSID (scan_capa = 0x0)" [High,Fix committed] https://launchpad.net/bugs/200950
<slangasek> asac: I think it's unlikely that your user is testing using that kernel branch...?
<slangasek> oh, n/m
<asac> slangasek: yes. my branch surely worksaround the issue
<asac> but i'd like to not workaround if the kernel module has scan_capa support now
<slangasek> IMHO it would be nice to have the workaround in place immediately since the kernel isn't uploaded yet, and users may not reboot to it immediately after it becomes available
<slangasek> (I expect it'll be another ABI-changing upload)
<asac> agreed, otoh it gets even harder to get feedback on the a nm without the workaround once the kernel modueles are available
<slangasek> suer
<slangasek> sure
<slangasek> if I can figure out how to get into my AP, I could do plenty of testing for iwl3945
<StevenK> With a screwdriver? :-P
 * StevenK hides
<slangasek> actually, I meant to ask you at some point about a problem I have with n-m (or wpa-supplicant directly) not wanting to talk to open APs for me, since, um... about January in London
<asac> slangasek: ok. looking at the code the iwl code tweak will not be used anymore once they have scan_capa support.
<asac> so it should be safe
<slangasek> ok
<asac> ok Ill upload. we haven't received feedback for ndiswrapper and atheros yet, but imo it should be fixed as well
 * slangasek nods
<asac> slangasek:  dpkg-genchanges -S -si >../firefox_2.0.0.13+0nobinonly-1ubuntu0.7.4_source.changes
<asac> dpkg-genchanges: including full source code in upload
<asac> looks bogus now ;) ... is noone else seeing this?
<slangasek> I don't use -si
<slangasek> isn't -si supposed to be implicit?
<asac> same happens without -si
<slangasek> I also don't ever run dpkg-genchanges by hand
<asac> slangasek: i don't do that too
<asac> i just see that during build
<StevenK> -si is implicit, according to the man page
<asac> same happens for debuis and dpkg-buildpackage
<slangasek> well, I did two uploads today and I didn't notice problems with either of them
<asac> strange
<slangasek> but maybe that just means I didn't *notice* the problems :)
<asac> yeah. i think soyus doesn't complain if you include an already existing orig.tar
<tjaalton> asac: hey, did you try to build the nm-0.7 branch?
<asac> tjaalton: read the branch comment :)
<tjaalton> asac: I know, but debuild failed much earlier :)
<tjaalton> it failed because there's no system-settings/plugins ifcfg
<tjaalton> +/
<asac> tjaalton: oh
<asac> i forgot to push the last revision i guess :-P
<tjaalton> asac: hehe :)
<StevenK> pitti: Oh, could you poke at NBS? There's a whole bunch of packages there that I thought didn't exist.
<asac> tjaalton: ok pushing right now
<pitti> StevenK: yes, I should get it cleaned up
<tjaalton> asac: great, thanks
<asac> tjaalton: revno 2789
<pitti> keescook, jdstrand: do we have a wiki page about "static code copies"? We are currently discussing main promotion of libarchive, which has the BSD versions of tar and cpio code inside
<seb128> Mithrandir, lool: could one of you look at bug ##197145?
<pitti> keescook, jdstrand: in intrepid we might switch to bsd's tar which uses libarchive, but too late for hardy
<seb128> bug #197145
<ubotu> Launchpad bug 197145 in bluez-gnome "REGRESSION [hardy] nautilus-sendto not compatible with bluetooth-sendto" [Low,Confirmed] https://launchpad.net/bugs/197145
<tjaalton> asac: yeah, built fine. now the same for nm-applet?-)
<slangasek> asac:  dpkg-genchanges -S >../directory-administrator_1.7.1-1ubuntu1_source.changes
<slangasek> dpkg-genchanges: not including original source code in upload
<asac> hmm
<asac> tjaalton: how hard is applet broken?
<tjaalton> asac: I haven't tried to build it, but assumed it needs an update as well
<asac> tjaalton: no i ment ... how broken is the applet in my ppa with the new NM?
<asac> (i know that probably all the great new features are missing ... just curious if its enough to verify that NM at least works :))
<pitti> cjwatson, evand: hm, on the current hardy daily desktop I get "the ext3 fs creation on /dev/sda1 failed"; yesterday I uploaded a new e2fsprogs, which might be the reason for that; however, /dev/sda1 does not even exist
<tjaalton> asac: ok, I'l try it first
<Fujitsu> Can we sync things from testing?
<pitti> cjwatson, evand: I completely repartitioned the device, using 'New label'; does that need something like an udevtrigger?
<pitti> hm, no, udevadm trigger doesn't help
<asac> Fujitsu: a downgrade sync?
<asac> :)
<pitti> StevenK: NBS cleaned
<Fujitsu> asac: No, a sync of a new upstream version, but there's a newer one that I don't want in sid.
<slangasek> Fujitsu: I'm not sure what that would do when auto-syncing came back on after the release
<slangasek> probably pull from unstable again
<Fujitsu> slangasek: That's fine.
<slangasek> I also suspect that a fake-sync is easier
<Fujitsu> With a build1 version, or a faked .changes?
<pitti> Fujitsu: http://people.ubuntu.com/~pitti/scripts/syncpackage
<Fujitsu> pitti: That's what I meant by faked .changes, yep.
<pitti> Fujitsu: you can use that; please do check the generated .changes, though
<tjaalton> asac: the old nm-applet snapshot fails to start: undefined symbol: nm_connection_settings_get_type
<slangasek> bryyce: <ahem> how's that fix for the spontaneous intel video crashes coming along? :-)
<Fujitsu> Spontaneous Intel video crashes?
<Fujitsu> Mine's been more stable than ever over the past couple of weeks.
<soren> I haven't had it crash on me for a while, too.
<slangasek> I have a bug with mine that only showed up recently; just had the third crash in as many weeks
<Fujitsu> Up until about 3 weeks ago, I had the occasional Compiz hang, but it's all good now.
<bryyce> slangasek: it's still waiting on someone to do git bisecting.  Which of course is a PITA since the bug occurs so sporadically
<slangasek> bah :/
<bryyce> "X crashes randomly" bugs are the bane of my existence
<soren> Oh, mine didn't just hang. It crashed. And X wouldn't start again.
<Fujitsu> soren: Ah, I had those in the first couple of months of Hardy.
<slangasek> soren: yes, that's what I have: "FatalError re-entered, aborting" -> "Existing errors found in hardware state"
<pitti> cjwatson, evand: hm, after rebooting the desktop CD again, the new partitions appear in /dev and all is well; hmm
<bryyce> slangasek: if it happens and you can ssh in and attach gdb and get a full backtrace, that may help.  However sounds like upstream is insisting on doing bisecting to find the issue.
<slangasek> bryyce: but once it happens, the X server is dead, I would have to attach with gdb beforehand...?
<slangasek> I've never done a git bisect before, can you give me a pointer to the right repo and a cheat sheet for running the bisect?
<bryyce> if its crashing to the command line, yeah.  In other cases where it freezes or hangs, you can often ssh in to get a backtrace.
<slangasek> yeah, this is the X server aborting altogether
<slangasek> and only kinda-sorta crashing to the commandline, since it leaves the video in an unusable state which requires a reboot
<bryyce> man git-bisect  has the best docs on it.  the repo can be checked out from gitweb.freedesktop.org
<bryyce> hrm
<tjaalton> might need some drm changes in the kernel too
<slangasek> I'm git-stupid, giving me more explicit instructions on checking out would help
<bryyce> slangasek: ok stay tuned, I'll see what I can come up with to make the process simpler.  Give me a couple days.
<slangasek> ok, cheers
<tjaalton> slangasek: if you have older kernels handy you could try booting -8 and see if it crashes the same way
<slangasek> I don't
<tjaalton> bummer
<slangasek> to the extent that it correlates with any change on my system, though, it seems to correlate with me wiping out my old xorg.conf and regenerating a clean one
<slangasek> OTOH, maybe I did that after it crashed the first time :-P
<bryyce> well, some of the stuff we've fiddled with recently includes setting "greedy" migration mode for EXA, turning EXA on by default, and adding a few minor patches
<tjaalton> we've had 2.2.1 for a month now
<tjaalton> and EXA has been the default since November :)
<bryyce> well, I mean in the sense that if he had an old xorg.conf that was setting XAA, then our EXA by default might have kicked in when he wiped out his old xorg.conf
<tjaalton> yeah, sure
<slangasek> bryyce: the old xorg.conf didn't set XAA explicitly; the only difference I can see is loading GLcore and v4l modules
<bryyce> hmm, yeah none of that should matter
<zdzichuBG> bryyce: textured video is still disabled?
<\sh> moins
<bryyce> zdzichuBG: I think it depends on the driver.  We're not forcing it to be disabled, so right now it's whatever upstream thinks best.
<\sh> someone forgot to sync bug #205737 (wireshark 0.99.8) this morning or yesterday evening...could this be synced now?
<ubotu> Launchpad bug 205737 in wireshark "[FFe] wireshark 0.99.8" [Wishlist,Confirmed] https://launchpad.net/bugs/205737
<tjaalton> zdzichuBG, bryyce: it's disabled for intel because of the overlay patch
<tjaalton> now it doesn't melt the CPU
<bryyce> tjaalton: ah, what about -ati?
<tjaalton> bryyce: I think support for textured video was recently added upstream
<davmor2> evand: I've found a dodgy issue with Wubi.  Not sure how to report it though.  Basically it won't install on my windows box if the only cd drive is a cd-rw.  Once I put in my old dvd-rw it worked flawlessly.  How do you report that?
<tjaalton> how do I finish a bzr merge after resolving a conflict?
<lool> bzr commit
<Mithrandir> bzr resolve then bzr commit
<lool> (But do bzr resolve the conflicted files=
<tjaalton> yes, bzr resolve done, commit next, thanks
<seb128> siretart: could you add "x-content/video-dvd;x-content/video-vcd;x-content/video-svcd;" to gxine mimetype list if you get the update approval?
<seb128> siretart: that's required to get it listed as a player for dvd and video cds in nautilus
<siretart> I'll add that to the bugreprt. ok
<seb128> siretart: if you don't I'll upload the change to hardy
<seb128> siretart: I mean if you don't get the approval, because we want this change anyway ;-)
<seb128> siretart: thanks!
<siretart> seb128: well, you could do the upload anyawys, and I'll merge it for the update, if you prefer
<seb128> siretart: ok, will do that then
<seb128> siretart: so we are sure the change is there
<seb128> siretart: looking at the diff you attached to the bug you likely want to add those to the new txt
<siretart> 'new txt'?
<seb128> siretart: mime.default, I was not sure of the name
<seb128> slangasek: could you approve bug #204563? That likely makes sense since the ubuntu documentation recommends installing gxine for dvd playing we want it working correctly
<ubotu> Launchpad bug 204563 in gxine "Update to gxine 0.5.901-1" [Undecided,New] https://launchpad.net/bugs/204563
<seb128> that's universe thing though, not sure who is supposed to approve those
<\sh> seb128: motu-realse :)
<\sh> motu-release even
<seb128> \sh: could you get them to approve the request?
<siretart> seb128: ah, sure.
<seb128> Hobbsee, TheMuso: ^
 * TheMuso takes a peak.
<seb128> TheMuso: thanks
<\sh> seb128: motu-release is subscribed, so I think when scottk, hobbsee or sistpoty have time, they'll deal with it
<seb128> \sh: trying to boost that, it's waiting for several days and we want to get it testing
<seb128> that's the recommended ubuntu dvd playing software
<seb128> not some random universe wishlist
<\sh> siretart: is sistpoty on your area? :)
<\sh> s/on/in/
<seb128> how many approvals do you need?
<seb128> TheMuso is looking at it now
<\sh> seb128: 2 at least..after that siretart could upload
<\sh> Hobbsee, ScottK: around?
 * TheMuso approves.
<\sh> seb128: could you do me a favour and sync wireshark 0.99.8 from sid (approval bug #205737)
<TheMuso> Just need another MOTU release person to look at it.
<ubotu> Launchpad bug 205737 in wireshark "[FFe] wireshark 0.99.8" [Wishlist,Confirmed] https://launchpad.net/bugs/205737
<seb128> TheMuso: cool
<\sh> I wonder where norsetto hides?
<seb128> TheMuso: btw while you are around, are the lpi changes something we want for hardy, are they blocked on something? you didn't reply to the comments I think
<TheMuso> seb128: I've been told they are wanted for hardy. I haven't replied because I've been working on it, and was actually going to reply to the emails that were sent. My updated changes are in the same branch as my original changes were found.
<seb128> TheMuso: ok, excellent
<ogra_cmpcng> seb128, do we plan to ship cheese in the default ?
<seb128> ogra_cmpcng: no, there has been not demand for that, we don't have extra cd space and that's late for a such change, why?
<ogra_cmpcng> i had complains from intel, the new classmate has a webcam built in and they apparently needed to run cheese as root to get it going (just installing it here, it works fine with ekiga)
<seb128> \sh: synced
<seb128> ogra_cmpcng: ask lool about it maybe, I think the mobile team is using it
<\sh> seb128: rthx
<ogra_cmpcng> seb128, works fine here out of the box, no idea what problems intel has ...
<seb128> ogra_cmpcng: maybe the video group has not rights on the device or something
<seb128> ogra_cmpcng: or their user is not in the group required
<ogra_cmpcng> there is only ione user in the cmpc installer and that is in the video group by default (i installed this testmachine about 10min ago and use teh default user)
<ogra_cmpcng> they must have done something wonky
<\sh> siretart: you can upload gxine .. it's approved
<siretart> \sh: after lunch. :)
<\sh> siretart: ok :)
<seb128> are non modified conffiles supposed to be removed automatically on upgrade if the package stop shipping those?
<sjoerd> no
<seb128> hum, suck
<sjoerd> http://www.dpkg.org/dpkg/ConffileHandling :)
<seb128> slomo_: ^ we need to make nautilus-cd-burner 2.22 remove mapping-modules.conf on upgrade
<seb128> sjoerd: thanks
<slomo_> hrm
<slomo_> does it break something if it's still there?
<seb128> slomo_: it displays ugly warning when starting an application using gnome-vfs
<slomo_> great :)
<seb128> slomo_: try sound-juicer
<slomo_> i hate conffiles
<seb128> sjoerd: and do you know if there is something special to do when moving conffiles between source and binary packages?
<seb128> I guess there is
<sjoerd> I think just the proper conflicts/replace rules, but i'm not sure
<seb128> the capplets-data xrdb things have been moved to gnome-settings-daemon
<\sh> damn...how do you script nowadays firefox to be placed at a special location on your screen...
<seb128> ok, so that one is correct ;-)
<tjaalton> how often are launchpad vcs-imports updated?
<tjaalton> nm-applet is 11 days old, that's why I'm asking..
<james_w> tjaalton: #launchpad should know better
<tjaalton> james_w: k, I'll try ther
<tjaalton> +e
<\sh> does anyone has a clue to do for getting instanbul actually running? I mean it stops working directly when you want to start recording
<Hobbsee> seb128: looks confirmed by now
<seb128> Hobbsee: right, thanks
<seb128> siretart: ok, you got the gxine approval, I didn't upload the changes since that was quick and there no point to upload things and then merge those to a new version
<siretart> seb128: ok. will upload with your change merged in
<seb128> siretart: thanks
<jdstrand> hi pitti!
<jdstrand> pitti: I don't know of a document about our policy on embedded code.  it's obviously discouraged generally, but..
<jdstrand> pitti: there is embedded-code-copies from debian's 'secure-testing', and it's not listed there, so I'll update it
<pitti> jdstrand: thank you
<laga> slangasek: thanks for looking at the debiancd stuff. did you merge it?
<soren> pitti: Oooh.. I just saw the usplash fsck thing for the first time. Neat.
<pitti> soren: :)
<pitti> soren: I just uploaded a fix-it-harder version of it three seconds ago
<Fujitsu> usplash turns off for me just after initramfs :(
<soren> pitti: Well, I didn't need to cancel it, so it worked as expected for me :)
<laga> slangasek: yay, you did. thanks a lot.
<laga> slangasek: oh, you did not. i need to wake up.
<mjg59> pitti: #201037 - we probably need network module unloading/loading in pm-utils
<ogra_cmpcng> mjg59, hey ... i got a new classmate here, having an issue with the brightness on resume ... do you know any way i can trigger a brightness up event on a i915 (works all fine but io have to hit a brightness key to get backlight after resume)
<mjg59> ogra_cmpcng: Which kernel version?
<ogra_cmpcng> yesterdays ... let me look for the exact version
<ogra_cmpcng> 2.6.24-12-generic
<mjg59> ogra_cmpcng: Ok. How are you suspending?
<ogra_cmpcng> i dont use any intel xserver (using vesa to get the panning mode) though
<mjg59> Ugh.
<ogra_cmpcng> mjg59, gpm
<mjg59> Please try with the intel x server
<ogra_cmpcng> i cant
<mjg59> Please try with the intel x server
<ogra_cmpcng> i mean iu can for a test
<ogra_cmpcng> but not constantly (no panning in intel, i810 which does panning eats half of my ram ...)
<pitti> mjg59: ah, indeed; that should become a /etc/pm/sleep.d/ script, I suppose?
<mjg59> pitti: /usr/share, ideally
<pitti> ah, right
<ogra_cmpcng> mjg59, ok, intel works, anything i can hack up to get vesa do the same ?
<mjg59> ogra_cmpcng: Not really, no
<ogra_cmpcng> hmm
<ogra_cmpcng> how does gpm do the brightness switching without having a sysfs socket or anything in proc ... i only need a single trigger it seems ... that could well go into a pm utils hook
 * ogra_cmpcng goes to look at gpm code
<mjg59> ogra_cmpcng: Is there anything in /sys/class/backlight?
<ogra_cmpcng> nope
<mjg59> Then gpm shouldn't be able to do any brightness control
<ogra_cmpcng> thats my prob else i'd just echo something to it :)
<ogra_cmpcng> hmm
<ogra_cmpcng> changing power changes backlight ... i wonder if thats bios based then
<mjg59> Yes
<ogra_cmpcng> vbetool vbestate save/restore seems to get me something but that seems way to hackish
<mjg59> That should be happening by default in any case
<mjg59> Oh, wait, it won't on i915
<evand> davmor2: where does it fail?
<mjg59> Hm. It sounds like the DRM code isn't restoring the backlight register.
<mjg59> I'll try to find out about that
<ogra_cmpcng> feel free to use me for tests if you have ideas :)
<davmor2> evand: It gets to the end of creating image then pops up a message saying "unable to access cd"
<asac> slangasek: on bug 194459 - the themes package should go imo.
<ubotu> Launchpad bug 194459 in firefox-themes-ubuntu "FTBFS in latest archive rebuild test" [High,Confirmed] https://launchpad.net/bugs/194459
<davmor2> evand: now though it gets past that point no problems and carries on the the first restart now prompt and then carries on installing.
<asac> slangasek: what does "classic chrome theme" mean in your words?
<evand> davmor2: is this drive otherwise reliable?
<davmor2> evand: It's the one I've done all the installs on for the last 6 months with no issues.  However like I say once I installed the dvd-rw all the issues went away I've installed 2 versions of Wubi since without issue, where as with the one drive in it would install any.
<davmor2> s/would/wouldn't
<evand> davmor2: hrm, there should be a Wubi-revXXX.log file in %TEMP%.  Can you attach that to a new bug report against the Wubi project, the description you gave me, and any additional information you can provide?
<evand> you'll probably want to delete the version that's there first, then run it again with the offending drive.
<evand> the version of the log, that is
<davmor2> evand: I'll need to strip the machine of a drive but it shouldn't be an issue but I'll have to do it again latter.  (mind you I haven't tried wubi in the old drive since I installed the new one so I'll try that first)
<davmor2> evand:  Also out of curiosity why doesn't wubi include M-A?  It seems odd that installing in a windows environment and then have to manually do your bookmarks etc.
<evand> ok, thanks
<evand> davmor2: it does, but there are likely bugs in m-a.
<evand> it doesn't pull in any folders though.
<davmor2> evand: it didn't pull anything at all no email no bookmarks nothing.
<evand> hrm, I'll take a look at that today
<davmor2> evand: no probs this is the cd a day before beta if you want I can update to yesterdays and try again if it's an issue you have remedied in M-A
<evand> nope, that shouldn't be necessary -- I don't believe it would have been remedied by any uploads I've made since then.
<davmor2> evand: no probs I'll try wubi from my old cd-rw and see if the issue still exists and if not I will remove the dvd-rw and try again and post the log file etc to a new bug for you.  Would it help to have a copy of lshw/lspci too
<evand> davmor2: it can't hurt.  It might help finding duplicates, should we start to get reports of similar issues.
<davmor2> evand: np's I'll do that latter though I got to go off for bit.
<evand> ok, thanks
<jdstrand> evand: hi!
<jdstrand> evand: can you take a look at bug #206030
<ubotu> Launchpad bug 206030 in ubuntu "cannot activate ufw in live mode" [Undecided,New] https://launchpad.net/bugs/206030
<jdstrand> evand: I was asked to bring this to your attention since colin is away
<davmor2> evand: Wubi crashed out at the same point I'll get the log files in a report asap
<evand> jdstrand: looking now
<evand> davmor2: yikes, thanks
<jdstrand> evand: the reporter is obviously talking about it in reference to ufw, but the problem is obviously that '/' is world writable on the live cd
<jdstrand> (can I say obviously more?)
<jdstrand> (obviously so...)
<davmor2> jdstrand: don't you need to reboot to get ufw up?
<jdstrand> davmor2: shouldn't
<jdstrand> davmor2: 'sudo ufw enable'
<davmor2> jdstrand: yes then it tells you that it will be enabled the next time you restart
<jdstrand> davmor2: it is disabled by default
<jdstrand> davmor2:
<jdstrand> $ sudo ufw enable
<jdstrand> Firewall started and enabled on system startup
<jdstrand> $ sudo ufw status
<jdstrand> Firewall loaded
<davmor2> our right me reading it wrong sorry
<cody-somerville> slangasek, the daily builds for Xubuntu are frozen, right?
<jdstrand> pitti: do you have any test scripts for cups? (I am preparing a security update)
<jdstrand> pitti: didn't see anything in qa-regression-testing and didn't know if you had even something hacky laying around
<ogra_cmpcng> wow, camporama seem not to work with anything here, telling me it cant access /dev/video0 ... i wonder why cheese works fine
<ogra_cmpcng> *camorama
<ogra_cmpcng> not even running it as root helps ... weird
<Laney> Hmm, why is bash-completion no longer installed by default in Hardy?
<pitti> jdstrand: I just recently fixed the upstream test suite to work at all
<pitti> jdstrand: did you see my patch sent to security@ubuntu/debian?
<pitti> jdstrand: otherwise my usual test is just to detect and configure a printer, print something, and check browsing/exporting
<_MMA_> SANE in Hardy is 1.0.19 correct?
<jdstrand> pitti: ok (yes I saw your email-- thanks!)
<tseliot> _MMA: yes, it's Version: 1.0.19-1ubuntu2
<_MMA_> Thnx
<davmor2> evand: bug 207137 I will update with lshw/lspci once ubuntu finishes installing on the system.
<ubotu> Launchpad bug 207137 in wubi "Wubi fails to install from my cd-rw but does from my dvd-rw" [Undecided,New] https://launchpad.net/bugs/207137
<evand> thanks, do note that ago has already commented on the bug.
<pitti> slangasek: WDYT about bug 196021? this drives me up the wall, too, and I agree that it is a regression, so I'd like to add back bash-completion to ubuntu-standard recommends
<ubotu> Launchpad bug 196021 in ubuntu-meta "include bash-completion by default in hardy" [Wishlist,Confirmed] https://launchpad.net/bugs/196021
<ogra_cmpc> pitti, i think colin already agreed on that in a recent platform meeting ... we had that topic some time in the recent past
<pitti> ah, fine
<tjaalton> ubuntu-desktop no longer Recommends oo.o but calc/writer/impress. I guess this was intentional?
<tjaalton> for instance oo.o-java-common is not installed due to that
<mario_limonciell> slangasek, yes we need gawk on the DVD
<mario_limonciell> slangasek, so if you can add that back for the next time it's generated, that would be most appreciated
 * dtrask is away: Lunch time...leave a msg
 * \sh wonders how the kernel sound stuff determines the name of a sound device...most C-media usb headsets are defaulting to "default" as name...
<\sh> crimsun: btw...I just got pulseaudio+flash to work..strange phenomenon is: you have to set the default output for the flash playback stream to the usb headset via padevchooser/volume manager after that it remembers this setting and works without problems
<broonie> \sh: It's propagated up from the driver.
<broonie> \sh: Though user space doesn't generally look *directly* at the kernel output.
<\sh> broonie: hmm...
<broonie> You can see the kernel idea in /proc/asound/cards
<\sh> broonie: which means: id + name ... i wonder what happens when two of the very same sound devices are attached and both have the same names attached to it...
<\sh> asoundconf is not very friendly for this case ;)
<\sh> what I'm trying now is to determine the right setting to capture sound for recordmydesktop...
<\sh> what setting is the right one to tell rmd that he should use pulseaudio ;)
<seb128> mdke: is anything in the ubuntu documentation mentioning gnome-cd or cddb-slave2-properties? because we want to drop those
<pitti> Riddell: can you replicate bug 206169? (The "Decoding unicode is not supported" thingy)
<ubotu> Launchpad bug 206169 in jockey "Jockey does not install anything, help button does nothing" [Undecided,New] https://launchpad.net/bugs/206169
<slangasek> http://bazaar.launchpad.net/~mythbuntu/debian-cd/mythbuntu-debiancd
<laga> slangasek: yeah?
<slangasek> laga: right, looking at it now ;)
<slangasek> asac: "classic chrome theme" are my words, aren't they? :-)  It means that firefox-themes-ubuntu needs to be able to find classic.jar for unpacking...
<Riddell> pitti: I don't have any hardware to test it on
<asac> slangasek: ah. ok thought you referred to some kind of special theme (like the old ffox 2 theme)
<asac> slangasek: the package should be dropped
<Riddell> the help button does nothing indeed
<asac> we don't need that anymore. firefox already uses system theme
<asac> slangasek: i can upload with depends on firefox-2 though (thought i already did that though)
 * dtrask-away is away: I'm back!
 * dtrask-away is back.
<\sh> pitti: when I set asoundconf set-pulse...all alsa capable apps should use PA via alsa backend, right?
<slangasek> laga: mythbuntu changes pushed
<laga> slangasek: thanks
<ogra_cmpc> \sh, yes if you point them to use alsa
<\sh> ogra_cmpc: recordmydesktop uses hw:0,0 as default..I wonder if this is correct...
<ogra_cmpc> unlikely
<\sh> so what setting could it be?
<ogra_cmpc> look in the selector of the volume control ... it should tell you what to use
<slangasek> cody-somerville: yes, Xubuntu daily builds are frozen...
<cody-somerville> slangasek, thanks
<\sh> ogra_cmpc: front:2 ?
<cody-somerville> slangasek, testing seems to be picking up for those two images. I imagine we'll be able to make the release by Friday at the latest.
<pitti> \sh: no idea what that does, sorry
<cody-somerville> slangasek, If not, we'll just forget about it
<\sh> ogra_cmpc: well, it tells me that it's front:2 but somehow it doesn't work..let's see if I can redirect all sound to front:0
<slangasek> pitti: I've never been a heavy bash-completion user, so I don't have a strong opinion... I remember cjwatson being opposed to it though
<slangasek> asac: why is it that it should be dropped, then?  is the existing firefox theme already ubuntuized...?
<slangasek> ah, so you said, ok
<asac> slangasek: you don't use firefox 3?
<seb128> mario_limonciell: do you really care about having the mythv totem plugin in the default installation?
<asac> slangasek: anyway ... i upload now (for firefox-2)
<seb128> that things add a depends on the mysqlclient lib
<slangasek> asac: a) no, b) I probably wouldn't know the difference between the themes anyway since when I do use it I only use it from the packages :)
<slangasek> asac: ok, thanks for the upload then :)
<asac> slangasek: ok its up. if its still in main feel free to demote it
<slangasek> ok, will do
<seb128> which is around 4meg CD space
 * seb128 considers doing a totem-plugins-extra and move that out of the space to win some megabytes
<seb128> s/space/cd
<mario_limonciell> seb128, that's fine with me
<seb128> ok
<mario_limonciell> space on that disk is more important imo
<seb128> slangasek: ^ will give you 5 extra megas on the desktop cd
 * slangasek bounces up and down gleefully
<slangasek> :)
<seb128> ;-)
<mario_limonciell> slangasek, so re bash-completion it was a chosen decision to remove it, not accidental then?
<slangasek> mario_limonciell: I don't know; doko's the person to ask
<slangasek> oh very nice, I notice my panel clock is displaying UTC after the last reboot... so I click on it to change it, the panel crashes and respawns with the right time
<slangasek> :P
<ScottK2> Feature: Enhanced automation.
<mario_limonciell> that reminds me i wanted to ask doko about bug 103929 too.
<ubotu> Launchpad bug 103929 in bash "Bash prompt string looks for xterm-color, gnome terminal identifies as xterm" [Wishlist,In progress] https://launchpad.net/bugs/103929
<mario_limonciell> been in progress since sept or so :)
<Ng> while we're asking about bash bugs, why is our PROMPT_COMMAND stuff commented out? :)
<slangasek> mario_limonciell: hmm, so I can't actually see where gawk was being included on the DVD image before
<mario_limonciell> slangasek, yeah I didn't either.  was it a fluke that it was somehow coming as a recommends to gawk-doc or somethign?
<slangasek> gawk isn't seeded directly anywhere, nor was it before the addition of the dvd seed; and it's only a build-dep of various packages
<slangasek> gawk-doc doesn't recommend it either, I looked for that
<slangasek> but obviously it makes no sense to ship gawk-doc on there *without* gawk...
<mario_limonciell> :)
<mario_limonciell> Is quilt still on the disk?  It was coming before to satisfy <awk> for a quilt depend I thought
<slangasek> er, there's really no reason it should've done that, awk is part of essential and should always be satisfied by mawk long before gawk is looked at
<slangasek> sorry, awk is "virtually essential" - it's a virtual package, depended on by base-files
<slangasek> pitti: is elisa still on your radar, btw?
<laga> bah, use mythtv ;)
<mario_limonciell> slangasek, take a look at http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/ubuntu/hardy/dvd-20080318.log
<mario_limonciell> "* Chose gawk out of awk to satisfy quilt"
<pitti> slangasek: what's still wrong with it?
<slangasek> mario_limonciell: yep, a peek at the gutsy seed shows it being pulled into main via quilt - because quilt used to depend explicitly on gawk
<pitti> slangasek: it's gone from http://people.ubuntu.com/~ubuntu-archive/testing/hardy_probs.html since yesterday
<slangasek> pitti: oh, ok :)
<slangasek> pitti: I was just looking at the CD report, which obviously lags
<pitti> slangasek: ah, if you mean today's DVD report, it's probably just lagging behind
<pitti> :)
<slangasek> mario_limonciell: so the question is... what pulled in quilt?
<slangasek> pitti: is there anything different about "supported" that would have caused build-dependencies to also be pulled onto the DVDs?
<mario_limonciell> installer dependencies it claims?  So maybe one of the udebs that lived in ubiquity
<slangasek> er?
<mario_limonciell> but then again that is a lot of -dev packages that were pulled.  you're right that it was probably build depends doing it
<pitti> slangasek: not that I know of
<slangasek> well, I don't think it's a loss to have build-depends off of there in general
<tsmithe> lamont, the rebuild of pdftk failed with an ICE in the same place
<tsmithe> (on hppa)
<lamont> unsurprising
<lamont> steps are (1) find someone to fix  java/hppa. (2) profit
<lamont> I'm still stuck on #1
<ogra_cmpc> you dont look close enough
<ogra_cmpc> (given that hppa devs are rare you likely have to look *very* close)
<doko> mario_limonciell, slangasek: thing is that bash-completion is unmaintained for about two years by upstream; however last week I was sent the upstream repository, and now somebody is trying to set up a project ib alioth to coordinate new upstream work. I'lll look to get it included on the CD without depending on it (just seeding it).
<doko> tsmithe, lamont: the pdftk build system should be rewritten
<tsmithe> doko, uhuh, but would that fix the ICE?
<ogra_cmpc> doko, thats like saying hppa should be re-soldered :P
<doko> tsmithe: I think so; just compile the code to byte code, and then, if needed, from byte-code to native code. the direct compilation from source to native is known to have problems
<doko> ogra_cmpc: not really, after you look at pdftk's build system
<ogra_cmpc> yeah was rather bad joking ...
<zul> can I get a giveback for nut?
 * Seveas gives zul a packet of peanuts
<zul> seb128: hi can you give back nut? thanks
<pitti> zul: he can't, but I can; done
<zul> pitti: thanks..
<pitti> zul: erm, wait
<pitti> zul: first, nothing to give back; it hasn't started to build yet
<pitti> zul: second, the most current version is 2.2.1-2.1ubuntu4~ppa1
<pitti> that might have been a wrong upload?
<zul> pitti: ah can you reject that one then
<zul> yes it was
<pitti> no, uploads can't be rejected unless a distro is frozen
<pitti> you have to supersede it with a newer upload
<zul> ok
<slangasek> seb128: does bug #203956 get resolved if we nuke shares-admin?
<ubotu> Launchpad bug 203956 in gnome-system-tools "Sharing the 'public' folder causes buggy behaviour " [Medium,Confirmed] https://launchpad.net/bugs/203956
<slangasek> (references policykit, which isn't involved with net usershare)
<seb128> slangasek: yes
<slangasek> seb128: should I assign it to you?  or to me, maybe?
<ScottK2> I know which one of those I would vote for if I was seb128.
<seb128> slangasek: assign it to me if you want, I'll close it when I remove shares-admin from gnome-system-tools later today or tomorrow
<slangasek> ok
<bryce> whoa, it's snowing.  snow in March in Oregon?
<Spads> We had snow on Easter in London.
<LaserJock> bryce: when did that start?
<slangasek> bryce: not here, just rain
<slangasek> though I got hailed on earlier in March
<bryce> couple minutes ago
<bryce> it's sort of rainy snow, not sticking of course
<LaserJock> bryce: it's just windy down here, but it might rain/snow soon
<slangasek> oh, LaserJock is part of the Oregon cabal too?
<LaserJock> no, I'm south
<LaserJock> in Reno
<slangasek> oh :)
<LaserJock> but the weather is similar-ish
<bryce> wow, now it's normal snow, with big huge flakes
<bryce> yes I'm easily amused
<_MMA_> Atlanta got flurries a couple of days ago. Nuts.
<saivann> mjg59: May-I abuse of your knowledge and ask for your opinion on what viable solution can be used for bug 188764?
<ubotu> Launchpad bug 188764 in usplash "[hardy]640x480 usplash on a 1024x768 LCD laptop" [High,Confirmed] https://launchpad.net/bugs/188764
<stgraber> here we got something like 40cm of snow on Friday and like 10cm yesterday morning
<LaserJock> other than the use of cm, that's impressive! ;-)
<mjg59> saivann: I have no sensible solution to this off-hand, other than doing DDC probing in usplas
<mjg59> h
<mjg59> But no, the postinst can't depend on a running X. For a start, it's running as root and not the X user
<saivann> mjg59 : Is that a possible solution for Hardy? Or time is missing
<saivann> mjg59 : I was not really convinced by this idea too
<mjg59> saivann: The alternative is for ubiquity to write the values
<saivann> mjg59 : I'm not a developer but I have a basic knowledge with packaging, may I help on this task?
<_MMA_> mjg59: Which wouldn't help in Alt disk installations. :(
<saivann> mjg59 : ubiquity, would means that good usplash resolution would only be set in the LiveCD
<mjg59> Yes, it would mean that
<cody-somerville> There is an Xubuntu community meeting taking place in #ubuntu-meeting in roughly 15 minutes. If you're interested in getting involved in Xubuntu or are interested in the future direction of the project, please feel free to join us. For background information, please see: https://lists.ubuntu.com/archives/xubuntu-devel/2008-March/005242.html
<mjg59> saivann: No, if DDC stuff is being done then it should be integrated into usplash directly
<mjg59> So it can check resolution at runtime
<slangasek> stgraber: but er, don't you live in the mountains? :)
<saivann> mjg59 : Since you know usplash very well, do you think that you can take this task? It would also fix bug 158048
<ubotu> Launchpad bug 158048 in usplash "Automatic usplash resolution (no static configuration file)" [Wishlist,New] https://launchpad.net/bugs/158048
<mjg59> saivann: Potentially, but I can't promise it
<mjg59> slangasek: What do you think?
<_MMA_> I'd personally pay someone to fix Usplash on widescreen resolutions.
<mjg59> _MMA_: Impossible
<_MMA_> :P
<mjg59> VESA doesn't include widescreen modes
<mjg59> Once we have kernel modesetting, sure
<saivann> mjg59 : of course, thanks. Can I do something else to help that bug report?
<stgraber> slangasek: switzerland is not only made of mountains you know :)
<mjg59> saivann: Not really, other tan to point out that the proposed solution won't work :)
<slangasek> mjg59: what do I think in reference to usplash?
<saivann> mjg59 : Thanks :)
<slangasek> stgraber: s/mountains/higher elevation/ ;)
<mjg59> slangasek: In reference to #188764
<stgraber> slangasek: well, 500m is not that high from my point of view :)
<LaserJock> has anybody screen been going weird the last couple days while hibernating and resuming?
<LaserJock> mine turned neon green
<LaserJock> and I don't get any more usplash
<mjg59> LaserJock: There's a proposed patch to fix that
<LaserJock> mjg59: ok, just wondered if it was me
<slangasek> asac: bug #201127 is just removing the .desktop file, right?
<ubotu> Launchpad bug 201127 in network-manager "(Hardy) please remove Network Manager Editor from Internet and Preferences" [Medium,Confirmed] https://launchpad.net/bugs/201127
<slangasek> mjg59: I think that I should let you tell me what I should think
<saivann> mjg59 : Wait, can-we simply ddcprobe in the postinst?
<mjg59> saivann: Not safely, since X is running
<saivann> mjg59 : Ah ok
<slangasek> stgraber: yes, my elevation here is 60m. :)
<mjg59> saivann: Actually, no, ddcprobe is a bad idea. Most laptops don't do DDC.
<saivann> mjg59 : ok
<saivann> mjg59 : Anyway, thanks for your work on this :)
<mjg59> saivann: Without the knowledge X has, I don't think there's anything we can do to fix this
<mjg59> saivann: So the closest to a solution right now will still be writing the file from ubiquity
<saivann> mjg59 : There is no way to fix usplash to discover automatically the good resolution to use?
<saivann> mjg59 : Not the package but usplash itself
<mjg59> saivann: No. We can't use DDC.
<saivann> mjg59 : owh.. that sounds bad..
<mjg59> In the future, when we have kernel modesetting, yes
<saivann> mjg59 : From now on, should I set back status to confirmed in ubiquity, IYO?
<mjg59> saivann: Sure
<saivann> mjg59 : Do you think that subscribing the ubuntu install team would be a good idea?
<evand> saivann: the install team is the bug contact for ubiquity, so there's no need.
<saivann> evand : Thanks for the confirmation
<Kopfgeldjaeger> @ufw-developers: couldn't you extend the "simple syntax"? to make "ufw allow port 23", too. so that the options are just set to "any" by default
<Kopfgeldjaeger> +"work"
<jdstrand> Kopfgeldjaeger: can you give an example?
<jdstrand> (of any)
<Kopfgeldjaeger> at the moment, ufw allow 23/tcp is the same as ufw allow proto tcp from any to any port 23 (or so)
<Kopfgeldjaeger> you should be able to do the same with "ufw allow port 23/tcp", or "ufw allow port 23/tcp from 192.168.0.1"
<emgent> kirkland: ping
<emgent> s/kirkland/kiko/
<Kopfgeldjaeger> so that the values for "from","to" etc. are set to any by default and you can use ufw in more ways
<jdstrand> Kopfgeldjaeger: well, the 'ufw allow port 23', isn't more ways-- just more typing
<kirkland> emgent: pong
<jdstrand> Kopfgeldjaeger: the other was done initially, but it made the parser much more complex
<Kopfgeldjaeger> yeah, that's what i mean
<jdstrand> Kopfgeldjaeger: changes like this would have to be after hardy
<jdstrand> Kopfgeldjaeger: can you file a bug report against ufw, with examples and mark as wishlist?
<Kopfgeldjaeger> sure
<jdstrand> Kopfgeldjaeger: thanks! :)
<Kopfgeldjaeger> np ;)
<Kopfgeldjaeger> against the package ufw or the project ufw?
<jdstrand> Kopfgeldjaeger: either is fine-- I get mail from both
<Kopfgeldjaeger> ok
<Kopfgeldjaeger> jdstrand: is it okay? ;)
<alex-weej> seb128: is human-murrine definitely getting kicked out of the default config? i ran the hardy beta on my housemate's macbook yesterday and realised it actually looks really nice :(
<alex-weej> and if so, is that not a UI freeze break? :P
<alex-weej> and if not, i need to fix the tooltip bug!
<seb128> alex-weej: ubuntulooks will be used for hardy yes, it looks better
<alex-weej> has the change already gone in?
<seb128> alex-weej: the new theme have some issues and the scrollbar, etc don't look as good I think
<alex-weej> ok fair enough
<seb128> alex-weej: I don't think so no
<alex-weej> as long as it is definitely happening
<seb128> that's what scott said at the desktop team meeting some days ago
<alex-weej> i don't want Hardy to ship with murrine and broken tooltips :)
<seb128> right
<mdke> seb128: I don't know offhand, can you describe exactly what they do? Maybe they are described in the gnome user-guide
<seb128> mdke: gnome-cd is a gnome cd player as its name indicates, enter gnome-cd on a command line to get it
<seb128> mdke: it's not in the menu, not started by default and sound-juicer and rhythmbox read cds without any issue
<mdke> seb128: ok, I've checked. Neither are referred to in the ubuntu specific documentation. I don't see anything obvious in the gnome user guide either, so I don't see any documentation problem with dropping them
<seb128> mdke: ok, good, thanks
<seb128> mdke: I'm asking to make sure but we didn't use it for a while and redhat and some other distros already stopped shipping it since we have better cd playing softwares now
<seb128> it's still available in the source package and can be built easily though ;-)
<mdke> yep
<Fujitsu> Should I really be able to completely stop X responding by debdiffing something sufficiently large on a LUKS-encrypted  disk?
<\sh> Fujitsu: depends on your IO? :)
<\sh> Fujitsu: I'm getting it every time, when I start three or more sbuilds with large source files...my controller <-> mainboard combination doesn't like so much IO load and X stops responding
<Fujitsu> \sh: I can generally only do one before it dies.
<Fujitsu> The CPU is mostly in IOWAIT, so it can't be the limiting factor.
<\sh> Fujitsu: without the encryption does it work then?
<Fujitsu> \sh: I haven't tried for about a year without encryption.
<Fujitsu> In Gutsy I didn't have this problem.
<soren> Fujitsu: How do you see that the CPU is mostly in IOWAIT?
<Fujitsu> soren: multiload-applet
<\sh> Fujitsu: try iostat
<Fujitsu> It does freeze after a while, but before it dies I can see the load shooting up, and the IOWAIT colour filling the CPU box.
<soren> Fujitsu: apt-cache doesn't know anything about that?
<Fujitsu> soren: It's the GNOME panel system monitor applet.
<Fujitsu> Installed by default, I believe.
<soren> Fujitsu: Ah.
<jdong> what's up with Ubuntu and unionfs vs aufs?
<jdong> I know our livecds use unionfs
<jdong> but everyone in $blogworld says that aufs is better?
<\sh> Fujitsu: the system monitor ?
<Fujitsu> \sh: That's it.
<\sh> Fujitsu: hmmm...I don't see iowait counters...not even in the preferences
<Fujitsu> \sh: It's the system monitor applet, not gnome-system-monitor.
<Fujitsu> iowait is represented by a very dark blue on the CPU box.
<\sh> na now it's light green ;)
<\sh> Fujitsu: so your dark blue graph goes up?
<Fujitsu> \sh: It's not dark blue for me either, but yes.
<\sh> fun part: iostat doesn't show any iowait stats with rt kernel
<ogra_cmpc> jdong, that might actually be but is nothing for hardy
<ogra_cmpc> most of the tools like casper etc have aufs support but dont enable/use it by default
<\sh> Fujitsu: I'll do some tests tomorrow morning in the company.../me needs to hit the bed now.
<Fujitsu> \sh: Night.
<\sh> cu tomorrow
<mjg59> ogra_cmpc: Hm. Intel have a couple of ideas about the backlight - I may have some kernel patches for you tomorrow
<ogra_cmpc> mjg59, yay !
<ogra_cmpc> you rock
<ogra_cmpc> :)
 * ogra_cmpc wants a --no-progress option in mksquashfs ... damned ... 
<ogra_cmpc> makes every log unreadable
<slangasek> --republican-health-care?
<ogra_cmpc> heh
<ogra_cmpc> we use it in so many places that get logged, i wonder why nobody patched it yet
<slangasek> I never thought about it until you mentioned :)
<ion_> When might cjwa-tson return?
<mario_limonciell> ogra_cmpc, perhaps 1>&3 or something so that it's not showing any output
<ogra_cmpc> ion_, next week
<ion_> ogra: Thanks
<ogra_cmpc> mario_limonciell, i actually want the rest of the output
<mario_limonciell> oh
<mjg59> ogra_cmpc: BTW, using -vesa will decrease battery life
<ogra_cmpc> just not the progressbar that makes it impossible to read it in a pager like less
<ogra_cmpc> mjg59, it frees up about 40M of ram
<mjg59> No framebuffer compression, no clock gating, chip ends up doing much more work
<ogra_cmpc> vesa vs i810
<mjg59> ogra_cmpc: Disabling gl in -i810 should free up most of that
<ogra_cmpc> hmm
<mjg59> It'll allocate much more RAM in order to have back buffers and so on
<ogra_cmpc> you mean patch it ?
<mjg59> But -i810 isn't going to be much better than -vesa from a power point of view
<ogra_cmpc> performance is actually not much different between the two
<ogra_cmpc> not even with video playback
<ogra_cmpc> or flash
<mjg59> Wurgh. Having an overlay enging will make a huge difference if you scale anything
<mjg59> Flash will be much the same speed on everything, yes
<ogra_cmpc> where should i scale to ? i have 800x480 ....
<ogra_cmpc> thats either maximized/fullscreen or not ...
<mjg59> ogra_cmpc: Anything other than the native size of the video
<ogra_cmpc> right, but the difference will be rather small on that screensize ...
<ogra_cmpc> do you think setting DRI to false in xorg.conf is sufficient to get rid of gl in ram ?
<ogra_cmpc> patching the driver would mean i need to put it in a ppa ... not really what i want
<crimsun> \sh_away: not a bug, but certainly counterintuitive.  Do you have suggestions for exposing the selection in a different fashion?
<ogra_cmpc> mjg59, did i say that you rule already ? Option DRI false gains me 50M with i810 :D
<ogra_cmpc> ending up with 3M more free ram than with vesa actually
<mjg59> ogra_cmpc: Ha
<mjg59> ogra_cmpc: How about the backlight? (not optimistic, but always possible)
<TheMuso> 5~/c
<ogra_cmpc> i'll try
<ogra_cmpc> nope, still needs a poke with the brightness key
<Fujitsu> Do I blame -ati if I don't get correct resolution detection using it?
<tjaalton> Fujitsu: yes
<tjaalton> Fujitsu: generally so
<Fujitsu> tjaalton: THanks.
<Fujitsu> tjaalton: Do I want to include the output of get-edid or similar?
<tjaalton> Fujitsu: that would be nice, and the logfile
<Fujitsu> tjaalton: Will do.
<asac> slangasek: yes.
<asac> slangasek: its just .desktop file from what i can see
<asac> (or better from what i remember)
<slangasek> asac: ok, proposed patch in the bug; I could upload that if you like
<asac> slangasek: i can do tht tomorrow ... when uploading the ap_scan branch
<asac> i hoped for more feedback, but i think its now going up
<neutrinomass> At the risk of being slightly offtopic, will ubuntu participate in this year's SoC ?
<mjg59> No
 * asac off for bed
<neutrinomass> Ok, thanks
<slangasek> asac: ok then; I just figured that since they're separate source packages, some parallelization might be in order :)
<slangasek> asac: 'night!
<ogra_cmpc> hmm
<asac> slangasek: oh right ... its applet. feel free to go ahead then (if you remember to update the bzr branch)
<asac> thanks and night
<ogra_cmpc> isnt visudo supposed to use $EDITOR or the editor alternative ?
<ogra_cmpc> ah, no its explicitly now
<ogra_cmpc> s/now/not/
#ubuntu-devel 2008-03-27
<superm1> slangasek, evand was going to make a new DVD image to include ubiquity 1.8.1 earlier but having internet troubles connecting to cdimage.  would you be able queue one up?
<slangasek> superm1: just queuing an ubuntu DVD build? sure
<superm1> yeah.  thanks :)
<slangasek> scheduled, expect results in > 3h
<keescook> blueprint: add -Werror to default compiler flags.
<keescook> step 2: lose all my friends
<StevenK> step 3: PROFIT!
<StevenK> Ahem
<cody-somerville> slangasek, I think Xubuntu alternative should be okay to release now
<ScottK2> He'd have lots of free time for Step 3
<slangasek> cody-somerville: I only see one test result for amd64?
<cody-somerville> I think Jim is going to do another amd64 test anyhow
<slangasek> shall I wait for results on that test before publishing?
<cody-somerville> How about we publish them tomorrow afternoon?
<cody-somerville> As long as there is no bad reports in by that time
<slangasek> afternoon in whose time zone?
<slangasek> (afternoon is fine, just want to know which noon it's to be after :)
<cody-somerville> hehe
<cody-somerville> How about 1600 UTC?
<ScottK2> How about Guam?
<ScottK2> ;-)
<cody-somerville> :)
<pochu> cody-somerville: congrats :)
<cody-somerville> Thanks pochu :)
 * calc is doing first build of OOo 2.4.0-1ubuntu1
<slangasek> cody-somerville: ok
<calc> anyone happen to know how to get changed properties to show up in bzr diff/stat/etc something?
<calc> it shows me something changed but not what
<alex-weej> if brasero is in the default installation, nautilus-cd-burn should be removed
<_MMA_> alex-weej: Wouldnt that also remove the ability to right-click on a image and burn? I wouldnt want to lose that.
<stgraber> calc: bug 46636
<ubotu> Launchpad bug 46636 in bzr "meaning of '*' in bzr status is undocumented and unverbose" [Low,Confirmed] https://launchpad.net/bugs/46636
<alex-weej> personally, i think brasero is not ready
<alex-weej> and i prefer nautilus's integration
<alex-weej> BUT, we currently have massive duplication
<alex-weej> you can right click an ISO and go to "Open with Brasero Disc Burner"
<_MMA_> Didnt answer my question and it looks like you're just trying to start something so nm.
<alex-weej> _MMA_: NO
<calc> stgraber: fun
<calc> stgraber: wow thats an old bug too
<calc> oh gah
<calc> doko: ping
<calc> doko: i'm getting crt1.o errors on amd64
<calc> http://pastebin.ubuntu.com/6124/
<calc> anyone know what the problem is there?
<calc> if i am reading it correctly its a bug in libc6 but i think i must be misreading it
<slangasek> (.text+0x20): undefined reference to `main'
<slangasek> so where's your main()?
<slangasek> that's not a glibc problem
<slangasek> -o ../unxlngx6.pro/bin/cpp
<slangasek> er... also, why does OOo need to build its own C preprocessor...?
<calc> because it is crack
<slangasek> sigh
 * calc is looking for the missing main
<mneptok> no, crack is what you're smoking if you think you can build OO.org without a blood sacrifice to mmeeks. :)
<slangasek> well anyway, those undef symbols aren't anything that glibc is responsible for providing
<calc> slangasek: ah ok
 * calc thinks he sees where the main is, but doesn't see where it is built
<calc> ah i see
<calc> its in _cpp.c
<calc> int main(int argc, char **argv)
<calc> thats a valid main isn't it?
 * calc will have to objdump _cpp.o and see whats in it
<calc> slangasek: what am i looking for in objdump output to be certain it is properly compiled?
<calc> i see this:
<calc> 0000000000000b20 g     F .text  00000000000000c7 main
<calc> i did a disassemble and see the assembly for the main function as well
<calc> do any of those weird PIE things apply to debuild stuff on a local machine, or just buildds? or can it even cause weird issues like this?
 * calc haven't looked into how PIE works, just that it does similar thing to what is done for fPIC libs
 * calc guesses he can test by attempting to recompile current hardy OOo to see if it still works
<calc> what does a lone -L do on a line for g++ ?
<calc> eg if the line contains various -L/foo/path then a -L
<calc> with nothing after it
<calc> I think I found the bug, now how to fix it
<emgent> calc: what bug?
<calc> emgent: bug in OOo 2.4.0 build system
<tritium> You gotta love $42 shipping fees + $53 customs fees for a 6 lb. order of shirts from shop.canonical.com...
<emgent> argh
<calc> tritium: wow
<tritium> calc: yeah, probably our last order, even though we would have wanted some of the laptop bags that were out of stock
<tritium> (as were the white polos)
<calc> hmm i wonder if i can buy them directly when in london, to skip on the nice shipping/custom fees
<tritium> calc: I certainly hope you can
<calc> i would probably have to ask to have them have it at the office, if i wanted it
<calc> since they sell through another company i think
<tritium> That would be a nice arrangement.
<emgent> calc: about bug #174112 have you saw debian patch?
<ubotu> Launchpad bug 174112 in openoffice.org "[openoffice.org] [CVE-2007-4575] Potential arbitrary code execution vulnerability in 3rd party module (HSQLDB)" [Critical,In progress] https://launchpad.net/bugs/174112
<emgent> ops, sorry i read now your last comment.
<calc> emgent: yea, i am going to have to do something about it soon, the upstream guy vanished before he gave me the fix
<calc> :(
<calc> i'm probably going to have to find out exactly how the patch for debian works and write different one for each of ubuntu's releases :-\
<calc> since upstream who was going to do it and send me the patches just stopped responding to emails entirely :(
<emgent> argh
<calc> emgent: as soon as i get OOo 2.4 resolved i will be working on that
<calc> emgent: i have some other related work to do soon anyway
<emgent> calc: if you like i can work with you about it.
<calc> emgent: ok, are you emgent@ubuntu.com ?
<calc> emgent: i think for the other work i have what is needed, just not for the old security bug
<emgent> not now, i'm motu-swat member and ubuntu-whitehat teamleader, but not official members now.
<emgent> calc: https://edge.launchpad.net/~emgent
<calc> ok
<ScottK2> emgent: Why is 174112 not marked as affecting hsqldb in Ubuntu and why is motu-swat subscribed when all the affected packages are in Main?
<emgent> one moment
<emgent> bug #174112
<ubotu> Launchpad bug 174112 in openoffice.org "[openoffice.org] [CVE-2007-4575] Potential arbitrary code execution vulnerability in 3rd party module (HSQLDB)" [Critical,In progress] https://launchpad.net/bugs/174112
<emgent> motu-swat is an error. removed.
<emgent> about hsqldb i'm working to it and i will add it.
<ScottK2> OK.  Sounds good.
<ds> why is swfdec-mozilla so old in ubuntu compared to debian?
<Fujitsu> !info swfdec-mozilla hardy
<Fujitsu> !info swfdec-mozilla sid
<Fujitsu> swfdec-mozilla |    0.5.4-1 | hardy/universe | source, amd64, i386, powerpc
<Fujitsu> swfdec-mozilla |    0.5.5-1 |      unstable | arm, armel, hppa, m68k, mips, mipsel
<Fujitsu> swfdec-mozilla |    0.6.0-2 |      unstable | source, alpha, amd64, i386, ia64, powerpc, s390, sparc
<Fujitsu> We're 0.0.1 behind lenny. I don't think that's too bad.
<Fujitsu> And we're not that far behind sid, considering we won't have synced in 3 months.
<ds> it seemed like an oversight, as it fixes the outstanding issues in launchpad
<Fujitsu> We unfortunately don't have enough developers to carefully watch every single package in Debian.
<ds> yeah
<Fujitsu> We would have noticed if the Debian uploads had closed RC bugs, but they didn't close any bugs at all.
<slangasek> calc: -fPIE would apply to locally-built executables, but isn't part of the standard flags right now; -Wl,-Bsymbolic-functions also applies, and could have something to do with it, but I'm not sure what given that other apps aren't having this problem when building.  Oh, I just now noticed that you're using ccache...
<slangasek> calc: oh, yes, -L by itself translates to "please screw up the interpretation of the following argument for me"
<bd_> Hi, there's a bug which breaks gitk and git-gui's dependencies, and has had a trivial patch in launchpad to fix it for about two weeks... Any chance of getting an upload so it's not broken for hardy? https://bugs.launchpad.net/ubuntu/+source/git-core/+bug/196846
<ubotu> Launchpad bug 196846 in git-core "gitk requires wish8.5 but depends on tk8.4" [High,Confirmed]
<enrico> Riddell: I just opened debian bug #472911
<ubotu> Debian bug 472911 in debtags "Data files are embarassingly created in the wrong place" [Serious,Open] http://bugs.debian.org/472911
<enrico> Riddell: it affects hardy
<enrico> Riddell: I should upload a fix within a day or two
<PurpleBlu> I really enjoy http://brainstorm.ubuntu.com/.   With this whole suggest/vote concept, how much of it would realistically transfers over?
<PurpleBlu> I know you can't quantitatively answer that.  I am just curious if my votes actually have better chances then me hitting megabillion lotto.
<nixternal> PurpleBlu: last time I checked, we only had mega millions here in Illinois ;p
<PurpleBlu> nixternal, I know FOSS is a hobbyist based community driven devs.  I was just curious that someone like me who is not a 1337 coder, how I can ultimately contribute.
<ScottK2> bd_: ubuntu-main-sponsors was not subscribed to the bug.  They are now.  Odds are no one who could upload it even saw it.
<nixternal> PurpleBlu: talk to me in #ubuntu-chicago
<PurpleBlu> k
<jdong> nixternal: Mega Millions and MegaPlier are registered trademarks of Mega Ball Lottery Games. Use of trademarks is subject to the End Speaker License Agreement (ESLA). By using these trademark terms you are certifyin agreement to these terms. Please drink responsibly.
<bd_> ScottK2: ah, okay, it wasn't clear what the procedure was for notifying the appropriate people :) or rather, the Bugs/HowToFix wikipage said to just come here...
<ScottK2> OK.  Somewhere it should say for ubuntu-main-sponsors or ubunt-universe-sponsors to be subscribed.
<ScottK2> I think there's a page on sponsorship that ought to be linked from that one.  If it's not, would you please add it.
<bd_> hm, the MOTU page talks about it a bit, but in the context of universe, not main (and mostly on how to contribute new packages)
<bd_> but I'm way behind on a school assignment atm so I think I shouldn't be futzing around with wiki pages atm, sorry :)
<ScottK2> bd_: I understand.  Thanks for contributing and come back when you have a little time.  The documentation is best updated by those who are trying to use it.
<calc> slangasek: ah nice :-\
<calc> slangasek: there isn't a way to get someone to fix that issue with -L screwing up the build?
<calc> a -L with a space following is obviously always wrong (or am I missing something?)
<doko> calc: problem solved?
<calc> doko: yea it was a empty -L
<calc> doko: why does empty -L cause build failures like that, shouldn't it just ignore it?
<doko> no, it just takes the next arg as the dir
<calc> oh so it doesn't have to have no space like how it usually is done
<calc> eg -L/path/to/something, i see :)
<calc> makes debugging things annoying unless you happen to see the extra -L floating about :)
<calc> i ended up comparing it to the working build to find it
<calc> since there were so many -L in that gcc call
<warp10> Good morning
<dholbach> good morning
<cody-somerville> lo dholbach :)
<dholbach> hiya cody-somerville
<pitti> Good morning
<dholbach> hiya pitti
<ion_> Hi all
<orbisvicis> im going through several scripts, but hardy jack client scripts call pasuspender and that can be really annoying if pulse outputs to jackd
<orbisvicis> *tip to packager
<ion_> ...who probably will never notice it if you only mention it here.
<ion_> Please file a bug report.
<orbisvicis> not going to file a bug per package
<orbisvicis> maybe i will if all these bash scripts are so badly written
<dholbach> hey seb128
<seb128> oh, dholbach is back!
<seb128> hey hey dholbach
<dholbach> seb128: I was in France! :)
<seb128> dholbach: how, was it? ;-)
<dholbach> very very nice :)
<dholbach> seb128: Mimi and I were in Paris for a few days - we even managed to meet up with lool
<pitti> dholbach: viva la France! *hug*
<dholbach> wooohoo! :)
 * dholbach hugs pitti
<seb128> hey pitti
 * seb128 hugs pitti
<soren> How do I do pm-suspend-hybrid from GNOME?
<pitti> soren: you don't, I think :/
<soren> Alrighty. I'll stop looking :)
<kagou> hi
<kagou> is there a problem with gnome-system-monitor, i can't find it in administration menu ?!
<james_w> It's moved to the System Tools menu it seems.
<james_w> in Applications
<kagou> james_w, diantre !
<kagou> james_w, indeed, thanks
<james_w> no problem
<asac> anyone knows how to make dget also fetch the debs listed in a .changes? (i only get the source parts, though the .debs are definitly listed in changes)
<cody-somerville> asac, According to the nice man page, you provide the package name and it grabs it from the mirror listed in your sources.list
<cody-somerville> asac, It appears that it does not support grabbing the binary packages by providing a url :)
<asac> thats strange. i am sure i got binary bits through dget yesterday
<asac> anyway. thanks
<asac> (and no, those are not in a archive i could list in sources.list)
<seb128_> cody-somerville: what manpage do you have?
<cody-somerville> The one that ships with ubuntu's dget?
<seb128_> "dget downloads Debian packages.  In the first form, dget fetches the
<seb128_>        requested URL.  If this is a .dsc or .changes file, then dget acts as a
<seb128_>        source-package aware form of wget: it also fetches any files referenced
<seb128_>        in the .dsc/.changes file.  When the -x option is given, the downloaded
<seb128_>        source is also unpacked by dpkg-source."
<cody-somerville> Ah
<cody-somerville> Fair enough
<cody-somerville> I was looking at the second paragraph
<pitti> seb128_: can you please have a quick look at https://bugs.edge.launchpad.net/ubuntu/+source/jockey/+bug/202898/comments/9, the second point?
<ubotu> Launchpad bug 202898 in jockey "gnome-appearance-properties shouldn't install restricted driver without asking" [High,Fix committed]
<pitti> seb128_: do you know which exit code appearance-properties checks, and how it should behave?
<seb128_> pitti: is that jockey-gtk --check-composite which does the driver installation?
<pitti> seb128_: right
<pitti> seb128_: we need to agree on how it should behave, and which exit code jockey shuold deliver for 'cancel', etc.
<seb128_> pitti: it checks for == 0
<pitti> seb128_: so it should return 0 IFF it installed the composite-aware driver correctly, and 1 on cancel/fail to install/no driver necessary?
<seb128_> pitti: yes
<seb128_> pitti: I'm happy to change the g-c-c code if you prefer something else though
<pitti> hm, that's what it does
<pitti> I don't quite understand what he means in the bug report
<kagou> slangasek, i'm investifating the use of nautilus-share (samba usershare) as it will be installed by default. Normal (non admin) users are not in sambashare group by default. usershare is provided by samba to allow normal users to share folders without special permissions. Is it a problem to hack user creation to add all users on sambashare on creation ?
 * kagou offer some croissants to slangasek 
<\sh> one question to PA: the monitor input devices (showing up in padevchooser) for the soundcards are (as I see it) a passthrough device from output devices to input devices, correct?
<pitti> YokoZar: ooh! congratulations to your MOTU badge, and welcome! *hug*
<YokoZar> pitti: bug is now closed ;) *hug*
<ogra_cmpc> YokoZar, hey, great to hear
<TheMuso> Does anybody object to adding pulseaudio-module-x11 to the desktop seed, so that pulseaudio properly gets killed on user logout?
<ogra_cmpc> TheMuso, doesnt that also bring the cool keyboard bell sounds ?
 * ogra_cmpc is all for it
<TheMuso> ogra_cmpc: If they are enabled, and I don't think they are by default.
<TheMuso> I'd have to check.
<ogra_cmpc> yup, its disabled
<TheMuso> ogra_cmpc: One thing I intend to spec for intrepid, is to use pulse to make the bell sound, as IMO we shouldn't use the PC speaker, and more and more machines are coming without them.
<ogra_cmpc> yeah
<ogra_cmpc> and it just sounds a lot friendlier than BEEP !
<TheMuso> I agree.
<ogra_cmpc> i would actually propose it for hardy ... its two comments to remove, unlikely to break anything and there are no screenshots of it :) we should put it on next weeks platform agenda (and ask the desktop team for comments)
<TheMuso> ogra_cmpc: Yeah but I think we need a better way for the user to set what sound to use.
<TheMuso> Atm it can only be done in that file. It would be nice if it could be done per user session, which I need to look into.
<ogra_cmpc> i remember we had it on in happer when we first evaluated polypaudio and people liked it (even though we dropped back to esd back then)
<ogra_cmpc> *dapper
<TheMuso> Right.
<TheMuso> I still think its something that should be configured per user.
<ogra_cmpc> thats a nice to have option imho
<ogra_cmpc> you cant configure the beep easily either
<TheMuso> Well, perhaps to select the sound yes, but whether the user wants a sound played, or a pc speaker beep I think should be user configurable.
<TheMuso> True.
<seb128> TheMuso: you forgot to revert the gucharmap patch changes otherwise lpi looks good
<TheMuso> seb128: Oh yeah right. :) I originally changed it thinking that it was the same patch used in the actual package. I'll do that now.
<emgent> heya people
<jdstrand> hi evand! I saw your comment in bug #206030
<ubotu> Launchpad bug 206030 in ubuntu "cannot activate ufw in live mode (/ is world-writable)" [Undecided,Fix committed] https://launchpad.net/bugs/206030
<jdstrand> evand: oh, heh-- but I didn't see 'Fix committed'
<jdstrand> nevermind... :)
<emgent> hi jdstrand
<jdstrand> hi emgent!
<emgent> jdstrand: when you have time see bug #207494 && bug #207490
<ubotu> Bug 207494 on http://launchpad.net/bugs/207494 is private
<ubotu> Bug 207490 on http://launchpad.net/bugs/207490 is private
<jdstrand> emgent: thanks emgent!
<emgent> np :)
 * dholbach added bitesize, upgrade, packaging, ftbfs and unmetdeps bugs to http://daniel.holba.ch/really-fix-it - hope it proves useful to you
<james_w> I'd like some advice on debian bug 464118 (ubuntu bug 192239)
<ubotu> Debian bug 464118 in coreutils "rm -r broken: Function not implemented" [Important,Open] http://bugs.debian.org/464118
<james_w> the Debian maintainer says that it doesn't need to be fixed for lenny, as it requires a kernel version older than that shipped in etch.
<james_w> can we apply the same logic for hardy/dapper?
<james_w> I think not, as the bug was reproduced on hardy running a .15 kernel, which was the most recent in dapper.
<mjg59> pitti: http://www.codon.org.uk/~mjg59/tmp/98-unload_network_modules.patch
<pitti> mjg59: ah, great;
<pitti> mjg59: I was about to ask you how the suspend script can "remember" which modules it unloaded, so that resume can modprobe them again
<pitti> so that 'modunload' macro does that trick?
<mjg59> Yup
<Ng> nice, wish I'd spotted that modunload was smrt. my aborted attempt at such a network module script was a horror show of trying to remember a list of modules ;)
<Ng> mjg59: is there any real need to do the IRDA and netconsole ones acpi-support does too?
<ogra_cmpc_> mjg59, why dont you just use the SUSPEND_MODULES variable ?
<pitti> seb128: hm, bug 207587, is that nautilus or gvfs?
<ubotu> Launchpad bug 207587 in human-icon-theme "[hardy regression] Missing icon for mounted encrypted volumes" [Medium,Confirmed] https://launchpad.net/bugs/207587
<mjg59> ogra_cmpc_: Because that's already used
<ogra_cmpc_> ah
<seb128> pitti: the icon theme I would say
<ogra_cmpc_> i dont see it used anywhere yet (i set it on teh classmate to get rid of button during resume)
<mjg59> ogra_cmpc_: I don't understand what you mean by "just use"
<seb128> pitti: the icon used is "media-encrypted""
<ogra_cmpc_> mjg59, instead of uloading them yourself with modunload i mean
<ogra_cmpc_> *unloading
<seb128> pitti: gvfs is where the icon are set if that's the question
<ogra_cmpc_> ... vs just appending them to SUSPEND_MODULES and let pm-utils care for it
<mjg59> ogra_cmpc_: Because that's a user-settable variable - I wasn't enthusiastic about overloading it
<ogra_cmpc_> ah
<pitti> seb128: ah, I see; I thought it should/would just use the same icon as for unencrypted devices
<pitti> mjg59: I'll upload it soon, thank you!
<mjg59> pitti: I've got another patch or two for you
<mjg59> pitti: http://www.codon.org.uk/~mjg59/tmp/97_fix_ppc_suspend_test.patch (for 189851)
 * \sh jumps from the next bridge...
<mjg59> pitti: Oh, and 70-remove-pm-pmu.patch needs to be dropped
<pitti> \sh: don't
<mjg59> pitti: ...and pm-utils made arch: any not all
<mjg59> Grah. Hideous debian-specific breakage.
<\sh> pitti: I'm doomed...why is it not possible to capture audio from an output device? pulseaudio is enabling an monitor device and offers it as input .. but apps with libasound compat are not able to get this device as input device :(
<mjg59> pitti: Hngh. This is all horribly awkward.
<mjg59> pitti: We need (a) that patch I provided, (b) lose 70-remove-pm-pmu.patch, (c) s/all/any/, (d) make sure pm-pmu-sleep is shipped in the PPC builds
<pitti> mjg59: hm, we can't just add some uname -m check to the script and leave it as arch:all?
<mjg59> pitti: No, because pm-pmu is a binary
<pitti> ugh
<pitti> mjg59: in pm-i I remember using a perl call do do the sleep ioctl
<sjoerd> \sh: sure they can
<mjg59> pitti: That'd be possible, but I'm not sure there's an advantage in deviating from upstream
<\sh> sjoerd: -device: plug:pulse? doesn't help...
<mjg59> pitti: The alternative would be to call /usr/lib/hal/hal-system-power-pmu sleep on PPC, rather than pm-pmu
<mjg59> pitti: That would keep us arch: all
<pitti> ah, even easier, yes
<mjg59> pitti: But it still needs my patch :)
<pitti> mjg59: too bad I don't have a PPC any more to test all this
<mjg59> pitti: Heh
<\sh> sjoerd: what device should I use when I want to use this monitor device of pulse in an libasound app?
<sjoerd> \sh: put pcm.monitor { \n type pulse \n device <pulse devicename> \n } in your .asoundrc
<pitti> mjg59: so, I'll head out for lunch, then do the desktop team meeting, and then see to assembling it all to a source, unless you beat me to it with a debdiff :)
<sjoerd> and then you can use the monitor device
<sjoerd> I'm not sure how and if you can specify that as a device parameter instead
<\sh> sjoerd: well, that is my problem...the device paramenter
<\sh> parameter even
<sjoerd> One idea we've been toying with is to create a pulse module that creates a asoundrc with all your devices listed automagically
<sjoerd> The nasty part is ensuring that goes away when pulse dies/crashes/is shot/etc
<\sh> sjoerd: the pulse device name is the name of the monitordevice which pulse added automatically?
<sjoerd> yes
<mjg59> pitti: Ok, cool
<\sh> sjoerd: well...the problem it seems, to tell the app to use this monitor device...I wonder what the alsa name of such a device is
<sjoerd> the device names are quite static
<soren> Are uploads to -proposed announced anywhere?
<seb128> soren: not on -changes
<soren> seb128: Precisely. Hence my question :)
<\sh> sjoerd: well, e.g. recordmydesktop is using hw:0,0 as default (it doesn#t know anything about the "default" mapping name of asound)...I could use as well plughw:0,0 .. when I set the defaults on padevchooser, this works...but whem I start to set default to the monitor device, it doesn't work :(
<\sh> grmpf...bbl
<\sh> sjoerd: YOU ARE DA MAN :)
<sjoerd> heh ?
<\sh> sjoerd: it works .)
<sjoerd> using -D directly or through a .asoundrc thingy
<\sh> apt-get install libasound2-plugins -> your pcm.monitor magic -> recordmydesktop -device monitor <- wokrs
<sjoerd> cool
<\sh> hey this costed me now one week of trying and banging my head on the table
<sjoerd> next time just jump in to #pulseaudio :)
 * ogra_cmpc_ thought we install that by default
<ogra_cmpc> \sh, i thought you had pulseaudio installed ... libasound2-plugins is a dep
<ogra_cmpc> ah, no, only a recommends
<\sh> ogra_cmpc: it's not
<\sh> ogra_cmpc: but fun part, without the pcm.monitor magic in .asoundrc it doesn't work
<Hobbsee> open week...again?
<seb128> Hobbsee: new ubuntu again, uds again, open week again ;-)
<Hobbsee> but...the last open week was only februrary....
<Hobbsee> -r
<seb128> Hobbsee: that was a developer week
<Hobbsee> oh
<\sh> ogra_cmpc: anyways..one week of hard work...and the solution is so simple
<Hobbsee> seb128: right, that makes sense then
<\sh> sjoerd: I will join #pulseaudio :) if I get my project working...I think it will be a nice example what you can do with linux and sound and video :)
<ogra_cmpc> at least if you invest a week :)
<\sh> ogra_cmpc: can you send privmsgs now with your nick now? :)
<ogra_cmpc> not with the cmpc one :) just set unregged to on for your client :P
<Hobbsee> where's mvo?
<pitti> Hobbsee: on holiday
<Hobbsee> oh
<Hobbsee> pitti: when's he back?
<pitti> next week
 * Hobbsee didn't think you guys were allowed holidays near releases.
<seb128> Hobbsee: that's not near yet
<seb128> Hobbsee: yeah, we have no holidays in the 3 months before and after each versions ;-)
<Hobbsee> seb128: that's normal for software development, it appears.
<Hobbsee> seb128: mind you, i grew up thinking that the australian working day didn't finish before 8pm, either.
<pitti> mjg59: WDYT? http://paste.ubuntu.com/6132/
<pitti> mjg59: that doesn't contain the e1000 fix yet, just the ppc suspend issue
<mjg59> pitti: Looks good
<pitti> mjg59: I'll forward the suspend fix to upstream, or is it already?
<mjg59> pitti: Not sure. It's not /strictly/ correct, because you can have a pmu without being able to suspend
<pitti> mjg59: ah, so you need to do that ioctl to know
<pitti> we have that in pmi
<emgent> i go to work, see you later people.
<lamont> jdstrand: btw, /var/lib/misc/group.db r, for cupsd (and anything else that uses/checks groups...)
 * jdstrand makes note of that
<lamont> Mar 27 07:35:14 mix kernel: [391824.339457] audit(1206624914.559:79):  type=1503 operation="inode_permission" requested_mask="rw" denied_mask="rw" name="/var/lib/misc/group.db" pid=6339 profile="/usr/sbin/cupsd"
 * lamont files that one under "WTF?"
<jdstrand> lamont: is there a bug for that? I'll be doing a cups update soon and can roll it in
<lamont> mid-upgrade firefox just crashed for me (gotta love transitioning libraries...)  so I didn't file one yet
<lamont> also, if nsswitch.conf has 'ldap' in it, then global read access for /etc/ldap/ldap.conf is kinda needed too.
<jdstrand> lamont: can you toss it all into the same bug?
<lamont> yeah - I'll file it in about an hour, once the upgrade completes
<jdstrand> lamont: cool, thanks
<dholbach> pitti, seb128, lool: you like  http://daniel.holba.ch/really-fix-it  now? :)
<seb128> dholbach: I'm wondering why C is before B ;-)
<dholbach> seb128: I just wondered the same :)
<seb128> and E before D
<dholbach> I'll fix that
<dholbach> no problem
<seb128> etc
<seb128> ;-)
<emgent> heya
<seb128> otherwise looks cool
<seb128> but the fact that launchpad has no patch status does make it easy to build a pertinant list
<mathiaz> I uploaded mysql-dfsg-5.0 yesterday. It built successfully on sparc, but I've received an email stating that it failed to upload for this arch. What should I do to fix this error ?
<pitti> dholbach: nice set sort ordering :)
<ScottK> dholbach: Do you have a way to exclude patches/bugs that have a fix, but the fix isn't a valid one?
<pitti> dholbach: looks nice! just waaay too big
<pitti> dholbach: is there a way to filter by component?
<dholbach> pitti: that's why I split it up :)
<dholbach> no, no filtering
<ScottK> dholbach: As an example, Bug #165184 solves a to much mail from spamassassin problem by piping mail to /dev/null.
<ubotu> Launchpad bug 165184 in amavisd-new "amavisd-new + spamassassin: cronjob spams root user" [Medium,Triaged] https://launchpad.net/bugs/165184
<pitti> dholbach: big> not the fault of the messenger
<pitti> ScottK: heh
<dholbach> ScottK: the only thing I know to work around it is to "unflag the patch thingie of the attachment" :/
<asac> pitti: you mean nm-editor menu entry, right?
<pitti> ScottK: debian/patches/dry_your_email_swamp.patch? :)
<asac> (not nm-tool)
<pitti> asac: right; slangasek did it this morning, so all is well
<asac> pitti: yep. I gave him green light yesterday. thanks for confirming
<ScottK> dholbach: How often does it refresh data from LP?
<dholbach> ScottK: every 4 hours because it takes ~40m to run - I don't want to hammer LP that bad
<ScottK> dholbach: Understand.  I unchecked that one and I want to know how soon to check back and see if that cleared it.
<dholbach> ScottK: I'm re-running it right now - I'll let you know
<rexy_> xb6FFFFFF xb7FFFFFF isnt that where ussually libc and such live?
<lamont> Error org.freedesktop.DBus.Error.Failed: Element <standard_system_servicedirs> not allowed inside <busconfig> in configuration file
<lamont> is that me, or hardy, I wonder?
<pitti> mjg59: https://bugs.freedesktop.org/show_bug.cgi?id=15226 FYI, if you want to subscribe
<ubotu> Freedesktop bug 15226 in General "network modules need to be unloaded during suspend" [Normal,New]
<pitti> mjg59: heh, cute; I just saw that I have an rmmod/modprobe in /etc/pm/sleep.d on my laptop :)
<collusion> any thoughts on how to debug a broken suspend on a x40 with hardy?
<pitti> mjg59: erk, s/done/fi/ in the script; fixing
<james_w> collusion: https://wiki.ubuntu.com/DebuggingKernelSuspend
<collusion> james_w: sweet, reading now, thx.
<rexy_> are there any issues wrt segfaulting of the pulseaudio daemon? forcing in a bluetooth source and switching streams will segfault it
<james_w> that sounds like an issue to me
<rexy_> heu i ment if anyone was aware on br's filed of that nature
<lamont> "Sorry, the package "updata-manager" failed to install or upgrade."
<lamont> there's something funny about that
<rexy_> there are several issues actually, depending on your options it will randomly decide to not start, it does not accept an virtual alsa bluetooth device on startup, but it will load it just fine through the pactl module loader, but crashes easily
<rexy_> how could i start that br_reporting thing from the cli?
<james_w> apport-cli
<ScottK> dholbach: What would you think about removing partner from the packages you list.  They really aren't an Ubuntu distro issue.
<rexy_> ok filed, #207796, anything i should add?
<dholbach> ScottK: um... which package and bugs do you mean in this case?
<ScottK> dholbach: Bug #146269 in openssl097 is the one I noticed, but I think partner should just be left out to reduce the noise.
<ubotu> Launchpad bug 146269 in openssl097 "[openssl security] OpenSSL SSL_get_shared_ciphers() off-by-one buffer overflow" [High,Confirmed] https://launchpad.net/bugs/146269
<dholbach> ScottK: added to my todo list - I'll try to figure something out
<ScottK> Thanks.
<ScottK> dholbach: One more comment: Bugs that affect multiple packages appear to be listed for all affected packages, not just the ones that have fixes.  Bug #204895 is an example.
<ubotu> Launchpad bug 204895 in harvestman "Packages failed archive rebuild test possibly due to python-central transition" [Medium,In progress] https://launchpad.net/bugs/204895
<ScottK> Finally, http://qa.ubuntuwire.com/bugs/rcbugs/ would be another source of information that might be worth integrating.
<dholbach> ScottK: it's impossible to figure out which of the tasks a patch is for :/
<dholbach> of course I could parse the filename of bug attachments
<ScottK> That or file a Launchpad bug ...
<dholbach> ok, adding to the list too
<dholbach> rcbugs looks great
<siretart> can someone from the release team please have a look at bug #204557? Is there something missing about that report?
<ubotu> Launchpad bug 204557 in xine-lib "Freeze exception for xine-lib 1.1.11" [Undecided,New] https://launchpad.net/bugs/204557
<dholbach> ScottK: is the bug you untagged still on the list?
 * ScottK looks
<smoser> sorry for offtopic question. does anyone know the difference between "Mobile Developer" and "Mobile Engineer" (http://www.ubuntu.com/employment) ?
<ScottK> dholbach: It is not!
<dholbach> ScottK: ROCK
<dholbach> smoser: you could try asking in #ubuntu-mobile
<wasabi> so at some point in the future we're going to stop asking our users to view diffs of smb.conf
<wasabi> right? :0
<siretart> dholbach: do you spot something missing on the xine-lib bug?
<ScottK2> wasabi: What would you propose we do instead?
<siretart> dholbach: do you think I should milestone it?
<wasabi> Automatically merge the settings in some fashion. Like every other OS, I guess.
<wasabi> I don't have a good answer. I'm wondering if anybody has thought about it.
<smoser> dholbach, i figured it was somewhat a "generic canonical job title" question. i'll ask there though
<dholbach> siretart: slangasek might know better than I do - it looks OK to me though
<ScottK2> wasabi: I think the people who have thought about it mostly get headaches from corner cases.
<wasabi> Wondering if maybe I was off base a bit. If we end up with a UI to manipulate Windows settings (join a domain, workgroup, make shares), maybe it should divert samba into a seperate private config file.
<wasabi> And revert the distro smb.conf
<wasabi> And just deal with ugprades and stuff on it's own.
 * ScottK2 imagines one might separate out a .local conffile and do something like that.
<collusion> well, /sys/power/pm_trace did not reveal anything too useful (i.e., no "hash matches ...")
<collusion> i was able to get it to suspend once while in recovery mode tho...
<mjg59> collusion: How's it failing?
<collusion> it's a thinkpad x40 and it seems to do most things (video off, e.g.,) but the little half-moon light keeps blinking and i can still use the keyboard to control the led typing light.
<collusion> i think i used to have to add acpi_support=s3_bios to the kernel config line.
<collusion> but i don't remember how to do that now; editing /boot/grub/menu.lst and running update-grub seems to nuke the manually edited menu.lst
<mjg59> collusion: This is suspend to RAM?
<collusion> yes, suspend to ram.
<collusion> i just ran through the https://wiki.ubuntu.com/DebuggingKernelSuspend instructions but the magic returned did not match any hashes.
<mjg59> collusion: Does it work with an older hardy kernel?
<collusion> uh. dunno.  i'm running 2.6.24-12-generic which is what came with this when i installed it.
<lamont> hooray for gnome-keyring and ssh-agent
<lamont> at least only one can grab the keyboard at a time...
<collusion> i used to be running 2.6.15-51 or something like that (whatever 6.06.2 had.)
 * lamont tries to remember how the hell to get his resolution back above 1280x1024
<mjg59> collusion: Ok. Next kernel update should fix it, with luck.
<mario_limonciell> mjg59, what's changing in the next kernel update that would be resolving this?
<collusion> oh, that's cool.  when's that due out?  was there a launchpad bug about it?  (there are so many suspend bugs in launchpad it is hard to find something specific.)
<pitti> mdz: with the e2fsprogs I'm just uploading, the remaining case of fsck usplash integration is fixed now as well  \o/ (feedback appreciated)
<ogra_cmpc> pitti, sexy !
<mjg59> mario_limonciell: Disabling the new DRM suspend code on i830 and i855
<mario_limonciell> ah
<tseliot> lamont: maybe you can use "gtf" to generate a modeline
<mjg59> pitti: Did you tweak the quirk blacklisting to run the quirks on i830 and i855?
<pitti> mjg59: yes, I did
<mjg59> pitti: Sweet, thanks
<pitti> mjg59: http://lists.freedesktop.org/archives/hal/attachments/20080326/db4dd274/attachment.patch is the current patch
<mjg59> pitti: Yup, looking at it now
<lamont> tseliot: given that ~/XFree86.0.log doesn't even mention 1680x1050....
<pitti> mjg59: I dropped the pm-utils patch again, it was too evil IMHO, and it fits much better in the hal script
<pitti> mjg59: evil in the sense of ignoring stuff you explicitly pass on the command line
<mjg59> pitti: Yup, that works
<tseliot> lamont: XFree86.0.log??? Oh, I thought you were dealing with Xorg.
<lamont> well, that could be an ancient file...
<lamont> heh.  aug 2004
<ogra_cmpc> pretty ancient
<mjg59> pitti: Hm. We probably want to hit 845 as well - that's 0x2562
<mjg59> And 865, 0x2572
<collusion> wow, this bug looks insanely complicated.  thanks guys.
<wasabi> bunch of stuff just started crashing in latest updates... gtk_toolbar_insert
<wasabi> Some critial assert that it's not really a toolbar
<lamont> dear gnome.  what have you done with my ssh-agent session?
<pitti> mjg59: thanks; http://bazaar.launchpad.net/~ubuntu-core-dev/hal/ubuntu/revision/223
<mjg59> pitti: Win, thanks
<pitti> ergh, "quirs"
<pitti> fixed
<stgraber> The Hardy Heron on my house :) http://www.stgraber.org/download/heron.jpg
<ScottK> dholbach: For the really-fix-it problem about multiple affected packages, you could at least not include the bug for packages marked Invalid or Fix Released.
<dholbach> ScottK: oh.... it should filter them out - if that'S not the case, I can fix it
<dholbach> ScottK: made a note of that and bug 204895
<ubotu> Launchpad bug 204895 in harvestman "Packages failed archive rebuild test possibly due to python-central transition" [Medium,In progress] https://launchpad.net/bugs/204895
<ScottK> OK.
<cody-somerville> slangasek, http://iso.qa.ubuntu.com/qatracker/build/xubuntu/all :)
<lamont> Warning: Tried to connect to session manager, Could not open network socket
<lamont> what's ^^ that mean?
<james_w> lamont: when do you see it?
<lamont> firing up a new uxterm
<lamont> and then there's: Cannot mount volume. org.freedesktop.DBus.Error.AccessDenied
<pitti> lamont: sounds like you don't have a ConsoleKit session?
<pitti> lamont: ck-list-sessions is empty, I guess?
<slangasek> kagou: well, I think you want to check with the desktop team about their plans for who should be added to the sambashare group by default
<lamont> ** (ck-list-sessions:12147): WARNING **: Failed to get list of seats: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success
<pitti> -rwsr-xr-- 1 root messagebus 259016 2008-02-29 10:25 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
<pitti> lamont: just gotta love stuff that perror()'s errno==0...
<pitti> anyway, I need to run, cu!
<lamont> no worries
<slangasek> cody-somerville: great, publising
<kagou> slangasek, ok
<kagou> slangasek, can we talk about including "map to guest = bad user" in smb.conf ?
<slangasek> kagou: we can, but we should get input from the server team as well on that :-)  (zul, mathiaz, or soren, most likely)
<kagou> ok :)
<slangasek> I can't think of any reason that it wouldn't be a reasonable default behavior, but the server team may have another opinion
<kagou> as nautilus-share will be included bu default, and shares-admin removed, usershare will be used
<seb128> hey slangasek
<slangasek> seb128: hiya
<seb128> slangasek: so there is an another issue with the shares-admin to nautilus-share switch
 * slangasek braces himself :)
<seb128> slangasek: what happens to users who configured shares using the old way once they upgrade?
<seb128> slangasek: they will have no way to unshare those
<zul> slangasek: meh...how secure is it?
<slangasek> seb128: hmm.  I'm not sure how avoidable that is, how would you then distinguish shares that were added using shares-admin from those that were added by hand?
<slangasek> zul: map to guest = bad user?  All that does is say that if the client provided an unknown username, the connection is automatically mapped to guest access
<seb128> slangasek: well, worded differently "do we consider that as an issue and have a migration plan or just write something in the upgrade notes about it"?
<slangasek> zul: not really a security issue, it's just a question of choosing between two sometimes-awkward behaviors
<slangasek> seb128: I think "upgrade notes" is best here - I don't see that there's any safe migration path, you can't just migrate all the shares to usershares without the risk of suddenly making some shares editable by users that weren't meant to have access to them
<seb128> slangasek: alright, what I though, I was just checking
<zul> slangasek: I dont really have a problem with it but you might want to check with mathiaz, soren is off
<mathiaz> slangasek: which scenarios do you refered to when you say "two sometimes-awkward behaviors" ?
<kagou> after many tests, with xp clients and ubuntu clients i can say that "map user guest  = bad user" is a definitively great enhancement on sharing folders/informations with samba under Ubuntu
<slangasek> mathiaz: if you map to guest on bad user, some clients won't give you any straightforward way to undo a mistyped username
<slangasek> mathiaz: if you *don't* map to guest on bad user, some clients won't give you any straightforward way to choose guest access :)
<kagou> hacking nautilus-share to prompt for smbpasswd will be the last step to have a fully working samba share system since ...  euh ... we never had a fully working samba share system ^^
<kagou> sladen, if you map... wich clients are you talking about ?
<kagou> sorry i mean slangasek
<mdz> pitti: thanks!
<slangasek> kagou: off the top of my head, I don't remember; some versions of Windows, though
<kagou> not xp clients, i'v tested. wrong user/pass don't allow to enter in non guest shared folders
<kagou> so each time xp clients try to enter in it , user+pass is asked
<kagou> until good login is provided
<slangasek> kagou: er, the problem is what happens when you connect this way to a share that *does* allow public access, but you want to connect as an authenticated user
<mathiaz> slangasek: isn't the authentication process decoupled from authorization in smbd ?
<seb128> kagou: so share have different access mode depending on whether you are guest or using an user
<seb128> s/so/some
<slangasek> mathiaz: in what sense do you mean?
<kagou> slangasek, using usershare, and allowing guest cause no problem to enter in it with xp client 'loged or not)
<slangasek> kagou: connect to a public share from XP; type in a wrong username; get mapped as a guest; now change the user you're connected as so that you can edit files.  How do you do this?
<slangasek> how do you correct a typo'ed username when samba agrees to map your access to guest?
<mathiaz> slangasek: I meant that authentication uses the share your want to access to check whether you can connect as anonymous ?
<kagou> slangasek, allowing writable share is done with usershare for all the world (guest) or require login. If this is requiring login, you can't enter in it without providing user+pass inforÃ¹ations
<kagou> folders protected by password are not browsable by guest
<mathiaz> slangasek: reading smb.conf and the map to guest option
<mathiaz> slangasek: the paragraph after the list of options for map to guest
<slangasek> mathiaz: yes; the authentication is done, and you're either authenticated as a user or mapped to a guest or given a "wrong password" error; and then if you're authenticated, samba then checks the share permissions and gives you a permission denied if you don't have access
<slangasek> kagou: oh, true, I didn't think about that limitation of usershares
<seb128> slangasek: right, but we don't provide a way to configure shares to allow password protected and anonymous login and act differently anyway
<kagou> seb128, actualy shares-admin neither (it's buged) ;)
<slangasek> kagou: well, it does cause problems for clients in the *general* case, when you need more advanced permission controls than what nautilus-share provides access to
<mathiaz> slangasek: so now - if we enable Bad User by default - and someone creates a non-anonymous share - a client connects to the server and gives a wrong password, he will be mapped to anonymous rather than being asked for a new password ?
<slangasek> seb128: yes.  So I agree this is not an obstacle for the current implementation
<slangasek> mathiaz: "map to guest = bad user" means this only happens if they provide a wrong *username*, not just a wrong password
<seb128> mathiaz: if anonymous is authorized
<slangasek> mathiaz: and anyway, when they're mapped to anonymous, they still won't be able to connect if the share isn't public, so the client will handle this permission error by asking for a different username/password
<slangasek> mathiaz: so I concur with kagou that, in the case of nautilus-share with its limited ACL interface, "map to guest = bad user" is not a UI problem
<slangasek> cody-somerville: images are published, I leave it to you to announce where you think it's appropriate (I'm not going to send a separate mail to ubuntu-announce for these two images)
<cody-somerville> aye
<kagou> slangasek, mathiaz adding this line will close Bug #32067
<ubotu> Launchpad bug 32067 in samba "public Samba SMB shares cannot be accessed anonymously from Windows XP, a password prompt appears" [High,In progress] https://launchpad.net/bugs/32067
 * slangasek nods
<azeem> slangasek: so, what about opensync, will it get dropped from hardy?
<azeem> who will make a decision?
<slangasek> azeem: what do you recommend?
<slangasek> (I have a personal bias here, so may defer to another member of the release team for the final decision)
<mathiaz> slangasek: hum... I don't see any problem with setting map to guest = bad user
<azeem> I never tried kitchensync, but Mandriva seems to think it's good enough as gui
<azeem> in any case, I don't think hardy should ship with 0.19
<azeem> if it's not possible to update to 0.22, I'd recommend dropping it
<slangasek> azeem: do you think updating to 0.22 is reasonable?
<slangasek> I don't have a bias wrt dropping 0.19 since it's not useful to me, but I do want 0.22 in :-)
<azeem> I didn't get any more feedback about the PPA packages, so it's really hard to say.  Windows Mobile devices won't work unless a miracle happens, that's for sure
<calc> grr i can't even get to the OOo bug tracker :\
<kagou> mathiaz, Glad to hear it ^^
<calc> i need someone that knows how to use bzr
<calc> i am getting weird stuff
<james_w> calc: can I help?
<calc> james_w: hopefully :)
<azeem> slangasek: AFAIK, the kitchensync currently in hardy is not the one used by Mandriva, but I'm not sure
<calc> james_w: i'm trying to use bzr in my build tree for OOo and it is claiming that i have removed files, but i didn't use bzr rm to remove them
<calc> james_w: it was due to uuencoding for diff.gz
<azeem> slangasek: ah no, it apparently is
<calc> james_w: when i went back to uudecode them to commit for bzr it now claims i have removed them and that they are also in unknown status as well
<calc> james_w: so is bzr just too smart for its own good?
<slangasek> azeem: the GUI doesn't really interest me personally... obviously it's interesting to a wider end user audience if there's a GUI, but there's no way kitchensync is going to be part of the desktop task or anything
<azeem> slangasek: of course
<calc> james_w: from what i recall with subversion you have to explicitly tell it to remove stuff from your tree, eg svn rm foo, but it seems bzr wants to do it anytime it sees a file disappeared
<james_w> calc: yes, bzr does autoremove files, there's some debate about whether it should
<james_w> calc: this isn't an svn checkout is it?
<kagou> slangasek, seb128 will contact author of nautilus-share to see if he can add a smbpasswd gui to his tool.
<james_w> calc: but as to why you get removed and unknown, I'm not sure.
<kagou> can we hope to have map to guest in smb.conf soon ?
<slangasek> azeem: so I think the real questions are: 1) does 0.22 meet the use cases that 0.19 is currently satisfying? 2) what does 0.22 give us over 0.19? 3) how much work is it going to be to get the polish on the integration done to the point where 0.22 packages are a satisfactory replacement for hardy?
<slangasek> zul: maybe you'd like to do the upload for the 'map to guest' change?  so you can see how slick the new ucf handling really is ;)
<calc> james_w: no its a bzr checkout
<zul> slangasek: sure :)
<slangasek> kagou: meh, I don't think nautilus-share should have a smbpasswd gui, I think we need a fix so that smbpasswd is integrated with PAM by default
<calc> james_w: it autoremoved them automatically :( then i uudecoded the removed files to have it check them back in since some changed and it now thinks they are removed and unknown
<calc> james_w: so you autoremoving files is definitely a really annoying feature for packaging use
<james_w> calc: does bzr revert file and then make it have the one you want fix it?
<calc> s/you/yea/
<azeem> slangasek: part of the problem is that my harddisk space is pretty low so I don't have a hardy installation currently to properly test this.  I'll try to remedy this on the weekdn
<calc> james_w: that probably will work, i would imagine, but is really annoying since i will have to do that after every rebuild
<james_w> calc: i.e. revert file will tell you there is a conflict I think, and then you can pick the one you want and delete the other, it should then work it out
<calc> james_w: since the binary files are removed on debian/rules clean
<calc> iow i would spending more time on reverting files than actually packaging
<james_w> calc: it's definitely a bug that it doesn't see them once you recreate them. Could you file a bug with the relevant parts of ~/.bzr.log please?
<kagou> sladen, you mean that samba passord will be the same as user password ?
<calc> so i think i will have to go back to only using bzr for final check in of changes for an upload
<kagou> arggl i mean slangasek
<azeem> slangasek: 1) 0.19 packages do not have a reasonable GUI either, and I am not even sure kitchensync works with it; besides 0.22 is considered very much superior by most people including upstream it seems
<slangasek> azeem: it would probably be helpful if you were to file a FFe using the process at https://wiki.ubuntu.com/FreezeExceptionProcess
<slangasek> kagou: yes, I believe that should be the goal
<calc> james_w: i rm'd the .bzr.log uudecoded the files then ran bzr stat and it doesn't really give anything useful in the log file
<calc> james_w: do i need to do something to make it more verbose?
<kagou> slangasek, oh, ok but since that (i don't think for hardy) if nautilus-share test for existence of samba password and prompt for one if it don't exist, this will be a nice work around before integration in PAM
<james_w> calc: "bzr -Dhashcache stat" is the only debug flag that seems vaguely useful.
<calc> james_w: returns nothing useful in .bzr.log
<slangasek> kagou: but how is the nautilus-share UI supposed to know *which* user needs an smbpasswd entry?
<calc> james_w: its probably easily reproducible though so i can just document how to cause the problem
<slangasek> kagou: if you share it as "allow other users", any user on the system could be the one that you need the password for
<james_w> calc: please do, a simple add rm touch test here doesn't show it.
<alex-weej> is Fx3 going to be in the final Hardy?
<kagou> slangasek, a shared folder, by usershare, requiring password, is only accessible with the user+pass from the user who have shared the folder. Only one user+pass is allowed to enter in it.
<slangasek> kagou: er, no, that's not what the "allow other people to write in this folder" flag is supposed to mean
<kagou> it's not allow other, it's allow guest or not, if not its user+samba pass
<slangasek> kagou: you're wrong, I've just tested a usershare here connecting as a different user
<zul> kagou: which lp bug # is that for the bad user stuff?
<slangasek> bug #32067
<ubotu> Launchpad bug 32067 in samba "public Samba SMB shares cannot be accessed anonymously from Windows XP, a password prompt appears" [High,In progress] https://launchpad.net/bugs/32067
 * alex-weej has given away his login to many Windows XP machines because of that :P
<kagou> slangasek, from another user, with it's login+pass, different than the one who'v created the share ?
<slangasek> kagou: yes
<kagou> wow...
<kagou> bug or feature of samba
<slangasek> feature
<slangasek> to the extent that there's a bug, it's a bug of nautilus-share
<slangasek> because nautilus-share is what populates the ACL setting within the config, and is setting it to "Everyone:R" or "Everyone:F"
<calc> bug 207891
<ubotu> Launchpad bug 207891 in bzr "bzr thinks files are removed and unknown at the same time" [Undecided,New] https://launchpad.net/bugs/207891
<calc> there's my bzr eats OOo bug ;-)
<slangasek> talk about indigestion
<james_w> calc: do the uuencoded files have the same names as the binary ones?
<calc> james_w: they have .uu appended to the end
<calc> james_w: once uudecoded they have the same name as original
<calc> so i think it probably will need to have the smarts to realize if an autoremoved file reappears to take it out of auto removed status automatically
<james_w> that's what it should do
<calc> preferably it would be possible to turn autoremoval off as well
<james_w> and what it does in my testing, so I'm trying to work out what is different in your setup
<calc> but that doesn't affect me on OOo as long as this other part is fixed
<calc> ok i'll manually revert the removals and then uudecode and see it can make it happen again
<zul> kagou: uploaded
<james_w> calc: thanks, the .bzr.log from that may still be useful, even if it doesn't look so to you, so please attach it
<calc> james_w: ok
<calc> interesting this time it worked
 * calc wonders what is going on
 * calc hates non-repeatable bugs
<james_w> yup
<calc> i closed out my bug until i can make it happen again
<kagou> zul, thanks :)
<\sh> infinity: what do you need for enabling wine for building on lpia? dollars, beer, buildlogs? wine runs on lpia :)
<\sh> at least our package ;)
<asac> james_w: there?
<infinity> \sh_away: Can you mail me a reminder about it?
<lamont> jdstrand: 207912
<kagou> slangasek, mathiaz  and zul , thanks for closing bug #32067
<ubotu> Launchpad bug 32067 in samba "public Samba SMB shares cannot be accessed anonymously from Windows XP, a password prompt appears" [High,Fix released] https://launchpad.net/bugs/32067
<zul> kagou: np
<kagou> Good night
<DktrKranz> Mithrandir, bluez-gnome has a couple of irritating bugs which are fixed by new upstream version. Do you plan to request it in Hardy?
<jdstrand> lamont: thanks
<james_w> asac: yep
<asac> james_w: i wonder if there is a simple fix to make bzr bd automatically fetch an orig and put it to the tarballs dir :)
<james_w> asac: there is, write a watchfile :-)
<asac> no... i mean from the archive
<james_w> it should do that as well
<calc> doko: i'm uploading the preliminary stuff for you to take a look at
<asac> james_w: what do you mean?
<james_w> asac: you are using a recent version?
<asac> here i am using the one from the archive ... but let me check
<asac> looks like 0.92
<james_w> asac: the changelog for 0.92 says "* Also look for upstream tarballs in the archives. Do this in preference to the watch file, for the case where the upstream was repacked."
<james_w> so it should do it. you're not using export-upstream mode are you?
<asac> james_w: no ... i am just running bzr bd --merge
<alex-weej> are extended attributes enabled on ubuntu systems by default these days?
<james_w> asac: will 'apt-get source -y --tar-only package=upstream-version' fetch the tarball without an error code in your case?
<asac> trying
<asac> james_w: no ... neither apt-get source -y --tar-only  firefox-2=2.0.0.13+1nobinonly .... nor apt-get source -y --tar-only  firefox=2.0.0.13+1nobinonly work
<asac> firefox is the source package name
<asac> firefox-2 the binary package name
<asac> only firefox-2 works for plain apt-get source here
<asac> (well ... firefox will give you firefox-3.0 source)
<asac> the upstream version looks correct
<james_w> so it tries to use the source package name
<asac> thats wrong in the first place i guess ... and using upstream-version doesn't work as well :/
<james_w> is this a problem with apt where it will prefer getting the source for a binary package of that name over the source package of that name?
<asac> james_w: i am not sure. does apt-get source SOURCE_PKG_NAME work at all?
<james_w> ah, no, sorry, I misread, it uses the binary version of the first package it finds that has the same upstream version
<asac> yes it does
<asac> hmm
<asac> that should work
<asac> but nothing happens here :(
<james_w> (cd /tmp && apt-get source -y --tar-only firefox=2.0.0.13+1nobinonly-0ubuntu1) works for me it seems
<james_w> Get: 1 http://archive.ubuntu.com hardy/universe firefox 2.0.0.13+1nobinonly-0ubuntu1 (tar) [34.9MB]
<asac> yes ...  but with full-pkg-version .. not upstream-version
<james_w> that's what it should be trying to use, unless I misunderstand
<james_w> I didn't actually write this code
<asac> james_w: https://code.edge.launchpad.net/~asac/firefox/ubuntu-2.0.0.x
<asac> that branch doesn't work for me
<james_w> asac: you might like to do (mkdir -p .bzr-builddeb && echo -e "[BUILDDEB]\nmerge = True" > .bzr-builddeb/default.conf && bzr add .bzr-builddeb && bzr ci -m"Make merge mode the default for the package")
<james_w> thanks, I'll grab that and have a look. Off to the pub now though, so it will be tomorrow probably, sorry.
<asac> thx
<LaserJock> bryce: congrats, about time ;-)
<bryce> LaserJock: thanks
 * slangasek shakes his fist at people trying to induce pitti to implement package-specific apparmor hacks for things that belong in the apparmor abstractions
<slangasek> jdstrand: new apparmor bug for you, then :)
<jdstrand> slangasek: you referring to cupsys?
<jdstrand> bug #207912 ?
<ubotu> Launchpad bug 207912 in cupsys "apparmor profile needs additions for nsswitch.conf" [Medium,Invalid] https://launchpad.net/bugs/207912
<slangasek> jdstrand: I'm referring to the bug about nss backends that for some reason ended up assigned to cupsys, yes
<slangasek> this is not cupsys-specific by any means, it should be part of the nameservice abstraction
<jdstrand> slangasek: I haven't looked at the cupsys profile yet, but figured that was all I was going to do to it
<jdstrand> slangasek: so you saved me a couple minutes ;)
<slangasek> heh, k :)
<slangasek> yeah, cupsys's profile is still correct, in this regard - it's just that apparmor is missing a few files in the nameservice abstraction
<slangasek> for the db and ldap backends
 * jdstrand nods
<siretart> is some uptodate d-i documentation for hardy online somewhere?
<calc> doko: done uploading now
<LaserJock> siretart: actually the doc team would like to know that too :-)
<siretart> :/
<LaserJock> all we have on help.ubuntu.com is a link for Edgy
<siretart> that isn't really up-to-date... hmm
<calc> anyone know how to find out what to put in /usr/lib/mime/packages/foo for a given example document?
<asac> siretart: for bug 50214 it looks more and more like it would be a blessing to wpa_drv_set_ssid _before_ doing the scanning in ap_scan 2 mode. you see any issues with that?
<ubotu> Launchpad bug 50214 in network-manager "can't connect to hidden network" [High,Confirmed] https://launchpad.net/bugs/50214
<asac> siretart: (in wpasupplicant)
<calc> also in /usr/share/applications/foo.desktop MimeType= ?
<calc> i need to update the types and i have example files but i don't know what to run against them to find out the official name of the MimeType
<asac> siretart: at least iwl drivers don't find any bssid when scanning a hidden network if the essid has not been set in advance
<asac> and i get the feeling that its the case for more
<siretart> asac: I'd be curious if that also happens with wpasupplicant 0.6.3 (which can be found in my PPA, and happens to work just fine with ath5k and WPA-PEAP, but I haven't tested hidden ssids, though)
<asac> siretart: this is just for hidden
<siretart> right.
<asac> siretart: and given that i had similar "hidden" complains with my nm 0.7 + wpasupp 0.6.x combo
<siretart> in general I recommend users playing with the ap_scan parameter
<asac> i doubt that its fixed
<siretart> default is 1, users have reported success with setting ap_scan to 2
<asac> siretart: which comment do you refer to?
<siretart> however AFAIK, nm doesn't offer a gui for setting the ap_scan parameter
<asac> siretart: the ap_scan is not a problem
<siretart> it isn't?
<asac> the problem is that ap_scan 2 doesn't even succeed if to find the bssid if you don't do a iwconfig essid XXXX before
<asac> and wpasupplicant doesn't do that (from code)
<asac> currently i forcefully do that in NM for some chipsets, but i'd prefer to move that to wpasupplicant as it looks more and more like ap_scan 2 always needs that
<asac> (in gutsy i did that for _every_ driver and thats how i explain that there are still users reporting regressions)
<asac> siretart: from what i see it would be one line in wpa_supplicant.c :)
<siretart> asac: you mean in wpa_supplicant_scan()?
<asac> YES
<asac> oops
<wasabi> launchpad_integration_add_bonobo_ui(0x6f3f00, 0x419b95, 8, 11, 0**
<wasabi> ** Gtk:ERROR:(/build/buildd/gtk+2.0-2.12.9/gtk/gtktoolbar.c:3021):IA__gtk_toolba
<wasabi> suspecting that's a problem. =/
<wasabi> Explains why most of my apps are crashing, anyways!
<siretart> asac: I don't see concrete problems with that. as a naive guess, I think a short sleep to settle things down on 'strange' drivers wouldn't be a bad idea. However, I'm not too experienced with that area of wpasupplicant, TBH
<asac> yeah ... i have to think about it as well
<alvarezp> Hi. I've noticed that some fonts in Hardy don't show anymore under xfontsel. Bitstream Vera Sans is affected. Gutsy Gibbon worked correctly. Where is this configured, or what package takes care of this? I'd like to file a good bug report.
<keescook> lamont: 207912> /var/lib/misc ?  that's goofy.  ldap is already handled in the nameservice abstraction -- which paths should be added?
<slangasek> keescook: according to the bug report, /etc/ldap.conf (not just /etc/ldap/ldap.conf)
<slangasek> er, or the other way around
<slangasek>   # all openldap config
<slangasek>   /etc/openldap/*         r,
<slangasek> keescook: ^^ buggy, wrong path
<slangasek> and /var/lib/misc isn't goofy, it's the longstanding path for the db backend
<keescook> slangasek: well, it may be the path, but it's still goofy.  :)
<slangasek> well, ok. :)
<slangasek> blame BSD!
<keescook> slangasek: what's the expected file mask?  /var/lib/misc/*.db ?
<jwendell> slangasek, any news on bug 201440?
<ubotu> Launchpad bug 201440 in anjuta "Please sync anjuta (universe) 2:2.4.0-2 from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/201440
<slangasek> keescook: yes
<slangasek> jwendell: none from me, but I'm not on archive duty today
<salty-horse> shouldn't this be a priority? for some production systems, those 7 minutes are important: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/157608/
<ubotu> Launchpad bug 157608 in ntp "Adjust Time -> Sync with Internet Time Servers never syncs." [Undecided,Confirmed]
<crevette> salty-horse: do you use Network-manager with Wifi ?
<salty-horse> no. I'm connected directly to the router
<salty-horse> (cable)
<crevette> (I'm reading the bug)
<crevette> I have this, I thought it was sometyhing with ntpupdate ruinning too early in the stack
<dmb> is oo going to be in hardy?
<dmb> oo 2.4 i mean
<seb128> crevette: ntp and ntpdate are different things
<xivulon> slangasek, is anything moving re metalinks?
<Fujitsu> Is Nautilus meant to bug me to install Samba every time I want a directory's properties window?
<slangasek> xivulon: mmm, I've been waiting for the first cut of the code to populate the mirror list, let me talk to the webmaster again
<seb128> Fujitsu: no, that would be a bug in the nautilus-share patch mvo did
<Fujitsu> seb128: OK, thanks, I'll look for a bug.
<crevette> seb128: i'm puzzled because bother are called in the same script (/etc/network/if-up.d/ntpdate)
<Fujitsu> Anybody know of a bug about Nautilus failing to copy directories to/from SFTP shares after a while? Often after finishing one directory, the SFTP thing will hang, eventually giving a DBUS error.
<seb128> crevette: what this one does it stopping ntp, calling ntpdate and starting ntp again
<crevette> seb128: ah yeah, them can't be run at the same time, I had the issue on RH and solaris
<seb128> Fujitsu: yes, several useless bugs with similar not clear descriptions
<Fujitsu> seb128: Lovely.
<seb128> Fujitsu: that's likely fixed in gvfs svn, a new tarball should be rolled soon
<seb128> Fujitsu: but since nobody managed to describe how to trigger the issue and it doesn't break on my installations I didn't bother trying
<xivulon> slangasek, if you want to you can use static metalinks just pointing to cdimage daily for the time being and replace them later
<Fujitsu> seb128: I've been able to reproduce it for a couple of weeks on my laptop. I just reinstalled (I managed to destroy a couple of filesystems will stuffing around with LVM), and am able to reproduce it again.
<Fujitsu> There's no easy way to trigger it; sometimes copies just don't start, sometimes they hang after finishing one directory (in the same place each time)...
<seb128> Fujitsu: what are the steps to trigger the issue then?
<slangasek> xivulon: well, tbh I haven't even learned how to write a valid metalink file because writing the generation code has been delegated, so I probably can't sanely create a static metalink file on my own either :)
<xivulon> you can copy the ones in http://wubi-installer.org/metalinks/8.04 , they are a bit lean (no md5, 1 mirror)
<slangasek> xivulon: thanks, I'll try to push that out later this afternoon then
<xivulon> also there is a link in the bug for a couple of scripts and if you need any help I can contact the devs in the metalink forum (one of them replied in the comments)
<bryce> ppa question - I'm trying to put older versions of the -intel driver into my ppa for users to test and help narrow down which upstream patches caused issues
<bryce> however, when uploading an earlier version, I got a rejection:
<bryce> Rejected:
<bryce> xserver-xorg-video-intel_2.2.0+git20080318.ac763634-bwh1.dsc: Version older than that in the archive.
<bryce> 2:2.2.0+git20080318.ac763634-bwh1 <= 2:2.2.1-1ubuntu3
<bryce> do I need to fake ppa out by numbering it from the latest version or something?  (seems kludgy) or is there a way to force ppa to allow old packages?  Or should I not be using ppa in the first place?
<TheMuso> bryce: Do you have an earlier version in your PPA already?
<Fujitsu> bryce: Increment the epoch, perhaps. PPA version-ratchets like primary, though you can remove packages.
<bryce> I'd built an earlier version a month ago, but deleted it; no difference
<TheMuso> hrm
<bryce> oh well, guess I'll go with the epoch bump.  that's less kludgy than futzing the version number
<slangasek> but also less reversible :)
<Fujitsu> slangasek: It's a PPA. They're erasable.
<slangasek> Fujitsu: not from the systems of those who've installed it <shrug>
<bryce> slangasek: yeah that's my worry... but I can just document around it
<Fujitsu> slangasek: They'd be downgrading packages otherwise; I'm sure they can install the primary archive ones again.
<mjg59> bryce: Hey - any idea if the Poulsbo kernel code is able to bring the video back up itself after S3?
<slangasek> Fujitsu: they'll have to downgrade packages again once the official fix is released to the archive
<bryce> mjg59: heya.  Not offhand.  (I'm also not sure how to test S3 on the test equipment)
<Fujitsu> slangasek: I meant that they also had to downgrade to the PPA package in the former case. THey have to downgrade either way, so I don't see what's so terrible about having to downgrade.
<bryce> slangasek: yeah I'd sort of prefer they had to downgrade to install my version, so if after testing they forget to restore to the original (or *gasp* prefer to use the old version), they won't get updates again after that, and it may not be clear why they're not
<mjg59> bryce: Ok. Do you know who would know? :)
<bryce> mjg59: amitk would probably know
<slangasek> Fujitsu: one can conceivably rig a version number that won't require downgrades either way, if you ship all the git bisecting bits in a .diff.gz ;)
<mjg59> bryce: Just chatted - I don't think he did
<Fujitsu> slangasek: True, but that sounds bad.
<bryce> mjg59: hrm... then next would be Calvin, via David Mandala and Don Johnson
<mjg59> Ok
<slangasek> Get:2 http://mirrors.cat.pdx.edu hardy/universe kde-icons-oxygen 4:4.0.2-0ubuntu2 [45.4MB]
<slangasek> what a hateful build-dependency
<Fujitsu> How is an icon set 50MB?
<RAOF> How is an icon set a build dependency?
<bryce> Calvin is the tungsten graphics rep.
<slangasek> why is it a build-dependency? :)
<Fujitsu> How is an icon set?
<seb128_> re
<seb128_> I was saying
<seb128_> <seb128> bryce: I would not use an epoch
<seb128_>  bryce: use current-version.is.really.version rather
<seb128_>  bryce: so they will get next upgrades
<bryce> wow, this really reduces ppa's usefulness
<seb128_> I think that's a bug
<seb128_> ask to cprov-out about it
<seb128_> or I would consider it a bug rather
<TheMuso> Hrm whatever is responsible for managing brightness etc is not showing the little graphic when I adjust the screen brightness on my notebook like it used to...
<mjg59> TheMuso: What hardware?
<TheMuso> mjg59: Thinkpad R50.
<TheMuso> no wait, an update has fixed it.
<mjg59> Ha, excellent
<LaserJock> easy fix ;-)
<LaserJock> mine just keeps going up and down if I want to manually set the brightness
<mjg59> LaserJock: What hardware?
<LaserJock> it's an HP Pavilion dv6000ish with mostly all intel hardware
<LaserJock> I assume it's the "normal" behavior
<mjg59> Ah, there's one fix I've pushed for the next kernel that may help there
<LaserJock> so if I manually set the brightness with special keys or applet it should stay there?
<mjg59> Yes
<LaserJock> that's handy, I just thought it was a missing feature
<seb128_> what do you call stay there?
<LaserJock> well, like if it resets the the gnome power management settings
<LaserJock> *to the
<mjg59> Oh, I see
<mjg59> If you're idle, it'll eventually dim it if you have that box checked
<seb128_> the dim is normal
<LaserJock> I would have thought that manually changing the brightness would override other settings
<seb128_> what is a bug is that changing the backlight value using the key doesn't update the stored value
<slangasek> how about those of us who don't have the 'dim when idle' box checked but still get dimming? :)
<seb128_> or rather than it doesn't back to whatever you were using when you are back
<slangasek> oh, correction, I do have it checked
<slangasek> teehee
<LaserJock> so if I uncheck the "dim when idle" then it should just stay?
<slangasek> what's frustrating to me is that I don't have control over the degree of dimming; so if it dims when I'm on battery, and I manually adjust it, then it dims for idle, then I unidle, I have to adjust again
<LaserJock> slangasek: exactly
<seb128_> slangasek: right, that's what I wrote
<seb128_> you have the control of the dim value though
<slangasek> seb128_: ah, so you did :)
<slangasek> seb128_: where?
<seb128_> it just doesn't go back to whatever you were using
<slangasek> I don't see anything under g-p-m that lets me control how much it dims
<seb128_> gconf-editor, /apps/gnome-power-manager/backlight/idle_brightness
<slangasek> ah, heh
<slangasek> go go GNOME HIG
<seb128_> I though that was somewhere in the dialog
<slangasek> :)
<mjg59> seb128_: Nope, just AC and battery defaults
<seb128_> mjg59: that's the value it's using on idle
<seb128_> it's not clear to me how it's supposed to work
<seb128_> the applet updates the gconf keys
<seb128_> where changing the backlight using the keyboard doesn't
<mjg59> I'd guess the idle value is some function of the set values
<mjg59> There's nothing in the dialog to let you change the idle value
<seb128_> indeed
<seb128_> I consider gnome-power-manager quite buggy
<seb128_> and upstream is not really responsive
<LaserJock> is that the wonderfully consistent dialog "Dim display brightness by" and "Set display brightness to"?
<tjaalton> when it dims my display and I resume working, it dims it even more :)
 * slangasek grins
<TheMuso> bryce: BTW congrats.
<bryce> TheMuso: oh thanks
* mthaddon changed the topic of #ubuntu-devel to: Launchpad is going down in from 00:00 UTC until 02:00 UTC for a code update | Archive: Feature Freeze, DocumentationStringFreeze | Ubuntu 8.04 LTS Beta released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopme
 * slangasek nods at the topic change and queues up his work locally :)
<slangasek> asac: hmm, no n-m upload yet?  (maybe I've lost track of the days...)
<seb128> slangasek: do you have an user friendly description of sambashare for gnome-system-tools? ;-)
<slangasek> seb128: "Share files with the local network"?
<slangasek> or maybe "Manage network file sharing"
<seb128_> re
<seb128_> hate my dsl provider
<seb128_> slangasek: dunno if you received what I wrote
<seb128_> <seb128> works for me
<seb128_>  thanks
<seb128_>  you share files "with" the network and not "on" the network?
<slangasek> seb128_: I believe either is grammatically valid, but "with" the network has nuances that remove some ambiguities
<slangasek> did you see my alternative suggestion? "Manage network file sharing"
<seb128_> no I didn't
<seb128_> hum
<slangasek> either is ok with me :)
<seb128_> I think I like the Share files option better
<slangasek> ok
<seb128_> I'll use this one
<slangasek> seb128_: hrm, any chance you can comment on bug #203328?  nautilus, tracker, and eog are all reverse-dependencies - do you know what the implications are of this upstream API change?
<ubotu> Launchpad bug 203328 in exempi "[Sync request] exempi source package from Debian sid" [Wishlist,New] https://launchpad.net/bugs/203328
<seb128_> slangasek: debian has the new version for over 3 weeks and we didn't get any nautilus or eog issue due to exempi that I know, they do a really limited use of it anyway
<slangasek> ok
<seb128_> slangasek: I would say it should be safe to sync, we didn't get any bug about the ABI breakage anyway
<slangasek> +#define XMP_OPEN_OPNLYXMP XMP_OPEN_ONLYXMP
<seb128_> so the ABI changed and fixed seems to not be used or create really used in those applications
<slangasek> heh, that's the only change
<slangasek> so that's entirely trivial
<seb128_> right
<slangasek> syncbugbot++
<seb128_> ;-)
#ubuntu-devel 2008-03-28
<emgent> hello
* mthaddon changed the topic of #ubuntu-devel to: Archive: Feature Freeze, DocumentationStringFreeze | Ubuntu 8.04 LTS Beta released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopme
<StevenK> mthaddon: You looked to have chopped off the topic
<mthaddon> StevenK, oops - had removed the launchpad outage message I'd added
<StevenK> mthaddon: Yup, I think the outage message caused the topic to be cut off in the first place.
* mthaddon changed the topic of #ubuntu-devel to: Archive: Feature Freeze, DocumentationStringFreeze | Ubuntu 8.04 LTS Beta released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<StevenK> Yay
<mthaddon> :)
<emgent> heya gang :)
<mthaddon> xchatlogs are a wonderful thing...
<emgent> irssilogs too :P
<TheMuso> I'm assuming that when one tries to upload the first package to a recently activated PPA and it FTBFS due to index files in the PPA not being found is a known bug?
<RAOF> Yup.
<Fujitsu> TheMuso: Yeah, and somebody decided it wasn't important enough, so they untargetted it...
<Hobbsee> TheMuso: not deemed important though.  just retry the build.
<Fujitsu> TheMuso: Retry the build in 5 minutes.
<TheMuso> Fujitsu: How? Can I do that from the interface now?
<RAOF> Yeah.  On the FTBFS page there's a "retry build" button.
<TheMuso> Thanks./
<Hydrant> Hey all,  I'm looking to do some open office development, has anyone setup an OO dev environment on Ubuntu here?
<_MMA_> Hydrant: calc is who you wanna talk to.
<Hydrant> calc: do you have experience with OO dev environment on Ubuntu ?
<calugor> why KDE is so slow and consumes too much ram?
<calugor> gnome runs fine
<Hydrant> calugor: what's your definition of slow ?
<ScottK2> slangasek: Did you get the word from Riddell that it's OK to nuke kdepim-kde4?
<calugor> apps take a few seconds to start
<Hydrant> calugor: turn off some eye-candy
<Hydrant> calugor: what are specs on the machine ?
<calugor> :/
<_MMA_> Why GNOME is so slow and consumes too much ram? Fluxbox runs fine. :P
<Hydrant> calugor: there might be some services running that aren't needed
<calugor> p4 512mb ram
<calugor> _MMA_, fluxbox with gnome apps :D
<Hydrant> calugor: so you're running a pure KDE environment, are you running the same apps in both GNOME / KDE ?
<calugor> used kde apps while running KDE but perhaps there was someother stuff running in the backgroud
<Hydrant> calugor: KDE can be very fast if configured well in my experience
<Hydrant> calugor: it may be other things are going on that are hurting performance too
<calugor> http://www.psychocats.net/ubuntu/purekde
<calugor> I will try this
<Hydrant> calugor: I don't know that will do anything for you
<Hydrant> calugor: is the performance really so bad?
<calugor> after it started using swap , yes
<Hydrant> calugor: ah using swap eh
<Hydrant> calugor: with 512MB RAM it shouldn't
<Hydrant> calugor: are you running something fancy or just plain old KDE ?
<Hydrant> calugor: sorry to ask, what is your user level experience?  I don't want to water down answers or go too advanced either, if you give me an idea I can help more
<calugor> average
<Hydrant> calugor: did you check what else might be using memory?
<Hydrant> calugor: I guess you can use ksysguard to check that
<Hydrant> or KDE crash guard, whatever it's called
<calugor> xorg was 300mb
<Hydrant> calugor: something's up
<Hydrant> calugor: what video card?  Have you done something fancy since install?
<calugor> no
<Hydrant> calugor: oh, btw, AFAIK video memory is in that stat, I forgot
<Hydrant> calugor: you must have a 256MB video card or something ?
<calugor> yes, I will try again
<Hydrant> calugor: no, if I'm right it's not a problem
<Hydrant> calugor: ok... so it's going to swap... how big is your swap drive?
<calugor> 1.5gb
<Hydrant> calugor: how do you know it's going into swap, and how much swap is being used?
<calugor> I need to test again and pay attention to the ksysguard or whatever it is called
<calugor> thanks
<calc> Hydrant: back
<calc> Hydrant: what was your question?
<Hydrant> calc: hey
<Hydrant> calc: I'm trying to do some OO development on Ubuntu, and was curious if anyone had that setup
<Hydrant> calc: I mean, if I wanted to build OO with debugging support it looks like I have to compile myself
<calc> Hydrant: debug builds for all packages are already available
 * calc looks up url
<Hydrant> calc: thx
 * calc thinks the url should be in the default sources.list
<calc> https://wiki.ubuntu.com/DebuggingProgramCrash
<Hydrant> what's the package name ?
<calc> depends on which package
<calc> i think they append -dbg to end of each iirc
<calc> oh maybe -dbgsym
<calc> read the page :)
<Hydrant> k, I'm used to debian
 * calc thinks debian should switch to doing it this way :)
<calc> much easier you don't have to care about it in your packaging afaict
<calc> tbh i don't even know how it does it
<Hydrant> nice, installing now
<Hydrant> do you know by any chance why unoidl isn't in Ubuntu
 * lamont decides to reinstall the gutsy version of kobodeluxe... unless I can figure out how to get the gutsy graphics in the hardy version
<calc> Hydrant: no, hmm
<calc> Hydrant: i wouldn't be surprised if most uno stuff doesn't work in general though, since we have no stable free java yet
<Hydrant> calc: so Ubuntu might not be a good dev platform ?
 * calc keeps his opinion of java to himself
<Hydrant> haha... my opinion of Java is likely much worse than yours
<calc> Hydrant: feel free to file bug about missing unoidl, not sure why its not there
<Hydrant> calc: hrrm... if only compiling OO didn't take all night
<calc> i don't mind the language itself that much just the surrounding issues
<calc> Hydrant: hehe
<Hydrant> calc: JVM is the devil
<calc> i'm booting up my other ubuntu vm to look at upstream ooo
<Hydrant> calc: k, thx...
<Hydrant> calc: I've gotta get a project done tonight, kinda in trouble if I can't get OO working right
<calc> i thought i was going to get 2.4 uploaded today, heh yea right
<calc> Hydrant: what do you need to get working on OO?
<Hydrant> calc: if it's in heron I might be able to put it in
<Hydrant> calc: I've been working on adding some spread sheet functions to OO Calc... spent a week or so trying in PyUno, found a major bug with it today that blocks that
<calc> i got to my first bug which i thought was an easy one, fix up mime types, then found out shared-mime-info doesn't even support most Office mime-types :\
<calc> Hydrant: yuck
<Hydrant> calc: today I've decided to just go back to C++'s loving embrace, but now I'm missing unoidl :-(
<calc> Hydrant: if you want to do it with Ubuntu and it looks like you are having weird bugs your best bet would probably be to use the official sun version, but you will lose gnome integration
<Hydrant> calc: don't care about that
<calc> i don't see unoidl even on upstream version
<calc> where is it normally located?
<Hydrant> calc: this is my dev environment, actual target server to deploy to is running Arch
<Hydrant> calc: no idea, I'll check on another server
<calc> its not in /opt/openoffice.org2.4/program/uno*
<Hydrant> try slocate
<calc> i don't see it anywhere in /opt/openoffice.org2.4
<calc> slocate unoidl returns nothing
<calc> i think your mythical unoidl is just non-existant (or at least in 2.4)
<Hydrant> http://udk.openoffice.org/common/man/tools.html#unoidl
<Hydrant> methinks the OO docs are in shambles
<Hydrant> calc: so are you the OO maintainer?
<calc> maybe its an internal program that they don't ship
<calc> Hydrant: yea
<calc> because in the official sun debs its not there either
<Hydrant> calc: You have my deepest sympathies :-)
<calc> they have lots of internal tools that i think they don't generally package up
<calc> Hydrant: heh yea :)
<Hydrant> calc: but it ought to be in the SDK
<Hydrant> calc: arrgh
<emgent> hi calc :)
<calc> i don't see a sdk deb so it must be part of what they call core or testtool(?)
<calc> emgent: hi
<calc> the debs i am talking about are the sun debs by the way
<Hydrant> calc: where can I get official sun debs?
<calc> eg OOo_2.4.0rc5_20080312_LinuxIntel_install_en-US_deb.tar.gz
<Hydrant> calc: how broken ?
<calc> they changed their website yesterday so i am not sure how to get them now, looking
<calc> http://download.openoffice.org/other.html#en-US
<calc> there it is
<calc> http://openoffice.bouncer.osuosl.org/?product=OpenOffice.org&os=linuxinteldeb&lang=en-US&version=2.4.0
<calc> its only available for 32bit and doesn't upgrade cleanly so if you go to upgrade you might have to do juggling later
<calc> eg placing packages on hold, etc
<Hydrant> well, I'd remove existing OO altogether
<Hydrant> I've likely broken it anyways
<calc> and you won't have office 2007 support, etc
<calc> since upstream doesn't support it at all yet
<Hydrant> meh, who cares...
<calc> just noting things that upstream lacks ;-)
<Hydrant> thx
<calc> official OOo gets Office 2007 support in 3.0
<Hydrant> speaking of lacking, I can't get the d/l to work
<calc> lol
<calc> i didn't try downloading it myself
<calc> it was just released today so that might be why
<Hydrant> the gods hate me
<calc> heh that was what i thought when i found all the missing support in shared-mime-info ;-)
<Hydrant> I'm getting the tar, hoping it's not source
<Hydrant> OO hurts my brain
<Hydrant> I spent all day tracking down a bug from 2004, that was "going to be fixed" in 2.0
<Hydrant> not only that... but the buggy source that never worked is on the wiki as an example of how to get this working
<Hydrant> ARRGH!
<Hydrant> k, I got a deb from a mirror
<bryce> my fiancee has been doing a lot of labels, cards, etc. etc. in OOo, and every time I have to redo the templates because they're off by part of an inch.  Extremely irritating
<bryce> plus OOo seems to have this fixation with A4, and pays no mind that my printer is set to print letter
<Hydrant> my personal favorite was the fact that fonts aren't stored in the OO file... so when we did a server upgrade the fonts changed in some inperceptible manner and broke all docs
<bryce> but at least it does the job...
<Hydrant> they were all aligned forms and had to be re-done
<bryce> makes me want to implement label printing support in inkscape though.  :-)
<Hydrant> but OO is working alright
<bryce> yikes
<Hydrant> overall it's alright, it's free, it's open source
<Hydrant> ... an obfuscator would be less confusing
<Hydrant> ... but open source
<bryce> there's an extraordinarily annoying bug where it doesn't have a <none> template
<bryce> so if you ever pick a business card template, you'll never be able to make blank business cards.  You must always have a template
<Hydrant> I've debugged more than my share of OO bugs
<Hydrant> Oh, I have a better favorite
<calc> bryce: file a bug http://www.openoffice.org/issues/query.cgi :-)
<bryce> I found if I used the "Attention:" template, it was easy enough to just backspace out the "Attention:" text from each card, and load from that
<calc> bryce: they are generally pretty responsive as long as you describe your problem enough for them to understand you
<bryce> calc, really?  Hmm
<Hydrant> ... debugging an OO BASIC script... you know how OO BASIC doesn't support threading, says so in the docs... I spent a week debugging a problem that wound up only being possible if it was a threading issue.... I wound up having to write an OS-like event dispatcher with interrupts and everything to make sure the stupid thing wasn't threading... ah well
 * calc is going to check on wordperfect then file mime bugs on it and be done with mime crap for now
<Hydrant> mime issues are a royal pain
<calc> Hydrant: yea have to fix them in both OOo desktop/mime files and in shared-mime-info
<calc> Hydrant: i just filed four high priority bugs to fix them for Office 2007 file types
<calc> i installed xp/office 2007 and saved out every format it supported and tested them and lots weren't supported
<calc> er weren't supported by shared-mime-info
<Hydrant> calc: hrrm
<Hydrant> calc: I'm sure that kinda testing is appreciated
<calc> Hydrant: yea i should have done that testing a few months ago
<Hydrant> I've been impressed with how little thinking I have to do with Ubuntu
<calc> now its going to be hard to get it supported before release :-\
<calc> of course it probably doesn't work on any other linux either, since its an upstream bug
<Hydrant> I've run Gentoo and Debian for years... for my personal desktop now I prefer Kubuntu only for not having to do so much work just to manage things
<Hydrant> calc: not to say it works in others, more so that you have to build it yourself as you go
<Hydrant> calc: I'm more used to a blank slate and building a lot of things from scratch
 * calc used debian from 1998-2004, slackware/redhat/etc before that
<Hydrant> calc: ooh, hardcore
<Hydrant> calc: I've only been using Linux since 2000
<calc> thats a pretty long time pre gnome 2.0 anyway ;-)
<Hydrant> calc: mostly as a user
<Hydrant> calc: yup... thats tldp days
<calc> i started using linux in high school, but that was a long time ago (1995)
<Hydrant> calc: I've learned that most Linux "gurus" who have used it for 3 weeks don't know of tldp, so it's a good litmus test nowadays to weed out people
<Hydrant> calc: not that that's important, I just get irritated when I get lectures on Linux from people who use it for 3 days... but now I'm just ranting on
<bryce> calc, huh, there's already a ton of bug reports about templates
<calc> tldp? if i know what you are talking about i thought it was just LDP
<Hydrant> calc: true
<Hydrant> calc: I wonder whatever happened to it, back in the day it was the most critical thing ever
<calc> bryce: yea templates were left out but it was other things besides that
<bryce> aha, here's the one where you can't do a <none> template - 42873
<calc> bryce: works file format, xml document format needs subclassing, etc
<calc> at least it probably could help to subclass it
<calc> if i understand how mime works at least
<Hydrant> I got 2.4 on now
<calc> Hydrant: linux got easy to use? ;-)
<bryce> ah, and here's one about the offsetting - 62349
<Hydrant> calc: yeah... I always Linux to succeed, now that it has I kinda miss the old days :-)
<calc> bryce: lp bugs or fdo bugs?
<bryce> calc, oo.org bugs (searching that link you sent)
<calc> bryce: oh ok
<bryce> so looks like pretty much all the issues I ran into already have bug reports
<calc> oh no, OOo Later means... you are screwed :-\
<calc> i think it depends on who looks at the bug if it gets marked to be fixed or marked to go to bug hell
<bryce> ah well
<bryce> probably I can talk one of my minions into implementing it in inkscape for me ;-)
<calc> once i get access to the ubuntu master bug i can start adding things people want to get fixed and we can push that list
<calc> convince upstream to consider those bugs higher priority
<Hydrant> calc: how do I get the SDK on ?
<Hydrant> It only seems to have RPMs
<calc> Hydrant: not sure, i thought everything was in each download
<Hydrant> nope :-(
<Hydrant> how is ubuntu oo-sdk made?
<calc> is it in the regular rpm download?
<calc> Hydrant: just from regular compile
<Hydrant> k, I'll alien and hope for the best
<slangasek> ScottK2: yes, I did; already nuked, thanks :)
<dholbach> good morning
<TheMuso> Hey dholbach.
<dholbach> hiya TheMuso
<dholbach> who can help me debugging bug 208113?
<ubotu> Bug 208113 on http://launchpad.net/bugs/208113 is private
<dholbach> hum
<dholbach> somehow debuild crashes on me on amd64 (libperl S_regmatch)
<dholbach> when I try to valgrind it, memcheck crashes in a similar way as bug 150477
<ubotu> Bug 150477 on http://launchpad.net/bugs/150477 is private
<dholbach> I just did a memory test and all seems good :/
<tjaalton> calc: the OOo rc5 doesn't yet support the 3D effects for impress?
<bryce> have you guys ever seen the error msg "Tainted filename: '<type 'file'>'." in ppa uploads?
<bryce> oh wait I see
<pitti> Good morning
<seria-mau> sorry for not being on topic, but: i just tried to install 7.10 on a disk with dm-crypt + lvm encryption without formating my dm-crypt partition. alternate installer. i choose to setup encrypted lvm devices and was asked for a passphrase twice(!)
<kagou> hi
<seria-mau> now i cant access the two logical volumes in this dm-crypt partition. i think the installer called luksformat on this dm-crypt partition and destroyed the lvm information
<doko_> calc downloading, build will take a a time ...
<calc> doko_: ok
<warp10> Good morning
<devilsadvocate> i've got a little package management question : I have KDE4.0 installed on hardy from the repositories, but I need QT 4.4, and so I'm compiling it all from svn. Now, how do I remove the KDE4 that i installed from the reopsitories?
<tomahasamoot> I just installed kubuntu 8.04 alt amd64, and it has the same bug that 7.04, and 7.10 had:
<tomahasamoot> https://bugs.launchpad.net/ubuntu/+bug/86666
<tomahasamoot> also why doesn't it install firefox by default?  honestly, I doubt that many people waste their time w/ konq
<Hobbsee> tomahasamoot: ....because it's a gtk app...
<tomahasamoot> Hobbsee: that's true, but the answer is to do the proper intagration, as it's the only real web bowser
<Hobbsee> tomahasamoot: feel free to help out.
<Hobbsee> and plenty of people use konq, only.
<tomahasamoot> Hobbsee: I'd like to see the break-down... as konq can't even do gmail, it's not a real contender for serious use... so I'm not sure what kind of useage pattern these konq users have?
<Hobbsee> gmail got fixed?
<Hobbsee> afaik, anyway
<tomahasamoot> that's what I was told, but it wasn't working when they said it was... I'll try again
<Fujitsu> Some people have sane email providers, I'm afraid. For them, Konqueror is an option.
<tomahasamoot> the point is that if it doesn't work for something so basic as gmail...
 * Hobbsee wasn't aware that "basic" meant "littered with ajax and other bits of that nature"
<tomahasamoot> no... still not working
<tomahasamoot> basic in the sence that it's one of the most important websites out there
<Hobbsee> does gmail render correctly in opera/safari/{other non-mozilla/ie browsers}?
<Hobbsee> i can't quite remember
<tomahasamoot> Hobbsee: I don't know
 * Hobbsee recalls something about user agents, etc.
<dholbach> asac: do you need any more info on bug 208141?
<ubotu> Launchpad bug 208141 in network-manager "acx chipset unhappy with network-manager" [Undecided,New] https://launchpad.net/bugs/208141
<pitti> doko: any chance you could reupload the sun-java5 dapper update with a bug number in the changelog?
<Fujitsu> Is said upload going to fix the plethora of CVEs?
<Fujitsu> apport removed need-i386-retrace from a bug of mine 20 minutes, but hasn't done anything since.
<Fujitsu> *20 minutes ago
<pitti> Fujitsu: http://java.sun.com/j2se/1.5.0/ReleaseNotes.html doesn't mention CVEs in general :(
<mdke> morning all
<pitti> Fujitsu: I had to kill it, because the chroot was broken; maybe yuo can retag it yourself?
<Fujitsu> pitti: Will do.
<Fujitsu> pitti: The latest upload to Hardy fixed a lot.
<pitti> doko: nevermind, accepting now; but pleeeease, pretty pretty please add bug # to changelogs in the future
<Fujitsu> pitti: `This release contains fixes for one or more security vulnerabilities. For more information, please see Sun Alerts  233321  233322  233323  233324  233325  233326 and  233327.'
<Fujitsu> They hide it remarkably well.
<doko> pitti: I'll add the upstream report numbers next time
<pitti> doko: most important is the SRU LP bug#
<dholbach> asac_: do you need any more info on bug 208141? :-)
<ubotu> Launchpad bug 208141 in network-manager "acx chipset unhappy with network-manager" [Undecided,New] https://launchpad.net/bugs/208141
<asac_> huaynac_: hi
<asac_> oops
<asac_> dholbach: hi :)
<asac_> dholbach: never seen this kind of access denied thing
<asac_> dholbach: is it a hidden SSID?
<dholbach> yes
<asac_> dholbach: does unhiding help?
<dholbach> asac_: let me try
<asac_> slangasek: i got some negative feedback on the bug i was waiting for answers for
<pitti> Hobbsee, ScottK: WDYT about syncing http://packages.qa.debian.org/s/slony1/news/20080223T003124Z.html ? 8.3 is our default version in Hardy, so it would be good to have a matching slony
<dholbach> asac: I don't get the crazy warnings any more, but it does not connect either - updated bug 208141
<ubotu> Launchpad bug 208141 in network-manager "[acx] cannot connect to hidden SSID" [Undecided,New] https://launchpad.net/bugs/208141
<pitti> Hobbsee, ScottK: (that's bug 191782)
<ubotu> Launchpad bug 191782 in slony1 "Slony1 1.2.13 for hardy? ( postgresql 8.3 capable )" [Undecided,Confirmed] https://launchpad.net/bugs/191782
<asac_> dholbach: when did you first test that chip?
<asac_> dholbach: e.g. do you know if it worked in gutsy?
<asac_> dholbach: could you also please remove the remembered connection from nm-editor before trying the connect
<dholbach> asac_: I did that
<dholbach> (mentioned it in the bug too :))
<asac> dholbach: what about gutsy?
<asac> dholbach: another info helpful would be to know if WPA works
<dholbach> asac: ugh... don't have a gutsy CD here any more
<dholbach> I can try WPA though
<asac> dholbach: ok try WPA first then
<dholbach> asac: just normal "wpa personal"?
<asac> dholbach: yes
<asac> dholbach: i assume it doesn't work?
<dholbach_> asac: no, it's seriously unhappy
<dholbach_> attaching the log in a bit
<dholbach_> asac: I remember: the problem in gutsy was a kernel issue (firmware was not loaded)
<dholbach_> asac: log attached
<asac> dholbach: it crashes?
<dholbach> asac: it only showed "WEP key something" when I selected the network, then I tried to select "shared key" and it crashed
<dholbach> how do I turn on apport on the livecd? :)
<asac> dholbach: thats on CD?
<dholbach> yes, on the livecd
<asac> thought it was an instlal ;)
<asac> dholbach: your driver doesn't support wpa
<dholbach> no, I wanted to see if everything works before I install ubuntu on my girlfriend's laptop :)
<asac> otherwise you won't see AP_SCAN
<asac> 2
 * dholbach can try WEP
<asac> you can, but chances are low
<asac> wpa is better than open in regards of getting feedback in user-space
<dholbach> ok... what do you think the problem is in this case?
<asac> dholbach: if you run iwconfig while connecting to a non-hidden network
<dholbach> the hidden ssid seems to irk NM, but that doesn't seem to be the real problem
<asac> do you see that th essid is set?
<dholbach> ok... let me get back to public non-hidden
<asac> dholbach: http://acx100.sourceforge.net/wiki/WPA i think an option would be to go for ndiswrapper
<asac> not sure how easy you can test that on livecd though
<asac> dholbach: the problem for open network is that the driver either never associates (which we are trying to figure out now) or it doesn't send a notification to user-space when association has happened
<dholbach> this sucks :)
<asac> dholbach: so ... do you see a essid set (using iwconfig) while connecting?
<dholbach> I'm just restarting the machine - network-manager was even more confused after it crashed (and I restarted it) - will let you know in a sec
<asac> ok
 * pitti pokes soren about bug 196149
<ubotu> Launchpad bug 196149 in dnsmasq "Please sync dnsmasq 2.41-1 (universe) from Debian unstable (main)." [Wishlist,Incomplete] https://launchpad.net/bugs/196149
<soren> pitti: Oh, right. That one fell completely off my radar.
<dholbach> asac: yes, I can see it
<asac> yeah.. thats a driver issue then
<asac> dholbach: you could ask ben if its really the latest
<dholbach> why?
<asac> or try ndiswrapper
<asac> dholbach: because it associates, but doesn't tell userspace that association has happened
<dholbach> hum
<asac> thats required for networkmanager, but not for dhclient
<asac> dholbach: there is one more thing you could try
<asac> you could try to use AP_SCAN 1
<asac> instead of two
<dholbach> so run        AP_SCAN 1 sudo NetworkManager        ?
<dholbach> so run        AP_SCAN=1 sudo NetworkManager        ?
<asac> no
<asac> that won't work :)
<dholbach> so? :)
<asac> get that branch: http://bazaar.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.6.x.ap_scan
<asac> oh ... hmm you can't do that on livecd i guess
<asac> dholbach: i think its really worth tto check with kernel folks that the driver is really the latest
<dholbach> it says 0.3.36 which is the latest release
<dholbach> 20080210 is a snapshot, I guess
<dholbach> I'll ask
<asac> http://sourceforge.net/project/showfiles.php?group_id=75380
<asac> yes, i am not sure if 0.3.36 is the same as 20080210
<asac> modinfo doesn't show version info
<dholbach> it shows in iwconfig
<asac> the driver version?
<asac> strange
<dholbach> Nickname:"acx v0.3.36"
<asac> if we have luck its really outdated and things are fixed in latest
<tbf> hmm.... would be really nice, if update-manager would display which repository a package comes from
<dholbach> asac: it is outdated and the changes are pretty huge
<asac> dholbach: great. good to figure out now
<asac> dholbach: please point th ekernel team to the bug ... i added a linux-ubuntu-modules target by now
<pitti> soren: did you test dnsmasq 2.41 in hardy with kvm?
<pitti> soren: FF-wise it looks acceptable, so I'll make this dependant on your testing results
 * soren blushes
<soren> Actually, I need to merge it.
<soren> Rather than have it synced.
<soren> I just noticed I changed stuff in dnsmasq after filing the sync request.
<pitti> oh, ok
<pitti> I'll mark it as invalid then
<pitti> soren: if you are happy with the new version, FF exception granted
<pitti> soren: ^ copied that to the bug, closed
 * soren questions the integrity of his todo list
<soren> pitti: The changes I did in 2.40-1ubuntu4 were to address the issues you raised in bug 190905
<ubotu> Launchpad bug 190905 in dnsmasq "Main inclusion report." [High,Incomplete] https://launchpad.net/bugs/190905
<pitti> soren: sweet
<Gatestone> How do you debug memory leaks/problems? Valgrind?
<dholbach> http://wiki.ubuntu.com/Valgrind
<soren> pitti: Ok, so I'll do the merge test, report, and we can close the MIR as well?
<pitti> soren: no, please don't close the MIR yet
<pitti> I'll do it after promotion
<pitti> but that needs the package be uploaded, built, and published first
<pitti> otherwise promotion will fail
<soren> Ok, cool.
<kagou> openoffice 2.4 is released, is it planed to provide it in Hardy ?
<seb128> kagou: yes
<kagou> oh nice seb128 :)
<seb128> kagou: we try to not stick to candidate versions when the stable version is available
<seb128> kagou: what would be the interest?
<kagou> indeed
<pitti> asac: I'd appreciate your input on bug 206875
<ubotu> Launchpad bug 206875 in seamonkey "Please remove iceape from Hardy" [Medium,Incomplete] https://launchpad.net/bugs/206875
<james_w> would we need the new dpkg-dev in hardy if we wanted to use the new source package formats in intrepid, or does that only matter for dpkg and new .deb formats?
<Fujitsu> pitti: 11:14 < asac> Fujitsu: iceape is just in gutsy, right?
<Fujitsu> 11:15 < Fujitsu> asac: It will be once the removal is processed.
<Fujitsu> 11:15 < Fujitsu> asac: Somebody apparently forgot to remove iceape from Hardy, even though the binaries are now all provided by seamonkey.
<Fujitsu> 11:16 < asac> Fujitsu: yes, so the security issues are actually phantom ones :)
<fabbione> pitti, keescook: http://dvlabs.tippingpoint.com/blog/2008/03/19/cansecwest-pwn-to-own-2008
<Fujitsu> pitti: Oh, I see I missed your comment.
<fabbione> pitti: so  far we are holding up pretty good :)
<asac> Fujitsu: thats just a transitional package then
<Fujitsu> pitti: iceape source is still in Hardy...
<Fujitsu>     iceape | 1.1.4-1ubuntu2 | hardy/universe | source
<pitti> hm, seems that madison on drescher lies then
<pitti> ok, so I'll kick that?
<asac> pitti: if the source is still there, then please remove
<asac> i invalidated the bug for now
<asac> based on your comment
<Fujitsu> The version in Hardy is lower than that in gutsy-security, which could do strange things.
<sistpoty|work> pitti: did the sync of attal/attal-themes succeed? (the output you added to bug #205810 looks like it didn't)
<ubotu> Launchpad bug 205810 in attal "please sync attal (1.0~rc1+cvs20080318-1) and attal-themes (1.0~rc1+cvs20080318-1) from unstable/main to universe" [Undecided,Fix released] https://launchpad.net/bugs/205810
<pitti> sistpoty|work: in progress
<sistpoty|work> pitti: thanks!
<Fujitsu> pitti: Thanks for removing that.
<\sh> pitti: when you are on sync crusade, please sync phpgroupware from debian unstable (bug #206948)
<ubotu> Launchpad bug 206948 in phpgroupware "phpGroupWare should be included in Hardy" [Undecided,Confirmed] https://launchpad.net/bugs/206948
<\sh> pitti: it was removed from debian and hardy because ajmitch was MIA ... now debian has a new maintainer
<\sh> pitti: request is acked (+2) by motu-release aka scott and hobbsee :)
<pitti> \sh: doing
<Hobbsee> pitti: i'm not against the sync.
<pitti> \sh: argh, sync-source.py barfs on that
<james_w> doko: I'm going through the milestoned bugs and I see https://bugs.launchpad.net/ubuntu/+source/gcc-4.2/+bug/184141 , would you like some help in creating that list?
<ubotu> Launchpad bug 184141 in gcc-4.2 "libstdc++6 has a binary incompatibility" [High,Confirmed]
<doko> james_w: yes, asked cprov and kiko (I do have the list for a)
<james_w> doko: ok, sounds like you are on top of it, great
<ScottK> pitti: bug 191782 approved.
<ubotu> Launchpad bug 191782 in launchpad "Slony1 1.2.13 for hardy? ( postgresql 8.3 capable )" [Medium,Confirmed] https://launchpad.net/bugs/191782
<pitti> ScottK: great, thanks
<pitti> asac: firefox-themes-ubuntu (main) b-deps on firefox-2 (universe); this needs to be fixed
<asac> pitti: can be demoted ... though steve already did that
<asac> thought
<pitti> asac: demoted, thanks
<pitti> asac: so I'll unseed it, ok
<asac> pitti: thanks to you
<pitti> ?
<asac> obviously yes.
<asac> pitti: thanks
<pitti> dholbach: wishlist: would be great if "update-signature yesterday" worked :) (date = time.localtime(time.time()-24*3600))
<dholbach> bug 208204
<ubotu> Launchpad bug 208204 in five-a-day "pitti dholbach: wishlist: would be great if "update-signature yesterday" worked :) (date = time.localtime(time.time()-24*3600))" [Wishlist,Confirmed] https://launchpad.net/bugs/208204
 * dholbach goes back to lunch :)
<pitti> dholbach: yay your irc2lpbug script
 * pitti hugs dholbach
<dholbach> hehe
<Hobbsee> pitti: when will you write a script that *fixes* bugs while being on irc?
<tuntun> hardy says the nvidia driver is installed but not in use. how do i use them?
<sistpoty|work> Hobbsee: I have one, but it depends on libjustdoit to work :P
<persia> +++++++++++++++++++++++++++++
<Hobbsee> sistpoty|work: ahhh
<sistpoty|work> so, I guess we'll need to wait until debian bug 456789 is fixed
<ubotu> Debian bug 456789 in gclcvs "gclcvs: FTBFS: Uses way too much RAM." [Serious,Open] http://bugs.debian.org/456789
<sistpoty|work> erm... not that one /me shuts up again
<ogra_cmpc> sistpoty|work, only with versions that ship /usr/share/libjustdoit/caffeine.in
<sistpoty|work> heh
<Ng> does anything call pm-powersave?
<\sh> pitti: uga....worked?
<\sh> pitti: ah ok....fakesync...doing it (phpgroupware)
<emgent> heya
<tuntun> I install hardy using wubi, did 100MB of udpates, restarted and then got "initramfs" prompt. whats gone wrong?
<Pici> tuntun: This inst a support channel, please ask in #ubuntu, thanks.
 * cody-somerville waves at davmor2.
<davmor2> cody-somerville: 0/
<Haegin> i just installed the Hardy Beta on my laptop and it looks pretty sweet - well done
<Tm_T> evand: hi
<evand> Tm_T: howdy
<Tm_T> evand: final is going, judges are voting
<evand> great!
<evand> nervous?
<Tm_T> evand: I had several hardware failures so my presentation was a tad bit raw but it went mostly ok
<evand> ok
<Tm_T> not anymore, I got my presentation ready while others were presenting theirs :-P
<evand> heh
<ogra_cmpc> pitti, is there a way to override the usage of /sys for batteries and force hal to /proc ?
<ogra_cmpc> seems the cmpc doesnt report all info in /sys but /proc worked before
 * ogra_cmpc has 1033975 h battery time remaining with 36% atm
<Haegin> impressive
<seb128> ogra_cmpc: fix whatever report the infos to have those in sys?
 * Haegin is jealous
<mjg59> ogra_cmpc: That sounds fixable in the kernel
<ogra_cmpc> mjg59, seb128, right i just wanted to know if we still support a manual override for falling back
<mjg59> ogra_cmpc: No
<ogra_cmpc> theks
<ogra_cmpc> theanks
<ogra_cmpc> gah
<davmor2> evand: first try of wubi on an up-to-date vista and it seems to be working fine :)
<davmor2> so far :)
<evand> good news
<davmor2> I'll let you know when it finishes :)
<pitti> ogra_cmpc: not that I know of
<Tm_T> evand: no luck, but I'll do it
<evand> ok
<davmor2> evand: worked fine Just need a way to backup vista now :(
<evand> davmor2: dd :)
<davmor2> evand: might be partimage doesn't like it (invalid compression).  But it's faster than dd so I'm going to be hitting it with a mallet to see if I can get it to work.
<evand> heh
<davmor2> evand: partimage is complaining it can't read the image.  So I'm wandering if it got corrupted somehow.  So I'm going to reinstall Vista do all the updates again and try again.  If it fails again I'll look at other alternatives :)
<evand> ok
<keescook> fabbione: yeah, I've been keeping tabs on it by remote
<sabdfl> network manager is breaking my balls, here
<asac> sabdfl: 0.6.6-0ubuntu4 ?
<sabdfl> 3
<asac> sabdfl: ubuntu4 should be on the mirrors already. it ships some iwl tweaks
<sabdfl> asac: here's what blows my mind
<sabdfl> with a 4-line wpa.conf (that basically just names the essid and password) and dhclient it ALWAYS works
<sabdfl> and fast
<sabdfl> wtf is up with NM?
<sabdfl> is it just a POS?
<asac> network manager depends on some driver features that are not needed for dhclient
<asac> e.g. send associate event to user space once your interface successfully associates with your AP
<ogra> asac, is that what dhcdbd provides ?
<asac> ogra: no, that provides a dbus server to run dhcp
<ogra> ah, k
<ScottK2> asac: Is network manager not restarting the network after it updates itself a bug, feature, known limitation?
<pitti> tkamppeter: I think I see the problem in bug 195782, just posted a followup
<ubotu> Launchpad bug 195782 in hplip "Users not automatically added to "scanner" group: No scanning functions of HP multi-function in Hardy" [Medium,Confirmed] https://launchpad.net/bugs/195782
<asac> ScottK2: what do you mean by restarting the network?
<asac> /etc/init.d/networking restart?
<ScottK2> asac: I just updated using apt and was not connected to the network when the update finished.
<ScottK> pitti: Would you please look at Bug 208097 and tell me who I ought to chase after to see if the package can be removed?
<ubotu> Launchpad bug 208097 in python-aptsources "FTBFS in Hardy due to python-distutils-extra changes" [Undecided,New] https://launchpad.net/bugs/208097
<pitti> ScottK: hm, the change of p-distutils-extra is my credit/fault
<pitti> but I actually didn't introduce any compatibility breaking things, hmm
<asac> ScottK2: can you still connect?
<ScottK2> asac: Yes.
<ScottK2> asac: Manually reconnecting worked fine.
<asac> ScottK2: please upload your syslog somewhere (that contains the incident)
<ScottK2> asac: Sure.
<ScottK2> asac: I'll take me a few minutes to sort through it.
<asac> ScottK2: i usually ask for the complete one
<pitti> ScottK: it has no rdepends at all, so I don't mind removing it if you think it's useless
<pitti> and it's not even in debian
<ScottK> pitti: It may be useful to someone, but it's been untouched since Feisty.
<ScottK> My thought is if it was being used, it'd have an rdpend somewhere.
<ScottK2> asac: OK.  I'll get it.
<ScottK2> asac: This is Kubuntu KDE3 Hardy.  http://paste.ubuntu-nl.org/61387/
<dholbach> have a great weekend everybody
<asac> dholbach: cheers
<dholbach> bye asac
<asac> ScottK2: didn't it reconnect at line 40++ ?
<asac> oh blind me :)
<ScottK2> OK.  I didn't watch the upgrade, just came back to it and found it not connected.
<asac> ScottK2: can you reproduce by running apt-get install --reinstall network-manager?
<ScottK2> I'll give it a shot.
<asac> ScottK2: 12:48:08 <- it starts
<asac> ScottK2: 12:48:16 <- IP retrieved
<ScottK> asac: I just did the reinstall and it's off the network
<asac> ScottK2: 12:48:18 KTS-D430 NetworkManager: <info>  Activation (wlan0) successful, device activated.
<asac> ScottK2: yeah ... wait a bit
<ScottK> OK.
<asac> it should reconnect after a while
<asac> (yes, it tears down the network ... which is a different beast)
<ScottK> asac: Is this while seconds or minutes?
<asac> depends on when the wpasupplicants scan kicks in
<asac> ScottK: can you see APs in the list already?
<ScottK> asac: Yes
<asac> ScottK: try nm-tool to see if NM already sees networks
<pitti> zul: has debian bug 365097 been addressed in our bacula?
<ubotu> Debian bug 365097 in bacula-common "bacula-common: Uses the same passwords on every Debian installation" [Important,Open] http://bugs.debian.org/365097
<asac> (maybe kde applet doesn't behave like gnome thing)
<zul> pitti: yes it has
<ScottK> asac: It does
<pitti> zul: thanks (shoudl be pointed out in the MIR)
<zul> pitti: yep
<ScottK> asac: Still no network.  What now?
<asac> ScottK: please stpo the kde applet and see if it works for you with gnome-applet
<asac> (i guess it should work)
<asac> on kde
<asac> just to see if its something applet related
<ScottK> OK.  I'll have to reconnect to install that and then I'll trip the reinstall again.
<ScottK3> asac: What's the package name for the gnome applet?
<pitti> keescook: awake already?
<asac> ScottK3: network-manager-gnome
<asac> ScottK3: you start with nm-applet --disable-sm
<keescook> pitti: I am, yup
<ScottK3> asac: Thanks
<pitti> keescook: WDYT about https://wiki.ubuntu.com/MainInclussionReportLibArchive?
<pitti> keescook: it's a nice library, but currently dup's code from cpio and tar, thus is security relevant
<pitti> keescook: so I'd like to get your "ack, we'll be aware of it" at least (or a "no, no, not that one!!!")
<keescook> pitti: I'm not quite "no no not that one" about it, but I'm not really a fan of it.
<keescook> 3 CVEs last year
<pitti> same for me
<keescook> (though they are fixed in hardy)
<seb128> note that the cpio and tar code are the bsd ones
<seb128> so they are not new and unused copies
<keescook> ironically, the older the archive code, the buggier it is, seemingly.
<keescook> does it have a test suite?
<keescook> (I think that should be added to the MIR QA questions...)
<pitti> keescook: yes, it has
<pitti> let me try it
<keescook> jdstrand: what is your opinion on libarchive?
<pitti> AFAICS it is supportable, but actually needs a little effort over 5 years
<jdstrand> keescook: all I know about it is that it embeds bsdtar and cpio
<jdstrand> I'm not super keen on that
<keescook> yeah, that makes me rather unhappy too
<pitti> switchign over our tar to bsdtar by default is late for hardy, but considerable for intrepid
<keescook> honestly, if cpio and tar were switched to use libarchive, that'd work for me.  ;)
<seb128> I wish we would solve the "main package can't have universe build depends"
<pitti> IMHO that shouldn't be 'solved' in any way
<seb128> that's hurting us right now because we have the choice to drop interesting features because we don't want to promote things or to not provide those to users
<keescook> considering this is LTS, and libarchive is still seeing vuln reports, I'd prefer it not go into main.  is there is really good reason for this to be in main?
<pitti> keescook: test suite isn't run by default on package build, but a simple "make check" does
<jdstrand> a quick search shows 4 CVEs in the last 2 years-- 3 all in archive_read_support_format_tar.c
<pitti> jdstrand: I guess tar itself had the very same?
<seb128> pitti: well, I consider not shipping cool stuff because we don't want to new cracks an issue
<seb128> pitti: well, I consider not shipping cool stuff because we don't want to support new cracks an issue
<keescook> seb128: yeah, hrm
<seb128> and there is no way to solve that
<seb128> right now we don't build epiphany using webkit
<jdstrand> pitti: that isn't the bsdtar code
<seb128> we don't have the gvfs archive code
<seb128> etc
<pitti> jdstrand: ah, so the default tar has completely different code? i. e. gnu tar and bsd tar are totally separate?
<jdstrand> it's just reading a tar archive bits (AFAICS from looking at this for 10 seconds)
<ScottK2> asac: Works with the gnome applet, so I guess we get to blame the KDE applet.
 * ScottK2 goes offline to remove gnome bits from his machine ...
<keescook> seb128: if you feel it is an important feature, I would say "okay" as long as the test suite is enabled by default (and will fail the build on a failure).
<seb128> keescook: well, that gives the ability to browse iso and archives from nautilus in a transparent way
<jdstrand> pitti: 'the 'bsdtar' program is a full-featured 'tar' replacement built on libarchive
<jdstrand> (from the README)
<jdstrand> the code I was talking about is in libarchive
<jdstrand> "libarchive: a library for reading and writing streaming archives"
<jdstrand> libarchive of course provides bsdtar, but it is different code
<jdstrand> (it didn't always though)
 * keescook thinks we should add fuzzing to the Security section of the MIR for things that process stream or file data :P
<seb128> keescook: which was a thing rated quite high on the new ideas website and that fedora already provides now
 * keescook nods
<seb128> but I agree that having to support extra crack to get features is not optimal
<seb128> but neither is not having those feature, especially when other distro do have those and user are wanting to try them
<pitti> hm, I damaged the code on two places, and the test suite still reports 'all passed', hmm
<keescook> libarchive wasn't written yesterday, and they've been okay about fixes.  so, like I said, since it has a testsuite, if that can be enabled in the build, I would object less.  :)
<keescook> pitti: ewww
<jdstrand> keescook: I updated embedded-code-copies this week for libarchive
 * LaserJock hugs pitti 
<jdstrand> pitti: uhhh, icky
<ScottK2> asac: Anything else I need to gather for a bug report?
<pitti> ah, my 9th damage was finally caught
<pitti> keescook, jdstrand, seb128: so, if it's so uber-cool, and you security guys are ok with it, do you agree with main?
<keescook> the weakness of the testsuite bugs me.
<jdstrand> doesn't look like cpio has tests
<jdstrand> fyi
<asac> ScottK2: you could trace the dump the dbus traffic for the relevant endpoints
<asac> s/trace the//
<jdstrand> tar and libarchive do
<pitti> keescook: admittedly those were pretty random changes
<ScottK2> asac: Thanks.
<asac> ScottK2: i have the feeling that kde applet doesn't deal with some dbus message
<ScottK2> Probably right.  Looking at the bug list for it, it looks like it needs more than a little love.
<asac> ScottK: what i don't understand is that you connect in the syslog
<asac> ScottK: do you still see that in syslog (e.g. stage 5 finished) when --reinstall ?
<ScottK> asac: One thought that just occured to me is that I may be connected and the applet doesn't know it.
 * ScottK has been believing the U/I.  Maybe it's just wrong.
<asac> ScottK: if the syslog snippet captures the relevant bits, yes.
<asac> ScottK: it ends with: Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete.
<keescook> pitti, seb128: okay, here's what I propose: 1) enable failure-sensitive testsuite in the build, 2) promote libarchive to main, but leave the bsdtar binary in universe.
<pitti> keescook: WFM
<seb128> WFM too
<pitti> keescook: although the bsdtar package is innocent; it's the library which has the code
<pitti> but we don't need it for gvfs
<pitti> (if we did, it could use /usr/bin/tar in the first place)
<keescook> right, but it doesn't actually link to libarchive, which bugs me.  :P
<seb128> pitti: but I really thing we have an infrastructure problem there which is worth discussing and trying to solve
<pitti> keescook: oh, urgh; static linking apparently
<seb128> s/thing/think
<pitti> seb128: can you please promote the source and the libs? -ESSH again, sorry (and I need to leave soon)
 * pitti kicks his ISP
<seb128> pitti: sure, thanks
<pitti> the one single reason why I want to move to a different place
<keescook> someone needs to enable the testsuite in the build too, seb128, can you do that?
<pitti> I'm at it
<seb128> keescook: yes, do you mind if there is a small delay between promotion and the change? (ie, can I promote it now and then fix libarchive?)
<seb128> ah, cool
<keescook> pitti: oh, okay
 * seb128 hugs pitti
<pitti> seb128: we can also promote it later
<pitti> whichever you want
<pitti> but I need to leave in 5
<keescook> seb128: no problem with a delay -- I just care about the final hardy state.  :)
<seb128> I promote it now
<seb128> I want to rebuild gvfs using it today ;-)
<lamont> why does mksquashfs hang, I wonder?
<mario_limonciell> pitti, I saw a note from Fujitsu that vlc can't be demoted to multiverse.  Do you know why by chance?
<pitti> seb128: I'll upload tomorrow then
<seb128> pitti: ok
<ScottK2> asac: I just tried the reinstall several times and it never got past stage 2. I think when it got to 5 in the syslog you were looking at it was when I manually activated it.
<pitti> seb128, keescook: new package prepared and tested; will upload tomorrow morning when the promotion is published
<ScottK2> asac: Looking at the syslog, it looks to me like a key management issue.  Is this really what it reads like: Mar 28 13:43:46 KTS-D430 NetworkManager: <WARN>  nm_dbus_get_wireless_user_key_done(): nm_dbus_get_user_key_for_network_cb(): dbus returned an error.   (org.freedesktop.NetworkManagerInfo.GetKeyError) org.freedesktop.NetworkManagerInfo.GetKeyError
<pitti> I'll send the diff to Debian, too
<seb128> pitti: ok, thanks
 * pitti waves
 * ion_ integrates pitti's wave
<asac> ScottK2: yes, that looks scary, but why could it connect a few seconds later?
<sistpoty|work> pitti: could you shove libghemical-* through binary-new, to make LaserJock happy?
<ScottK2> asac: Good question.
<ScottK2> asac: I'll see if I can pursue it in #kubuntu-devel because I'm going to guess this is wallet related somehow.
<jdstrand> pitti, keescook, seb128: disregard my comments on cpio-- cpio/cpio.c isn't compiled in our build
<tkamppeter> pitti, thank you. I have answered. My idea now for a better script is to generate an fdi file with entries for all possibilities which match the wild cards of /etc/udev/rules.d/55-hpmud.rules. This would be 5 * 256 entries, or would this slow down HAL a lot?
<__mikem> If I wanted to do opengl development, what package should I install?
<nacitar> How can I increase the maximum number of semaphores?  I need to do this as part of some testing I'm doing at my job.
<jdstrand> pitti, keescook: /bin/bash ./libtool --tag=CC   --mode=link x86_64-linux-gnu-gcc  -Wall -g -O2 -static -I/libarchive -Wl,-z,defs -o
<jdstrand> bsdtar tar/bsdtar-bsdtar.o tar/bsdtar-getdate.o tar/bsdtar-matching.o tar/bsdtar-read.o tar/bsdtar-tree.o
<jdstrand> tar/bsdtar-util.o tar/bsdtar-write.o -larchive -lacl -lz -lbz2 -lattr -lacl
<lamont> I thought trackerd got shot in the head for hardy?
<jdstrand> so it looks like it statically liks to libarchive and other libs
<ion_> lamont: Nope, it just doesn't index ~ by default.
<lamont> it still chews up an entire core forever
<lamont>  1887 lamont    39  19 56124  35m 2908 S   99  1.7 129:31.59 trackerd
<ScottK> lamont: Hogtied, not shot.
<ion_> There's a bug then.
<lamont> well, there's also 433GB of /home
<lamont> ]The following packages will be REMOVED:
<lamont>   libdeskbar-tracker* tracker* tracker-search-tool*
<lamont> there. bug fixed
<ion_> Your older settings may still have indexing on.
<lamont> Oh, probably... this machine started life as feisty, iirc
<lamont> and my total involvement with trackerd has been to terminate it with predjudice whenever I notice that it's chewing up the machine...
<lamont> I understand that it does wonderful things, if it ever finishes  indexing
<lamont> OTOH, I also haven't run evo since about hoary time
<lamont> in other news, I need to figure out WTH gnome did to my sshagent stuff, and how to fix my sledgehammer to do what I want, or else figure out how to use seahorse or whatever
<lamont> ion_: and I have no clue where I'd even look to find out what my trackerd settings are
<ion_> You could open the tracker settings window. :-)
<laga> slangasek: okay, how do i make d-i install an udeb in the alternate disks? the mythbuntu disks aren't quite there yet..
<slangasek> laga: set the udeb priority to standard?
<slangasek> laga: what's the udeb?
<laga> slangasek: mythbuntu-diskless-client-builder
<caci> where would i report bugs in translated strings in package gdm?
<caci> upstream?
<seb128> caci: upstream or language-pack-gnome-locale-you-are-using
<slangasek> laga: ok, I'm having a look inside the image
<laga> thanks
<kagou> sladen, Hi
<slangasek> (rather, I will be when jigdo finishes :)
<caci> seb128: any reasonable chance something happens?
<kagou> can we imagine that samba password will be integrated by PAM for Hardy or is it too late for this ?
<slangasek> ideally we would get help from the server team to drive that forward
<laga> slangasek: note: i havent made any serious attempt to get it installed. just a warning ;)
<slangasek> laga: I'm not trying to install from it, just look inside it
<jdstrand> pitti, keescook: re bsdtar and staic libs> just libarchive is statically linked, the others end up dynamic (libtool-fu?)
<ogra> laga, seeding it should be enough to have it in the installer
<ogra> then you just need a preseed file that calls it ... i.e. ltsp-build-client/run=true is the call for the ltsp udeb
<laga> ogra: i am seeding it and it actually is included on the disk.. or are you talking about preseeds?
<ogra> both
<laga> yeah, the preseed is in place as well
<ogra> seeding is to get it in, preseed to execute
<slangasek> laga: if mythbuntu-diskless were reuploaded with mythbuntu-diskless-client-builder set as Priority: standard, that should be sufficient
<laga> ogra: so, seeding makes sure it is installed, and preseeding triggers code inside the postinst.
<slangasek> laga: it currently isn't Prio: standard in the archive, so it doesn't get set Prio: standard in the CD
<ogra> well, preseeding sets vars
<slangasek> then you could forego any preseeding
<slangasek> (and in the general case we would use preseeding instead of twiddling priorities, because once you've set it Prio: standard, it's Prio: standard for everything; but in this case, mythbuntu-diskless-client-builder isn't going to be on any images except the ones you want..)
<ogra> in case of ltsp i check the debconf value for the run variable ... if thats true i run, else i skip
<laga> ogra: yes, that's what i meant
<laga> just curious: if i left out the preseeding, would the udeb still get installed?
<ogra> installeed, yes, thats handled by the installer seed usually
<laga> slangasek: just to make sure: we're talking about this priority: http://www.pastebin.ca/961148
<laga> ogra: ah, nifty. i thought preseeding just set debconf values.
<ogra> yes, it is
<slangasek> laga: not the priority for the source package; you want to change the priority *only* for the udeb
<slangasek> so you would add a Priority: standard field to the per-binary stanza of debian/control
<laga> okay
<laga> thanks everyone for their help :)
<slangasek> blueyed: ping?
<blueyed> slangasek: pong
<slangasek> blueyed: hi.  anyone else stepping forward on bug #203736 yet for sponsorship, or should I have a look?
<ubotu> Launchpad bug 203736 in hdparm "FFe: Please merge hdparm 8.6-1 (main) from Debian unstable" [Wishlist,New] https://launchpad.net/bugs/203736
<blueyed> slangasek: dunno?! please sponsor it, if you want/can, of course.
<slangasek> blueyed: ok, looking
<kagou> slangasek, do you want that i open a bug (for tracking informations) about integrating samba/pam password ?
<slangasek> kagou: if there isn't one already, then I think it should be opened as a bug, yes (on the pam package)
<kagou> slangasek, ok, i check this
<lamont> apport makes firefox take too long to crash
<infinity> Disable it!
<kagou> slangasek, i'v done Bug #208419 can you check that i'v well explain the problem (my english is not good enough)
<ubotu> Launchpad bug 208419 in pam "Integrate samba password in PAM" [Undecided,New] https://launchpad.net/bugs/208419
<dajhorn> Should privacy bugs get the security tag?  I'm currently feeling uptight about Bug #208399.
<ubotu> Launchpad bug 208399 in lshw "[Hardy] lshw 02.12.01-2 phones home (with tcpdump example)" [Undecided,New] https://launchpad.net/bugs/208399
<keescook> dajhorn: I'd prefer a patch that added a "--check-for-new-version" flag or something rather than just ripping the whole thing out.
<keescook> lots of software do these kinds of new-version checks (firefox extensions, for example).
<slangasek> kagou: looks good, subscribing myself/ubuntu-server
<dajhorn> keescook: Would it be similarly appropriate for bash or gzip to phone home?  Network access from Firefox is expected.
<slangasek> keescook: I consider it very bad form for any software I installed as a distro package to do its own new version checks
<keescook> dajhorn: it's a bit odd, I'll give you that.
<keescook> slangasek: yeah, true.  that's the other point in the bug.  I think we should take that patch.
<dajhorn> keescook: I noticed the change doing a security audit, but I didn't notice a changelog entry or other commentary.
 * keescook nods
<keescook> dajhorn: code review or saw the traffic?
<dajhorn> keescook: First I noticed different linkages.
<dajhorn> keescook: The upstream code is clean, it is just a simple query.  Nevertheless, I trust the Ubuntu distro, not each and every upstream developer.
<keescook> yeah, it's certainly not a least-surprise issue
<keescook> or, rather IS a least-surprise issue
<keescook> (rebuilding it now, should have it uploaded shortly)
<dajhorn> I'm sure the bug was introduced in good faith. I'm much more interested in how this fits policy.
<dajhorn> Somebody subscribed the security list on the original bug before it got nailed shut.
<dajhorn> keescook: I see the commit now.  (Thanks.)
 * dajhorn returns to bug hunting.
<keescook> dajhorn: you're welcome -- thanks for catching it
<slangasek> blueyed: your hdparm diff introduces a debian/hdparm.default file not present in the current package or the Debian package, and not documented in the changelog
<blueyed> slangasek: are you sure? I cannot find something relevant in the diff.
<blueyed> slangasek: which line?
<blueyed> I cannot find even "hdparm.default" as string..
<slangasek> blueyed: I was sure, now I'm less so :)  Let me see what's going on..
<slangasek> blueyed: ok, no, it's present in the Debian version, it just shows up as a diff relative to what MoM produces
<protonchris> slangasek: if you have a second, could you take a look at bug 208436.  Should we go ahead and patch the version in hardy?
<ubotu> Launchpad bug 208436 in cairo "Latest cairo has an api change which causes problems" [Undecided,New] https://launchpad.net/bugs/208436
<slangasek> so MoM is getting something wrong
<blueyed> slangasek: could be, I've used DaD
<slangasek> protonchris: wouldn't it be just as straightforward, and more future-proof, to fix this in cairomm
<slangasek> ?
<protonchris> slangasek: well I am concerned that the api change will cause problems in other packages as well.
<slangasek> protonchris: well, should be testable by rebuilding all of the cairo reverse-depends and seeing if any FTBFS.  I'm ok with patching it for hardy, though I don't think it should be treated as a blocker
<infinity> I'm inclined to say that breaking stable APIs is a Bad Thing.
<infinity> (Especially when upstream has reverted the breakage)
<slangasek> but haven't considered the breakage severe enough to do a new release yet
<slangasek> and APIs << ABIs :-)
<protonchris> Well, I am up for either patching cairo or cairomm.  Both have upstream patches that should be easy to include in the packages.
<infinity> I'd fix both, if it were me.
<infinity> They're both small and "obviously correct" patches.
<protonchris> Thanks.  I'll fix cairo first and cairomm if I have a chance.
<infinity> The cairo fix should render the cairomm fix less urgent, but I think it's more obviously correct to apply both patches.
<protonchris> Do I need a FFe for https://launchpad.net/bugs/208436
<ubotu> Launchpad bug 208436 in cairo "Latest cairo has an api change which causes problems" [Undecided,New]
<cody-somerville> protonchris, Does the upload introduce new features?
<slangasek> blueyed: hmm, there's a bug in the Ubuntu patch for hdparm - there's code in the preinst to remove the hdparm init script on upgrade, but the init script is still being shipped in the package.  Any chance you'd be willing to take a look at that before upload?
<slangasek> protonchris: no, you don't
<blueyed> slangasek: introduced with the merge or already with the current package?
<blueyed> slangasek: looking
<Chipzz> pitti: my opinion as a user on the libarchive issue is: if you do, please do not switch over gnu tar to bsd tar
<slangasek> blueyed: already in the current package
<Chipzz> pitti: gnu tar, in typical gnu style, most likely has a lot of command-line options that don't exist in bsd tar (though I would have to check that)
<Chipzz> I use tar from the command-line quite often, and I do think quite some people would be upset with having to re-learn tar
<blueyed> slangasek: so the init script should be dropped, too? (and the version in preinst adjusted) correct?
<blueyed> slangasek: it probably gets added with every merge again, hmm? maybe only the version in the preinst needs to be bumped?!
 * Chipzz wonders how feasable it would be to dlopen tar and invoke the needed functions that way instead of including a seperate copy
<slangasek> blueyed: no, it's not the preinst that needs to be bumped - the debian/rules needs to be fixed to not install the init script at all
<slangasek> well - the init script should *also* be bumped, but as a one-time change accompanying the debian/rules fix
<slangasek> s/init script/preinst script/
<blueyed> slangasek: ok.
<blueyed> slangasek: well, dh_installinit gets called by debhelper.. and it finds the .init/.default files and installs them. We use "--noscripts", but that's something different.
<blueyed> slangasek: I'll try adding --onlyscripts, too.
<slangasek> blueyed: patching the init script out of the package completely may be the easier solution
<blueyed> slangasek: yes, but it gets merged back every time, doesn't it?
<slangasek> I don't know
<slangasek> if so, that's an error on the part of the person doing the merge :)
<blueyed> yes.. :) but we could make it easier for the merger next time..
<blueyed> slangasek: updated diff for bug 203736
<ubotu> Launchpad bug 203736 in hdparm "FFe: Please merge hdparm 8.6-1 (main) from Debian unstable" [Wishlist,New] https://launchpad.net/bugs/203736
<blueyed> works with "--noscript".
<blueyed> ..well, and "--onlyscripts"
<sistpoty> hm... if I have an or'd builddep left | right, which one will get drawn in by default by soyuz? (and will it draw in the other one, if the first cannot get satisfied?)
<sistpoty> (/me only remembers, that it used to be the oppisite of pbuilder long ago)
<infinity> sistpoty: It will pull in the left build-dep first, and go through the list until it finds one available.
<sistpoty> infinity: thanks... (I'm trying to get ghc6 up on lpia again, and the problem is that haskell-utils is missing, which however should build with hugs as well)
<infinity> sistpoty: Ahh, I was planning to bootstrap that sometime when I was bored, but if you can do it with a few bootstrap uploads instead, that works just as well, and frees up some time for me.
<sistpoty> infinity: *if* haskell-utils still works with hugs, it should be just one upload and a few give-backs... hppa is a different story though :(
<sistpoty> infinity: if haskell-utils doesn't work, I could do a local bootstrap, and do some bootstraps upload for lpia in my ppa, if that helps?
<infinity> sistpoty: I wouldn't waste too much sleep on hppa.  If we want it fully built, lamont and I can take a weekend and do something about it.
<sistpoty> heh
<infinity> sistpoty: And, no, PPA bootstraps won't help me much, because it still introduces trust issues (nothing personal, of course), so if we *need* a bootstrap, I'll have to do it myself.
<sistpoty> infinity: well, you could take the ghc6 binary packages for lpia to very much ease a personal bootstrap ;)
<protonchris> sistpoty or infinity: if either of you have time to take a look.  I have attached a debdiff to Bug 208436 .
<ubotu> Launchpad bug 208436 in cairo "Latest cairo has an api change which causes problems" [Undecided,Confirmed] https://launchpad.net/bugs/208436
<sistpoty> protonchris: sorry, I'm just a motu and cannot upload to main then
<infinity> protonchris: Looks correct to me.
<protonchris> sistpoty: Whoops.  Thanks anyway.
<protonchris> infinity: thanks.
<davmor2> evand: ping
<davmor2> evand: don't worry sorted :)
<evand> ok
<simira> what's "worse" in german? Like in "worse than ..."?
<simira> no germans around?
<davmor2> evand: just a quick query about M-A which you had emailed to me but I couldn't find.  But I found it :)  we weren't sure if vista was supported and I felt sure you said you were working on it for intrepid but I thought it was through a gsoc project or something :)
<ion_> "schlechter als" according to /usr/bin/translate-bin
<ion_> "worse than", that is.
<simira> danke
<sistpoty> ion_, simira: translate-bin is right with "schlechter als"
<LaserJock> any weirdnesses with NM/iwl3945. My laptop doesn't seem to "see" connections anymore
<infinity> slangasek: For the record, that cairo bug has caused some FTBFSes (which I was just about to report), so rather than report the bugs, I think I'll just upload the fix. :P
<infinity> slangasek: https://lists.ubuntu.com/archives/ubuntu-autotest/2008-March/018788.html for example.
<infinity> Meh, firefox needs an option to "prefer browsers on current active desktop" when opening links in new tabs.  Searching all my desktops for the firefox that was the "top window" and got the link is annoying.
<slangasek> infinity: ok then :)
<infinity> dpkg-buildpackage: error: fakeroot not found, either install the fakeroot
<infinity> HATE NEW COMPUTERS, ARGH.
<infinity> Also hate packages that need dpatch in the clean target.  *sigh*
<ion_> infinity: That's why you should have your own metapackage handy that depends on all the essentials. :-)
<infinity> protonchris: Thanks for doing the heavy lifting, uploading your change now.
<protonchris> infinity: no problem.  I am new to packaging.  So if you have any advice, I would love to hear it.
<infinity> protonchris: The patch was pretty much perfect, as-is.  Changelog was decent, patch itself was correct, bonus points for correctly using the patch system that the package already had in place, etc.
<infinity> protonchris: I'm just sponsoring the upload with your name in the changelog, as I didn't feel the need to "fix" anything.
<protonchris> infinity: great. thanks.
<infinity> protonchris: If you're not already, can you subscribe to the bug, to follow up and make sure the upload doesn't explode?
<infinity> protonchris: Ahh, and you already have.  Excellent.
<lamont> sistpoty: re hppa: what infinity said;
<infinity> lamont: Doesn't nick hilighting on arch tags make you grumpy some days? :)
<sistpoty> lamont: heh, it's priority whishlist on my radar...
<protonchris> infinity: thanks.  I'll keep an eye out for any explosions.
<LaserJock> can anybody translate "Vorbereiten zum Ersetzen von"
<laga> LaserJock: "prepare to replace <something>"
<ion_> "Prepare for replacing" says /usr/bin/translate-bin, and i think the "von" means "of"
<bardyr>  Today ubuntu is build to support all legacy CPU's is there any chance for maybe building a ubuntu port with for modern CPU's with all the nice CPU features and instructions set enabled?
<bardyr> or is ubuntu 64bit the best option?
<laga> bardyr: yes, that's called "amd64" ;)
<LaserJock> hmm
<bardyr> laga, Okay, thanks :)
<laga> i'm by no means an expert on that topic, but amd64 might be a bit better with regards to opimization.. recompiling ubuntu just to take care of the newest instruction sets on your CPU won't do much good
<laga> maybe for some very specific apps
<LaserJock> could I get somebody with Hardy and a fast internet connection to install gcompris?
<bardyr> LaserJock, 20mbit hardy :)
<laga> LaserJock: yes
<LaserJock> I just need to make sure version 8.4.4-1.1ubuntu1 installs
<bardyr> LaserJock, installing atm
<bardyr> LaserJock, installed without a problem
<laga> it installs just fine
<laga> hum
<laga> ah, now it's started
<laga> that took a while
<bardyr> omg, what have i installed :D
<LaserJock> bardyr: ok, thanks
<LaserJock> bardyr: one of the best educational applications the free software world has ever created ;-)
<sistpoty> meh... seems like soyuz isn't that smart as I thought... haskell-utils build-depends on ghc6, which depends on haskell-utils, which is not installable, but it doesn't consider the alternative :(
<laga> gcompris has an interesting UI
<bardyr> LaserJock, kickball is great :D
<bardyr> LaserJock, and i love the voice
<laga> goal: fine motor coordination. i wonder if kids who need to be taught to use a mouse will understand that ;)
<LaserJock> bardyr: you can also do fun things like play chess and play with electrical circuits if you have gnucap installed
<laga> LaserJock: i get some warning about missing gnomevfs libaries (i'm running kde). i guess that's ok
<LaserJock> hmm, not sure
<LaserJock> I'd have to look at it
<laga> LaserJock: http://www.pastebin.ca/961415
<LaserJock> laga: interesting, I've not seen that before, although I normally run it in Gnome
<laga> it seems to run fine
<laga> at least tux landed on the boat
<blueyed> bug 89269!
<ubotu> Launchpad bug 89269 in acpi-support "power.sh: wrong laptop_mode activation" [High,Triaged] https://launchpad.net/bugs/89269
<ion_> I made my irb calculate 89269!, but it's unsurprisingly taking a long time. :-P
<LaserJock> heh
<slangasek> blueyed: hdparm uploaded, thanks!
<blueyed> slangasek: thanks. Do you mind looking at major acpi-support issues? Like the one above?
<blueyed> I have a bzr branch for it..
<lamont> infinity: you used my name
<slangasek> blueyed: ENOTIME right now, sorry
<lamont> infinity: I don't highlight on arch tags
<infinity> lamont: LIES.
<slangasek> blueyed: ah, uploaded and rejected because I built with the wrong options, oops fixing :)
<lamont> infinity: statistics??
<ion_> It's still computing 89269!. Perhaps i should have done that on a faster box, or not in an interpreted language. ;-)
<LaserJock> ion_: maybe Java would've worked ;-)
<ion_> I don't have a stick long enough to dare touch javur. :-(
<sistpoty> infinity: please give back happy and alex on lpia :)
<infinity> I object to both, just because they have silly source names...
<sistpoty> heh
<infinity> sistpoty: So, you've made haskell-utils installable at some point, I take it?
<sistpoty> maybe I should have written: "please give back happy alex on lpia" :P
<sistpoty> infinity: correct... though this upload should vanish soonish, as it will draw in hugs when installing ghc6
<infinity>   ghc6: Depends: haskell-utils but it is not installable
<infinity> sistpoty: Still waiting on a publisher run, perhaps?
<sistpoty> infinity: grmpf... I thought "ACCEPTED" means that this had already happeneD?
<infinity> sistpoty: Nah.
<sistpoty> infinity: ok, then it still needs its time
<sebner> infinity: would you mind giving "revelation" a give back on hppa.?
<infinity> sebner: Done.
<sebner> infinity: thank you :D
<protonchris> infinity: I am thinking about leaving cairomm alone since it is a sync from debian.  If I go ahead and patch cairomm to be completely correct, I'll make more work for us when we want to get back in sync with debian.  What do you think?
<infinity> protonchris: If it's not currently ubuntuish, don't bother.  As I read the bug and the patches, the cairomm patch, while correct, is entirely unnecessary with cairo already fixed.
<protonchris> infinity: I agree.  So does that make the cairomm bug fixed or invalid?  Bug 205701
<ubotu> Launchpad bug 205701 in cairomm "Latest hardy cairomm is broken" [Undecided,Confirmed] https://launchpad.net/bugs/205701
<protonchris> infinity: by the way, thanks for all your help today
<infinity> protonchris: It makes the cairomm bug unfixed, still open, but low priority.
<infinity> protonchris: It's certainly not "broken" anymore.
<aquo> i want to document my package selection and make installations with a defined package-set reproducible ...
<infinity> aquo: "dpkg --get-selections"
<aquo> infinity: i know that, but i am thinking about creating meta-packages
<infinity> aquo: And you can pipe that same output to "dpkg --set-selections" on another system, before running "apt-get dselect-upgrade"
<aquo> infinity: --get selections is not modular enough
<infinity> aquo: If you want to learn how to create metapackages, this isn't the channel for you.  #ubuntu-motu might be a better starting spot.
<aquo> ok, thank you
<awen_> cjwatson: hey
<awen_> cjwatson: was told that you might know why bash_completion isn't installed in hardy as default?
<james_w> awen_: cjwatson probably isn't around, there are other people that know though, so you may get an answer if you don't direct your question to one person
<blueyed> wow.. have not expected pressing the power button to shutdown my system.. (hibernating since last kernel update) :p
<blueyed> Isn't that expected to present a shutdown dialog or do nothing? (kde4)
<awen_> james_w: okay, was just told that he was the best bet... but if anybody else knows :)
<sistpoty> awen_: I knew that this topic was dealt with in the last few days (sorry, don't know exactly when, or what the outcome was)... maybe grepping irclogs might give you some clue?
<sistpoty> awen_: (right here in ubuntu-devel)
<james_w> yeah, I think cody asked about it yesterday or the day before
<blueyed> wouldn't mapping the power button to "hibernate" make far more sense? (if it's possible through pm-utils)
<awen_> sistpoty: okay... i'll try looking through them, thanks
<james_w> blueyed: in gnome it launches the log out/supsend etc. dialog
<torkel> blueyed: at least in Gnome you can set what it should do in the power management preferences
<blueyed> james_w: Through gnome-power-manager probably then.
<sistpoty> imho in kde as well... *being bold and just trying*
<blueyed> Great. KDE3 did so, too IIRC. Needs a fix in KDE4 then, like the shutdown in general :p
<sistpoty> wohoo, I'm still there :)
<blueyed> sistpoty: kde3?
<sistpoty> blueyed: yes
<blueyed> sistpoty: lucky you :D kde4 even does nothing, from the shutdown menu currently. I've always manually called "sudo pm-hibernate", which works great.
<james_w> sistpoty: :-)
<sistpoty> heh
 * awen_ found it, thanks... but thinks might + may is included one too many times in the conclusion
<juliank> Any chance to get http://incoming.debian.org/ndisgtk_0.8.3-1.dsc synced? It fixes bug #108656 and the changes are very very small
<ubotu> Launchpad bug 108656 in ndisgtk "ndisgtk can't remove installed driver" [High,Fix released] https://launchpad.net/bugs/108656
<TomJaeger> Hi. What is the preferred way of including autoreconf in the build process of a package?
<slangasek> the preferred way is to not have to ;)
<TomJaeger> I need to fix a Makefile.am
<slangasek> but if you're going to: build-depend on the autotools you need; call autoreconf somewhere before calling ./configure; and remove all of the autogenerated files in the clean target, to not cause gratuitous interdiffs.
<Fujitsu> TomJaeger: Are you the Tom Jaeger of bug #194214 fame? If so... thanks for finding the solution!
<ubotu> Launchpad bug 194214 in xorg-server "Keys get "stuck" down" [Unknown,Confirmed] https://launchpad.net/bugs/194214
<tjaalton> indeed, that'll get included before too long
<TomJaeger> yup, that'd be me
<TomJaeger> slangasek, interdiffs that remove files are okay?
<TomJaeger> because the original tarball already has all those autogenerated files in it.
<slangasek> TomJaeger: removal of files present in the orig.tar.gz are ignored when creating the .diff.gz
<slangasek> TomJaeger: so they wouldn't show up in the interdiff at all
<TomJaeger> okay, thanks
#ubuntu-devel 2008-03-29
<sistpoty> infinity: unless lp confuses me again, now would be a good time to give back happy alex on lpia ;)
<Nafallo> happy alex?
<sistpoty> Nafallo: see backlog
<sistpoty> Nafallo: (iow, the joke was already made)
<Nafallo> sistpoty: ah. I /lastlogged and couldn't see what you meant first. then I saw the "and" ;-)
<sistpoty> or maybe lamont? (since infinity seems to be away)
<TomJaeger> dpkg-buildpackage: source only upload: Debian-native package
<TomJaeger> what did I do wrong?
<sistpoty> TomJaeger: wrong name of orig.tar.gz, I assume (btw.: for such packing question I assume that #ubuntu-motu is more suited)
<TomJaeger> okay, thanks
* elmo changed the topic of #ubuntu-devel to: Launchpad is going down from 00:55 UTC until 01:15 UTC for a code update || Archive: Feature Freeze, DocumentationStringFreeze | Ubuntu 8.04 LTS Beta released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for ht
 * slangasek blinks
<ion_> slangasek: Well, be thankful the limit isn't what it used to be in IRCnet. :-)
<slangasek> oh, no, I'm just blinking at the downtime
* elmo changed the topic of #ubuntu-devel to: Archive: Feature Freeze, DocumentationStringFreeze | Ubuntu 8.04 LTS Beta released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<infinity> Okay, so this is the first time (since I got a shiny new laptop with decent 3D) that I've run compiz instead of immediately switching back to metacity...
<infinity> Can anyone tell me if I can "fix" the fact that the fancy 3D Alt-Tab switcher doesn't understand Shift-Alt-Tab to cycle backwards?
<sistpoty> infinity: I'd lie, if I say I could in case you'd give back alex and happy on lpia :P
<infinity> sistpoty: I'd love to, if LP wasn't down.
<sistpoty> infinity: it still is?
<infinity> sistpoty: Oh, it's back. :)
<sistpoty> :)
<infinity> sistpoty: So, how do I fix the compiz task switcher? :P
<james_w> infinity: there are various plugins that provide alt-tab like switching, so it may be that one of them can do it.
<sistpoty> infinity: good question, I use KDE though, and I lied :P
<james_w> although the one that I have doesn't understand it
<infinity> james_w: Yeah, the default one seems to not know how to go backwards, which makes me grumpy.
<infinity> james_w: Given that every window manager (heck, every OS) I've used in the last decade could do so. :P
<james_w> infinity: run ccsm
<james_w> infinity: you may have to install it first
<infinity> simple-ccsm?
<james_w> select "Application switcher"
<james_w> you need the real thing I think
<james_w> the advanced button in simple-ccsm spawns it
<james_w> on the "Bindings" tab there is a "Prev window" setting, and it is unbound by default
<infinity> Genius.
<infinity> I've never looked at any of this before.
<infinity> Of course, binding that should be the default, IMO, but I don't know how deeply I care about filing a bug to fix it this late.
 * infinity squeals with glee.
<infinity> james_w: You're my hero for the next 30 seconds.
<infinity> james_w: If you ever needed a favor from me, ASK FAST.
<james_w> umm, umm...
<thom> too slow
<ion_> james_w: You had a chance to ask infinity's hand in marriage, and you blew it?
<james_w> dammit
<james_w> asac: I've found the problem you were having, apt-get source only responds to a source package name without a version. I think I can work around it by picking the first binary package out of debian/control. I think it's unlikely that the first package will have been added in that revision.
<nepbabu> what's the status of launchpad?
<nepbabu> is it rebooted and done it's maintenance? thanks :)
<james_w> nepbabu: there is a #launchpad
<james_w> looks like it's all over though.
<nepbabu> james_w: tia! but the SSL cert is invalid says ff
<james_w> nepbabu: are you on firefox 3?
<nepbabu> james_w: yes
<nepbabu> ff3b4 james_w
<james_w> I don't know then, it works here
<nepbabu> hmm..
<sistpoty> any buildd admin still around who could give back hscolour and haddock on lpia?
 * sistpoty tries with highlighting the indirect members: elmo, Spads, lamont, Ng for the give-backs of hscolour and haddock on lpia :)
<TomJaeger> Can somebody help me with bug #195953 ?
<ubotu> Launchpad bug 195953 in wacom-tools "Tablet input resolution tied to display resolution" [Medium,Triaged] https://launchpad.net/bugs/195953
<ion_> There's the same problem with plain mice. I've been saying it should be fixed. :-)
<TomJaeger> I'm just trying to get a new upstream version uploaded.  How would I go about getting sponsorship for the new version and do I need a freeze exception?
<protonchris> TomJaeger: take a look at https://wiki.ubuntu.com/SponsorshipProcess and https://wiki.ubuntu.com/FreezeExceptionProcess
<TomJaeger> Wow, that sounds complicated
<ScottK2> TomJaeger: What package?
<TomJaeger> wacom-tools
<ScottK2> Is it bug fixes or new features?
<TomJaeger> I don't know why nobody feels responsible for this
<TomJaeger> bug fixes
<ScottK2> TomJaeger: 20,000 packages and ~100 developers.  You do the math.
<andresj> Is this the right channel to ask for somebody to apply a fix for a bug? https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/208556
<ubotu> Launchpad bug 208556 in qt4-x11 "qdbuscpp2xml uses moc-qt3 instead of moc-qt4" [Undecided,New]
<Fujitsu> ScottK2: 100 developers, most of whom are inactive.
<ScottK2> That too
<ScottK2> TomJaeger: Since it's a Main package it's a rather simpler process.
<ScottK2> TomJaeger: Is the release in Debian already?
<TomJaeger> no
<ScottK2> andresj: You will probably have more luck with that package on #kubuntu-devel
<alex-weej> ScottK2: s
<alex-weej> "it's maths, jeremy"
<TomJaeger> The thing that bugs me is that all these procedures will take just a few minutes for someone who knows what they're doing, but will take me forever to figure out
<alex-weej> TomJaeger: but once you've figured it out
<ScottK2> TomJaeger: I can understand that, but the first thing it takes is motivation.
<alex-weej> it's not like the people who can do it are sitting around scratching their backsides, they're busy on other things that they feel are more important
<ScottK2> TomJaeger: I've got about a dozen things on my list to get done before release.  If I get to 4, I'll be lucky.
<andresj> ok, ScottK2
<TomJaeger> I'm more than happy doing things like tracking down bugs, providing patches and talking to upstream.  But trying to package that stupid package has been a complete nightmare so far.  I feel like my productivity there is close to zero.
<ScottK2> OK.
<ScottK2> I'd suggest focus on writing a bug that makes the case for why it's important and why it's safe.
<TomJaeger> I've done that
<ScottK2> TomJaeger: What bug?
<TomJaeger> bug #195953
<ubotu> Launchpad bug 195953 in wacom-tools "Tablet input resolution tied to display resolution" [Medium,Triaged] https://launchpad.net/bugs/195953
<TomJaeger> If it doesn't get fixed, Tablet PCs are almost useless with hardy
<ScottK2> Right.
<ScottK2> slangasek: Would you please look at ^^^^ bug and give an opinion on if you'd accept a new wacom-tools version to fix it at this point?
<TomJaeger> Do I know why the debdiff is so large? It's a complete mystery.  The diff between the two directories is 600k, and that's mainly autoconf stuff
<ScottK2> TomJaeger: He's the Release Manager.
<slangasek> ScottK2: I would potentially accept *a* new wacom-tools version, but to know whether I'd accept *this* wacom-tools version it would have to go through the FFe process; and I probably wouldn't be the one to sponsor it myself, I think it'd be better to have it done by someone with more direct knowledge of the issues
<ScottK2> slangasek: I understand.  I'm just looking for a rough idea of if it's worth pursuing.  Who'd be the core-dev best equipped to look into this?
<slangasek> ScottK2: bryce, maybe?
<slangasek> i.e., Mr. Inkscape
<ScottK2> Right.
<ScottK2> slangasek: Thanks.
<ScottK2> TomJaeger: Now you have an idea that this might be doable and who you want to discuss it with rather than worry overmuch about packaging it yourself.
<TomJaeger> ScottK, thanks
<bryce> hey slangasek I have something for you :-)
<bryce> slangasek: http://people.ubuntu.com/~bryce/bisect/
<bryce> slangasek: these are pre-git bisected -intel debs for testing.
<bryce> (the page is still a work in progress)
<james_w> bryce: how are you building them?
<bryce> james_w: bunch of scripts
<bryce> james_w: I'd gotten stuck down a rathole trying to get them to build in PPA, but PPA has turned out to be worthless for this
<james_w> I was just wondering if you be able to basically run "git bisect run debuild"
<bryce> james_w: well, ironically 'git bisect' never gets used
<james_w> It obviously wouldn't work just like that, but it's an interesting idea.
<james_w> bryce: :-)
<bryce> yeah basically I pull a bunch of info out of git log, sort the commit id's, then do a bunch of git reset's and such to cycle through them, plunk in debian/ dirs, debuild, pbuilder, rsync, and generate the web page
<ScottK2> bryce: TomJaeger was here earlier looking at bug #195953 and hoping for someone to champion getting it uploaded.  slangasek pointed vaguely in your direction.
<ubotu> Launchpad bug 195953 in wacom-tools "Tablet input resolution tied to display resolution" [Medium,Triaged] https://launchpad.net/bugs/195953
<bryce> ScottK2: whoa that's an insanely huge debdiff
<bryce> rats, it crashed my ff3
<ion_> :-D
<TomJaeger> bryce, the debdiff b/w 0.7.7.7 and 0.7.9.3 is more than 5M
<ion_> A nice little 3.5 MiB debdiff.
<TomJaeger> I made a little mistake in the "original" tarball there.  the doc directory should be one level further down.  Not that it changes anything about the size of the debdiff.
<bryce> hrm, well looks like it needs some additional packaging work before it can be put in
<slangasek> TomJaeger: wait, why are you diffing 0.7.7.7 and 0.7.9.3 when hardy currently has 0.7.9.3?
<slangasek> bryce: heh, my architecture is amd64, not i386...
<TomJaeger> slangasek, just for comparison
<slangasek> bryce: I think a git bisecting howto would've served me better :-)
<bryce> slangasek: rats!!!
<bryce> slangasek: back to the drawing board
<slangasek> TomJaeger: erm, comparison of what, exactly? I don't see how 0.7.7.7 can be relevant here
<ion_> git bisect is teh awesome. :-)
<TomJaeger> slangasek, people are complaining about the size of the debdiff.  I'm just saying the last debdiff was even bigger.
<slangasek> oh, I see
<jdong> it's not the size of the debdiff that matters....
<TomJaeger> the issue seems to be that there is prebuilt stuff in the original tarball
<jdong> it's the color of the pill that makes the debdiff easier to work with.
<ScottK2> bryce: Yeah.  The packaging needs some work by someone who knows what they are doing (e.g. not me).
<calc> how long does it take for a bzr commit to show up in LP?
<jdong> less than 30 minutes typically for the HTTP branch to be updated
<calc> I did a commit 35m ago and it still isn't showing
<calc> oh ok so it should be soon
<jdong> the SFTP/SSH developer one is instant of course
<calc> i did a ssh and its not showing up
<jdong> yeah, typically for me it hasn't been more than 30 min
<calc> hmm i'll check it out somewhere and verify the commit made it
<calc> wow this is taking a very long time to checkout
<Fujitsu> calc: bzr-lp is particularly slow now; they're working on it.
<Fujitsu> It'll be like this for another couple eof days, thought.
<calc> Fujitsu: ah ok
<Fujitsu> If you use bzr+ssh, it should be quicker to update, but SFTP has to be checked to ensure you haven't uploaded evil stuff.
<calc> yea i am using bzr+ssh
<calc> ok the commit is there, it just haven't shown up on the webpage
<jdong> Fujitsu: you mean it's *not* for my video collections?
<Fujitsu> jdong: Devastating, I know.
<TomJaeger> I think I figured out all the different ways the debian maintainer messed with the original tarball. Things look much better now and the debdiff's down to 600k.
<warp10> Good morning
<tjaalton> yep, we really need the newer wacom-tools, but I never figured out how to compile it and pushed it forward. For some reason the Debian maintainer hasn't updated it, even though he promised to do it two months ago
<asac> james_w: ah, good to know. thanks!
<pitti> tkamppeter_: shouldn't, but in the interest of not accidentally catching unrelated devices I'd transform the list as the existing script does
<pitti> Chipzz: gnu tar switch> right, I see; would break compatibility
<\sh> moins pitti :)
<Chipzz> pitti: and probably in quite a visible and especially *unwanted* way :S
<Chipzz> pitti: as an unrelated data-point, I did man tar on my OSX system, to see which options would be different. And apparently OSX doesn't even ship BSD tar, it ships GNU tar instead. Now if even a BSD based system ships the GNU version, I very much doubt we'll want to ship the BSD version... ;)
<pitti> Chipzz: heh, indeed
<\sh> oh wow...it's a sunny day...
<Chipzz> pitti: also, doesn't dpkg use tar internally? I'd hate to see the breakage that would cause..
<tjaalton> uh, so new upstream versions don't end up in quarantine
<tjaalton> I uploaded a new wacom-tools and thought it would end up in the queue
<StevenK> Because we aren't in a freeze
<Hobbsee> tjaalton: no, it's a trust system.
<Hobbsee> tjaalton: and you tend to get the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!â¢ coming in your directino if you violate it badly.
<tjaalton> well, trust me, this was needed :)
<tjaalton> the old wacom-tools was broken with xserver 1.4
<zorglu_> q. before i found a channel with the ubuntu people which take care about all the server/mirror to store the .deb of ubuntu. i dont remember the name tho... anybody got suggestion?
<tjaalton> and the new one didn't build until Tom Jaeger fixed the issues
<\sh> asac: suddenly I see black holes with ff3 while browsing some pages...when I click on the pictures, they are display correctly...but embedded in the page they are black...
<pochu> zorglu_: #ubuntu-mirrors
<zorglu_> pochu: thanks
<Chipzz> \sh: dunnow if it's related, but I've had FF beta4 do funny things for me on MacOSX too
<Chipzz> like only loading some of the images on a page
<Chipzz> I didn't quite get "black holes", but rather the image with the alt tag displayed though
<Chipzz> asac: ^^^ as a data point -> most likely an upstream issue
<Chipzz> \sh: only happened to me after several days of browsing, and was fixed by a browser restart though
<asac> \sh: thats the zoom level
<asac> we have to use in-source jpeg most likely
<asac> (i know that its fixed that way, but i hoped to get the proper jpeg patch cherry-picked from firefox sources)
<\sh> asac: so the bug is known...
<asac> yes
<asac> its a blocker
<asac> we will revert to in-source jpeg if no solution is found
<\sh> asac: thx :) I was wondering if something was wrong on my side :)
<asac> \sh: are those jpegs?
<\sh> asac: jepp
<asac> ok then its known
<\sh> btw..is there any tool for metacity to configure its own compositing thingy?
<Hobbsee> azeem: ping?
<Hobbsee> azeem: got a #debian-type question for you.
<j1mc> hi all, could anyone tell me if kubuntu has a set of targeted milestone bugs set up like ubuntu does ( https://launchpad.net/ubuntu/+milestone/ubuntu-8.04 )?
<j1mc> my guess would be no, but i wanted to check.
<Hobbsee> j1mc: it doens't - that's the complete list for all flavours (assuming they're all using it)
<j1mc> Hobbsee: thanks.
<Hobbsee> j1mc: see specs assigned to Riddell for the planned kubuntu stuff, though
<j1mc> Hobbsee: thanks again.  a question was asked about this in xubuntu-devel.  this is helpful information.
<Hobbsee> j1mc: xubuntu is free to add to that list, and discuss things with slangasek and other members of the release team, too
<j1mc> i will pass along that information. :)
<Hobbsee> but please assign the bugs to some of your guys
<Hobbsee> as you're responsible for them
<j1mc> Hobbsee: understood.  thanks.
<Hobbsee> at least, that's hte way this all worked in gutsy.  i'm unsure if slangasek has changed protocol, as i haven't seen many non-canonical people involved in any areas of RM this cycle.
<azeem> Hobbsee: pong
<Hobbsee> azeem: /query?
<azeem> Hobbsee: sure, but I'm probably not around long :-/
<Hobbsee> azeem: no problem, hopefully it won't take long
<laga> slangasek: i tried today's mythbuntu alternate disk and the udeb wasn't installed, despite it being  Priority: standard
<laga> slangasek: do you think you could take another look?
<laga> slangasek: or.. wait. when is the menu entry in d-i supposed to show up? right at the beginning or is it added later, eg after the base system was debootstrapped?
<lamont> why do my shift and control keys not wokr anymore/
 * lamont applies the redmond solution
<lamont> seb128: why doesn't my shift key love me anymore//  ditto for ctl...
<seb128> hey lamont, dunno I'm not an xorg guy
<lamont> heh
<lamont> it's like gnome... ;-0
<lamont> hrm... emoticons screw up too...  amazing how much one uses the shift key...
 * lamont hits it with a rock
<kagou> hey seb128
<Chipzz> lamont: I read something about a fix for the "keys stuck" problem in X
<Chipzz> lamont: there was a patch for that
<lamont> Chipzz: ah, cool
<Chipzz> lamont: not sure if it got uploaded though
<Chipzz> lamont: maybe that could possibly have the side-effect you're seeing?
<Chipzz> lamont: the fix would be in the xorg-core package, so try downgrading that (you would also need to restart your X-server obviously)
<Chipzz> lamont: lemme see if I can find the url in the backlog ;)
<wasabi> This "run this action now" dialog... may at least be putting power in my hands... but it's way too technical.
<wasabi> Package authentication failure of some sort.
<Chipzz> lamont: https://launchpad.net/bugs/194214
<ubotu> Launchpad bug 194214 in xorg-server "Keys get "stuck" down" [Unknown,Confirmed]
<Chipzz> lamont: hrrrm no mention of the patch being applied and uploaded yet; so that's probably not it
<lamont> seb128: sometime, I should find out about the rising dominance of gnome-keyring-manager (or whatever the hell it is) and seahorse, and figure out what to add or remove from my sledgehammer-of-a-gnome-session
<lamont> maybe it's finally usable out of the box??
 * lamont wanders off for a while
<seb128> lamont: the gnome-keyring new changes are cool ;-)
<slangasek> laga: ok, trying to take a look; it's possible that I have to set the priority to 'Standard' in the archive overrides rather than relying on what the package thinks, for that change I should probably check with cjwatson and pitti first
<slangasek> laga: right, it looks like the CD build takes the package priorities from the archive overrides, rather than looking inside the individual packages.  In that case, making it Priority: standard for the installer would require making it visible as Priority: standard for other install methods too, so that'll need more discussion; sorry for putting you to the effort
<calc> Riddell: ping
<calc> Riddell: does kde use shared-mime-data and associate programs via desktop files for mimetypes they claim to open?
<slangasek> tjaalton: ugh, 195953 should have gone through an FFe...
<slangasek> tjaalton: are you tracking this package then, to make sure there are no regressions?
<warrend> hi
<warrend> can someone look at this bug? https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/188764
<laga> slangasek: so are you going to talk to cjwatson/pitti or should i bug them myself?
<slangasek> laga: I'll talk to them (on Monday, I expect - I don't think either of them are around this weekend)
<laga> slangasek: thanks, that's much appreciated
<afflux> does the livecd environment currently warn the user when he doesn't seem to have enough ram?
<afflux> hm, I'll  better ask in -installer
<tjaalton> slangasek: yeah.. sorry about it :/
<tjaalton> slangasek: I'll monitor any issues with it, and actually the upload was broken so I'll fix it asap
<slangasek> tjaalton: ok :)
<tjaalton> huh, this is strange.. it included wacom_drv.o, when it should have built .so
<tjaalton> but building it locally generates only .so
<slangasek> heh
<tjaalton> maybe it's the default CFLAGS etc biting me again?
<slangasek> that would be strange if so
<slangasek> a strange misfeature of the upstream build rules
<tjaalton> yep
<tjaalton> found the bug.. now figuring out how to fix it
<tjaalton> fails to find the module dir
<tjaalton> hmmh, is 'elif -z "$FOO"' bashism? the wacom configure script seems to fail with '-z: command not found'
<ion_> Probably missing 'test' or [ ].
<tjaalton> yep, test should do it, since all the other tests have it
<tjaalton> quality
<slangasek> I don't think that's even a bashism, I think it's invalid shell
<tjaalton> right, bash fails too
<tjaalton> seems that no-one is using latest wacom :)
<tjaalton> or at least not reporting these upstream
<slangasek> well that's encouraging
<tjaalton> hehe
<tjaalton> anyway, a fix uploaded
<tjaalton> the release is a month old, so the actual code should be quite solid :)
<slangasek> how do we know that, if no one's actually managing to build it successfully?
<tjaalton> slangasek: maybe they were built by hand?-) anyway, upstream is adamant about this being much better for xserver 1.4..
<tjaalton> better release
<\sh> keescook / bryce: are you pushing inkscape 0.46 to hardy? editing pdfs sounds awesome :)
<YokoZar> I'm trying to track down a bug regarding Cyrillic input, but don't have a cyrillic keyboard...what's a good way to emulate that?
<ion_> setxkbmap ru?
<YokoZar> ion_: the trouble is I don't really know what buttons to push, heh
<Fujitsu> The GNOME keyboard layout setting thing shows the mapping when you select it.
<YokoZar> Fujitsu: ahh ok.  I should learn to look in obvious places, thanks.
<sistpoty> Keybuk | Mithrandir | doko: please give back haddock and hscolour on lpia, thanks
<doko> sistpoty: can't do that: it's MANUALDEPWAIT
<sistpoty> doko: what does that mean?
<Fujitsu> sistpoty: It'll automatically be retried when the dependency is available.
<sistpoty> Fujitsu: ah, thanks
<Fujitsu> MANUALDEPWAIT isn't manual at all. Isn't it great?
<sistpoty> oh... haddock is already built... cool, but I don't see manualdepwait for hscolour on lpia?
<ScottK2> Just for the record I'd like it noted that I'm self-censoring right now.
<sistpoty> Fujitsu: any clues about hscolour, and where I could see it being manualdepwait?
<Fujitsu> sistpoty: Looking.
<sistpoty> thanks
<Fujitsu> doko: hppa and lpia failed to build; they're not MANUALDEPWAIT.
<sistpoty> doko: ok, then please give back hscolour on lpia (hppa is no use to give back, we don't have ghc6 there)
<doko> Fujitsu: according to  https://edge.launchpad.net/ubuntu/+source/haddock/0.8-2 both are "Dependency wait"
<Fujitsu> doko: Ah, I speak of hscolour.
<sistpoty> doko: that's haddock, and it's for gutsy (which I misread in the first place as well *g*)
<sistpoty> (and for hppa...)
<doko> sistpoty: done
<sistpoty> doko: thanks!
<YokoZar> Is there a reason why /usr/share/X11/locale/locale.dir  lists ru_RU.UTF-8/XLC_LOCALE  ru_RU.UTF-8  rather than en_US.UTF-8/XLC_LOCALE  ru_RU.UTF-8 ?
<slangasek> because of KOI8, according to the diff.
<keescook> \sh: yawp, been done: inkscape | 0.46-0ubuntu1   | hardy/main
<YokoZar> slangasek: Which package is that?  It may be causing a rather old bug in Wine ~ cyrillic input: https://bugs.edge.launchpad.net/wine/+bug/68594
<ubotu> Launchpad bug 68594 in wine "No cyrillic input in apps under wine. " [Undecided,New]
<slangasek> YokoZar: hrm? I'm talking about diff -u /usr/share/X11/locale/{en_US,ru_RU}.UTF-8/XLC_LOCALE
<slangasek> I think you're unlikely to make a persuasive case that a wine bug should be fixed by *not* using the Russian KOI8 map
<slangasek> and I'm not aware that XLC_LOCALE has anything to do with input anyway?
<YokoZar> slangasek: I'm not sure why making the change fixed the problem earlier either.  Now, it looks like I can type Cyrillic characters in Wine's notepad (which is a UTF-8 app), but I don't have an ANSI app to test this on.  Wine's free fonts just started supporting Cyrillic letters too.
<slangasek> if the problem was display of Cyrillic characters, then XLC_LOCALE would have some bearing
<YokoZar> slangasek: that makes sense.  I'll close the bug
#ubuntu-devel 2008-03-30
<bryce> \sh_away: inkscape 0.46 is already in hardy
<dbmood1> oi we have bug with ubuntu gutsy and local time in australia in in nsw
<dbmood1> we need the time to move forwards one hour -- ntp is not providing the proper time
<dbmood1> this is a major problem for security etc. and needs to be worked on as soon as possible
<ScottK> StevenK: ^^^ How's your time now?
<dbmood1> 11:20 instead of 10:20
<dbmood1> i will to go tzdata now and see if i can fix it
<dbmood1> http://www.timeanddate.com/worldclock/city.html?n=240
<Fujitsu> dbmood1: Timezones won't change for another week.
<Fujitsu> It changed this year. It's the first week in April.
<dbmood1> http://www.abc.net.au/news/stories/2008/03/30/2202804.htm
<dbmood1> it needs to be moved -- forwards and then back
<dbmood1> Fujitsu: yes you are normal correct it was changed
<Fujitsu> We should still be +11.
<Fujitsu> Is it not 0021 UTC at the moment?
<sistpoty> well, UTC doesn't change, does it?
<dbmood1> let me try apply utc
<Fujitsu> It doesn't, but my system says it's 1123 local time.
<dbmood1> its 00:23:31 according to my altered clock
<dbmood1> as in put back for daylight savings
<Fujitsu> All of my systems are correctly still +11.
<Fujitsu> THey weren't meant to switch back, and didn't.
<Fujitsu> I checked this some weeks ago.
<dbmood1> what ?
<sistpoty> dbmood1: I saw a new tzdata coming in recently (maybe today, not too sure). do you have that installed already?
<sistpoty> (for gutsy)
<dbmood1> i'm using ntpd to update too...
<dbmood1> is that a problem ?
<Fujitsu> We're not meant to switch from +11 to +10 for another week. My Dapper, Gutsy, Hardy systems haven't switched yet.
<dbmood1> well i have just switched
<Fujitsu> dbmood1: Which version of Ubuntu are you running?
<sistpoty> Fujitsu: lucky you... I'm loosing an hour tonight already :(
<dbmood1> 7.10 here i can check hardy
<Fujitsu> dpkg -l tzdata
<dbmood1> Desired=Unknown/Install/Remove/Purge/Hold
<dbmood1> | Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
<dbmood1> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
<dbmood1> ||/ Name           Version        Description
<dbmood1> +++-==============-==============-============================================
<dbmood1> ii  tzdata         2007f-3ubuntu1 time zone and daylight-saving time data
<dbmood1> i might have my updates screwy ?
<Fujitsu> Ooh, damn.
<Fujitsu> You're right.
<dbmood1> is it just me ?
<dbmood1> or ...
<Fujitsu> 2007f-3ubuntu1 is too old, I think.
 * Fujitsu looks harder.
<dbmood1> rofl oh cool
<Fujitsu> I'm thoroughly confused.
<dbmood1> thank you
<dbmood1> sorry
<dbmood1> seems all is fine
<dbmood1> but iinet my isp repos are slightly outdated
<dbmood1> or something
<dbmood1> oh wait .... was the tz.. thing a recommended update ? because i don't have those ticked
<ion_> Let's just get rid of the stupid DST altogether. :-)
<Fujitsu> Oh what.
<Fujitsu> WHy the heck did this only go into -updates?
<dbmood1> let me tick recommended and see what happens
<Fujitsu> dbmood1: That's the problem.
<dbmood1> its a security bug it should be in security too tho
<Fujitsu> The update has been in *-updates since 2008/03/07.
<dbmood1> i don't imagine many people to have recommended ticked
<Fujitsu> But not in -security.
<Fujitsu> Most people should.
<Fujitsu> This sort of update should really go into -security, I think...
<dbmood1> is it default ?
<Fujitsu> As it's utterly critical.
<Fujitsu> I believe it is on by default.
<dbmood1> hopefully
<dbmood1> -- what about for lts and the server releases -- yeah that fixed it
<pwnguin> how is a tzdata bug a security bug?
<dbmood1> well if you have encryption that is based on time etc. / you get time based attacks
<pwnguin> because you're an hour off from everyone else?
<dbmood1> ........a whole hour
<dbmood1> yes
<dbmood1> got an end user to confirm (hopefully didn't touch it) that she doesnt' have the correct time ....
<dbmood1> no wait
<dbmood1> she got the update
<pwnguin> well, there's a hardy tz bug
<dbmood1> well i will know the full answer when she returns...
<keescook> doko: got any pointers for pycentral usage with a package that has SWIG python bindings?  I seem to be missing some critical step -- everything gets built and installed but python can't seem to find it...
<dbmood1> but my debian box has the correct time it seems and this is an etch box... zdata         2007j-1etch1   Time Zone and Daylight Saving Time Data Australia/Sydney  Sat Apr  5 15:59:59 2008 UTC = Sun Apr  6 02:59:59 2008 EST isdst=1 gmtoff=39600
<dbmood1> Australia/Sydney  Sat Apr  5 16:00:00 2008 UTC = Sun Apr  6 02:00:00 2008 EST isdst=0 gmtoff=36000
<dbmood1> sorry to be so spamish i will be quiet except to tell you the out come of the lady's update
<Fujitsu> The change was made in 2007g.
<slangasek> pwnguin: hrm? what tz bugs are there in hardy?
<slangasek> pwnguin: more precisely, why is there no bug report about this that's importance: high and milestoned for the release? :)
<Fujitsu> So anybody who has updated from -updates since 2007/10/20 will have the changes.
<Fujitsu> If tzdata updates are only pushed to -updates, it shouldn't be `Recommended updates', it should be `Critical (unless you don't care about even slight accuracy of time) updates'
<pwnguin> slangasek: they're actually bugs in gnome-clock-applet
<dbmood1> in this case it is an hour off and they - end users who might not have it ticked will have it off - some admins might not want to allow the recommended -- or know about the change yet -- they probably have them off
<pwnguin> slangasek: apparently it doesn
<slangasek> pwnguin: oh, I guess you mean the fact that gnome-panel guesses your timezone wrong
<pwnguin> yes. just mentioning it in case the above "end user" was merely judging from hardy, etc
<dbmoodb> apparently if you do not turn ntp on the time even with the correct tzdata will not fix the problem immediately (end user result) -- hope you guys can start looking into this --- seems easy to fix and blah (package seems to be fine -- waiting for sometime i guess)
<mttr> i installed the beta,, everthing went well but grub doesn't like the partition
<Fujitsu> mttr: #ubuntu+1.
<mttr> np
<_MMA_> gah.. After new updates GDM sound nor logout sounds work. :(
<jdong> _MMA_: and you're sad?
<_MMA_> Well a little more than sad because this has been something that has broke for one reason or another for 2 releases now. But I don't wanna be a di*k about it yet.
<ion_> dirk?
<_MMA_> dick
<ion_> Ah, right. I thought you mean dink.
<_MMA_> If ya wanna be a smart-ass. ;)
<_MMA_> Oh well. I'll work on it Monday.
<lifeless> there will be a short outage to the wiki and bazaar.launchpad.net, to hoepfully address the bazaar.launchpad.net performance problems
<Oasys> hey
<warp10> good morning
<Hobbsee> ah yes, australian time confusion
<ompaul> we got 11 hours gap or 9 now?
<ompaul> you fell back and we went fortward
<Seveas> @now sydney
<ubotu> Current time in Australia/Sydney: March 30 2008, 20:18:58 - Next meeting: Server Team in 3 days
<ompaul> so 9
<ompaul> no
<Seveas> 8 for me
<Seveas> 9 for you
<Hobbsee> Seveas: that's wrong.
<Hobbsee> Seveas: it's currently 9.18pm
<Seveas> ah
<ompaul> Hobbsee, you don't change for two weeks iirc
<Seveas> Hobbsee, hmm, odd
<Hobbsee> ompaul: yeah.  something like that.  i only noticed when the pin clock for work was showing the wrong time.
<ompaul> Seveas, they are auzzies  ;-)
 * Hobbsee beats ompaul before he can run away
 * ompaul buys Hobbsee a cup of tea and tells her to work on getting her country to change time in sync with the rest of the planet (or close enough that it don't matter)
<Seveas> there's no python-tz update for dapper
<Seveas> fun :/
<slangasek> ompaul: so every time some government nutter up here decides to extend DST by another few weeks, Australia should get a few weeks less DST? :)
<pwnguin> sounds great
 * persia discourages synchronisation.  Conference calls are annoying when there is more than one time transition happening the same week
<Hobbsee> persia: this is why we all deal in UTC.
<Hobbsee> this must mean that the UK/AU time crossover gets significantly worse again, though
<persia> Hobbsee: True, although I've recently discovered that some people confuse UTC and British Time
<Hobbsee> yeah, true
<Fujitsu> I find it most unfortunate that those without -updates enabled are doomed to have incorrect times.
<persia> I think anyone living in a country that changes the clocks is doomed to have incorrect times once in a while.
<Fujitsu> If you have -updates, you're safe.
<persia> (excepting at least Argentina)
<Fujitsu> Well, if we're *really* quick...
<persia> heh
<ompaul> slangasek, na there is normally a two week lag between .eu and .au
<ompaul> slangasek, after that you factor in the nutters ;-)
<Seveas> ompaul, that's not just with DST
<StevenK> Actually, NSW comes first. Except they've changed it so that all of .au changes DST (the states that use it) at the same time
<persia> StevenK: Not only the same day, but the same time?
<StevenK> persia: Well, I mean the same day. It used to be NSW dropped DST today, and the rest followed a week later. Now we all have to wait until next week
<StevenK> (And well done Telstra for having your time sources on the phone network jump back an hour today)
<Nafallo> lol
<persia> Ah.  That makes more sense.  I thought it was something like 4am in the east, 3am in the middle, and 1am in the west
<StevenK> Actually, 4am in the east, 3:30am in the middle and 1am in the west
<persia> Err.  Never mind the bit about the west
<persia> Huh?  I thought there was a timezone between Melbourne and Adelaide.  Time to study the time map again
<StevenK> There is.
<StevenK> Melbourne is +1100, and Adelaide is +1030
<StevenK> Perth is +0800
<StevenK> (After next week, it's +1000, +0930, +0800)
<persia> Ah.  And Victoria and NSW are the same.  Right.  And summer time expires in West Australia in 2009.
<StevenK> persia: Yes, Victoria and NSW are the same in terms of DST. Queensland is not.
<persia> Ah.  That was the source of confusion.  Thank you.
<emgent> hello
<pitti> lamont: look at what?
<pitti> lamont: sorry, tab error; unping
<emgent> hi dendrobates :)
<Riddell> calc: KDE 4 uses shared-mime-info, KDE 3 not
<keescook> why does glib2.0 have such an odd version number?  it's less than the unstable version it's based off of
<keescook> it really should be named 2ubuntu1 not ~hardy1
<jdong> I was wondering about that too
<calc> Riddell: is there a way for me to query what kde 3 uses for particular files to see what i need
<keescook> jdong: 209308
<jdong> bug 209308
<ubotu> Launchpad bug 209308 in glib2.0 "glib2.0 version is wrong" [Undecided,Confirmed] https://launchpad.net/bugs/209308
<jdong> cool
<calc> doko: how is the progress on the i18n stuff?
<doko> looking ...
<calc> doko: i'm testing my first full build right now, so it might be ready for upload tomorrow
<doko> yes, second build finished, I'll let you know tonight
<calc> doko: great :)
<ffm> Does anyone here work on wubi?
<calc> the cairo patch fixes OOo font display issues :)
<protonchris> calc: which patch?
<jdong> calc: so I have to scroll back 24hrs in my IRC logs to understand the context of that statement? :D
<calc> jdong: no, if you notice OOo fonts have looked wrong for like forever, they will be fixed probably tomorrow (when i manage to upload)
<calc> it was using cairo/libfreetype incorrectly :)
<jdong> calc: awesome! and yes, I have noticed that
<calc> i don't remember which bug report had the patch there were many related bug reports about OOo fonts looking bad
<calc> it appears it doesn't do subpixel smoothing but works for the other settings
<calc> jdong: yea i see you were one of the people commenting on the oldest of the fonts bugs
<jdong> I vaguely recall filing a sarcastic bug or two on that when I felt in a particularly bad mood :D
<calc> jdong: heh :)(
<calc> er :)
 * calc has fat fingers
<tjaalton> calc: will impress support 3D effects too?
<calc> tjaalton: not sure i haven't looked at that yet
<calc> tjaalton: probably if it is listed as a 2.4 feature upstream
<milli> calc: thank you!!  (font bugs with OO)
<tjaalton> it's probably a config option or something, the current version in Hardy doesn't support it
 * milli hates ugly fonts
<calc> so far the font bugs look to be fixed EXCEPT for the subpixel stuff, but that is a lot better than it was
<tjaalton> I mean build config option..
<calc> tjaalton: hmm ok
<calc> i'll need to dig to see if i can find a patch to fix the subpixel part also
<calc> erm
<calc> it looks like it is working now, wtf
<calc> yea its definitely working, i thought it wasn't earlier, so now i am confuse
<calc> confused
<calc> ok yea its consistently working now, so i am not sure what happened earlier
<calc> one minor issue is you have to restart OOo to get the font setting to change, you can't change it while running
<tjaalton> calc: --enable-ogltrans
<calc> tjaalton: ah
<tjaalton> calc: don't know what it depends on
<calc> let me see if it isn't getting enabled for some reason
<tjaalton> calc: it was added after rc2 :)
<calc> it appears to be attempted to be used via
<calc> --enable-opengl
<calc> so that might be a bug then
<calc> ok
<calc> well its still not there in the debian version as of 2.4 final
<calc> i'll look into it and see if the arg needs to be changed or added in addition to the other one
<tjaalton> cool, thanks
<Riddell> calc: kde 3 uses /usr/share/mime
<Riddell> calc: /usr/share/mimelnk/ rather
<calc> Riddell: does it just do matches based off of file extension? or is there a way to determine what mimetype it would consider a particular given file to be?
<calc> Riddell: i'm wanting to make sure that i list all the needed mimetypes for KDE in OOo to open the files correctly
<calc> Riddell: i already have it for all the shared-mime-info using gvfs-info to verify
<calc> Riddell: so i think that will probably already work correctly for KDE4 (haven't tested)
<Riddell> calc: kde 3 also does some magic detection, using kdelibs-3.5.9/kio/magic
<calc> Riddell: is there any kde util that i can use to have it spit out the mimetype?
<emgent> calc :)
<Riddell> calc: don't think so, probably not hard to write on in python
<Riddell> calc: http://kubuntu.org/~jriddell/tmp/mimetype2.py
<calc> Riddell: thanks!
<calc> Riddell: still here?
<calc> Riddell: i tried running that script and its bombing out
<calc> Riddell: tells me list index out of range
<calc> Riddell: i can paste it to pastebin if you are around, not sure why it is saying that
<calc> http://pastebin.ubuntu.com/6234/
<calc> i ran it as ./mimetype2.py filename
<calc> ah it worked when i ran it as python mimetype2.py filename
<calc> i'm not quite sure why but it worked
<calc> i am confused, this script is telling me kde thinks a excel file is type application/msword
<calc> but in dolphin it says its an excel file
<calc> is dolphin using shared-mime-info or kde's mime stuff
<calc> if this is working right then kde's mime support is crummy
<calc> it claims xml file is text/plain
<lifeless> is there a bug open on the AEST/AEDT tzdata error ?
 * calc thinks he'll let a kde person determine if the files are opening correctly, since it seems kde mime support is very weird
<calc> borderline broken it would seem
<Riddell> calc: http://kubuntu.org/~jriddell/tmp/mimetype2.py updated
<calc> Riddell: ok testing that
<calc> Riddell: works much better! :)
<calc> now it thinks excel files are... excel files ;-)
<calc> yipee it looks like it is working much better all around :)
 * calc can now make sure all these mimetypes are in the files as well
<Fujitsu> lifeless: Which error? The updates have been in -updates since late October.
<Fujitsu> But I'm not sure what you're expected to do if you only use -security.
<lifeless> Fujitsu: I'm running hardy and its wrong
<lifeless> Fujitsu: by which I mean, the NSW senate changed the daylight saving rules
<Fujitsu> lifeless: Ermm.
<Fujitsu> I'm in Vic, I know of the change.
<Fujitsu> dpkg -l tzdata
<calc> well its still a bit buggy but i wouldn't be surprised if it was actually real bugs at this point since most of the types are showing up right
<lifeless> Fujitsu: 2008b-1ubuntu1 :P
<Fujitsu> Ah, I'm only on 2008a...
<Fujitsu> cat /etc/timezone
<Fujitsu> I bet it's User defined.
<lifeless> no such file
<Fujitsu> Um.
<Fujitsu> Anyway, I have to head off to uni now... but tzdata in all releases has been updated with the right dates.
<lifeless> Another ubuntu user I know of has the same symptoms of an early change back
<lifeless> bye
<RAOF> lifeless: My (Hardy) clock is correctly showing DST.
<lifeless> RAOF: thanks
<jdong> my gutsy clock handles DST correctly too, although I use -proposed, -updates.
<slangasek> lifeless: you're using the gnome clock applet?
<lifeless> slangasek: well two things got it wrong: my server, and my gnome clock applet
<lifeless> the server I can tell via irssi :>
<slangasek> lifeless: click, Locations, Edit, verify that the timezone automatically populated for your city isn't wrong
<lifeless> server is 7.04; probably just haven't updated in an age
<jdong> I think this will be a great excuse for not turning in my paper on time tonight!
<lifeless> slangasek: tiemzone "australia/sydney" with caps; looks right to me
<lifeless> slangasek: and 'date' in a console has the same time
<slangasek> hmm, ok
<slangasek> so what time is it supposed to be there right now?
<lifeless> did feisty get the tz updates?
<lifeless> its supposed to be 0838
<slangasek> lifeless: that's what I see on the console with current hardy when I type TZ=Australia/Sydney date
<soren> Wow. A 1 minute offset?
<soren> :p
<lifeless> soren: race condition on the minute boundary :-}
<slangasek> lifeless: so I don't think the problem lies with the tzdata package
<lifeless> slangasek: well, thats quite bizaare then.
<ion_> Since it was :39:58, the boundary was quite wide. :-)
<lifeless> whats current utc ?
<slangasek> lifeless: hwclock in UTC?  does it display the right time? :)
<slangasek> 21:40
<ion_> Sun Mar 30 21:41:59 UTC 2008
<lifeless> TZ=utc hwclock --show --utc
<lifeless> Sun 30 Mar 2008 21:43:07 UTC  -0.117192 seconds
<lifeless> so, other than fucking around with kerberos, the hwclock seems ok.
 * slangasek grumbles and adjusts his clock by hand, since repeatedly setting it via the clock panel causes it to drift backwards :P
<slangasek> yet another bug I should file on that damn thing...
<lifeless> TZ=Australia/Sydney date
<lifeless> Mon Mar 31 08:43:39 EST 2008
<lifeless> so my current time zone is apparently not Australia/Sydney
<slangasek> score
<slangasek> blame bug #185190
<ubotu> Launchpad bug 185190 in gnome-panel "Clock applet chooses wrong timezone for many cities (eg Pittsburgh, Beijing)" [Low,Triaged] https://launchpad.net/bugs/185190
<slangasek> even if it's not the bug at issue ;)
<lifeless> ~$ echo $TZ
<lifeless>  
<slangasek> ls -l /etc/localtime?
<slangasek> (well, "readlink /etc/localtime")
<lifeless> not a symlink !
<lifeless> and I'll bet that my friends bug is the same
<slangasek> and you said you don't have an /etc/timezone, so you get to try to guess which file under /usr/share/zoneinfo it corresponds to, enjoy
<slangasek> welcome the world of precision timekeeping
<slangasek> s/the/to &/
<lifeless> running tzselect doesn't make it a symlink eithe
<lifeless> well, I bet I know what file it is
<lifeless> its the *old* Australia/Sydney file.
<slangasek> oh, heh
<lifeless> in fact, wtf is tzselect meant to do these days
<slangasek> well, the reason it's not a symlink is that it screws things up if /usr is on a separate partition at boot
<lifeless> cause it sure as hell ain't writing to /etc/localtime
<slangasek> but /etc/timezone is supposed to be used to track this
<lifeless> nor to /etc/localtime
<lifeless> sorry, not to /etc/timezone
<slangasek> and obviously we need to be updating /etc/localtime when the package updates
<slangasek> lifeless: dpkg-reconfigure tzdata? :/
<lifeless> yes just found via the tzselect man page
<lifeless> :)
<lifeless> and it too writes a static file
<lifeless> yup
<lifeless> you want to file the bug?
<slangasek> no, I want you to file the bug and me to fix the bug ;)
<lifeless> blah
<lifeless> lp account name ?
<slangasek> vorlon
<lifeless> mailed
<slangasek> we're going to have to get a gnome-panel task for this well, since the gnome panel is not interacting appropriately with the tzdata-controlled files
<slangasek> thanks
<lifeless> breakfast, then to see about unfucking the wiki & b.l.n
<slangasek> lifeless: looking at the postinst, the failure here is because /etc/timezone didn't exist; I'm guessing you don't have any overt knowledge of removing this file yourself... :)
<slangasek> (in which case I need to track down why it wasn't created on upgrade)
<lifeless> I'm glad I poked around a bit first :)
<lifeless> and no
<Seveas> slangasek, which upgrade should have created it? I'm missing the file as well but my hardy is slightly outdated (a week or so). Might help tracking it down
<slangasek> Seveas: an upgrade long ago, I think.  There's mention of a preinst having been added in Aug 2007, but that preinst doesn't exist now; I'm going to chase this with the Debian glibc maintainers
<slangasek> lifeless: what was this machine originally installed as?
<lifeless> -EDUNNO
<lifeless> feisty or gutsy 64 bit; then I copied various things from my 32-bit laptop (like exim config files)
<lifeless> probably the fister
<calc> great i found all the mimetypes i needed for kde :)
<slangasek> lifeless: do you happen to remember if it was liveCD or alternate?  It's conceivable that this was a ubiquity bug
<Seveas> slangasek, mine (2 of them) were desktop installs
<slangasek> Seveas: installed from which release?
 * slangasek needs to know which CD to start downloading :)
<Seveas> that's what I'm trying to find out, edgy or later for sure
<Seveas> one of them ubiquity 1.2.5
<slangasek> that's edgy
<Seveas> another 1.4.11
<slangasek> feisty
<slangasek> fun fun
<emgent> uhm cacti FTBFS, and patch is ready. If someone can please see bug #194687
<ubotu> Launchpad bug 194687 in cacti "cacti web frontend fails with 'Invalid PHP_SELF Path' after upgrade" [Medium,In progress] https://launchpad.net/bugs/194687
<emgent> ScottK: ping
<ScottK> emgent: Pong
<emgent> about bug #194190
<ubotu> Launchpad bug 194190 in cacti "Please sync cacti 0.8.7b-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/194190
<emgent> i saw now that debian version bump fix all.
<emgent> i go to remove ubuntu patch and i will attach debdiff.
<lifeless> slangasek: no idea
<slangasek> okie-day
#ubuntu-devel 2009-03-23
<Pollywog> cjwatson: I even followed the instructions in the wiki for using chroot and there are some things left out that I had to figure out on my own
<Pollywog> and I am using schroot instead of dchroot
<Pollywog> so this learning process will be slow
<directhex> YokoZar, which player?
<YokoZar> directhex: default totem (installing -restricted-extras didn't change anything)
<cjwatson> the most important thing to realise is which things are important ... chroots are a nicety that you can look into once you have the basics working. The purpose of using a chroot is either to make sure that your package builds in a clean environment, or to build it for some different environment than your usual one. It is not the first thing that you should be reaching for when trying to debug why something is not working
<cjwatson> start small and build up
<Pollywog> I wanted to build on a machine running Intrepid, but the package is for another running Hardy
<Pollywog> hence the chroot
<Pollywog> and I wanted to make a custom deb package because one does not exist
<Pollywog> I have used checkinstall for this for years but I wanted to do it the right way
<cjwatson> well, if you're using a chroot for that purpose then you probably need it, but you should start by constructing an environment within the chroot that you can debug in just as you would outside the chroot
<cjwatson> the goal being that you shouldn't need to remember that you're in a chroot most of the time
<cjwatson> the fewer bits of state you have to keep in your head at once, the better
<cjwatson> the fact that you mention that a chroot is slowing your learning process indicates to me that you haven't quite got there yet :)
<directhex> i find a stateless brain helps
<Pollywog> no chroot is not slowing the process
<Pollywog> the process is just a slow one
<Pollywog> since some things are not documented
<cjwatson> what you need to do is teach yourself the basic tools first
<cjwatson> trying to figure out what DEB_CONFIGURE_EXTRA_ARGS does is starting from the wrong end
<Pollywog> and when I came to Ubuntu from Debian, I found some things are not the same
<cjwatson> start by learning the basics of GNU make and shell scripting if you don't already know them
<Pollywog> though they are similar
<Pollywog> k
<Pollywog> good advice
<cjwatson> then read through the policy manual and familiarise yourself with the packaging format
<cjwatson> then pick a sample package, read its debian/rules, and look up manual pages for anything you don't recognise that looks interesting
<cjwatson> repeat
<Pollywog> is the Ubuntu Policy Manual different from the Debian one?
<cjwatson> in small ways, none of which are relevant to you
<cjwatson> at least not the problem you have described
<Pollywog> I wanted to do that with kmail but I think I should pick a smaller app
<Pollywog> cjwatson: I read this same advice about learning a package, but perhaps kmail is too complex for a first package
<cjwatson> Pollywog: cdbs is the least well-documented of all the popular helper packages
<cjwatson> not only is kdepim large in and of itself, but it's using a packaging helper which is designed to allow the maintainer to express very powerful things while typing very little
<cjwatson> while furthermore largely not explaining what it does
<cjwatson> this is certainly not going to be conducive to learning; but the majority of Ubuntu (and Debian) packages are much simpler
<ebroder> Yeah, that's definitely true. The people I learned packaging from use cdbs exclusively, but you can't really use it without understanding at least the concepts behind debhelper packaging
<Pollywog> I guess I could use some smaller package like equivs
<cjwatson> ebroder: right, hence my comments about building up
<Pollywog> the reason I picked kmail is that it has an annoying bug of long standing
<cjwatson> debhelper is a straightforward set of helper tools that operate by abstracting out things you might otherwise type into debian/rules, but in a fairly simple subroutine-call kind of way
<cjwatson> debhelper is also generally very well-documented
<cjwatson> since cdbs builds on top of debhelper, you must understand debhelper first
<cjwatson> in order to understand debhelper, you must understand the things it's abstracting, i.e. the basic packaging format
<cjwatson> if you work in the right order, it is all much easier and less overwhelming
<Pollywog> I will read the debhelper stuff again and again, it was hard to digest
<cjwatson> did you read it before understanding the basic packaging format, though?
<cjwatson> it's written for people who already know that
<Pollywog> no
<Pollywog> k
<directhex> we've seen some frankly bizarre ones here before from people seeking to avoid learning the "right way" - one guy was editing control.tar.gz in a .deb by hand
<cjwatson> oh, well, I've done that for very specific reasons, but I already knew what I was doing ;-)
<ebroder> ..eww
<cjwatson> (it's a straightforward way to work around broken preinsts if you're in a rush)
<directhex> cjwatson, i think you've probably earnt the right to do sordid things to packages by now
<Pollywog> I had to fix a script in a Debian package once and then put the package together again
<Pollywog> so I could remove it and then install it again
<Pollywog> it worked :)
<cjwatson> the preinst (well, and nowadays the config as well) is the only case where you actually need to reassemble the package like that
<cjwatson> everything else you can just fiddle about in /var/lib/dpkg/info/ or elsewhere on the filesystem
<Pollywog> yes a preinst or postinst was broken
<cjwatson> editing a postinst does not require disassembling and reassembling the .deb
<cjwatson> for the simple reason that the postinst is run in a distinct step (with its own dpkg option, even) after the package is unpacked
<Pollywog> another trick I have used is to make a fake package with equivs
<Pollywog> then remove the fake
<cjwatson> none of this is required to deal with problems removing packages
<cjwatson> if a prerm fails (which is one case where dpkg doesn't provide you a clean get-out), then it's much simpler and more reliable to edit the script in /var/lib/dpkg/info/
<Pollywog> well I did not know that at the time
<Pollywog> yes I have done the editing too
<Pollywog> I think someone told me to do that instead of making fake packages
<cjwatson> the point I'm trying to make is not "woo I'm so tough I can edit files in /var/lib/dpkg/info/" :-) but that, rather than having to remember all the tricks, it all becomes obvious once you know how the mechanisms work
<cjwatson> it's like your car mechanic mostly doesn't have to learn every single possible part number and what might fail with each - they learn how cars work instead
 * NCommander kicks debmirror
 * cjwatson stops preaching and goes to bed. :)
<NCommander> have a good night cjwatson
<ebroder> Is script/runner "Repository.fetch_changesets" what causes tickets to get updated based on commit messages?
<ebroder> Err..sorry - wrong window
<slangasek> Nafallo: and that's exceptional based on the previous pattern?
<calc> anyone know enough about python/launchpadlib to know why this code is wrong: if task.bug_watch != "None":
<Snova> Remove the quotes around None.
<stgraber> are you sure it's "None" and not None ?
<stgraber> I'd guess it's a NoneType and not the string None
<ebroder> "task.bug_watch is not None" would be the more typical way of doing that
<calc> ah maybe so
<calc> thanks guys that worked
 * calc thinks launchpadlib is really slow
<calc> something like 2 seconds per bug that it is checking
<ScottK> calc: It can't be any faster than Launchpad.
<calc> ScottK: true, maybe there isn't a quick way to get at this data, similar data comes up nearly instantly in the web interface
<calc> i ended up with this, i think it works but its still running
<calc> for pkgbug in package.searchTasks(status=['Triaged']):
<calc>   for task in pkgbug.bug.bug_tasks:
<calc>     if task.target.resource_type_link.split('#')[1] is 'project' and task.status is 'Invalid' and task.bug_watch is None:
<calc>       print task.bug.id, "-", task.bug_target_name
<calc> those are the type of bugs that end up vanishing at least afaict when searching in the web interface
<calc> eg if you use hide_upstream they are hidden and if you use resolved_upstream it only shows invalid if it has a bug_watch
<ArneGoetje> slangasek: new -base language-packs for Jaunty have been uploaded.
<calc> ah is and == aren't quite the same thing
<ebroder> Right - "is" is pointer equality, and "==" are value equality, roughly speaking
<calc> ebroder: ok
<slangasek> ArneGoetje: thanks; accepting
<calc> jcastro: what format was she trying to save in?
<calc> jcastro: i'm guessing at word 2003 xml
<jcastro> calc: I think so, I will investigate tomorrow
<jcastro> I've been trying to deal with this crap all night. :-/
<calc> jcastro: fun :\
<calc> jcastro: too bad we can't just cram java onto the cd, it breaks lots of bits of OOo
<jcastro> ok so it's not really a bug, it's just a tradeoff for that certain format?
<calc> the filters are written in xsl which OOo uses java for the xslt libraries, etc
<lifeless> ScottK: launchpadlib can be faster in theory, as portlets are not rendered etc
<jcastro> calc: it would be nice if it installed that kind of stuff on-demand like with mp3's, etc.
<maco> can it be taught that?
<jcastro> we do it with rhythmbox and totem, how hard could it be? *grin*
<calc> lmao
<calc> for one OOo is its own platform
<calc> not easy at all, i am accepting patches of course :)
<calc> pretty much if you use OOo you need Java
<calc> you can't even search help without Java
<maco> really? eek
<calc> i suppose i could add a check to the OOo startup script to automatically ask the user to install java if it isn't already
<jcastro> you know, I think I'd prefer if it did just that, be honest to me upfront, etc ..
<calc> i added to the javaldx error message a few weeks ago to tell the user to install the openoffice.org-java-common package which installs java along with it
<jcastro> a "No seriously you need this" thing on startup or something
<calc> jcastro: problem is that would happen for all instances running OOo pretty much
<calc> jcastro: which would cause people to complain that it annoys them, heh
<jcastro> yeah but on the other hand she had no idea what to do when she got the error
<calc> we just need to bite the bullet and either 1. force Java onto the CD somehow, 2. ask the user to install Java when they get a net connection, or 3. get rid of OOo from default install so it can have proper depends
<calc> the more OOo is developed the more things in it depend on Java
<TheMuso> thats... um.... icky.
<TheMuso> IMO
<calc> in 10 years it probably will be completely written in Java ;-)
<jcastro> calc: going to bed now, I'll add it to my "things I should bring up at UDS"
<jcastro> thanks for the tip!
<calc> jcastro: rick mentioned getting Java onto the cd for karmic, but i'm not sure how that will happen it pulls in a lot of packages to make OOo work
<LordKow> isn't the cd image size currently pushing 700 already?
<TheMuso> Yes
<maco> calc: what if in ~/.openoffice it touched a file after they'd been prompted once?
<maco> calc: check for that file's existence and don't prompt again
<calc> maco: maybe, i don't know how to hook that into OOo itself though, its pretty ugly as it has its own toolkit, etc
<superm1> if that was checked on the first startup of OOo, then you wouldn't really have utility of using it on a live disk anymore, as you'd use use up the the tmpfs with those installed packages if you installed on the live session
 * calc wishes people would stop writing their own toolkit for their apps and just use something standard
<maco> superm1: its not needed to run, just to use some of the more advanced features and help
<maco> so maybe....is there a way to see if its the live cd and not prompt?
<maco> oy, getting complicated
<superm1> maco, but wasn't calc proposing possibly adding it to the startup script?
<calc> maco: or saving to file formats
<maco> yes
<calc> maco: its used in many features, i don't even know what all myself
<maco> oh right what jorge was just saying
<maco> superm1: yes. i was suggesting that the script do if ((java not installed) && (not live cd) && (havent prompted before)): ask
<ebroder> Where can I find documentation on how the netboot images are built?
<ebroder> (Is there documentation?)
<highvoltage> for booting workstation terminals or remote installation?
<ebroder> Err, sorry - not actually netboot. The mini.iso images that are buried in the netboot directory
<highvoltage> iirc, mini.iso is if you want to boot from a small cd image and install the rest of the system over the network
<ebroder> Right. I'm looking to customize it, and I was wondering how they're generated for the archives
<highvoltage> ah, ok
<ebroder> It's, uh, relatively hard to try and search for
<TheMuso> ebroder: you want the dbian-installer source package.
<TheMuso> debian-installer even
 * ebroder stares at the build-depends
<ebroder> I'm mildly disturbed by this package
<ebroder> Thanks, TheMuso
<TheMuso> ebroder: np
<Amaranth> ebroder: I think everyone is, really
<Amaranth> Here there be dragons
<pitti> Good morning
<pitti> slangasek: 345531> I agree that forward is better than backwards; I saw the branch, I'll review/pull/upload
<pitti> calc: 325973> no, it's not supposed to happen by default; as I read it, you need to disable a gconf key (manage desktop with nautilus) to get it
<pitti> calc: there might be some timing issues which trigger the same behaviour on the live system, though
<dholbach> good morning
<pitti> calc: do you get that every time you boot a live system, or just seldomly?
 * pitti hugs dholbach
 * dholbach hugs pitti back :)
<dholbach> there's lots of good stuff still in the sponsoring queue
<slangasek> pitti: spiff; let me know if there's anything you think should be changed about it, I don't really understand how things are meant to split between hal vs. hal-info and policy vs. information vs. preprobe
<pitti> slangasek: what sets the sony-nvidia method?
<slangasek> pitti: it's set in the added fdi file; that got committed, right?
<pitti> slangasek: ah, I see it now; odd, that got dropped from the patch attachment in the merge request email
<slangasek> ah, no
<slangasek> the merge request mail went out before I committed that part
<slangasek> (at that point, I was thinking perhaps it belonged in hal-info instead of hal)
<pitti> slangasek: ideally the fdi file should be in smartdimmer
<pitti> but hal-info is also okay
<slangasek> but not hal?
<slangasek> most 'policy' stuff of this sort seems to be in hal
<slangasek> as I said, I don't understand how things are actually divided
<pitti> hal-info has the hardware specific lists
<pitti> slangasek: but either way, if that's for beta, let's leave it like it is
<slangasek> then why is 10-dell-laptop-brightness.fdi in hal? :)
<pitti> slangasek: but that needs to be discussed upstream first, I don't want to just commit those patches upstream
<slangasek> sure
<slangasek> I don't mind moving it to hal-info; not knowing which package it belongs in was part of why I sent the merge request
<slangasek> (or to smartdimmer, either)
<pitti> slangasek: indeed 10-dell-laptop-brightness.fdi is weird; it's not a vendor/product list, but rather a kludge (it will disappear with kernel 2.6.29)
<slangasek> ah
<pitti> slangasek: don't waste too much work on it; we can clean it up after beta, when it got discussed upstream
<pitti> slangasek: I'm happy to upload this now
<slangasek> also, are the fdi files parsed in alphabetical order?  If so we may need to rename this file, so that it sorts before 10-laptop-panel-mgmt-policy.fdi
<pitti> slangasek: they are
<slangasek> ok, then we need a different name for this file
<slangasek> hmm, I think
<pitti> slangasek: shouldn't make a difference, though? since you use <merge>, i. e. the device will get all access methods anyway?
<slangasek> oh, right
<slangasek> yeah, doesn't matter after all
<pitti> slangasek: if you change keys, the last change wins, not the first change
<slangasek> sure
<pitti> so sorting after sounds right
<slangasek> I was concerned that laptop-panel-mgmt-policy was doing things that were conditional on the keys we set in this new fdi
<slangasek> but it doesn't, it just cares that access_method != "custom"
<slangasek> feel free to upload, then - I actually wasn't expecting all the pieces to come together until after beta, since there's an MIR involved also
<pitti> slangasek: how urgent is the upload? do you need it right now, or can I have another hour or so for bug 322798?
<ubottu> Launchpad bug 322798 in hal "Segfault in hald startup (hald/linux/devices.c)" [High,In progress] https://launchpad.net/bugs/322798
<pitti> slangasek: it has a patch, but I'd like to go through it with a fine comb first
<slangasek> speaking of which, could you review bug #95444 for me?  (FFe request for nvclock, which motu-release punted back to ubuntu-release due to the MIR)
<ubottu> Launchpad bug 95444 in nvclock "No Screen Backlight Control; Notebooks (Vaio, Macbook, HP/Compaq, Samsung, Zepto et al.) with Nvidia Geforce8/Geforce9/Quadro series graphics" [Undecided,Confirmed] https://launchpad.net/bugs/95444
<slangasek> pitti: not urgent at all
<pitti> okay, great
<pitti> slangasek: so the acpi-support task should be wontfix then?
<slangasek> if there's agreement to move forward, yes
<slangasek> siretart: you could've reuploaded ffmpeg-debian with the same version number and asked for the first to be killed from the unapproved queue ;)
<pitti> slangasek: I'm a bit confused; your hal patch adds a dependency to smartdimmer, and there you need a newer nvclock which talks about obsoleting the smartdimmer package and include its own smartdimmer program?
<slangasek> pitti: plan goes like this: 1) newer nvclock, 2) MIR, 3) make nvclock start building the smartdimmer binary package from the new source, 4) profit
<slangasek> pitti: I may have said something different in a bug log at an earlier point, but that's the current plan
<pitti> slangasek: ah, I see
<pitti> slangasek: reviewed and comment added; looks fine to me, modulo the Encoding= line from the .desktop file
<pitti> oh, buildds are langpack'ed
<pitti> slangasek: on a tangent, new langpacks won't help CD downsizing; the update packs replace -base, thus there should never be duplicate files on the live system
<slangasek> yeah; I accepted those ASAP to try to get them through for beta
<slangasek> hmm
<slangasek> well, maybe that's why only alternates are currently oversized :)
<slangasek> er, except i386 desktop is also oversized, darn
<slangasek> still, that's only 1 ISO to worry about shrinking, instead of all 4
<slangasek> pitti: the .desktop file isn't shipped in the package; ok to punt on that change?
<pitti> slangasek: fine
<Nafallo> slangasek: except I had a gdm screen waiting this morning :-/
<slangasek> Nafallo: aha; so doesn't appear to be toolchain-related after all
<slangasek> Nafallo: do you have a useful backtrace in your gdm.log?
<slangasek> er, s/\./ /
 * Nafallo installs pastebinit
<Nafallo> slangasek: http://paste.ubuntu.com/135876/
<pitti> slangasek: oh, seems we need to keep the hal patch as Ubuntu specific for now, see mjg59's response to http://lists.freedesktop.org/pipermail/hal/2009-January/012858.html
<slangasek> pitti: yes, not surprising, this ultimately should be a sensible sysfs interface
<pitti> slangasek: oh, and the patch doesn't cause the fdi to actually be installed; I'll fix that
<slangasek> oh
<slangasek> ok
<slangasek> didn't realize there was an explicit list, sorry :)
<slangasek> the comment about sony-laptop providing a backlight interface worries me slightly; I hope this change isn't a regression for users of any of these models who don't have smartdimmer installed
<pitti> slangasek: explicit list> welcome to automadness :/
<slangasek> :)
 * Nafallo heads in for breakfast and data centres
<pitti> slangasek: hal uploaded; the other patch I was talking about was already in
<dholbach> bryce: around? do you know the state of the x11proto-xext libxi-dev depends discussion?
<dholbach> seems that libvncserver (bug 346836) and libxtst (bug 346841) FTBFS because of that
<ubottu> Launchpad bug 346836 in libvncserver "FTBFS in jaunty" [Undecided,New] https://launchpad.net/bugs/346836
<ubottu> Launchpad bug 346841 in libxtst "FTBFS in jaunty" [Undecided,New] https://launchpad.net/bugs/346841
<dholbach> bryce: debian bug 499858 is still open
<ubottu> Debian bug 499858 in x11proto-xext-dev "x11proto-xext-dev: Missing libxi-dev dependency" [Important,Open] http://bugs.debian.org/499858
<dholbach> (and the patch in there says "libx1-dev" instead of "libxi-dev" :))
<slangasek> Nafallo: aha, your backtrace matches mdz's latest - very promising progress
<slangasek> hmm, only the inner part matches
<slangasek> but this could mean it's a bug in the logging routines themselves...
<dholbach> bryce: nevermind, just read up on the situation
<slangasek> Nafallo: would appreciate it if you could post that backtrace to bug #328035
<ubottu> Launchpad bug 328035 in xserver-xorg-video-intel "*** glibc detected *** free(): invalid next size (fast) for xf86Wakeup() call" [High,Triaged] https://launchpad.net/bugs/328035
 * NCommander wonders if debian-cd comes with instructions ...
<slangasek> Nafallo: how do you feel about running your X under valgrind, btw? :)
<slangasek> your crash seems to happen at the exact point that mine did before; I can't see any bugs in the actual log handling code, so it looks like it's external heap corruption
<pitti> Nafallo, slangasek: I just encountered an X.org crash after suspend yesterday, is that what you are talking about? (I only got some drm:i915 unknown parameter error in dmesg, no xf86Wakeup() call messages)
<slangasek> pitti: that matches the high-level description of the bug, yes.
<slangasek> pitti: check gdm log for the glibc backtrace
<slangasek> (it's SIGABORT on heap corruption, so no apport love)
<slangasek> er, SIGABRT rather
<slangasek> pitti: bug #328035, targeted for jaunty but we don't have any real traction on it yet
<ubottu> Launchpad bug 328035 in xserver-xorg-video-intel "*** glibc detected *** free(): invalid next size (fast) for xf86Wakeup() call" [High,Triaged] https://launchpad.net/bugs/328035
<pitti> [   30.805891] (EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70.
<pitti> I have a ton of those
<pitti> but none of xf86Wakeup
 * pitti checks the bug
<pitti> slangasek: thanks
<slangasek> which version of xserver-xorg-core do you have?
<slangasek> (the fix to have glibc stacktraces dumped to the log was only added in the latest upload)
<slangasek> hrm, I wonder why iwl3945 is being totally inconsistent today about seeing the APs in the neighborhood
<pitti> slangasek: 2:1.6.0-0ubuntu4, the one with Kees' patch
<slangasek> it couldn't see our own AP earlier today when it was sitting right above my head; now it only sees our AP, when there are two others in range
<slangasek> pitti: ok
<pitti> hm, but it was only installed yesterday around noon
<slangasek> ah :)
<pitti> I'm pretty sure I rebooted after that, though
<pitti> yep, I did, 5 hours later
<slangasek> alrighty
<pitti> and I got the crash this morning
<pitti> I'll keep this under observation
 * slangasek nods
 * slangasek is going to try to spend some more time today reproducing it again here
<slangasek> if I can get the backtrace, I can start fiddling with valgrind
<pitti> slangasek: do you know enough about NIS to make a call on bug 345137? I'm afraid it's a little outside of my realm
<ubottu> Launchpad bug 345137 in nis "nis should recommend nscd" [Undecided,New] https://launchpad.net/bugs/345137
<slangasek> I know enough about nscd to say that nothing should recommend it ;)
<NCommander> +1 slangasek
<slangasek> (to be fair, that's based on earlier versions of nscd... maybe it's saner now)
<slangasek> pitti: libnss-ldap only Suggests: it; the same is probably appropriate for nis
<directhex> how about gnscd?
<directhex> we use it in production, it seems to suffer far less from terminal suck
<pitti> slangasek: okay, I leave the reply to that to you then :)
<slangasek> pitti: oh, recommending nscd would also mean a universe -> main promotion
<pitti> right
<pitti> it doesn't seem very appropriate to me at this late time, but I know next to nothing about nscd
<Nafallo> slangasek: sure. can do.
<Nafallo> slangasek: (posting the output. the valgrind thing I would need hand holding on I reckon ;-))
<slangasek> Nafallo: it involves dpkg-divert /usr/bin/X and replacing it with a shell script that exec's valgrind. :)
<slangasek> (may require setting valgrind suid since X is suid, sigh)
<slangasek> also: yuck, why is gdm still referencing /usr/X11R6/bin as the path to X
<directhex> in case you decide to run it on RH7.2?
<slangasek> Nafallo: valgrind recipe posted, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/328035/comments/34
<ubottu> Ubuntu bug 328035 in xserver-xorg-video-intel "*** glibc detected *** free(): invalid next size (fast) for xf86Wakeup() call" [High,Triaged]
<slangasek> (untested, so keep hold of the unwind directions in case the valgrind script breaks your X ;)
<Nafallo> slangasek: anything else then valgrind needs installing?
<slangasek> nope
<Nafallo> Suggested packages:
<Nafallo>   libc6-dbg kcachegrind alleyoop
<Nafallo> oki :-)
<slangasek> and since valgrind traps & handles most heap corruption on its own, you probably have to peek in the log after each resume to check if there's anything interesting there
<slangasek> since chances are X won't crash
<slangasek> btw, you've used valgrind before, right?  You know this is probably going to make X an order of magnitude slower / more memory-intensive?
<Nafallo> hehe. no. didn't know that :-)
<slangasek> ah, yeah
<infinity> *cough*
<infinity> Yeah, just slightly slower...
<Nafallo> oh well. let's wait until X crashes so GDM launches the valgrind then :-)
<slangasek> it has to intercept all heap activity.  That's expensive. :)
<slangasek> TheMuso: this dmraid debdiff is hard to read given that it clobbers previous ubuntu revisions; is this targeted for beta, or should I set it aside for the time being?
<TheMuso> slangasek: feel free to set it asside, it clobbers Ubuntu revisions because they are in Debian, and due to differing MD5 sums for orig tarballs, its a fake sync.
<siretart> slangasek: oh, indeed, well version numbers are cheap, aren't they? ;-)
<mvo> Riddell: could you please apply http://people.ubuntu.com/~mvo/tmp/desktop-effects-kde_0.4.4.1.debdiff to the bzr tree or give me acccess to the bzr so that I can commit it myself?
<cjwatson> damn, if it had occurred to me that language packs wouldn't affect desktop CD size, I'd have done something about the latter yesterday
<slangasek> well, the langpacks took care of alternate CD size nicely in any case
<agateau_> asac: ping
<asac> agateau_: hello
<agateau_> asac: I was sent to you because I have troubles connecting to my wifi AP with NM
<agateau> I am running Jaunty and can connect to my wifi AP manually or with wicd, but not with NM (tried KDE plasmoid and nm-applet)
<agateau> asac: what's the best way to give you useful info about this?
<asac> agateau: a good start is starting your system, trying to connect once and then give me your syslog
<agateau> asac: ok, going for this
<agateau> asac: just tried it and realized i did not use the appropriate entry in "Security" combo box. It works now, problem was between keyboard and chair... sorry for the noise :)
<asac> agateau: is that WEP?
<mvo> doko: I uploaded a new command-not-found that should suggest "pythonX.Y" now instead of "pythonX.Y-minimal" when "pythonX.Y" is not found
<doko> nice
<slangasek> pitti: btw, over the weekend we converted the hal bzr branch to 1.6.1-rich-root instead of the dead-end dirstate-with-subtree; so you may want to redo any local checkouts you have, for a noticeable speed boost. :)
<pitti> slangasek: I can't, since mine is a branch from an svn checkout
<pitti> slangasek: well, bzr-svn might have caught up in the most recent version, trying
<slangasek> 1.6.1-rich-root is specifically one of the formats that can handle bzr-svn
<slangasek> (getting it there is a PITA though, you can't bzr upgrade you have to bzr init + bzr pull)
<wgrant> It is the second-latest recommended format for bzr-svn.
<pitti> bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>.  Does not support rich root data.
<pitti> nope, seems not
<slangasek> er, see above
<wgrant> That's not the same error, is it?
<wgrant> pitti: What command was that?
<wgrant> bzr upgrade --1.6.1-rich-root
<pitti> I tried that, but doesn't work either
<pitti> bzr: ERROR: No repository present: "file:///home/martin/ubuntu/hal/ubuntu/"
<cjwatson> 10:39 <slangasek> (getting it there is a PITA though, you can't bzr upgrade you have to bzr init + bzr pull)
<cjwatson> so bzr init --1.6.1-rich-root and then bzr pull into that
<pitti> oops, the previous attempt moved .bzr away, sorry
<slangasek> yeah, it has a habit of doing that :-P
<pitti> ok, sorry
 * pitti engages full brain here
<slangasek> oh, the :-P wasn't for you, it was at the memory of how many times I had to restore .bzr on the LP branch using lftp the other night :)
<slangasek> would be nice if bzr were more clever about that
 * wgrant forgot it did the rich root error, *then* the subtrees error.
<pitti> hm, so what's the magic incantation to pull into a freshly init'ed branch?
<wgrant> bzr pull, oddly enough.
<wgrant> cd into the new branch, bzr pull from the old one.
<pitti> oh, interesting; magic..
<slangasek> pitti: if you know of any other bzr branches of interest on LP that were made using old bzr-svn (and are therefore using dirstate-with-subtree), feel free to let me know; I seem to be becoming quite practiced at such conversions, perhaps eventually they'll stop being painful :)
<pitti> slangasek: the only other one I'm aware of is cdbs; but I think that's even older (pack-0.92)
<pitti> it's again a case where I have debian (bzr-svn) and ubuntu branches, and merge from the former
<slangasek> ah - pack-0.92 might actually upgrade cleanly
<pitti> trying
<slangasek> <nod>
<slangasek> heh, try it locally first to spare yourself the lftp pain ;)
<wgrant> pack-0.92 will upgrade to 1.6 fine.
<pitti> yes, works fine
<wgrant> pack-0.92 is positively modern compared to dirstate-with-subtree, AFAICT.
<pitti> unfortunately the upgrade broke merging again
<pitti> .. but I think that was rather due to the bzr pull in the debian branch
<pitti> *sigh*
<pitti> slangasek: I know what you mean; for cdbs I got a "file exists: backup.bzr"
<pitti> slangasek: (on the remote lp branch)
 * pitti lftps it away
 * slangasek opens evolution for the first time since the font size change and snorts at the ridiculousness
<slangasek> asac: this default font size change makes evolution look absurd; is that a known issue on its way to being fixed, or should I be sending screenshots?
<slangasek> (and does it actually look !absurd in some configuration?)
<seb128> slangasek: it does look alright there
<pitti> it looks fine here, but then again I might have a manual configuration of my font setting
<pitti> seb128, asac: is there some magic gconftool -R /some/path for resetting font configuration to the factory defaults?
<directhex> slangasek, can i see a screen?
<slangasek> seb128, pitti: System -> Preferences -> Appearance -> Fonts -> Application font: 13.333?
<pitti> hm, that says "10" here
<pitti> I thought it'd be 10 pt == 13.333 px on my 96 dpi?
<pitti> erm, I mean s/-R/--recursive-unset/
<seb128> slangasek: http://people.ubuntu.com/~seb128/evo.png
<seb128> slangasek: what is stupid looking there?
<slangasek> seb128: ah; I meant the calendar panel
<slangasek> (I don't use it for mail)
<pitti> me too, and it looks fine to me
<seb128> the 2 labels in the sidepane could be a tide smaller
<slangasek> seb128: that's the part that was looking absurd :)
<seb128> slangasek: http://people.ubuntu.com/~seb128/evocal.png
<pitti> ah, is it /desktop/gnome/font_rendering ?
<asac> slangasek: evolution is known
<pitti> I assume so
<seb128> slangasek: I would not go until calling that absurd
<asac> slangasek: its the gtkhtml which doesnt honour absolute font sizinbg
<pitti> and /desktop/gnome/interface/{font_name,document_font_name,...}
<asac> slangasek: i even have the patches for that, but i am trying to get some feedback on it from pango developer first
<asac> pitti: yes. i only can give you a command that unsets the individual settings
 * pitti does gconftool --recursive-unset /desktop/gnome/interface
<asac> pitti: lol
<asac> pitti: metacity title font also needs to be changed to px in the end
<pitti> slangasek: right, now I get it, too
<pitti> it's way too big
<seb128> I start thinking we should roll back to 96 dpi for jaunty
<seb128> that's good we tackle those issues but it's late for this cycle
<slangasek> er, I'm *at* 96dpi
<seb128> we have a good idea on what to do now
<seb128> slangasek: well, 96dpi forced and 10pt fonts the intrepid way
<slangasek> ok
<seb128> slangasek: right now we have autodetected dpi and px fonts settings
<seb128> and we start discovering all those applications not handling px correctly
<asac> pitti: slangasek: http://paste.ubuntu.com/135952/ http://paste.ubuntu.com/135953/
<seb128> I think it's late for this cycle we should just roll back getting jaunty stable and rocking with not too many changes as said
<asac> gtkhtml + evolution patch
<seb128> and deal with that early next cycle
<asac> funnily gtkhtml had all the "point" booleans in place
<asac> just not implemented
<slangasek> seb128: this definition of "correctly" is completely wrong, but that's somewhat beside the point
<seb128> slangasek: right, let's say applications just don't behave correctly with the current defaults
<seb128> or don't look right
<seb128> or whatever you call it ;-)
<pitti> asac: hm, those look backwards somehow
<asac> pitti: backwards?
<pitti> IF get_size_is_absolute THEN set_size ELSE set_absolute_size
<asac> pitti: which line?
<pitti> asac: I'm not saying that they are wrong, just that they look wird
<asac> pitti: e-text?
<pitti> asac: first hunk in http://paste.ubuntu.com/135953/
<pitti> yes
<pitti> second hunk as well
<seb128> slangasek: will we get language pack updates for beta?
<asac> pitti: yeah right. i didnt update my .dsc ;)
<asac> pitti: in build tree i have !...is_absolute)
<slangasek> seb128: already happening
<pitti> asac: ah :)
<seb128> slangasek: ok good thanks
<asac> http://paste.ubuntu.com/135954/
<slangasek> cf. https://launchpad.net/ubuntu/+builds?build_text=&build_state=pending :)
<asac> lets hope that evolution has a clean build system ... updating diff.gz
<seb128> asac: "clean"?
<pitti> asac, slangasek: WDYT about reverting those changes (two gconf key defaults, for font size and 96 dpi) in libgnome for the beta?
<slangasek> were the gconf key defaults all that was changed?
<seb128> yes
<asac> pitti: yeah go for it.
<slangasek> and is the intent to add those changes back post-beta?
<pitti> slangasek: well, there were some application fixes for dynamic size handling; but we can surely keep those
<seb128> I would be in favor of staying with 96dpi fixed in jaunty
 * pitti too
<seb128> we said jaunty would be a stable not disruptive version
<asac> most issues i found are in gnomea pps
<seb128> let's deal with that next cycle
<pitti> I'd like to get bugs filed for all the issues that popped up and revert for jaunty
<asac> i will upstream them and let them decide if they take them for .1
<asac> yeah
<asac> next cycle
<asac> pitti: i have a big list already
<pitti> but it was a great experiment to learn where work needs to be done, and the issues around it
<pitti> so it was far from vein
<seb128> indeed
<asac> pitti: i will make super bug out of 345189
<pitti> vain, I mean
<asac> and upstream from there
<pitti> asac: awesome
<BUGabundo> asac: I just added to more apps to the bug
<asac> BUGabundo: thanks!
<slangasek> then yes, I think reverting this for jaunty is reasonable
<BUGabundo> UM and OOo
<asac> ok i can upload it
<BUGabundo> do all of them need to be upstream?
<asac> seb128: pitti ^^?
<seb128> slangasek: would you accept a fusa upload to add some _() so strings are showed translated before beta?
<asac> BUGabundo: yes. all needs to be upstreamed
<seb128> asac: please do
<pitti> asac: libgnome you mean? fine from my side, needs slangasek's ack for beta coordination
<BUGabundo> doing so for OOo then
<asac> pitti: yeah. i backout the gconf change
<asac> great
<slangasek> seb128: hmm, do the translations exist anywhere?
<pitti> asac: the other one, too? (96 dpi)
<asac> or well not so great. i would have loved if apps are smarter about font handling ;)
<asac> pitti: i have no strong opinion about it
<pitti> asac: yeah, I guess everyone would have..
 * BUGabundo would love a peaceful world too
<asac> pitti: but maybe that make sense
<BUGabundo> we can't always get everything
<seb128> slangasek: yes, they are translated but some of the call lack _() so the english string is displayed
<asac> hehe
<pitti> asac: would it even make sense to have one without the other?
<directhex> asac, never seen a 200dpi screen?
<slangasek> seb128: ah - yes, please upload
<seb128> slangasek: ok thanks
<asac> pitti: well. if we keep the dpi detection we see the bug that caused the change of font default ... so i think no
<asac> directhex: please send me a 200dpi screen
<dholbach> I was just taking a look at the problem of packages that don't (implicitly or explicitly) build-dep on libxi-dev but include XTest.h somewhere - unrelatedly gthumb and xnee FTBFS, if somebody wants to take a look at them
<BUGabundo> hihi
<asac> directhex: we also have a firefox feature we would need to test on screens with higer dpi than 150
<pitti> asac: that's what I thought
<directhex> asac, http://club.vaio.sony.co.uk/clubvaio/gb/en/vaiopseries/page.jsp
<asac> unfortunately we never found anyone
<asac> who could test that
<asac> directhex: well. i think in mozilla bug we also found a monitor with 300 dpi ;)
<asac> but that was way too expensive ;)
<BUGabundo> asac: ask on the ML -devel
<BUGabundo> someone said they had access to those big screens
<Trewas> the font sizes are currently very ridiculous at least when running in virtualbox, "echo $COLUMNS" in gnome-terminal offers 71 when the window is maximised (with everything at defaults and the maximum available resolution, 800x600)
<slangasek> Trewas: what does xdpyinfo within vbox show?  Sounds like a bug in vbox.
<directhex> Trewas, oh, what's why my jaunty kvm's consoles look silly
<Trewas> slangasek: "dimensions: 800x600 pixels (212x159mm), resolution: 96x96 dots per inch"
<slangasek> ttx: sblim-sfcb> you know that s-s-d option can be specified more simply as '--retry=5'?
<slangasek> Trewas: ah; I suppose I'm not seeing that on my 96dpi display because I've customized gnome-terminal before now
<Laney> you only see the full impact of the new fonts on clean installs
<directhex> or new users?
<Laney> potentially
<slangasek> geser: huh, any idea what's going on with the bittorrent upload failure?
<Laney> well, actually I tried this and it wasn't that bad. Dunno if I changed some system-wide setting
 * directhex updates his vm
<slangasek> Laney: what's the real dpi of your display?
<slangasek> or do you mean that you get different results for new install vs. new user?
<Laney> slangasek: I mean I tried it on my laptop and instantly noticed several broken applications, but a dist-upgraded install on my desktop has been fine
<Laney> so "customisation masks the problems" is my message
<BUGabundo> slangasek: I had to request asac help to get my system to a similar state of a clean install
<\sh> slangasek: is it planned to have a full archive rebuild run for jaunty before RC?
<asac> libgnome uploaded
<slangasek> \sh: a rebuild of main is in progress.  I don't know whether there are plans to rebuild universe.
<\sh> cjwatson: bug #346797 I was sitting yesterday and tried to fix it...it needs some more love then just changing the .tab file...and it looks like that /usr/share/i18n/SUPPORTED and /usr/share/iso-codes/*.tab is not in sync after a trivial change ...most of the UI code just breaks...
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/346797/+text)
<pitti> asac: thanks, accepted
<ttx> slangasek: I missed that. Thanks for the pointer :)
<kirkland> any idea why firefox slowed down tremendously after upgrading this weekend?
<kirkland> it's like it's single threaded, can't do more than one thing at a time
<directhex> Trewas, okay, i get COLUMNS=91 at 1024x768 in kvm
<directhex> and 71 at 800x600
<dholbach> gthumb and xnee FTBFS, if somebody wants to take a look at them
<seb128> we should drop some screensavers
<seb128> there is over 7megas of those on the CD
<seb128> the  skyrocket one taking almost 1.5megas
<directhex> i agree. who uses screensavers anymore?
<directhex> drop rss-glx?
<jcastro> seb128: we should ship like 4 at the most
<seb128> right
<jcastro> the feet, the ubuntu logos, black, and maybe the squares or something
<seb128> bah
<seb128> doko: when packages are in bzr and you modify those please push the change to bzr too
<doko> seb128: err, all of these were rebuild-only uploads
<seb128> doko: and?
<seb128> doko: which means I do bzr pull, do my changes upload and get it rejected because bzr is outdated
<seb128> then I've to commit your changes redo the work, etc
<seb128> not nice
<seb128> it would be better if you could push your changes to bzr too
<doko> then we should use another version numbering scheme, so that you can do just that
<seb128> do what? ignore your upload?
<doko> yes
<doko> hopefully we'll get binnmus ...
<siretart`> seb128: but package uploads to the archive are pushed automatically to package-import.u.c, aren't they?
<siretart`>  
<siretart`>  
<slangasek> yes, but that's not mergeable with existing package branches
<seb128> siretart`: I don't know I don't use package-import
<siretart`> right, that requires to actually use those branches..
<seb128> I'm wondering if we have an interest to still install gamin by default
<slangasek> tseliot: what more is happening on bug #320632 between now and beta?
<seb128> I don't think anything really use it
<ubottu> Launchpad bug 320632 in xfree86-driver-synaptics "tap-to-click and edge-scrolling broken in Jaunty" [Medium,Confirmed] https://launchpad.net/bugs/320632
<slangasek> seb128: is everything using inotify now?
<seb128> slangasek: yes, at least gio is and I'm not sure what is using libgamin out of libgio-fam which is in universe right now
<tseliot> slangasek: nothing I guess. I haven't had the time to look at the change mentioned in comment 142. Furthermore if that is the cause of the problem, reverting that change might cause regressions - which is not nice - especially when I don't have the specific piece of hardware affected by the problem.
<slangasek> tseliot: would it cause regressions relative to intrepid, or just relative to earlier jaunty?
<tseliot> slangasek: regressions in jaunty since the commit's date is Dec 4 17:16:40 2008
<slangasek> tseliot: well, that seems like an acceptable risk; and more acceptable before beta than after, if it's going to happen...
<cjwatson> \sh: I'll convert it to use the XML files
<cjwatson> \sh: it's no wonder that things totally break when you use iso_639.tab instead; that's for languages, not countries!
<tseliot> slangasek: ok, I'll see what I can do. I can't promise anything though as I have a lot of work to do already
<slangasek> tseliot: understood; thanks
<\sh> cjwatson: well, I was wondering where the other file was...
<cjwatson> \sh: /usr/share/xml/iso-codes/iso_3166.xml in a different format. In practice what you're supposed to do nowadays is use isoquery.
<\sh> cjwatson: ah ok..and I thought iso_639.tab replaced the 1366.tab...my mistake
<slangasek> lool: bug-buddy changelog shows you dropping then re-adding the Recommends: on gnome-dbg; this still wants to pull a bunch of libraries from universe into main
<slangasek> lool: can I just drop the recommends again?
<lool> slangasek: bug-buddy shouldn't be in main
<lool> slangasek: We drop deps on bug-buddy rather than bug-buddy deps usually
<slangasek> oh
<lool> slangasek: I re-added the recommends to avoid a delta on bug-buddy with Debian
<lool> Debian uses bug-buddy/-dbgs and we use apport/-dbgsyms, so it kind of makes sense to pull -dbg for Debian and bug-buddy usage in general, and to avoid bug-buddy in Ubuntu
<slangasek> hrm, then what is bug-buddy doing in main in the first place
<slangasek> meh, seeded on the DVD
<lool> I wonder why
<cjwatson> hysterical raisins I imagine
<slangasek> been seeded for a long time, in fact
<lool> # included so that upstream GNOME community members can use it
<cjwatson> the DVD seed was mostly just moved wholesale from the old supported seed
 * slangasek nods
<\sh> kees: pitti: would you like to take care about bug #332025 (it just needs a sync...sec update...cve included)
<ubottu> Launchpad bug 332025 in uw-imap "Please sync uw-imap 8:2007b~dfsg-1.1 (universe) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/332025
<\sh> we still have -1
<lool>   Move bug-buddy from desktop to supported
<lool> cjwatson: Good catch :)
<lool> It was Tue 2008-08-26 so not too far awy though
<slangasek> lool: that's when it was moved to supported from desktop; the addition was much farther back
<pitti> \sh: ah, ubuntu-archive wasn't subscribed; I did that now
<slangasek> ArneGoetje, pitti: language-support-translations-cs doesn't appear to Depend on evolution-documentation-cs
<\sh> pitti: grmpf...right...my fault...I thought kees wanted to have a look about it first as it was a security bug..thx :)
<lool> haha back in the past bug-buddy was downgraded to a recommends: "Our guiding philosophy should be that the user should be able to remove/replace default applications and documentation as they wish without disturbing the metapackage, while ensuring that essential infrastructure is implied by the metapackage"
<lool> (just had recent exchange about usplash/plymouth with cjwatson where I wanted to make it a recommends; I guess it boils down to what "essential infrastructure" is)
<lool> Ok, bug-buddy dates from revision 1
<pitti> slangasek, ArneGoetje: ah, it's already in the lists, seems it just wasn't rebuilt; doing
<lool> So it's definitely old cruft
<slangasek> lool: and now it's removed cruft :)
<lool> slangasek: If you care about -dbg, you might want to drop Extra-Include: *-dbg *-debug from supported perhaps?
<slangasek> 06:20 < cjwatson> slangasek: anything that actually ships a -dbg is either (a) cruft from dbgsym and should go in Extra-Exclude or (b) actually useful due to being a second build pass. IMO anyway ...
<\sh> cjwatson: pkgsel pkgsel/install-language-support boolean false should avoid any try to install langpacks during preseeding installation, right? or do I need to empty pkgsel/language-pack-patterns ?
<lool> slangasek: That's an *Include*
<cjwatson> \sh: the latter
<slangasek> lool: yes, I know.  the above is cjwatson's argument against removing the -Include.
<cjwatson> I'm not sure it's directly an argument against; it's a maybe
<slangasek> ok, "response" :)
<cjwatson> my concern is whether we would miss out on useful debugging facilities
<lool> Well the python -dbg packages are special infrastructure we use
<slangasek> the current solution does have the advantage that someone has to look at the -dbg packages (they show up on component-mismatches fairly automatically)
<pitti> slangasek: l-support-tr-cs uploaded
<slangasek> ok
<lool> slangasek: with extra-include?  I don't understand why they show up as a mismatch if they are seeded
<ArneGoetje> pitti: thanks
<slangasek> lool: because when new ones show up they tend to show up in universe
<\sh> cjwatson: somehow the documentation from debconf-get-selections --installer is not as obvious as it should be...but I'll learn quickly ,-)
<slangasek> and get looked at before being promoted
<lool> I see
<cjwatson> \sh: it's not supposed to be documentation. Use the installation guide
<cjwatson> heh, not that this is documented there either
<\sh> cjwatson: that's what I wanted to say...and when I follow the installation guide, I always end with lang-packs of gnome, openoffice and friends ,-)
<cjwatson> oh, I improved the logic in jaunty
<cjwatson>   * Fix logic to check whether pkgsel/language-packs has been preseeded.
<cjwatson> previously preseeding it to the empty string was incorrectly taken to mean "not preseeded"
<cjwatson> \sh: so this will work in jaunty, but in previous releases you had to use 'd-i pkgsel/install-language-support boolean false'. Sorry for my incorrect statement earlier about pkgsel/language-pack-patterns.
<cjwatson> \sh: note that it ought to be "d-i" as the first field there, not "pkgsel".
<Riddell> mvo: desktop-effects-kde committed thanks (you are free to join kubuntu-users yourself of course :)
<cjwatson> (otherwise you will end up with cruft in your installed system's debconf database)
<\sh> cjwatson: ok...thx for the heads up :)
<mvo> Riddell: thanks
<Riddell> mvo: apport's config file seems to prompt during an upgrade from intrepid http://humboldt.canonical.com/~jriddell/9.04-upgrade/intrepid-upgrade-7.png
<mvo> Riddell: right, know issue. we can apport during the upgrade and that causes it to prompt, it will go away for the final release
<Riddell> mvo: ok, another problem was this packagekit crash during the upgrade, bug 347290
<ubottu> Bug 347290 on http://launchpad.net/bugs/347290 is private
<mvo> Riddell: could you make it public please?
<Riddell> bug 347290
<ubottu> Launchpad bug 347290 in packagekit "aptDBUSBackend.py crashed with ImportError in <module>()" [Undecided,New] https://launchpad.net/bugs/347290
<Riddell> mvo: fixed
<Riddell> mvo: it lacks a dependency?
<mvo> Riddell: maybe - or it was a problem gconf not configured yet
<Riddell> gconf? surely just python-gobject?
<mvo> Riddell: eh, right. sorry
<mvo> Riddell: just to confirm, "fixed" refered to that you fixed it in bzr already?
<Riddell> mvo: in respect to what?
<Riddell> mvo: no, the fixed was the bug privacy
<seb128> ok
<seb128> so we could get libgnomeprint and libgnomeprintui out of the CD quite easily for jaunty if we want
<seb128> we just need to split the gnome-python-desktop bindings
<seb128> and to look through the archive to what is still using those binding and depends on the binary to those
<seb128> do you think it's worth the effort?
<slangasek> I'm very nervous about splitting those python bindings
<seb128> slangasek: why?
<slangasek> are you going to look through universe/multiverse as well?
<seb128> slangasek:
<seb128> $ apt-cache rdepends python-gnome2-desktop | wc -l49
<seb128> ups
<seb128> -> 49
<slangasek> seems like a lot of packages
<slangasek> do you disagree?
<seb128> that's a not too big list, grepping for "import gnomeprint" in this list should be quick enough
<slangasek> no tar-in-tar that we have to worry about missing in a grep?
<seb128> slangasek: 49 sources to get and grep? yes I disagree
<pitti> Keybuk: cups only sends d-bus signals to the system bus, it doesn't export any interfaces to call; it seems that this doesn't need a dbus config file at all, or am I missing something?
<seb128> slangasek: gtksourceview and gnomeprint are deprecated libs for some time and I don't many things are using them
<seb128> slangasek: and going through 47 sources manually is not too much work ... but right we can wait next cycle
<slangasek> seb128: if the number of packages that need to be changed turns out to be sanely small, then I guess I'm ok with that.  We will break any third-party packages depending on python-gnome2-desktop and using these libs though
<Amaranth> looking at that list I can't imagine many of them using libgnomeprint anyway
<slangasek> seb128: for next cycle, I believe Debian is already working on a transition plan
<dholbach> seb128: how correct was this list? http://paste.ubuntu.com/136041/
<seb128> slangasek: right, I would just have split those 2 to get the corresponding libs out of the CD for jaunty if we wanted to
<seb128> dholbach: it has only things installed on your box but otherwise good ;-)
<dholbach> seb128: no, that's sources I downloaded
<seb128> oh
<seb128> should be an accurate summary if there is no tarball in the tarball sources there
<dholbach> seb128: that's a quote from a discussion we had a few days ago, remembeR? :)
<seb128> Installed-Size: 320
<seb128> Installed-Size: 584
<seb128> that's probably not worth the trouble for jaunty
<slangasek> seb128: yep - which changes the definition of "python-gnome2-desktop" for packages already depending on it.  I'm not convinced it's worth it for < 1MB, yeah
<seb128> we are not going to move libgnomeprint to universe anyway, abiword still use it
<dholbach> boooooh!
<seb128> slangasek: that's why I suggested to go through the rdepends but let's wait next cycle and do the full split as debian then
<seb128> hum
<seb128> the respective -datas add over 3megas though
<seb128> slangasek: ^
<slangasek> hmm
<slangasek> yes, that would be worth it
<seb128> those libs are deprecated for some years and I'm pretty confident few things use them
<seb128> I will go through the list but http://paste.ubuntu.com/136041 is basically that
 * dholbach hugs seb128
<seb128> gnome-games can be dropped from there they used gnomeprint in sudoku and that has been fixed in svn since
 * seb128 hugs dholbach
<Keybuk> pitti: correct
<slangasek> dholbach: strange, why is XInput.h not in x11proto-input-dev?
<Keybuk> though reading the e-mail, Matthew is correct
<Keybuk> if you *send* signals, you should support introspection
<Keybuk> thus need a policy to enable it
<slangasek> dholbach: that seems like the one obvious header to be in a package with that name...
<dholbach> slangasek: bryce and jcristau might be the best people to talk to about it - I merely stumbled over it during sponsoring
<seb128> <jcristau> XInput.h is in x11proto-input-dev in debian still
<seb128> from #ubuntu-x earlier
<slangasek> hmm, so why was it moved?
<dholbach> or tjaalton: ^
<seb128> slangasek: <tjaalton> it was moved in intrepid because of the input-properties changes, but then upstream moved it back for XI 1.5
<seb128> <tjaalton> so we're just waiting for XI2 and things should be in sync again :)
<slangasek> hmm
<seb128> slangasek: ok, found an another easy 900k
<slangasek> wow :)
<seb128> slangasek: libbonoboui2-common has the html api documentation which should be in -dev
<seb128> changing that now
<maco> trying to slim down packages to make more room on the cd?
<seb128> trying to get some extra translations on the CD yes
<Riddell> mvo: hardy to jaunty upgrade isn't possible?
<davmor2> Riddell: hardy .2
<davmor2> or hardy kde4
<Riddell> hardy.2
<davmor2> I'll have a play with it after and see if I can do it on ubuntu too
<mvo> Riddell: not out of the box, I do it for testing sometimes and it seems to work ok
<Riddell> mvo: well we need it to be possible for Kubuntu
<mvo> Riddell: oh? could you get into more details?
<mvo> Riddell: why do you skip intrepid?
<mvo> Riddell: do you do it for all hardy installs? or just for particular ones (like kde4 installs)?
<maco> mvo: my guess is "just to see what'll happen"
<maco> oh missed that line
<maco> nevermind
<Riddell> mvo: I'm sure we've talked about this lots.  Kubuntu hardy isn't LTS but intrepid was not ready for many users so we turned off the upgrade prompt from hardy, but want it back on so people upgrade before hardy loses support
<maco> and 4.2 is nice
<mvo> Riddell: right - what metarelease uri is kubuntu hardy using?
<Riddell> mvo: http://changelogs.ubuntu.com/meta-release but skipping intrepid
<mvo> Riddell: or what bzr branch for the kde version of the update-manager download thing (adept I guess?) - so that I can check myself?
<mvo> Riddell: if you direct me to the hardy version of that tool I check what we need to do
<Riddell> mvo: it's the DistUpgrade tool that's the problem  http://muse.19inch.net/~jr/tmp/jaunty-upgrade-1.png
<mvo> Riddell: ok - if everything else is settled, I add the support for that now (that should be trivial)
<mvo> Riddell: sorry for the trouble, it was not on my radar
<Riddell> mvo: mm, looks like adept is doing the wrong thing anyway, but that's my problem
<mvo> Riddell: ok, I commited what needs to be done, hopefully that is enough, I do a test kubuntu hardy->jaunty upgrade now
<slangasek> seb128: hmm, file-roller declares a Vcs-Bzr header pointing to a non-existent branch
<seb128> slangasek: right, the product is called fileroller and not file-roller on launchpad and I noticed after upload that I couldn't push due to that
<seb128> I wanted to ask somebody if the product name can be fixed but I forgot
<seb128> if you need to do a change just upload for now I will fix that later
<slangasek> ok
<cjwatson> answers.launchpad.net/launchpad for renaming a project, I think
<slangasek> it's a missing build-dep on libtool, FWIW, causing a FTBFS
<seb128> cjwatson: thanks
<seb128> slangasek: weird, it uses cdbs which depends on intltool in ubuntu
<seb128> ups, libtool you said
<seb128> why does it require libtool?
<slangasek> for an m4 macro
<seb128> that's rather the autoreconf patch which is buggy
<slangasek> oh? you're meaning to avoid build-time re-confing?
<seb128> I guess that's another bug due to a lack of quilt add
<seb128> I hate quilt
<seb128> slangasek: yes, we autoreconf with known to be working versions to avoid surprises
<seb128> so we are sure builds don't break when autotools changes and the new version doesn't work correctly with some old syntax or something
<slangasek> hm.  let me look more closely at this build log; I don't see anything related to the debian/patches
<seb128> slangasek: DOH
<slangasek> configure: WARNING: unrecognized options: --disable-maintainer-mode
<slangasek> well, that's clever
<slangasek> seb128: you've seen something?
<allquixotic> Is anyone else getting broken metacity compositing in the latest devel? I get "Desktop Effects could not be enabled" on Intel i965 hardware. I know it's a bug *in metacity* because xcompmgr correctly composites, even though it doesn't add any effects. When I drag a window on top of an OpenGL window, with xcompmgr there is no damage region (black area) left behind. But there is without.
<seb128> slangasek: yes, I forgot the quilt add aclocal.m4 apparently
<seb128> slangasek: fixing now
<slangasek> seb128: ok, I'll leave it to you
<pitti> quilt becomes even more *headdesk* for newly created files :/
<pitti> I spent some 45 minutes last Thursday just on creating a working autoreconf patch with quilt
<ScottK> But 'everyone' says that quilt is better (for reasons that also escape me) ....
<ScottK> ;-)
<seb128> pitti: I usually change the quilt-patchsys.mk to simple-patchsys.mk use cdbs-edit-patch and switch back
<slangasek> because it is better, pff
<slangasek> infidels
<seb128> we should really fix cdbs-edit-patch to work with quilt
<pitti> seb128: ah, nice trick; I quilt push'ed to n-1, copied tree, autoreconf and clean thhere, and diff -Nur > /tmp/patch
<seb128> I never know
<seb128> but the desktop CD has compression?
<pitti> ScottK: well, the idea of quilt is nice, in terms of workflow
<pitti> you have a full tree, can build it, test it, and in the end quilt refresh
<seb128> ie the CD space win is the installed size value or not?
<pitti> but the idea is spoilt by several things which make it absolutely useless, such as quilt add, or not being able to clean cruft
<seb128> gnome-games documentation translations = 21megas
<seb128> we can split that after beta if we want to win an another locale
<ScottK> pitti: I agree it has some nice ideas, and I'm kind of getting the hang of it.  I just don't find it a panacea for all situations.
<cjwatson> seb128: the desktop CD is compressed, yes, although the compression is different from .deb compression
<pitti> ScottK: personally I really like bzr looms, which combine the original "in-place" idea of quilt with sane file handling
<allquixotic> Oh hmm, `SKIP_CHECKS=yes compiz --replace` works, but regular old `compiz --replace` doesn't. Looks like my card (i965) is no longer on the whitelist after it being on it for 8.10??
<cjwatson> seb128: so in general CD space win will be fairly close to .deb size, but not in all situations
<seb128> ok
<cjwatson> seb128: for example duplicate files across packages will probably be compressed better on the live CD than in .debs
<seb128> there is no easy way to simulate that I guess
<seb128> just use the deb win as a rough estimation
<slangasek> yep
<seb128> thanks
<pitti> seb128: it's not that rough actually
<ScottK> pitti: I mostly want to stop having to learn n+1 different patching system/vcs/etc every third time I touch a package.
<pitti> ScottK: *nod*
<maco> er allquixotic went away....but er...regular compiz --replace works fine on i965 here.
<seb128> bah, I hate symlink handling on upgrade
<pitti> bdmurray, sbeattie: bug 345953 FYI (IIRC you were involved in cups apport hooks)
<ubottu> Launchpad bug 345953 in cups "/var/log/cups/* should be adm group readable" [High,Fix committed] https://launchpad.net/bugs/345953
<seb128> so libbnoboui2-common does
<seb128> lrwxrwxrwx 1 root root 34 2009-03-23 15:46 /usr/share/gtk-doc/html/libbonoboui -> ../../doc/libbonoboui2-common/html
<seb128> what is the right way to replace that by a real directory on upgrade?
<slangasek> rm the link in the preinst
<seb128> ok, ,what I did but using at if -d
<seb128> I guess that's not correct because the directory might be removed first and which case the link is not a directory
<seb128> hum no, I didn't clean up everything, let's try again
<sbeattie> pitti: great!
<geser> slangasek: re the upload failure: checking but I don't have an idea what went wrong. It looks like the upload both failed and succeed (processed twice?). will try to get an answer from LP people
<slangasek> geser: alrighty
<geser> slangasek: known bug, cprov is fixing it
<slangasek> geser: huzzah
<ogra> could anyone from ubuntu-mir takle a look at bug 345294
<ubottu> Launchpad bug 345294 in redboot-imx "MIR for RedBoot-imx" [Undecided,Confirmed] https://launchpad.net/bugs/345294
<seb128> slangasek: libbonoboui uploaded with the documentation installed in the correct binary and file-roller uploaded which should build correctly
<seb128> current i386 desktop iso = 698meg == no need to drop the french language pack now? ;-)
<slangasek> seb128: how much does libbonoboui save us?
<seb128> slangasek: 900k of installed files, not sure how much that will be on the CD
<slangasek> I already kicked pt off to get it to fit; so I'd like to add pt back again if we find the room
<seb128> Installed-Size: 1612
<seb128> Installed-Size: 2536
<seb128> slangasek: how much was pt? we didn't win so much space for deskbar-applet + one language pack
<slangasek> seb128: pt is 7MB; I took pt off and shoved a bunch of other langs on in its place
<seb128> ah ok
<cjwatson> Riddell,mvo: do we need to make the Kubuntu CDs ship an update-manager including hardy-backports rather than intrepid-backports?
<tkamppeter> pitti, I have added a fix for bug 345183 to the BZR repo of CUPS.
<ubottu> Launchpad bug 345183 in cups "CUPS, foomatic, & pdftopdf fail when printing more than one copy of an image" [High,Fix committed] https://launchpad.net/bugs/345183
<pitti> tkamppeter: ah, thanks
<pitti> tkamppeter: I'll do an upload after beta; currently discussing bug 318742 still
<ubottu> Launchpad bug 318742 in cups "D-Bus Policy needs checking" [Low,Incomplete] https://launchpad.net/bugs/318742
<Riddell> cjwatson: we have backports on the CDs?
<mvo> cjwatson: we do not use -backports currently, so it should be ok
<cjwatson> Riddell: just of dpkg and apt for update-manager
<cjwatson> mvo: hmm, you don't? why are we wasting CD space with them then?
<cjwatson> oh, hmm, maybe we aren't :)
<cjwatson> ok, I'll ignore that problem then
<cjwatson> Riddell: ok, I guess I'll rephrase, we have the capacity to do so but it's only if there are actually release-upgrader-{apt,dpkg} packages in -backports
<cjwatson> which apparently there aren't
<pitti> Keybuk: I'm still confused about cups/dbus; are you saying that cups really ought to provide a real d-bus object, or that a by and large empty (just introspection) d-bus configuration file is necessary?
<Keybuk> yes
<Keybuk> you can't just connect to the bus, fire off a signal, and expect everything to be able to catch that
<pitti> well, that's what cups does right now :/
<seb128> slangasek: ok, so splitting gnome-games documentation would make a 11.6meg deb difference on gnome-games-data
<seb128> do we have an estimation of what language packs we could add with that?
<Keybuk> pitti: right, so it never has a registered bus name
<pitti> Keybuk: right
<Keybuk> which means most bindings won't let you match the signal (they expect you to provide the registered bus name)
<pitti> seb128: I have a script to tell exactly
<Keybuk> and many of the more modern bindings won't even let you anyway, since they can't introspect the object
<slangasek> seb128: that might be enough to get French onto amd64 desktop, which doesn't have it right now
<seb128> pitti: please do tell me then ;-)
<pitti> Keybuk: ATM it's just being used by system-config-printer (by the Python bindings)
<seb128> slangasek: ok, we will do that after beta then
<pitti> seb128: we are up to de?
<slangasek> seb128: excellent
<Keybuk> pitti: the Python bindings (at least the newer versions) certainly fall into the "difficult to get them to play ball" category
<seb128> pitti: something around that I guess, we have de and fr but not pt on I386 now
<pitti> seb128: pt is 10.5 MB, so we could add that back
<Keybuk> but if it works now, it works
<seb128> I don't want to do too much documentation splitting
<Keybuk> it just isn't really a useful signal or a well-behaved service :p
<pitti> seb128: oh, that's probably not true, since my script doesn't count replaced files
<seb128> but I guess gnome-games is a good win so we can do this one
<pitti> seb128: it should be more like 6 MB..
<pitti> seb128: ah, if we are talking about the alternate, then it is correct
<ebroder> Where can I find out why a package isn't synced from Debian? (I'm specifically looking for locales-all, but I'm curious about the process)
<pitti> seb128: we need to wait for today's langpack builds really
<seb128> right
<pitti> Keybuk: it does
<seb128> those changes are for after beta anyway
<slangasek> pitti: 10.5MB?  How do you get a different number than I do?
<slangasek> (larger by 3MB)
<pitti> slangasek: that's probably the previous langpack version; apt-get update'ing right now
<cjwatson> ebroder: if it's a source package, then http://people.ubuntu.com/~ubuntu-archive/sync-blacklist.txt often has useful comments. However, in this case, locales-all is a binary package that's part of the glibc source package in Debian, so you'd look at glibc's Ubuntu changelog
<cjwatson> ebroder: and the short answer is because our locale handling is substantially different from Debian's due to the presence of language packs, I imagine
<ebroder> cjwatson: Yeah, that seems to be the case
<pochu> should I notify the tech board for regressions in security updates?
<mvo> calc: do you know anything about #346525 ?
<calc> mvo: was OOo 2.4.1 before the update?
<cjwatson> pochu: yes please, although also the security team of course
<mvo> calc: I don't know but I can ask
<calc> mvo: there is/was a bug with fontconfig that could cause OOo to die, which has been fixed in 3.0.1
<mvo> calc: ok, mind if I reassign to OOo ?
<calc> mvo: but if they were running 2.4.1 at the time it died that could be expected unfortunately
<pochu> cjwatson: sure, thank you
<calc> mvo: it has no backtrace so its really a bug i would just mark invalid unless they could come up with useful information, just a it crashed isn't enough to debug it :\
<mvo> calc: ok, I asked for more information for now
<calc> mvo: ok i followed up to it as well
<pitti> slangasek, seb128: right; with today's langpacks, pt is 7.11 MB; fr is 4.67
<calc> i thought i did but it apparently was a race condition ;-)
<seb128> pitti: weird that there is a such difference
<pitti> seb128: the previous update packs were really big
<pochu> are there logs for security builds available somewhere?
<seb128> ok
<Riddell> mvo: ping
<Riddell> mvo: it is your fault after all :)
<Riddell> mvo: "Date: Thu, 24 April 2009 12:00:00 UTC" in meta-release  April should be Apr else QDate won't parse it
<Riddell> meta-release-development that is
<tkamppeter> Any Perl exper here? There is bug 346044, which reports a segmentation fault on a Perl program, in exit().
<ubottu> Launchpad bug 346044 in foomatic-db-engine "foomatic-ppdfile crashed with SIGSEGV in exit()" [Medium,New] https://launchpad.net/bugs/346044
<mvo> Riddell: heh :)
<mvo> Riddell: ok, will fix that (also I think its a bit unclever that qdate ;)
<tkamppeter> For me it looks like a bug in the Perl interpreter.
<kees> pochu: what's the issue you found?
<pochu> kees: bug 347351
<ubottu> Launchpad bug 347351 in wesnoth "wesnoth 1:1.4.5-1ubuntu0.2 english only not italian" [Critical,Triaged] https://launchpad.net/bugs/347351
<cjwatson> tkamppeter: certainly a segfault is a bug in C code rather than in Perl code, in general, but it's not necessarily in the interpreter; it could be a memory allocation bug in some XS module that's being loaded
<cjwatson> tkamppeter: valgrind would probably help to track it down, and it might even be possible to do that without being able to reproduce the segfault directly
<tkamppeter> cjwatson, what is an XS module?
<cjwatson> a Perl extension module written in C
<cjwatson> (approximately)
<Riddell> mvo: when do you expect to upload update-manager?
<mvo> Riddell: the meta-releae file is fixed now
<mvo> Riddell: the update-manager upload, not sure, today?
<tkamppeter> cjwatson, then I think it is better to move this bug to Perl, so that people working on Perl itself and on general Perl libraries see it. Foomatic does not provide any XS module.
<cjwatson> probably, yes
<kees> pochu: uhm, that is very strange.
<tkamppeter> cjwatson, thanks for the help.
<kees> pochu: i'll poke at it.
<Riddell> mvo: let me know when it's in so I can test out the full upgrade process
<cjwatson> valgrind is not showing up anything particularly scary for me
<pochu> kees: thanks
<cjwatson> it's interesting that the stacktrace seems to think the problem is in libcrypt though ...
<cjwatson> but that could just be the victim
<mvo> Riddell: I was going over the buglist to look for other low hanging fruits
<jdstrand> kees: I'd be happy to look at it
<cjwatson> kees: my guess is that since PPAs are not especially component-aware then maybe translations are being stripped from everything regardless of whether they're in main or not
<devilsadvocate> ok, i know this is not a question for the dev channel, but can someone tell me what happened to /dev/ttyUSB0 (and why, if thats ok)
<kees> cjwatson: if that were true, no one has noticed for 6 months.  :P
<kees> cjwatson: I don't think it is, since the security queue uses non-virtual buildds.
<kees> cjwatson: but we'll check.
<Pollywog> I notice that in addition to the -dbgsym packages, there are often the -dbg packages and I can find documentation for using the dbg packages.  Is there a difference between the two types?
<maco> Pollywog: dbgsym are only in ddebs and -dbg is in main. i think you can only use one (of a specific package) at a time and ddebs has more of them
<Pollywog> btw now that I am using the debugging kmail packages, kmail is not crashing
<maco> either should work fo getting a stacktrace, i  think
<Pollywog> I see
<Pollywog> thanks
<Pollywog> and yes the two types seem to be incompatible
<Pollywog> With some packages, when I run dbg is says there are no debugging symbols, so I wonder if they were correctly built or if I am missing something
<Pollywog> but kmail-dbgsym seems to be fine
<LaserJock> -dbg and -dbgsym are created in somewhat different ways but I believe they aim to provide the same thing
<LaserJock> -dbg packages are included in the source package, and hence could have mistakes
<Pollywog> LaserJock: ty, I had never heard of the ddebs until recently and I usually compiled my own package with debugging enabled
<Pollywog> yes I suppose they could have mistakes, I had not thought of that
<LaserJock> ddebs is created outside of the packaging
<Pollywog> yes I see that they are  :)
<Pollywog> I just started using them yesterday
<Pollywog> I will have to wait for this annoying bug to show itself, usually happens when I try to delete a spam
<Pollywog> a spam that contains an image or html
<cjwatson> *-dbgsym are automatically created by extracting debugging symbols from packages and stuffing them into a new package. *-dbg are created manually and independently by various packages; sometimes they are essentially the same as *-dbgsym and sometimes they are different (e.g. a different build pass that enables more debugging features in the binary itself).
<cjwatson> In many cases the reason why there's duplication is that we inherit a lot of the *-dbg packages from Debian, which doesn't have *-dbgsym.
<Pollywog> cjwatson: I suspected that, since Debian does not have them
<Pollywog> I have only been using Ubuntu for about 2 yrs, used Debian before that
<Pollywog> I thought I saw a book in the No Starch series, having to do with Ubuntu, I will have to find out if one exists.  Maybe it explains these things
<Pollywog> There was such a book for Debian
<Pollywog> but that was several yrs ago
<calc> pitti: i see someone else followed up to bug 325973 seeing it on vmware as well
<ubottu> Launchpad bug 325973 in nautilus ""Starting File Manager" windows open uncontrollably" [Unknown,Fix released] https://launchpad.net/bugs/325973
<pitti> calc: ah, thanks
<calc> pitti: actually it was in bug 328176 which seems a lot of people are seeing this issue in vmware
<ubottu> Launchpad bug 328176 in meta-gnome2 ""Starting File Manager" infinite loop after GNOME login (dup-of: 325973)" [Low,Incomplete] https://launchpad.net/bugs/328176
<ubottu> Launchpad bug 325973 in nautilus ""Starting File Manager" windows open uncontrollably" [Unknown,Fix released] https://launchpad.net/bugs/325973
<calc> pitti: it might be related to the double free bit that was mentioned in the upstream report and i also saw it in .xsession-errors myself
<pitti> seb128: do you think robert and you can take a look at this this week? ^
<calc> repeatedly crashing might cause that same behavior(?)
<pitti> calc: yes, I think so; if you kill the 'main' nautilus, it'll respawn, and then open a window
<calc> i haven't tested an i386 cd but on amd64 cd it happens immediately on bootup of the live cd
<pitti> calc: so in the end it might be a totally different bug which just looks similar in effect
<calc> pitti: i did ps aux and killed what i saw but it was respawning into infinity anyway
<calc> it seems something restarts nautilus so there isn't really a main nautilus process
<calc> pitti: yea it might be a different bug that just looks similar
<pitti> calc: I mean the process which drives the desktop
<calc> pitti: ah ok
<pitti> calc: it's spawned by gnome-session
<seb128> pitti: as said this morning we can
<seb128> gnome-session restart everything which crash or exit which has autorestart on
<seb128> I doubt the issue there is the same
<calc> i only have a current iso but if it is useful i can try downloading older alphas and see what it starts happening
<calc> s/what/when/
<seb128> the sjow_desktop one is "nautilus has nothing to do and exit, gnome-session restart it"
<seb128> you could start by attaching gdb to nautilus and see if it crashes
<calc> hmm actually older alphas aren't on the server
<calc> seb128: nautilus is crashing immediately
<seb128> get a stacktrace then
<calc> seb128: ps aux shows a different process id every time i run it
<calc> seb128: so i need to trace from gnome-session?
<seb128> calc: no, open a command line and gdb --pid $(pidof nautilus)
<pitti> calc: you said "double free bit"
<seb128> the double free should show in .xsession-errors
<pitti> calc: so perhaps there's already a stack trace in the upstream report?
<seb128> and I bet it's librasero again
<calc> pitti: yea i saw a glibc double free error message like is noted in the bug report
<seb128> what bug?
<pitti> calc: it doesn't leave a .crash file behind :(
<calc> pitti: from what i recall there isn't one in the upstream report
<pitti> calc: ?
 * calc looks 
<seb128> your issue is a different one
<seb128> don't abuse the show_desktop bug please
<seb128> yours is not a respawning bug but a crasher
<calc> it shows up as a respawning bug which is why i added to it
<seb128> get me the .xsession-errors but I'm ready to bet it's librasero
<calc> it spawns huge number of nautilus windows that looked just like that bug report
<calc> ok i'll boot it up and copy out the xsession-errors
<calc> http://bugzilla.gnome.org/show_bug.cgi?id=571417#c5
<ubottu> Gnome bug 571417 in Navigation "nautilus flips out when show_desktop is unchecked" [Normal,Unconfirmed]
<pitti> calc: the problem here is that the mechanics of the respawning are exactly the same; just the cause is different (crash vs. nautilus is configured to disable itself)
<calc> that is similar to what i see wrt .xsession-errors double free
<pitti> calc: thanks for investigating this, much appreciated!
<calc> so yea it looks like it is brasero, but i will get the log file
<calc> seb128: is there another bug number for the brasero issue?
<calc> ah i see a couple of them
<Pollywog> I did not know this channel had an Ubottu
<seb128> yeah, I've just been reassigning nautilus bugs there
<Pollywog> is he a twin or the same bot?
<seb128> pedro_: ^ maybe you know
<seb128> pedro_: seems there is a frequent double free issue is libbrasero
<seb128> is -> in
<calc> yea it is definitely brasero
<calc> i just looked in the log in more detail
<calc> its still happening as of mar 22 cd i downloaded
<seb128> it will not have changed since
<calc> ok
<calc> seb128: do you want my xsession-errors as well it looks essentially the same as bug 335286 but is on amd64 (that bug report is i386)
<ubottu> Launchpad bug 335286 in brasero "Nautilus - repeated crash/restarts while starting Jaunty LiveCD Alpha5" [Medium,Incomplete] https://launchpad.net/bugs/335286
<seb128> calc: no need
<calc> ok
<seb128> calc: http://bugzilla.gnome.org/show_bug.cgi?id=576439
<ubottu> Gnome bug 576439 in libbrasero-media "nautilus crash because of probable double g_free in brasero_medium_get_css_feature" [Critical,Unconfirmed]
<seb128> calc: bug #339993
<ubottu> Launchpad bug 339993 in brasero ""Starting File Manager" windows open uncontrollably, even when displaying desktop" [Medium,Confirmed] https://launchpad.net/bugs/339993
<calc> seb128: is that something that could be fixed before beta, otherwise our call for testing the cd may end up with just lots of duplicates of this issue :\
<seb128> calc: you are welcome to work on the issue since you have the bug on your box
<seb128> we didn't get so many duplicates until now and it's not new
<seb128> could be configuration specific or something
<calc> may be just showing up under vmware
<seb128> I'm doing CD testing under kvm and I've no such issue
 * calc is very busy with fixing OOo issues atm so probably can't get to it in time
<calc> i found the issue while trying to work on OOo issues actually lol
<calc> is the line removal in upstream bug report sane? it might cause leaks?
<seb128> just move the brasero thing away while you want to get work done
<seb128> the upstream bug seems pretty well described
<seb128> I added a comment there
<seb128> I've no clue about this code I don't work on brasero
<calc> ok
<seb128> let's wait for them to comment
<calc> ok
<calc> i'll bbl, about to have a meeting
<Riddell> mvo: upgrade from hardy seems to work with DistUpgrade from bzr, yay
<mvo> Riddell: excellent
<mvo> Riddell: feel free to upload (bzr-buildpackage -S should work fine) - otherwise I do it tomorrow morning (I need to leave now)
<ebroder> mvo: question about the disable third party sources.list entries bug (I can't find the LP number right now...)
<ebroder> Will that work for Intrepid -> Jaunty upgrades? Or just upgrades after Jaunty?
<seb128> hum
<ebroder> bug 147080 - there it is
<ubottu> Launchpad bug 147080 in update-manager-core "do-release-upgrade should make disabling third party repositories optional" [Wishlist,Fix released] https://launchpad.net/bugs/147080
<seb128> current daily still has deskbar-applet why?
<pitti> seb128: can you check the .manifest whether the current livefs really has the new gnome-applets with the suggest?
<seb128> pitti: well the installed version is the new one and apt-cache show lists it as suggest
<seb128> where is the .manifest?
<pitti> http://cdimage.ubuntu.com/daily-live/current/jaunty-desktop-i386.manifest
<seb128> yes, it's current
<seb128> gnome-applets 2.26.0-0ubuntu3
<pitti> hmm
<seb128> grep-dctrl -s Package -F Recommends deskbar-applet ... lists nothing else
<seb128> and apt-get remove on the liveCD just uninstall it without complain
<pitti> pitti@rookery:~/seeds/ubuntu.jaunty$ grep deskbar-applet *
<pitti> dvd: * deskbar-applet
<pitti> hm, nothing here either
<LaserJock> cjwatson: if I clean out non-Edubuntu items from edubuntu.jaunty's supported seed will that mess anything up?
<RainCT> Uhm.. On Jaunty screen dimming doesn't work properly here (this is a regression from Intrepid). If I plug out the cable brightness doesn't change, but if I open gnome-power-preferences it goes down; if I plug it in again, it only changes at the moment I open gnome-power-preferences
<RainCT> Any idea on this, or should I file a bug (with what info?)?
<LaserJock> I noticed that it seems to be causing a component mismatch for gcc 4.1 an 4.2
<seb128> pitti: ok, nothing depends or recommends it so I don't know
<pitti> seb128: it's a mystery to me, too
 * pitti -> Taekwondo, cu tomorrow
<seb128> pitti: have fun!
<Pollywog> btw what are "udeb" packages?
<Pollywog> I have seen them a few times when compiling my own packages
<seb128> special debs for the installer
<Pollywog> they end up in the same directory as my new packages
<ebroder> "microdebs"
<Pollywog> oic
<mdz> pitti: I've filed bug 347457 with a trivial hal-info patch.  I assume that you sweep through those and batch them into uploads.  If it would be better for me to just upload with this one change, I'm happy to do that instead, just let me know
<ubottu> Launchpad bug 347457 in hal-info "Should ignore U3 (Windows software) on SanDisk Cruzer Titanium" [Low,Triaged] https://launchpad.net/bugs/347457
<imachine> sup,
<imachine> anyone else experiencing problems with qt apps not respecting dpi?
<imachine> ever since Jaunty
<imachine> they respect font, looks, etc.
<imachine> (I think qt-gtk-engine or whtever it's called, intorduced in 4.5 of qt is in works here) but they don't respect the dpi size for fonts, .i.e, I get slighlty larger fonts with qt apps.
<imachine> any ideas what might be wrong and where I ought to start looking ?
<imachine> I don't think it's plainly Ubuntu's faulkt
<imachine> since if I create a new user, there is no such issue.
<imachine> any ideas where I could look for this setting?
<imachine> #gnome? P
<imachine> ;P
<Nafallo> imachine: /topic
<imachine> I've read it.
<imachine> oh, not fully I guess
<imachine> so. -bugs huh?
<imachine> I automatically supposed that if it's jaunty, -devel would be a better palce.
<imachine> no probs, will try #-bugs
<Nafallo> imachine: #ubuntu would be a good first one.
<calc> asac: ping
<calc> asac: can you look at bug 271283 someone claims this could be fixed in gnome somewhere by setting an option in a file
<ubottu> Launchpad bug 271283 in openoffice "[ooo-build] OpenOffice.org subpixel font rendering broken with new cairo" [Unknown,Confirmed] https://launchpad.net/bugs/271283
<imachine> Nafallo, I guess it's a bit too crowded ;p
<calc> asac: https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/271283/comments/19 <- that comment in particular
<ubottu> Ubuntu bug 271283 in openoffice "[ooo-build] OpenOffice.org subpixel font rendering broken with new cairo" [Unknown,Confirmed]
<seb128> slangasek: ok, I've been looking through the archive, nothing out of gnome-games sudoku uses python gnomeprint (and that's fixed in svn now)
<seb128> slangasek: and only 5 packages use python gtksourceview1
<seb128> slangasek: the gtksourceview split is not worth it, the debs are less than 300k, gnomeprint might be worth doing
<seb128> and deskbar-applet is still on the current daily-live for no obvious reason
<asac> calc: yes. checking
<calc> asac: thanks
<asac> calc: is there a trick to svn checkout openoffice?
<asac> calc: i tried it a few hours ago, but at some point my svn spit out some "XML" errors and then consumed all memory
<calc> i don't know i normally just use the tarballs
<asac> heh. ok ;)
<calc> i haven't checked out OOo in a while, before its conversion to svn
<asac> calc: ever requested a bzr sync ;)?
<calc> heh, no
<asac> calc: so they migrated _this_ year from cvs to svn?
<asac> calc: is there a cross reference for ooo source with quick searching?
<calc> asac: yea migrated this year
<calc> asac: not sure if there is a cross reference
<calc> asac: if there is one i don't know about it
<calc> and searching on google turns up nothing
<asac> calc: and a web code browser where i can search for functions/strings?
<calc> asac: not afaik :\
<calc> asac: OOo needs to be brought into the 20th century first ;-)
<calc> before it can catch up with the 21st century ;-)
<seb128> cjwatson: any idea why deskbar-applet is still on the current i386 livecd image?
<Laney> world's speediest archive admin!
<walters> asac: you have tried http://google.com/codesearch, right ?
<cjwatson> seb128: the most recent livefs builds for both amd64 and i386 seem to have been killed with SIGTERM part-way through. I don't know why
<cjwatson> infinity: ^- do you?
<seb128> cjwatson: the current published iso has it but nothing recommends or depends on it
<seb128> cjwatson: ie the manifest and iso have the current gnome-applets which use a Suggests now
<infinity> cjwatson: What time?
<seb128> cjwatson: but deskbar-applet is still on the image
<cjwatson> seb128: read what I just said :-)
<infinity> cjwatson: vorlon asked lamont to whack some builds and return terranova/king to a sane state earlier today (4 or 5 hours ago?)
<cjwatson> seb128: the most recent livefs build, presumably after your gnome-applets change, failed. Therefore the gnome-applets change is not yet reflected in the current image
<cjwatson> infinity: ah
<seb128> cjwatson: ok, the current image has the fixed gnome-applets version when you dpkg -l there though so I though it would reflect the version used for the build
 * seb128 should learn about cd images build
<cjwatson> seb128: strange
<seb128> the .manifest on cdimage also list the current version
<cjwatson> hmm, I mean, you're right, it does
<cjwatson> but the manifest's date is around the time of http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/jaunty/ubuntu/20090323.3/
<seb128> ok, let's wait for the next successful build then
<cjwatson> seb128: ok, I *think* what may have happened is that deskbar-applet wasn't actually being pulled in by the recommendation directly, but because it still had a Task: ubuntu-desktop field in the archive
<seb128> we can still investigate if the new build is buggy
<cjwatson> seb128: due to a design problem in Soyuz, Task fields can take one additional publisher run to settle sometimes
<cjwatson> so I think that's probably what was going on here
<seb128> ah ok, that would make sense
<seb128> thanks for the explanation ;-)
<cjwatson> seb128: sorry for misexplaining earlier
<cjwatson> I hadn't noticed that gnome-applets was up to date
<seb128> cjwatson: that's alright, I was just not sure if I was missing something obvious, it makes sense now ;-)
<cjwatson> the fix for the Soyuz bug would be to run germinate based on the expected results of publication *before* actually publishing the dists/ tree
<cjwatson> the basic problem is that the Packages files are an input to germinate, but also germinate's output is an input to Packages file generation
<cjwatson> so, to decouple this, germinate would need to be fed equivalent data to Packages internally in Soyuz, so that its output could be used to generate the Task fields straight away
<cjwatson> to make matters slightly worse, changes in germinate's output are not enough to cause Soyuz to treat a pocket as "dirty", so sometimes the subsequent publisher run won't have any effect until you give it a package to publish
<cjwatson> but, in the meantime, repeated publisher runs and the odd judicious accept are usually enough to work around all the problems
<seb128> seems to be some non trivial work
<seb128> for little win
<cjwatson> it is worth it, I think, but not immediately urgently
<cjwatson> it does result in confusion and wasted time at exactly those times when we're in a rush
<asac> calc: http://svn.services.openoffice.org/opengrok/xref/
<cody-somerville> cjwatson, can you associate https://edge.launchpad.net/germinate/trunk with the correct branch?
<cjwatson> cody-somerville: done
<cody-somerville> thanks
<calc> asac: cool! thanks for the url
<calc> asac: that will come in handy for me as well :)
<calc> asac: unfortunately it doesn't include 3.0.1 but should still be fairly useful
<kwah> hi all
<kwah> just got a situation
<kwah> totem upon running a video file crashes x-server
<kwah> do not see anything suspicious in the logs
<kwah> what else can I do to find out the source of problem?
<kwah> second run on the same file does not reproduce the problem
<TheMuso> slangasek: that first test build for studio on the tracker is no good, a lot of langpacks are broken. I am suspecting they will sort them out, but will need an ETA for that.
<TheMuso> to know when we can start testing.
<TheMuso> ./c
<bryce> slangasek:  Seen http://jasondclinton.livejournal.com/72910.html ?
<bryce> slangasek: it's been suggested that some of the -intel performance regressions people have complained about might be due to ondemand brokenness rather than X or the video driver as has been assumed...
<davmor2> bryce: sorry to bug you but do you know of a way to enable the mouse for a wacom tablet at all.  The fix for Intrepid doesn't seem to work for Jaunty.  Only I can't find any info on it :(
<bryce> davmor2: sorry not offhand.  tjaalton might know better
<davmor2> bryce: Thanks :)
<davmor2> tjaalton: was it you I spoke to before?
<kwah> don't bother... I found bug-report.
<slangasek> TheMuso: is the ubuntustudio-look upload intended for beta?
<TheMuso> slangasek: yes due to the engine for th theme likely to give weird errors and users reporting bugs otherwise
<slangasek> bryce: oh argh, ondemand has regressed? :(
<slangasek> well, I guess that nicely ties together all the complaints about it :P
<bryce> heh
<bryce> slangasek: that was just posted to ubuntu-x
<slangasek> seb128: gnomeprint after beta, then?
<seb128> slangasek: if you are fine doing it before jaunty yes
<seb128> slangasek: btw any reason we have deb-src sources on the livecd?
<seb128> the apt index corresponding takes some space
<slangasek> I don't know
<seb128> the current CD images still have deskbar-applet btw the livefs update didn't work correctly apparently or something
<seb128> you will probably win some other megs in the next update
<slangasek> yep, expecting that :)
<slangasek> TheMuso: "weird errors" - I guess you mean the warnings that everyone gets on console when starting a gtk app... I don't think that's fixed in the Ubuntu theme yet, even :)
<TheMuso> slangasek: does the murrine engine get used for the ubuntu theme?
<slangasek> but that's fine, ubuntustudio needs a reroll anyway and we can afford to wait another hour for ubuntustudio-look to publish
<slangasek> TheMuso: AIUI the human theme uses it
<TheMuso> ok
<bombshelter13> Where can I get the source for Wubi? Specifically I'm most interested in it's initrd. The wubi site only seems to offer the binary.
<bombshelter13> cjwatson: ping
<IntuitiveNipple> bombshelter13: This any good? https://wiki.ubuntu.com/WubiGuide#Where%20is%20the%20source%20code?
<bombshelter13> That looks promising... now gotta see if I can figure out how they're getting the NTFS partition support in their initrd
<IntuitiveNipple> bombshelter13: grub4dos/stage2/fsys_ntfx.c
<IntuitiveNipple> minus the typo :)
<bombshelter13> IntuitiveNipple: *looks at that* this could prove useful, actually, I might need it...
<bombshelter13> IntuitiveNipple: So they use this to mount the NTFS? Is Fuse/NTFS-3G involved in the process?
<cjwatson> yes
<cjwatson> it's basically just the normal Ubuntu initrd
<cjwatson> the Ubuntu fuse and ntfs-3g packages install the relevant scripts into the initramfs
<bombshelter13> Hmm, interesting. I'm trying to implement something with a similar overall purpose, my plan had been to integrate Fuse and NTFS-3g into the initrd and use those to mount the Windows partition..... curious, do you know if that option was considered, and, if so, whether there was a particular reason it was rejected?
<seb128> cjwatson: do you know if the deb-src are useful on the livecd?
<cjwatson> bombshelter13: err ... that's what we do
<cjwatson> seb128: it's probably OK to remove it
<cjwatson> seb128: obviously it's useful, it's all relative
<bombshelter13> perhaps I misunderstood; I thought you said it was the normal ubuntu initrd? (or are fust and initrd part of the normal ubuntu initrd?)
<seb128> I'm not sure how much space we are trying to win in fact, I've just been looking through candidates for some extra space today
<cjwatson> fuse and ntfs-3g are installed in the standard Ubuntu system, and therefore the scripts they provide are part of the normal Ubuntu initrd
<seb128> the source index is 2.7meg
<bombshelter13> cjwatson: hmm, i see... i'll have to look into how I can accomplish something similar, I guess.
<cjwatson> seb128: and compressed?
<cjwatson> or is that compressed?
<seb128> 685k gziped
<seb128> not a real win
<seb128> I mean it will not win us another language pack and the deb-src can be handy
<seb128> ok, I'm done listing obvious targets I think
#ubuntu-devel 2009-03-24
<mathiaz> kirkland: do you remember what's the state of acpi in jaunty? Is acpid supposed to be running?
<mathiaz> kirkland: it seems that the jaunty installer doesn't install acpid by default anymore
<mathiaz> kirkland: which explains why virsh shutdown vm-id doesn't work
<kirkland> mathiaz: i have it installed on my desktop
<kirkland> mathiaz: perhaps it got dropped as a recommends somwhere?
<kirkland> mathiaz: and we need to re-add it to the server seed?
<mathiaz> kirkland: IIRC there is some code in the installer that checks if /proc/acpi/ is available and if so installs acpid.
<cjwatson> yes, in hw-detect. It only works if it's on the CD.
<cjwatson> there was substantial conversation recently about acpid being obsoleted by other packages
<cjwatson> slangasek might remember more
<mathiaz> cjwatson: oh. And acpi is not the -server isos.
<cr3> strictly speaking, what's the difference between a "package archive" and a "repository"?
<cjwatson> cr3: do you believe that there is a difference?
<thiebaude> i thought older packages are kept in the archive
<cjwatson> mathiaz: acpi != acpid
<cr3> cjwatson: not to my knowledge, but I was wondering if these were strictly synonyms or whether there might be a slight difference
<cjwatson> thiebaude: that would be a pretty confusing term to use for Ubuntu given that it's archive.ubuntu.com
<cjwatson> cr3: they're both somewhat fuzzy terms but I would regard them as essentially synonyms, unless perhaps there's some clarifying context
<cr3> cjwatson: for example, maybe archive.ubuntu.com/ is the repository and maybe ubuntu/ is the archive. just thinking out loud
<cjwatson> no
<mathiaz> cjwatson: well - neither acpi, nor acpid is on the -server iso.
<thiebaude> then current packages are not kept in a archive :)
<cjwatson> thiebaude: current packages are, as it happens, kept in an archive.
<cjwatson> "archive" and "repository" are two more-or-less synonymous terms for something you point apt at.
<mathiaz> kirkland: I think acpid should be put back on the -server iso.
<mathiaz> kirkland: IIUC it's an important component of the suspend/resume for server spec.
<cjwatson> except that isn't quite accurate because you actually point apt at a single distribution and a set of components within an archive, in each sources.list line
<cr3> cjwatson: might it make a difference when you point apt to a series (.../ubuntu jaunty main) and when you point apt to a directory (.../ubuntu ./)?
<cjwatson> cr3: man sources.list
<kirkland> mathiaz: yeah, i concur
<thiebaude> cjwatson: i think i'am starting to understand
<kirkland> mathiaz: you wanna do that?  or did you want me to?
<mathiaz> kirkland: you can do it - I was wondering why acpi stopped working in my freshly installed jaunty kvm guests.
<mathiaz> kirkland: you may wanna wait afte beta though.
<cjwatson> cr3: which uses "archive" consistently for both meanings, but AFAIK you could replace "archive" with "repository" throughout and get the same meaning
<mathiaz> kirkland: I don't think it's a beta blocker.
<kirkland> slangasek: when would it be safe for us to add acpid back to the server-ship seed?
<cr3> cjwatson: ok, thanks for the clarification
<cjwatson> thiebaude: Debian has archive.debian.org, which holds archived versions of no-longer-current Debian releases. The name clash with archive.ubuntu.com is perhaps slightly unfortunate, but we were aware of it at the time and decided that it was not terribly important
<cjwatson> thiebaude: the equivalent for Ubuntu is old-releases.ubuntu.com
<cjwatson> and old versions of packages that weren't necessarily final versions in a given release are kept on Launchpad
<kirkland> mathiaz: it only needs to be in server-ship, right?
<cjwatson> Sigh. Bugs should not have a user-visible importance.
<mathiaz> kirkland: yes
<cjwatson> It just leads to people making irrelevant complaints about their bug having the "wrong" importance.
<cjwatson> (I'm trolling slightly ...)
<slangasek> kirkland: "back"?
<slangasek> kirkland: ah, so it's available for apt-install.  Mmm, do it now and I can get it included for beta.
<slangasek> mathiaz: ^^
<slangasek> it's not a beta blocker, but I've just now rerolled ubuntu-server and can do so again if you want this in
<kirkland> slangasek: committing ...
<kirkland> mathiaz: slangasek: committed and pushed
<kirkland> Committed revision 1449.
<slangasek> ok
<slangasek> starting the CD rerun
<Laney> is notify-reboot-required still the right way to request a reboot?
<Laney> seems so
<TwoToneSpirit> So, if one wants to get their feet wet in Ubuntu-devel, what's the language of choice to learn?
<ebroder> "Makefiles"
<TwoToneSpirit> ebroder:   Was that meant for me?
<ebroder> TwoToneSpirit: Yes, but somewhat jokingly
<ebroder> TwoToneSpirit: Makefiles are the core of Debian/Ubuntu packages, although there are usualy several layers abstracting that away
<ebroder> Ubuntu uses Python fairly extensively for a lot of the custom development that's done
<TwoToneSpirit> I currently regard PHP as my primary language
<ebroder> That being said, there are packages that use just about every language imaginable - I doubt there are many languages that wouldn't be useful
<cjwatson> TwoToneSpirit: I find Ubuntu development is a heck of a lot easier if you're prepared to work in several different languages
<TwoToneSpirit> I hear that Python is a natural next step from PHP for many people
<cjwatson> people do ask this question a lot here, but there is no good answer to it
<TwoToneSpirit> cjwatson:  Well that's why I asked about getting my feet wet :-)
<cjwatson> Python is used a lot for many things in Ubuntu, but in order to work with packaging you'll also need the rudiments of GNU Make and the Unix shell
<calc> i finally have all my upstream bugs linked :)
<cjwatson> and familiarity with C, Perl, and maybe C++ is unlikely to hurt either
<cjwatson> it's much more important to have the skill of picking up languages than it is to know any particular language, I find :)
<cjwatson> as ebroder says, distributions are made up of a wide variety of software written in nearly every language under the sun
<calc> aiui some languages are more evil (lisp) than others, heh
<IntuitiveNipple> The best language to learn for packaging, is Telepathy :)
<ebroder> Aww! I <3 lisp. Well, Scheme
<cjwatson> there are mini-languages in Ubuntu that exist for a single purpose
<calc> yippee, 0 new, 1 confirmed (can't test yet), and only 10 targeted bugs for 9.04 :)
<calc> for OOo
<TheMuso> calc: Cool.
<calc> TheMuso: i can't believe i managed to completely catch up on triaging :)
<Amaranth> calc: That's unpossible
 * Amaranth files 40 more bugs targeted to 9.04
<calc> Amaranth: :-P
 * Amaranth thinks calc is just closing bugs
<calc> Amaranth: nope, been working around the clock :\
<calc> Amaranth: https://edge.launchpad.net/ubuntu/+upstreamreport <- also shows the amount of bugs ;-)
<Amaranth> only 426? that's not bad
<Amaranth> and most of them are upstream, nice
<calc> for some reason the number of bugs not triaged shows as 36 but when you click on it you can only see 35
<calc> i wonder if one of the bugs is hidden from me for 'security' reasons
<Amaranth> you aren't in the ubuntu-bugs team?
<calc> yea, but even then you can't see security bugs until subscribed
<calc> there is a higher level elite launchpad bugs access level
<kees> calc: need me to find something?
<calc> kees: yea look at https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bugs?search=Search&field.status=CONFIRMED&field.status=INCOMPLETE_WITHOUT_RESPONSE&field.status=INCOMPLETE_WITH_RESPONSE&field.status=NEW do you see 36 bugs or 35?
<calc> kees: upstream bug report claims there are 36 but it only shows me 35
<Amaranth> calc: I used to be in some team that had access to security bugs
<calc> kees: if there is something that is marked special i probably need to be subscribed to it
<kees> calc: I see 35.  Perhaps upstream report is out of date?
<Amaranth> thought it was ubuntu-bugs
<calc> kees: maybe so, i thought it was always up to date
<kees> hm, dunno
<calc> i can see if i can find someone on the launchpad team to check it out for me
<calc> kees: thanks for checking for me :)
<kees> calc: sure, no problem.
<maco> Amaranth: bug-control can see private-not-CVE bugs
<maco> dunno about CVEs though
<Amaranth> that was it
<Amaranth> I stupidly let it expire
<calc> maco: aiui bug-control can't see private bugs marked as security, not just cve bugs
<Amaranth> along with motu
<cjwatson> by definition private bugs are only visible to their subscribers
<maco> oh ok
<maco> ive never seen a security one that didnt say cve
<calc> cjwatson: ah so it could be a bug on OOo is private that does not have bug-control or security team on it?
<cjwatson> this is not to say that ubuntu-bugcontrol or some related team is not subscribed to some private bugs
<maco> cjwatson: bug control can see them too to check the crash reports
<cjwatson> calc: entirely possible
<calc> cjwatson: you don't happen to have master access or something like that do you? :)
<kees> private bugs are private -- only subscribers can see them.  most private bugs start their life as private security bugs, and as such, security is subscribed to them, even after they're unmarked security and only the security team can unsubscribe the security team, so we tend to be able to see any private bug.
<cjwatson> maco: only because apport explicitly subscribes "crash bug triagers for main packages" or whatever it is to those bugs
<kees> lag
<cjwatson> calc: no
<calc> cjwatson: ok
<maco> cjwatson: ooo ok
<cjwatson> calc: launchpad.net/~admins
<calc> cjwatson: ok
<cjwatson> calc: but actually if you want to know, answers.launchpad.net/malone is probably a better way to ask
<calc> ok
<dholbach> good morning
<highvoltage> good morning dholbach
<dholbach> hiya highvoltage
<lool> morning
<dholbach> hiya lool
<lool> Hi dholbach, how is it going?
<dholbach> I'm waking up - how 'bout you? :)
<lool> It's about the opposite: I was up so I came to the computer  :-)
<highvoltage> dholbach sometimes sounds like a lyrics generator :)
<dholbach> highvoltage: really? I didn't know that was one of my strengths :)
<dholbach> learn something new every day :)
<dholbach> how are you doing highvoltage?
<highvoltage> oh it is. I might ask you if I can use some of it one day :)
<highvoltage> dholbach: I'm just about to finish a second big deadline that's been a denial-of-service on me for the last 2 months or so
<highvoltage> then I can return back to a state where I can actually relax and do normal things again :)
<highvoltage> dholbach: but it's going well thanks
<highvoltage> dholbach: I guess I'm slightly jealous that summer is leaving us and going over to your hemisphere now :)
<dholbach> highvoltage: slowly, very slowly - it's 2Â°C here
<pitti> Good morning
<pitti> mdz: hal-info> indeed; I commit them upstream right away, and every now and then I package a git snapshot
<pitti> mdz: right now we are frozen anyway
<sbeattie> does the apport-retracer process a bug if it's already been marked as a duplicate of another bug?
<pitti> sbeattie: no, those are ignored
<sbeattie> pitti: okay, thanks.
<sbeattie> pitti: BTW, it'd be useful to extend apport-collect to take a crash file as an argument.
<pitti> sbeattie: that would attach the info in the .crash file to a bug report?
<pitti> sbeattie: I'd rather have apport-{gtk,qt,cli} do that, or a separate script
<pitti> sbeattie: there's an existing bug report for that, too
<sbeattie> pitti: have apport-{gtk,qt,cli} attach to an existing report rather than always create a new one?
<pitti> something like that
<pitti> well, I don't particularly mind which does which
<sbeattie> pitti: sure, I'm not picky about the solution; I just dislike currently creating a duplicate bug so I can do the apport collection when I've recreated a bug on something that didn't get one to begin with for whatever reason (in this case, failure of mdadm while booting)
<Keybuk> cjwatson: why do we now use LABEL by default?
<slangasek> uh?
<slangasek> setting labels, or referencing them?
<Keybuk> I assume he means in /etc/fstab
<Keybuk> mounting-by-LABEL instead of mounting-by-UUID
<slangasek> I'm entirely unaware of this design decision having been revisited
<sbeattie> Keybuk|slangasek: that reminds me, is bug 347370 actually a bug or just an expected change in hal behavior?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/347370/+text)
<slangasek> last I knew, Debian was transitioning to also mount by UUID in squeeze
<Keybuk> slangasek: my reference is bug #347685
<ubottu> Launchpad bug 347685 in initramfs-tools "breaks with labels containing slashes" [High,Triaged] https://launchpad.net/bugs/347685
<Keybuk> Colin Watson said "Since we now use LABEL= by default if filesystem labels are set"
<slangasek> ah, "if filesystem labels are set"
<sbeattie> Sorry, try that again; https://bugs.launchpad.net/ubuntu/+source/hal/+bug/347370
<ubottu> Ubuntu bug 347370 in hal "REGRESSION: volume labels have underscores instead of spaces" [Low,Confirmed]
<slangasek> so they're not set by default, but referenced if someone sets them, hmm
<Keybuk> right, but the reason we never did that originally is because filesystem labels are trivial to clash
<Keybuk> if you have two disks with LABEL=root
<slangasek> yes
<Keybuk> it's not just that the wrong one might be mounted
<slangasek> I don't know why we're doing that, then
<Keybuk> but that the one that is mounted is picked AT RANDOM
<slangasek> but it worries me a bit less than the idea that we were doing this on all new installs
<Keybuk> it's fine if the user uses LABEL= themselves, and puts that in fstab themselves (which is why we've always supported it)
<Keybuk> but any automatically generated file imo should never use it
<slangasek> sbeattie: no clue if it's expected, that's pitti's department :)
<Keybuk> even if the filesystem has one
<slangasek> anyway, you'll probably have to wait a few hours to get an answer from cjwatson, he was up late last night handholding a beta-critical debconf fix
<lool> TheMuso: around still?
<lool> TheMuso: I have an issue with pulseaudio, and I'm trying to find out who's the culprit
<lool> TheMuso: It regularly exits with "E: cpulimit.c: Received request to terminate due to CPU overload." particularly on sites with flash; there's a wiki page on the pulseaudio wiki to debug such issues which suggest it might be driver related; http://pulseaudio.org/wiki/BrokenSoundDrivers however doesn't work for me as the proposed test case spawns pulseaudio for me
<Nafallo> slangasek: X didn't start with the valgrind madness, so had to revert.
<lool> In fact even "aplay" spawns pulseaudio by default when sending to hw:0; this seems to be a bug in /usr/share/alsa/pulse.conf
<slangasek> aw
<slangasek> Nafallo: do you have an error message?  I should fix up the recipe if it's wrong
<slangasek> (well, otherwise I'll find out here next time my X crashes, since I've already done the same)
<Nafallo> ==3295==
<Nafallo> ==3295== Warning: Can't execute setuid/setgid executable: /usr/bin/X.valgrind-madness
<Hobbsee> kirkland: oh, btw, was /home encryption with the alpha5 alternate cd supposed to work?
<Nafallo> ==3295== Possible workaround: remove --trace-children=yes, if in effect
<Nafallo> ==3295==
<Nafallo> valgrind: /usr/bin/X.valgrind-madness: Permission denied
<Nafallo> 3023 2832
<Nafallo> giving up.
<Nafallo> ^ slangasek
<Nafallo> slangasek: thank god for /var/log/gdm/ :-)
<Nafallo> s/god/kees/
<slangasek> Nafallo: ah - should be fixable, I'll dig into that some more, thanks
<Nafallo> :-)
<soren> How does grub figure out on which partition to look for its configuration file? Does it have the partition ID hardwired into the stage 1.5 loader?
<liw> soren, I believe it does
<seb128> liw: hey, do you still work on computer-janitor?
<liw> seb128, sure
<seb128> liw: you seem to not be subscribed to its bugs on launchpad, could you consider the patch on bug #344704 or at least comment? the application is one of the few poorly translated in jaunty right now due to that
<ubottu> Launchpad bug 344704 in computer-janitor "[I18N] Wrong translation domain in ui_gtk.py, some translations not shown" [Undecided,In progress] https://launchpad.net/bugs/344704
<cjwatson> Keybuk: the installer now uses them if they're explicitly set (but otherwise uses UUIDs, as obviously labels aren't suitable for automatic assignment); furthermore, it will not allow you to proceed past the partitioner if you have any duplicate labels
<liw> seb128, I am getting all its bug mail, certainly; I'll apply the patch as soon as I get around to it
<seb128> liw: ok, launchpad is still weird to me your name is not on the list on the side of this page for example, anyway thanks for considering that one
<seb128> liw: would be nice to get it fixed just after beta so translators have time to test it and make sure it works good and update their translations if required
<Keybuk> cjwatson: why does it do that though?
<Keybuk> when we originally discussed this back on MontrÃ©al, we explicitly ruled out ever writing LABEL= by default
<cjwatson> Keybuk: because labels are a lot more readable, and if the user explicitly set some, then it's probably because they wanted to use it
<Keybuk> since labels are most likely to be the filesystem's purpose
<Keybuk> ie. "/" or "root" or "home" or "/home"
<Keybuk> they are much more likely to clash if you put an extra disk in your machine
<Keybuk> or even just a usb key
<Keybuk> and then you end up with random mount behaviour
<Keybuk> we agreed that if a user wanted to use a label in /etc/fstab, they could put it their themselves
<cjwatson> sigh.
<Keybuk> but that we would never put them there automatically
<cjwatson> ok, I'll revert it post-beta.
<Keybuk> thanks
<cjwatson> and try to explain to debian-boot@ what's going on
<cjwatson> because this was explicitly requested there upon trying to get the UUID changes into Debian
<Keybuk> I really just think seeding mount-by-label automatically is dangerous
<Keybuk> if I plug a usb key in, it's generally slightly more likely to win than the sata disk controller
<Keybuk> but not always
<Keybuk> so the random behaviour is just too much of a risk
<cjwatson> I'd only remembered the duplicate label issue
<seb128> TheMuso: do we really need this orca menu item? it adds a menu category for something which opens a command line tool ...
<cjwatson> Keybuk: I think I'll add a partman/mount_by_label preseed or similar
<cjwatson> defaulting to false
<Keybuk> that'd be ok
<Keybuk> I don't mind if a user takes an action to use them, then it's their fault
<Keybuk> and when they file a bug, we can go "aha! but you did foo, so don't do that then"
<cjwatson> do we need to unwind this for beta to avoid having to support upgraded systems?
<Keybuk> I'd just release note it
<cjwatson> THE RIGHT ANSWER
<Keybuk> when did the installer start using labels?
<cjwatson> 24 Feb
<Keybuk> yeah, I'd just release note that - say that systems installed may use label in /etc/fstab - and that this could cause unexpected behaviour if another disk with the same label is added later
<Keybuk> with instruction on how to find the uuid of the device
<cjwatson> can you file a bug on partman-target and ubuntu-release-notes?
<cjwatson> I got five hours sleep last night due to this debconf bug, and need to go and get a bit more ...
<Keybuk> sure
<cjwatson> thanks
<mdz> pitti: excellent, thank you
<TheMuso> lool: dtchen is working on this, give me a sec and I'll get you a bug numbetr.
<TheMuso> seb128: I can address this post beta, its probably not needed there anyway. It opens a terminal because orca tries to set itself up if orca and accessibility is not set up.
<lool> TheMuso: Ok; concerning the autostarting of pulse is it a bug or it's just me reading the description wrong?
<TheMuso> lool: description of what?
<lool> TheMuso: the pulse.conf machinery
<seb128> TheMuso: ok thanks
<lool> # PulseAudio alsa plugin configuration file to set the pulseaudio plugin as
<lool> # default output for applications using alsa when pulseaudio is running.
<lool> TheMuso: But what this plugin really does is to start pulseaudio if it isn't running
<TheMuso> lool: dtchen decided to re-enable auto spawning of pulse if it wasn't running
<TheMuso> lool: no the plugin doesn't do that, see my comment re auto spawn
<lool> TheMuso: Well however you turn it, it's hard to avoid using pulseaudio in this case
<TheMuso> lool: bug 343254
<ubottu> Launchpad bug 343254 in linux "pulseaudio: alsa-util.c: snd_pcm_avail_update() returned a value that is exceptionally large" [High,In progress] https://launchpad.net/bugs/343254
<lool> TheMuso: I wanted to debug pulseaudio per the upstream instructions and couldn't until I disabled this snippet
<TheMuso> lool: I suggest you talk to dtchen about his reasoning.
<lool> TheMuso: Ok
<lool> TheMuso: The bug you point at is fixed in jaunty; it's certainly not fixed for me
<lool> Ah I guess I need new kernels
<TheMuso> lool: hang on it may be the wrong one
<TheMuso> ah ok
<TheMuso> lool: I think dtchen points to test kernels in that bug
<lool> Yes, I found these kernels in multiple ways already, ok thanks
<mdz> lool: where are the installation instructions  for UNR?
<lool> mdz: http://cdimage.ubuntu.com/ubuntu-netbook-remix/daily-live/current/ > https://wiki.ubuntu.com/MobileTeam/Mobile/HowTo/ImageWriting
<mdz> lool: thanks
<lool> mdz: For the installation media creation; or were you looking for instructions on running ubiquity etc.?
<mdz> lool: imagewriter looks nice; how come it isn't in universe?
<lool> mdz: I think at some point we wanted to merge usb-creator and imagewriter rather than having two tools
<mdz> lool: I was looking  for the analogue of https://help.ubuntu.com/community/Installation
<mdz> lool: that sounds like a good idea, but if it won't happen for 9.04, I think having both in the archive would be useful
<lool> I'll raise it with ogra then
<\sh> something is strange regarding keyboard focus with unr cursor keys always focuses on the menu sidebar but not inside the selection...
<apw> cjwatson, if i have a bug with a number of tasks on the wrong packages
<apw> should i mark them invalid and make new ones, or does it make more sense to convert them to the right ones
<Ampelbein> apw: i would just change the package assigned, not invalidating. the reason is that even if a task is invalid, the subscribers of that task still get bugmail.
<apw> cool thanks was leaning that way too as they added no information
<mvo> Riddell: new update-manager is uploaded
<Keybuk> dpkg-gensymbols: warning: debian/libblkid1/DEBIAN/symbols doesn't match completely debian/libblkid1.symbols
<Keybuk> meh
<Keybuk> what does _that_ mean?!
<cjwatson> apw: yeah, what he said
<cjwatson> pitti: any idea why bug 347452 hasn't been retraced yet?
<ubottu> Launchpad bug 347452 in network-manager-applet "nm-applet crashed with SIGSEGV in g_main_context_dispatch()" [Undecided,New] https://launchpad.net/bugs/347452
<cjwatson> reported 16 hours ago
<ogra> meh, no iso re-roll over night ?
<pitti> cjwatson: the retracers got stuck, they got restarted now
<pitti> s/now/an hour ago/ roughly
<cjwatson> ah, thanks
<mdz> I am officially worried about bug 328035
<ubottu> Launchpad bug 328035 in xserver-xorg-video-intel "*** glibc detected *** free(): invalid next size (fast) for xf86Wakeup() call" [High,Triaged] https://launchpad.net/bugs/328035
 * ogra wanted to see if the kernels end up on the armel CDs ... indeed i did forget that the automatic builders are off during freeze
<seb128> cjwatson: do you know in which package is the "Restart Now" or "Continue Testing" dialog after ubiquity install?
<mdz> if any of you have seen an unexplained X server crash, please check the gdm logs to see if it is this bug
<cjwatson> ogra: I can do a manual one
<cjwatson> seb128: that's in ubiquity itself
<ogra> cjwatson, i would really appreciate that
<cjwatson> ogra: running
<ogra> thanks
<seb128> cjwatson: there is lot of strings not displayed in french there but ubiquity on launchpad seems to not have changed for ages and to be translated in french correctly
<seb128> weird
<seb128> https://translations.edge.launchpad.net/ubuntu/jaunty/+source/ubiquity/+pots/ubiquity/fr/+translate?batch=10&show=all&search=Restart+Now
<seb128> -> not listed
<ogra> cjwatson, i see you and steve are both diung a full run every time, just armel would be fine ...
<seb128> no "Restart Now" in the template apparently
<ogra> *doing
<cjwatson> ogra: *shrug*
<cjwatson> ogra: I just copied and pasted it out of the crontab
 * seb128 apt-get source ubiquity
<ogra> ah
<cjwatson> seb128: well, ubiquity's translations do have to be updated by hand, but let me check
<cjwatson> I did that on 18 March
<ogra> oh, you only do ports, i see, steve did all desktops yesterday
<seb128> cjwatson: ubiquity has been translated 100% in french for ages, did all those strings changed recently?
<cjwatson> just checking
<seb128> https://translations.edge.launchpad.net/ubuntu/jaunty/+sources/ubiquity/+translate indicates it didn't change since 2008-04-23
<cjwatson> ah, yes, they did, 2009-03-02
<cjwatson> seb128: that's the wrong place to look though
<cjwatson> https://translations.launchpad.net/ubuntu/jaunty/+source/debian-installer/+pots/debian-installer
<cjwatson>   Current French:   (*) RedÃ©marrer maintenant
<cjwatson>                         Translated by FredBezies on 2009-03-10
<cjwatson>                         Reviewed by Bruno Patri on 2009-03-21
<seb128> right
<cjwatson> so just waiting for us to suck the updated translations into the package
<seb128> ok thanks
<cjwatson> I'll do that again afterbeta
<cjwatson> with extra spaces
<seb128> I was just making sure it's only pending translations and not a bug in ubiquity or an outdated template in rosetta
<cjwatson> seb128: the ubiquity .pot file is just the .desktop files
<cjwatson> seb128: I'd probably better check that the current installer .pot matches the one I generate
<IntuitiveNipple> Who would be responsible for gnome-screensaver translations? I reported to the launchpad team a couple weeks ago that over 100 translations were attributed as uploaded by me but I have nothing to do with it
<seb128> TheMuso: there is no audio theme selected by default in the sound capplet do you know if that's a known issue with ubuntu-sounds or something?
<TheMuso> seb128: Its the first I've heard of it actually.
<TheMuso> I'll have a look tomorrow and get it sorted post beta.
<seb128> thanks
<liw> whee, out of the blue, someone e-mails me and asks if they may help develop computer-janitor
<liw> this must be what it feels like to author successful free software
<directhex> liw, i thought that involved making legal threats against anyone making patches for your software... or was that only a specific free software dev...
<liw> directhex, a developer of formerly free software, even :)
<seb128> TheMuso: bug #347537 if you need a bug number
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/347537/+text)
<directhex> liw, it's perfectly free if someone at a conference winks at you when telling you the licenses are incompatible! that's like a CONTRACT!
<TheMuso> seb128: thanks
<cjwatson> seb128: there were a few strings not in the template, so I'm uploading new versions now
<seb128> cjwatson: thanks
<mdz> cjwatson: can you offer any advice regarding bug 346589?
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/346589/+text)
<cjwatson> mdz: well, I agree with Evan. There's no point in offering a disk for partitioning when partman is going to fall over when it tries to do anything non-trivial with it.
<cjwatson> mdz: or am I missing your point? you don't give context of your specific situation
<cjwatson> mdz: I think it is a bit tenuous for you to say "both of the issues identified here", since the original reporter actually said that he was pleased to see a warning displayed
<cjwatson> mdz: so if you think that part is a problem, it should definitely be a fresh bug
<doko> mvo: https://bugs.edge.launchpad.net/ubuntu/+source/glibc/+bug/339589 there are a lot of upgrade logs like this one. apparently /usr/share/debconf/confmodule is missing when the glibc.preinst is run
<ubottu> Ubuntu bug 339589 in glibc "package libc6 2.9-4ubuntu2 failed to install/upgrade: subprocess pre-installation script returned error exit status 1" [Undecided,New]
<cjwatson> doko: I don't think that can be the case. In this case the terminal log shows debconf output
<cjwatson> which doesn't point to /usr/share/debconf/confmodule being missing, quite the opposite ...
<cjwatson> looks more like the dialog frontend getting used when the terminal is not really usable (i.e. will fail when you try to read from it)
<doko> cjwatson: yes, seen now as well. the log has all the escape sequences, so it's looks rather like an upgrade with RELEASE_UPGRADE_MODE != desktop, or the debconf priority changed on the system
<cjwatson> right, though ideally debconf ought to notice that dialog isn't usable and try something else ...
<mvo> doko: I have no good solution for this, there is no easy way to detect if the upgrade was aborted by hand manually or if its a real error
<mvo> doko: the user will end up with a system that has jaunty in the sources.list and no packages update, it will require manual intervention
<doko> ok
<lamont> Keybuk: wtf do I have to do to make a package that wants debhelper 7 survive with hardy's debhelper (6) ??
<Laney> lamont: hardy-backports has dh7
<lamont> not an option
 * lamont ponders dh_prep and how to stab _that_ in the face, too
<Keybuk> lamont: no idea
<cjwatson> dh_prep used to be spelled dh_clean -k
<lamont> cjwatson: yeah - man pages for the face-stabbing win
<lamont> sed -i 's/\(debhelper *\)( *>. *7[^)]*/\1(>= 6/' ${CTL}
<lamont> sed -i 's/dh_prep/dh_clean -k/' ${RULES}
<lamont> somedays, I feel _dirty_
<TomaszD> hello, if there are any Ubuntu devs around, I would like to report that the "New Broadband Connection" wizard thing is not available for translation, it's in main, but I have no idea what package provides this wizard
<TomaszD> thus I'm asking here if anyone knows what should I report this against
<TomaszD> networkmanager?
<TomaszD> I'll be on and off around here, so if anyone knows just contact me
<TomaszD> I suspected libmbca, but I'm not sure
<Riddell> evand: auto login doesn't seem to make sense with oem install, should it be removed from the UI for oem install?
<evand> Why doesn't it make sense?
<evand> oh
<evand> you mean auto login in ubiquity when in oem mode, not in oem-config, right?
<davmor2> Riddell: it makes sense for netbooks
<Riddell> evand: well it logs in automatically as oem but once the user is set up it still tries to log in as oem (which doesn't exist any more) and gives an error
<evand> ah
<Riddell> evand: right, it could be added to oem-config
<evand> Riddell: can you file a bug for this?
<Riddell> yep
<davmor2> Riddell: is this in oem on Kubuntu because it has just worked twice on ubuntu :(
<evand> thanks
<Riddell> davmor2: yes
<Riddell> davmor2: what happens in ubuntu?
<davmor2> Riddell: it logs into oem fist time round but once you hit setup for enduser then reboot.  It goes to end user setup and then you get gdm login for enduser
<Riddell> bug 347900
<ubottu> Launchpad bug 347900 in ubiquity "auto logon in oem mode fails" [Undecided,New] https://launchpad.net/bugs/347900
<Riddell> davmor2: maybe gdm just doesn't give an error when set to autologin as a user which doesn't exist
<cjwatson> Riddell: I think the bug is that oem-config fails to undo the autologin
<cjwatson> not that ubiquity permits autologin
<Riddell> cjwatson: but does that happen in gnome and kde or just in kde?
<cjwatson> well, the way it's supposed to work is that ubiquity leaves /etc/kde4/kdm/kdmrc.oem behind and then oem-config simply puts that back
<allquixotic> 2.6.29!
<allquixotic> Woohoo!
<cjwatson> Riddell: can I have /var/log/installer/syslog and /var/log/oem-config.log please in case there's any sign there?
<cjwatson> Riddell: (see the disable_autologin function in /usr/sbin/oem-config if you're curious)
<Riddell> cjwatson: http://www.kubuntu.org/~jriddell/tmp/syslog
<Riddell> http://www.kubuntu.org/~jriddell/tmp/oem-config.log
<cjwatson> Riddell: could you attach them to the bug, please?
<Riddell> done, bug 347900
<ubottu> Launchpad bug 347900 in ubiquity "auto logon in oem mode fails" [Undecided,New] https://launchpad.net/bugs/347900
<cjwatson> Riddell: does /etc/kde4/kdm/kdmrc exist?
<cjwatson> Riddell: or indeed /etc/kde4/kdm/kdmrc.oem?
<Riddell> cjwatson: /etc/kde4/kdm/kdmrc does, no /etc/kde4/kdm/kdmrc.oem
<cjwatson> Riddell: and the former contains "AutoLoginUser=oem"?
<Riddell> cjwatson: yes
<cjwatson> so the question is what on earth happened to /etc/kde4/kdm/kdmrc.oem?
<cjwatson> we edit /etc/kde4/kdm/kdmrc using sed -i.oem
<Riddell> cjwatson: I'll do another oem install to check it ever exists
<absabs> why ubuntu exit gsoc2009?
<Riddell> evand: bug 347912  why does wubi have a 8.04 version?
<ubottu> Launchpad bug 347912 in wubi "Kubuntu wubi "learn more" broken" [Undecided,New] https://launchpad.net/bugs/347912
<mdz> cjwatson: here's the scenario:
<cjwatson> mdz: I posted a more extensive comment to the bug
<mdz> cjwatson: I put UNR on a USB key, put it into a netbook,  boot it up, select "Install", and when I get to the partitioning step, I see a random dialog pop up with a warning telling me something about /dev/sdb (whatever that is)
<mdz> what it's telling me is that it won't be able to let me repartition the installation media during installation
<mdz> I don't need to do that, and I don't need a dialog telling me so
<cjwatson> mdz: ok. My bug comment covers that. Yes, this should be a fresh bug report.
<cjwatson> there are other important situations that we need to handle too
<Aquina> I searched the whole net (incl. launchpad), etc for the "/var/lib/dpkg/tmp.ci/control"-(file not found)-problem during apt-get install, but couldn't find something useful. Has anyone an idea what this could be or ever experienced the same? I already filed a bug report.
<mdz> cjwatson: filed bug 347916
<ubottu> Launchpad bug 347916 in ubiquity "Warns user about the fact that the installation medium is mounted" [Undecided,New] https://launchpad.net/bugs/347916
<cjwatson> mdz: thanks
<cjwatson> mdz: (we've flip-flopped on this for a while, and each time we get urgent complaints from a different set of people, so I feel pretty strongly that we need to solve the whole problem now)
<evand> Riddell: looking into it
<mdz> ah, the mystery of 328035 is solved
<soren> mdz: \m/
<mdz> bryce: back over to you
<seb128> does anybody else has computer crashes (ie blank screen no way to switch to VT or anything) happening often after user switching on intel in jaunty?
<seb128> I can't really use the guest session or user switching due to that on jaunty and I'm not sure how to debug it
<maco> i dont do that often, but I hit that last week
<Riddell> cjwatson: kdmrc.oem also has AutoLogin set
<cjwatson> Riddell: now that's odd, that suggests that it's broken in the livefs
<cjwatson> Riddell: or ... I don't suppose you installed to an existing partition?
<cjwatson> as in, without formatting it?
<Riddell> cjwatson: I don't think so
<cjwatson> the log suggests that you may have done
<cjwatson> mind you, /etc should be cleared anyway
<cjwatson> it's going to be ages before I can check this out myself :(
 * cjwatson glares at rsync
 * davmor2 pass cjwatson his make rsync work hammer
<maco> Keybuk: that HFS detection for util-linux...you said it's in current upstream for 2.15rc. Does that mean it can go in jaunty?
<Keybuk> maco: that kind of decision is up to slangasek or cjwatson or someone like that ;)
<Keybuk> it's a trivial enough patch, that is already upstream, so I think there's a strong argument for a freeze exception for it
<Keybuk> but then I'm also vaguely hoping that I might make an argument for the new upstream version itself <g>
<cjwatson> HFS detection sounds like a bug fix to me ;-)
<calc> tkamppeter: bug 320391, i just posted a question to you about it
<ubottu> Launchpad bug 320391 in openoffice.org "impossible to print multple copies under ubuntu 8.10 and the current test release" [Medium,Triaged] https://launchpad.net/bugs/320391
<calc> tkamppeter: basically should i be seeing full pages for each copy sent or just some code in the postscript telling the printer to print multiple times?
<cbr> has anyone succeeded in running kernel mode setting and plymouth in ubuntu?
<mvo> doko, could you please have a look at #347939 - pycentral says its a locally installed file, but that was a automatic install, I never touched any files manually in it
<Keybuk> cbr: you need a later kernel than is shipped by Ubuntu
<Keybuk> and most likely a later X server as well
<cbr> Keybuk: i am aware of the kernel stuff, that's why i asked
<cbr> whether it could be done at all
<cbr> i know that you have to possibly recompile the kernel to enable KMS, since the ubuntu dev kernels don't have it
<cbr> but dunno if it will all work after that
<Keybuk> might do ;)
<Keybuk> there are upstream kernel builds available from apw
<Keybuk> try one of those
<amitk> cbr: you can find the 2.6.29 kernel deb here -> http://kernel.ubuntu.com/~kernel-ppa/mainline/
<Keybuk> (you might need to change the config to get kms enabled of course)
<amitk> cbr: you're on your own for the X.org bits though
<cbr> amitk: i read in the forums that it has kms disabled
<cbr> Keybuk: apw?
<apw> apw is a person
<ogra> s/is/pretends to be/ *g*
<apw> the binaries are where amitk pointed: https://wiki.ubuntu.com/KernelMainlineBuilds
<apw> i am very good at pretending
<ogra> :)
<jameswf> anyone know a X driver for use in a jaunty virtualbox install.. 600X800 makes for some crappy looking screen caps
<amitk> apw: can we enable kms in those configs?
<apw> hrm.  we are using the kernel config from the nearest release as a rule
<apw> so i guess when karmic comes those will come with kms
<apw> ie. 2.6.27 are made with intrepid configs, .28 with jaunty and later with karmic when it appears
<apw> we might be able to force it on, if its switchable at boot time
<amitk> apw: it is probably not default in 2.6.29
<cbr> Enable modesetting on intel by default (DRM_I915_KMS) [N/y/?] (NEW)
<apw> so my stuff will not be turning that on
<apw> i think its on in karmic though
<ni|> any reason trackpads are having problems in jaunty?
<apw> yeah its on there.  so we will start building them with it on when that gets into place
<ni|> using ubuntu for work development
<cbr> can i use the linux-source package to change an option and then still compile my own kernel based on that source and make a .deb out of it?
<apw> in theory yes, not ever tried to do that for a mainline build .deb tho
<cbr> what's a mainline build?
<cbr> no ubuntu specific patches?
<apw> yes
<apw> literally a mainline tag checked out and built using the ubuntu configs
<ni|> is this the wrong channel for jaunty discussion?
<apw> then packaged into .deb
<Pici> ni|: #ubuntu+1
<apw> ni|, #ubuntu+1 is probabally your first stop
<ni|> thanks
<cbr> apw: so what will i be missing? what do ubuntu specific patches do anyway?
<maco> cbr: often hardware bug workarounds
<maco> some cherry-picked patches from newer kernels to fix bugs
<apw> what maco said
<maco> so it might be 2.6.28 and include some bug fixes from 2.6.29
<cbr> so nothing important
<maco> unless you've got that hardware ;)
<apw> important to some people, not others
<apw> for instance you won't have aufs, so you can't make a live cd out of the kernel
<pitti> hey kirkland
<kirkland> pitti: yo!
<pitti> kirkland: I did an install on my USB stick today, and then used adduser --encrypt-home
<pitti> kirkland: very cool stuff!
<kirkland> pitti: :-)
<kirkland> pitti: woohoo!
<pitti> kirkland: I have two bugs, which I'll file on LP now, and one question
<kirkland> pitti: k
<pitti> kirkland: I noticed that there's some stuff in /var/lib/ecryptfs/username/
<pitti> kirkland: is it possible in any way to move them to /home/username/.ecryptfs/?
<pitti> kirkland: to make /home self-sustained?
<pitti> kirkland: so far I have had /home on a separate partition, and just threw away / for a reinstall
<pitti> likewise, I could boot several OSes with sharing /home
<pitti> having the metadata separated will break those use cases
<kirkland> pitti: so that's a complex question
<kirkland> pitti: basically, it comes down to this....
<pitti> kirkland: if that's not possible for some reasons, never mind
<pitti> just wishful thinking :)
<kirkland> pitti: your .ecryptfs directory needs to be readable when $HOME is mounted, and when it's not
<pitti> and I wondered whether it makes sense to write a bug report for this
<pitti> kirkland: right, understand
<kirkland> pitti: ecryptfs has a "passthrough" option
<pitti> kirkland: it would need to be '"transparently" passed through the encryption
<kirkland> pitti: but i found it buggy, unreliable, and confusing to users
<kirkland> pitti: right
<pitti> much like for files I add to ~/.Private on my workstation
<kirkland> pitti: and that's what passthrough is
<pitti> I see
<kirkland> pitti: but there's no policy governance support for passthrough
<pitti> kirkland: so it's possible in principle, but a matter of bugs/
<pitti> ?
<kirkland> pitti: so ecryptfs doesn't know what to do if you want to write a new file in a directory that was passedthrough
<kirkland> pitti: is that new file encrypted, or not
<kirkland> pitti: same with if you append to an existing file
<kirkland> pitti: or delete a file, and create a new one
<kirkland> pitti: anyway, that needs to be solved in the kernel, and it's not yet
<pitti> kirkland: I guess it'd be too evil to special-case ".ecryptfs/"?
<apw> kirkland, how about instead of that
<kirkland> pitti: we actually considered that
<apw> you loopback mount ~/.ecryptfs to /var/foo
<kirkland> pitti: i think "evil" was sort of the conclusion....
<pitti> apw: bind mount, you mean?
<apw> and then loopback mounted an empty dir over it
<jordi> TheMuso: ping?
<apw> andthen mounted home over the top
<apw> pitti, yes
<apw> so its in there, but not
<apw> in fact
<jordi> TheMuso, pitti: there's a discussion in the Debian ALSA team regarding what to do about asoundconf.
<kirkland> apw: pitti: yeah, i think persia suggested that
<apw> what if you bind mounted out of there, then moutned your encrypted mount
<pitti> jordi: ugh, *blows the dust away*, that still exists..
<kirkland> apw: pitti: cjwatson challenged me to keep this to one-mount-per-user using ecryptfs
<apw> and bind mountd the original again over the top
<apw> oh that a shame
<kirkland> pitti: the option I very much preferred was /home/.pitti mounted on /home/pitti
<pitti> kirkland: one just needs to be aware that /var/lib/ecryptfs/ is part of /home now
<jordi> TheMuso, pitti: we're getting bugs, I've noticed we don't have some fixes/additions that are present in Ubuntu packages and if we're going to keep it in Debian we really need someone from Ubuntu taking care of that part
<kirkland> pitti: you could do this ....
<kirkland> pitti: i agree
<jordi> TheMuso, pitti: elimar removed it entirely from SVN, I'm holding the upload while I try to make a decision which maybe is less drastic...
<pitti> jordi, TheMuso: do you actually think that we still need it? at least in GNOME and KDE we have much better ways to configure audio now..
<jordi> pitti: but your reaction was funny. :)
<pitti> jordi: I'm all for that
<kirkland> pitti: you can move /var/lib/ecryptfs/$USER wherever you want ... just put a symlink back to that location
<kirkland> pitti: and actually, it's just $HOME/.ecryptfs that needs to be correct
<jordi> pitti: honestly I'd be happy to drop the python dep and get rid of it entirely
<pitti> jordi: it might have been a good hack 5 years ago, but right now I feel that it's hopelessly outdated by all the pulseaudio stuff
<kirkland> pitti: break the symlinks which are in *both* your mounted and unmounted $HOME/.ecryptfs
<kirkland> pitti: and put them wherever you want
<kirkland> pitti: such as /home/.$USER/.ecryptfs
<pitti> kirkland: ah, so I could put it into /home/.martin?
<jordi> pitti: nod, Debian doesn't do pulseaudio by default though. Maybe this is a good time to push it
<pitti> kirkland: nice
<kirkland> pitti: aboslutely
<kirkland> pitti: in fact ....
<pitti> jordi: eventually Debian will have to as well
<pitti> jordi: it's more and more becoming a required GNOME component
<bryce> mdz, whoa it was the timestamping patch?  How ironic.  Well, we had planned to disable that around beta time all along.  Cool, I'll post it today
<jordi> pitti: how does pulse replace asoundconf
<kirkland> pitti: mine is in /dev/sdb1, which is a pcmcia card
<kirkland> pitti: which means that i *must* have that pcmcia card in my computer to login
<pitti> jordi: for jaunty we jumped through some hoops to keep it halfway optional, but we can't sustain that
<kirkland> pitti: voila!  2-factor authenttication ;-)
<mdz> bryce: I'm not sure I agree that we should disable it; I find it extremely useful when debugging and don't see any harm in it
<kirkland> pitti: i can step away from laptop, take my sd-card with me, and my encrypted data is not accessible ;-)
<jordi> MDZ!
<pitti> bryce: that relieved me a lot; nice to see it being tracked down
<pitti> jordi: well, in the new world you don't configure alsa any more, you tell your app to which pulse sink to route its audio, etc.
<mdz> jordi: JORDI!
<pitti> jordi: from my POV it can be ripped out for good
<pitti> jordi: TheMuso might have a broader opinion wrt. ubuntu studio, though
<jordi> pitti: that's enough for me then. Thanks for the valuable input. May I mention you also are in favour of getting rid of it in the changelog's rationaler?
<kirkland> pitti: just make sure you update both symlinks in mounted and unmounted $HOME/.ecryptfs
<kirkland> pitti: or, just change /var/lib/ecryptfs/$USER to be a symlink too
<pitti> jordi: absolutely
<kirkland> pitti: actually, the latter is the easiest ;-)
<pitti> kirkland: thanks a lot for the heads-up
<jordi> pitti: *nod*. as ubuntu already carries a good deal of asoundconf delta, if studio needed it it can be added entirely to the buuntu diff
<kirkland> pitti: sure... what else do you have?
<jordi> pitti: thanks mate
<pitti> kirkland: I don't have this setup on my workstation, just on the usb stick test install I just did
<jordi> mdz: dude
<jordi> mdz: I'm going to tell you something.
<pitti> kirkland: now I have a complete workstation for carrying around on my keyring :)
<mdz> jordi: you still don't have a title
<pitti> 16 GB sticks rock
<kirkland> pitti: whoa
<pitti> kirkland: the other are just bugs, I'll file them now
<jordi> Since July, 2005, ALL my mobile phones have been configured to show "POP THE TRUNK" on the wallpaper screen
<kirkland> pitti: cool, thanks
<kirkland> pitti: any chance you can help me get something into update-notifier that says "you haven't written down your passphrase yet..." on first boot?
<jordi> mdz: not yet. I'm sense I might be getting nearer
<pitti> kirkland: sure; can you please file a bug report with your requirements, and subscribe me? I'll handle that from there then, to keep a record of the discussion
<kirkland> pitti: will do, thanks
<kirkland> pitti: file against ecryptfs-utils?
<pitti> kirkland: against ecryptfs-utils, I think (since that should ship the notification)
<kirkland> pitti: perfect, thanks.
<pitti> it makes most sense there, AFAICS
<bryce> mdz, I agree it can be useful for debugging, but I'm thinking that we do more debugging during development than after release so that is when it is maximally useful.  Post-release, there is value in having it in that it makes the log less cluttery and more similar to what upstream is accustomed to.  As well, as this bug has shown, even a debug patch can have bugs in it...
<bryce> mdz, but we can discuss retaining it if you feel strongly that we should.
<mdz> bryce: I think we should send it upstream
<mdz> there is at least one further bug:
<mdz> Markers: [    0.022270] (--) probed, [    0.022288] (**) from config file, [    0.022301] (==) default setting,
<mdz> 	[    0.022314] (++) from command line, [    0.022326] (!!) notice, [    0.022338] (II) informational,
<mdz> 	[    0.022351] (WW) warning, [    0.022363] (EE) error, [    0.022375] (NI) not implemented, [    0.022387] (??) unknown.
<mdz> which should be easy to fix
<calc> tkamppeter: ping, it seems you forgot to reassign 320391 to ghostscript?
<calc> tkamppeter: or were you doing something else first before doing that?
<bryce> mdz, my guess is that they'll reject it
<mdz> bryce: why?
<mdz> most other useful log files have timestamps
<pitti> kirkland: bug 347969 and bug 347970 FYI; I took the liberty to assing them to you, but feel free to unassign/delegate
<ubottu> Launchpad bug 347969 in adduser "adduser --encrypt-home fails in German locale" [Undecided,New] https://launchpad.net/bugs/347969
<ubottu> Launchpad bug 347970 in adduser "deluser --remove-home leaves /var/lib/ecryptfs/<username> behind" [Undecided,New] https://launchpad.net/bugs/347970
<bryce> mdz, I think they won't like changing the format.  Best case they might add a server flag (defaulted off) to enable it.
<mdz> bryce: because change is bad?
<mdz> surely X isn't quite that stodgy ;-)
<bryce> mdz: they have their stodgy moments for sure ;-)
<kirkland> pitti: cool, thanks
<bryce> mdz: of course, it hurts little to try and I can do that, but just be prepared when I get flamed by daniels for it ;-)
<bluefoxicy> apt needs to work more like emerge does on gentoo
<bluefoxicy> it installs everything and oops, config file update
<bluefoxicy> sticks it in .config_0000.filename or something
<bluefoxicy> then when everything's done you run etc-update or something and it does all the "diff/replace/keep" stuff
<bluefoxicy> apt you set to update 200 packages, leave for 8 hours, and when you come home it has 4 hours of work to do because it stopped on the third package to ask you if you want to update a confidg file or not
<dholbach> cjwatson: were you going to merge the examples_desktop_file branch of casper?
<cjwatson> dholbach: yes, intending to review it shortly
<dholbach> cjwatson: super, gracias!
<mdz> bryce: looking at the patch, I'm not surprised it had this type of bug in it
<mdz> ++	    tmpBuf = malloc(strlen(format) + strlen(s) + 1 + 1 + 25);
<pitti> don't waste a single byte! :-)
<cjwatson> xasprintf!
<mdz> bryce: even with tormod's latest changes, I don't think it's very robust
<bryce> mdz: I agree
<mdz> as cjwatson says
<cjwatson> (just a shame that the x* family aren't in glibc)
<bryce> X may already have an equivalent in there somewhere
<tkamppeter> calc, this I wanted to do. I have done it now.
<calc> tkamppeter: ok
<cbr> in the mainline kernel repo.. is there anyway to do "apt-get source linux-source.." on it?
<cbr> or is it even possible to somehow get the debian/ dir required to build the debs for it?
<cjwatson> dholbach: looks fine, just fixing up bug statuses and such before committing
<liw> mvo, I added a comment to #108568 -- if you have time, could you see if you agree and that we can close the bug?
<dholbach> cjwatson: thanks a bunch - still testing example-content, but about to upload in the nxt 30m
<cjwatson> dholbach: surely examples-content is post-beta
<dholbach> cjwatson: alright - I'll leave that to you guys to decide
<cjwatson> well, it would mean a CD respin now
<davmor2> pitti: Just to let you know you fix worked for jockey on freesoftware only :)
<pitti> davmor2: nice, thanks for testing it!
<calc> asac: we use system cairo for building OOo
<calc> asac: the patch that sets this up is in ooo-build not in upstream OOo
<calc> asac: i can find the patch that is involved so you can see it via svn.gnome.org
<asac> calc: how far is our cairo out of sync with OOO in-source one?
<calc> asac: hmm actually i think cairo support is now in 3.0.1
<calc> asac: looking now
<calc> asac: the internal cairo (which we don't actually use) is cairo 1.6.4
<calc> asac: http://www.openoffice.org/issues/show_bug.cgi?id=85470
<ubottu> OpenOffice.org bug 85470 in gsl "render text with cairo" [Enhancement,Verified: fixed]
<calc> asac: i believe that was the patch that was added that seems to be slightly buggy in this case
<kees> Nafallo: er, I had something to do with /var/log/gdm?
<calc> seb128: so we went back to not using native dpi for jaunty? (or did i misunderstand what you said in the meeting)
<TwoToneSpirit> So, one passion of mine is adding features to the desktop environment within compiz.  For example, I'd really like to be able to have different wallpapers and icons sets on different viewports.  Where might I begin to investigate this?
<seb128> calc: right we switched back to 96 dpi, too many applications to change to support px fonts values correctly
<seb128> that's for next cycle
<kirkland> pitti: do you think bug #347970 is jaunty, or karmic material?
<ubottu> Launchpad bug 347970 in ecryptfs-utils "deluser --remove-home leaves /var/lib/ecryptfs/<username> behind" [Low,Triaged] https://launchpad.net/bugs/347970
<maco> TwoToneSpirit: different wallpaper is already implemented in compiz, isnt it?
<TwoToneSpirit> maco:  Sort of.  The problem is that one needs to completely disable nautilus, and thus operate with no icons.  Perhaps my quest needs to start with nautilus.
<TwoToneSpirit> maco, et. al.:  One way or another, I want to get into devel, and I just don't know where to begin.
<seb128> is there any reason ubuntu-devel-list gets merge requests emails?
<cjwatson> seb128: we decided we wanted to move ubuntu-core-dev's contact address to a mailing list so that individual developers stopped being spammed by that sort of thing
<cjwatson> seb128: we (TB) debated back and forth a bit, and ultimately ubuntu-devel seemed reasonable since it's useful for contributors to see the patch review process
<cjwatson> seb128: if it gets too noisy we might split off a separate list or something
<seb128> isn't that a way to say to launchpad to not email about such things nowadays or to use a virtual launchpad where you can subscribe?
<seb128> virtual launchpad list
<cjwatson> there's no way to tell it not to mail except by setting a contact address
<sbeattie> pitti: is bug 347370 actually a bug, or just an expected change in behavior?
<ubottu> Launchpad bug 347370 in hal "REGRESSION: volume labels have underscores instead of spaces" [Low,Confirmed] https://launchpad.net/bugs/347370
<calc> seb128: ok, cool, i hoped we weren't reverting back permanently fixing applications is good :)
<cjwatson> and we do want mail to be sent about merge requests, IMO, not for them to be blackholed!
<cjwatson> we could move to lists.launchpad.net, yes. I'm not sure it's necessary yet; merge requests are pretty on-topic as ubuntu-devel goes
<james_w> you could change the subscription settings for core-dev for each branch
<calc> seb128: also you may already know this but for verifying things work 100% its good to test at ~ 150dpi, OOo didn't really start showing noticable problems for me until someone with a screen like that used it
<james_w> but that is a lot of work, in addition to hiding the requests
<calc> ~ 150 dpi can be seen on 15.4" 1920x1200 screen
<calc> eg the ThinkPad W500
 * calc bbl, lunch
<seb128> cjwatson: right, fair points, we do want to now about sponsoring requests too it doesn't mean that the mailing list is the right media to collect those
<cjwatson> seb128: is the volume really prohibitive right now?
<seb128> cjwatson: I'm not clear what would be better but I perceive those emails on the list as noise right now
<cjwatson> it's a lot less than sponsorship requests would be right now, I believe
<cjwatson> and I do think it's a lot better than mailing individual developers
<seb128> cjwatson: no, we just got 7 in a day which made me start about them
<cjwatson> so the only alternative IMO is another list
<seb128> it's not an issue right now but if we start using this launchpad feature often it will get noisy
<seb128> the other alternative I see is to filter those out in the list configuration
<seb128> and use an another way to go through the pending requests as we do for sponsoring
<seb128> anyway it's not really a real issue for now since we don't get a lot of those
<pitti> kirkland: 347970> it's just a bug, thus it's appropriate for jaunty; thus I'd say it depends on workload, not freeze
<kees> Keybuk: wow, that'll be a rough feature-freeze exception.  :P
<pitti> sbeattie: unsure; looking
<kirkland> pitti: i'm testing the fix now
<kirkland> pitti: http://pastebin.ubuntu.com/136893/  <--- i think that's all that's needed, i'm testing it now
<Keybuk> kees: ? :)
<pitti> kirkland: indeed, I expected something like that
<kees> Keybuk: your update of libblkid and all other tools
<kirkland> pitti: that's not quite it, but i'm close
<kirkland> pitti: ;-)
<Keybuk> kees: I may need you to distract slangasek ;)
<Keybuk> there's a volcano near Portland, right? :p
 * kees adds "can cause volcano erruptions" to list of powers people think I have
<kees> Keybuk: there is, but I'm closer to it than he is.  :)
<kees> I suspect the river he's on the other side of may stop lava flows.
<elmo> lava >> river
<elmo> just sayin
<kees> Keybuk: so, if you tested LVM-on-RAID booting, I'll try your PPA crack
<kees> elmo: probably true, but honestly if the lava makes it all the way to portland, it's gonna be a bad time for the northern hemisphere
<Keybuk> of *course* I tested it :D
<maco> calling software "crack"....is this common? dtchen does it all the time and i usually roll my eyes at him
<kees> maco: I'd never heard it before joining the Ubuntu community, but it sure seems appropriate from time to time.
<robbiew> cjwatson: do we need to be concerned with bug 347370
<ubottu> Launchpad bug 347370 in hal "REGRESSION: volume labels have underscores instead of spaces" [Low,Confirmed] https://launchpad.net/bugs/347370
<kees> I suspect it's a Gnome-ism
<Keybuk> robbiew: given that HAL doesn't use them for any reason I'm aware of, I don't think so
<kees> Keybuk: btw, did you see the "RAID10 segvs mdadm" bug?
<kirkland> maco: and we're all crack pushers, by way of "bzr push crack"
<Keybuk> kees: no, iz not udev bug
<punkrockguy> Hey, I'm not really sure if this is the right channel for this, but I'm a coder on the fceux project and our program, fceux, works fine on ubuntu 8.10, but does not work properly on ubuntu 9.04... Is there anyone that could help try to fix our application for 9.04?
<kees> Keybuk: only raid10 kittens seem to have died from the incremental build changes
<cjwatson> robbiew: it looked essentially cosmetic to me
<Keybuk> what the hell is RAID *10* ?
<robbiew> cjwatson: that's what I thought
<kirkland> Keybuk: raid1 + raid0
<Keybuk> cjwatson: I think that's actually a udev change
<punkrockguy> The strange thing is that it works perfect on 8.04 and it does not recognize input on 9.04 even with the exact same code.. It's based on SDL however the sdl libraries are the same in 8.10 and 9.04, I really have no idea what could make it work on one and not the other
<kees> Keybuk: it's madness.  basically, the precursor to sane LVM
<kees> Keybuk: it's RAID1 but with RAID0 concat
<Keybuk> cjwatson: well, libvolume-id change
<Keybuk> Summary of changes from v129 to v130
<Keybuk>       vol_id: always use the safe string versions for unencoded label and uuid
<kees> punkrockguy: if it's an X-input issue, I would ask in #ubuntu-x
<Keybuk> though that suggests its the vol_id too, not the library
<kees> so, I now how to "hold" a package version.  how do I *block* a package?  i.e. it's in Recommends so it keeps trying to get installed, but I want to stop it from getting installed.
<kees> s/now/know/
<kirkland> kees: Conflicts ?
<Keybuk> cjwatson, robbiew: Hmm, I can't see anything here that's changed in HAL or udev
<kirkland> kees: 7.4 of http://www.debian.org/doc/debian-policy/ch-relationships.html ?
<kees> kirkland: well, I mean at the apt level.  I don't actually want to block it in packaging details.  I just want to set a local preference on this machien to never install nspluginwrapper.
<kirkland> kees: is your flash madly broken too?  ie, won't install?
<kirkland> kees: that's on my list of shit to fix after i swallow mdadm for the day
<kees> kirkland: while I adore asac's diligence, flash is insanely unstable for me.  I use adobe's native 64bit flash, and it is 100% stable.
<kees> so, I have a held version of flashplugin-nonfree, and I want nspluginwrapper to never be installed.
<kirkland> kees: is that flashplugin-nonfree?
<asac> kees: this means that 64bit is more stable than 32bit ;)
<asac> for me its similar unstable on 32bit as its on 64bit with wrapper
<kees> asac: their native 64bit with a wrapper is stable?
<asac> kees: sorry 32 bit with wrapper on amd64 ;)
<kees> asac: right, hugely unstable: 32bit with wrapper on 64bit.  for me, hugely stable: 64bit without wrapper.
<kees> kirkland: I guess I could add a Conflicts to my flashplugin-nonfree fork: https://edge.launchpad.net/~kees/+archive/ppa
<kirkland> kees: http://manpages.ubuntu.com/manpages/jaunty/en/man5/apt_preferences.5.html
<kirkland> kees: priorities, maybe?
<kees> kirkland: I think I'll just add a conflict to my crazy fork.  :)
 * calc back
<asac> kees: just ensure in your postinst that all nspluginwrapper leftovers are removed
<kees> asac: yeah, I did.
<Keybuk> robbiew: jaunty udev and intrepid HAL produces Test_Disk label
<Keybuk> so iz not udev bug, -> desktop ;)
<asac> kees: if you removed the wrapped .so's from all the plugins dirs then it should work well and nspluginwrapper shouldnt get in your way ... even if installed
<robbiew> heh
<Keybuk> robbiew: I'll reassign to pitti
<robbiew> Keybuk: okay, thnx
<asac> kees: we are fixing nspluginwrapper to not create that kind of pollution anymore
<kees> asac: yeah, it's not in my way, it just keeps getting reinstalled.  I do a dist-upgrade, it gets installed.  I do an autoremove, it goes away.  really odd, but I realize it's due to my crackful fork.  :)
<asac> kees: you mean nspluginwrapper comes back?
<asac> the package it self?
<asac> or is it that you accidentially upgrade to the archive flashplugin-nonfree ?
<calc> is the proper tag for regression "regression"?
<slangasek> elmo: nah, I'm in the safe part of town where the volcano only takes out our water supply
<pitti> kirkland: oh, did I file the bug against ecryptfs-utils? It should have gone to adduser in the first place
 * asac wouldnt feel safe nor comfortable without water
<kirkland> pitti: nope, you did it right
<kees> asac: right, nspluginwrapper keeps getting reinstalled. not really sure why.
<pitti> Keybuk: the "_" in device labels issue you mean?
<kirkland> pitti: i didn't read closely enough :-)
<pitti> Keybuk: ah, seems so
<asac> kees: i would think its really that archive version gets bumped and that pulls in nspluginwrapper. otherwise its probably a bug in apt :/
<kees> yeah
<kees> mostly I was just curious if there was an apt way to block a package.
<asac> kees: you can install an empty package with version 9999 ;)
<luca> where could I find the source of the ubuntu installer?
<asac> stupid idea, i know
<slangasek> asac: the city limit is a 20 minute walk west, and on the other side, their water is sourced from the hills in the other direction :)
<cjwatson> luca: well, if you hadn't left, I could have told you
<kirkland> pitti: just a thought, but would deluser --remove-all-files be more appropriate?
<kirkland> pitti: that option is already supported and does prune
<cjwatson> --remove-all-files can be *really* slow
<kees> sbeattie: erf, apparmor 2.3+1289-0ubuntu10 did not make it into the bzr tree.  fixing...
<sbeattie> kees: thanks
<ni|> what is the default runlevel? 3??
<siretart> cjwatson: I've seen you've hilighted me in #ubuntu-meeting, and the topic was ffmpeg. are there some open questions left I can answer?
<cjwatson> siretart: I think it was addressed at the time
<cjwatson> ni|: 2
<ni|> thanks
<ni|> a lots :)
<ni|> cjwatson: what is the proper room to ask how to ensure Xorg is up before an init script runs -- its for an app
<ni|> (i know this is the wrong room sry :/)
<cjwatson> ni|: I don't know what the correct IRC channel would be, sorry
<ni|> alright
<\sh> grmpf...why can't d-i tell me, "Dude, you try to partition 2.5TB while you have less then that on your storage device, pls fix your partman recipe, thx" but invane, it starts to partition the last available space with something i don't want....*grr*
<pitti> kirkland: well, --remove-all-files should imply --remove-home, and --remove-home actually purges all the encrypted files, right? so is there anything left why the /var/lib files should be kept?
<pitti> cjwatson: ah, FYI, I think I found out why an installation of today's image on USB caused uname to be 2.6.28-9 -- if I do usb-creator again after completely purging the stick, it doesn't boot at all
<pitti> thus I suppose on this morning's attempt there really was the old kernel still
<pitti> evand: have you tried/heard about successful usb-creator installations recently?
<pitti> evand: the stick looks complete to me, but it doesn't boot at all; it worked just fine some two weeks ago
<kirkland> pitti: and the problem with your other bug is easy too
<kirkland> pitti: count=`ls -Al "$MOUNTPOINT" 2>/dev/null | grep -v "^total" | grep -v "^l" -c`
<kirkland> pitti: insgesamt 8
<pitti> kirkland: hah :)
<pitti> kirkland: so, just set LC_MESSAGES=C ?
<kirkland> pitti: :-)  me and my english-centered world :-P
<pitti> kirkland: or perhaps use a more stat-like approach?
<kirkland> pitti: i was just looking at the latter
<pitti> or wc -l?
<slytherin> gnome-netstatus-applet was recently demoted from recommends to suggests of gnome-applets. Should it also be removed from depends of ubuntu-desktop?
<pitti> seb128: I guess it should, do you agree? ^
<seb128> pitti: that's what I suggested the other day yes
<mvo> siretart: hi! do you happen to know if faumachine can simulate bad cd burns? I would like to test various scenarios with that
<pitti> seb128, slytherin: dropped from the seeds, next -meta rebuild will have it
<kirkland> pitti: okay, patch attached to https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/347970
<ubottu> Ubuntu bug 347970 in adduser "deluser --remove-home leaves /var/lib/ecryptfs/<username> behind" [Low,In progress]
<kirkland> pitti: i've tested it and it works as designed for me
<slytherin> pitti: Ok. Thanks.
<kirkland> pitti: you, or someone with adduser/deluser expertise might take a look over it at this point, to make sure it's kosher
<pitti> kirkland: cool, thanks! maybe we can fix it together with the locale one, since we can't upload right now anyway
<pitti> kirkland: if you don't want to upload yourself, please sub ubuntu-main-sponsors, or assing to me
<kirkland> pitti: agreed
<kirkland> pitti: i'm taking a look at the locale one too
<kirkland> pitti: well, those are uploads to two different packages
<pitti> kirkland: ah, ok; the locale one indeed is in ecryptfs itself then?
<kirkland> pitti: yeah, definitely
<kirkland> pitti: okay, assigned 347970 to you
<kirkland> pitti: review the debdiff, test, and upload at your discretion
<pitti> thanks
<kirkland> pitti: how do i turn my term into german?
<kirkland> pitti: export LANG=de_DE.UTF-8 isn't quite doing it
<pitti> kirkland: sudo locale-gen de_DE.UTF-8
<kirkland> oh, i bet i need the language pack or something
<pitti> kirkland: or install the langpack, yes (which will do that)
<pitti> kirkland: then LANG= will work
<kirkland> pitti: hmm, that's not quite it
<kirkland> pitti: does it take a logout?
<siretart> mvo: yes, there was a master thesis that implemented a cdburner. but you would need to ask sistpoty about its status
<siretart> mvo: is faumachine already in the archive?
<pitti> kirkland: no, it just works
<siretart> (I believe sistpoty was the supervisor of that thesis)
<pitti> kirkland: sudo LANG=de_DE.UTF-8 adduser ... will work
<pitti> kirkland: that sets it just for one command
<kirkland> pitti: k
<pitti> kirkland: you need to have the locale generated, though
<kirkland> pitti: did that
<pitti> ah, hang on
<pitti> kirkland: indeed you need language-pack-de
<pitti> kirkland: since otherwise you can't get any actual translation :)
<kirkland> :-)
 * kirkland foobars his system with german nonsense
<kirkland> :-P
<kirkland> pitti: cool, now I have insgesamt 768
<kirkland> hehe
<mvo> siretart: I think it was added some days ago, but I might be wrong
<siretart> mvo: cool!
<mvo> ogra: who should I bug aobut moddle? it appears to be hanging with DEBIAN_FRONTEND=noninteractive in my upgrade test
<siretart> mvo: it will be a great asset for the qa team, e.g. for simulating live cd installs
<pitti> kirkland: sehr gut!
<ogra>  mvo hmm LaserJock did some work on it
<mvo> siretart: yeah, I would like to simulate a upgrade with a bad CD
<ogra> i didnt touch it since about a year
<mvo> ogra: ok, thanks
<kirkland> pitti: i think this will get me what I need: ls -Al | egrep "^[drwx-]{10}"
<siretart> mvo: oh, that means that you don't actually need the burner, but just the regular faumachine cd drive. I think fault injection should work just fine there, but as said, better ask sistpoty to check that
<kirkland> pitti: thank goodness file perm chars aren't translated :-P
<siretart> mvo: if not, I'm sure he can implement that easily. after all, his phd work is about the faumachine vhdl compiler :-)
<pitti> kirkland: OMGno :)
<kirkland> pitti: seriously?  or joking?
<pitti> kirkland: if they were translated, madness would start
<kirkland> pitti: heh, okay :-)
<kirkland> pitti: i thought you were hating on my egrep
<lamont> stgraber: around?
<lamont> stgraber: --> /pm
<mvo> siretart: heh :) ok - thanks, I will try to catch him when he is online
<kirkland> pitti: woohoo!  fixed.
<kirkland> pitti: i'll commit to upstream bzr, and upload ecryptfs-utils 73-0ubuntu2 when the freeze ends ;-)
<slytherin> seb128: did you get any time to do the DVD playback testing?
<pitti> kirkland: yay you
<kirkland> pitti: i needed some 'success' today, after many, many hours/days fighting with mdadm
<seb128> slytherin: it works now on my desktop and laptop using severals DVDs with the jaunty versions
<slytherin> seb128: Ok. It fails for me with 5-6 DVDs I tried.
<seb128> weird
<slytherin> seb128: do the DVDs you tried have menus?
<seb128> yes
<seb128> menus worked
<seb128> to select chapters or audio tracks
<cbr> damn.. enabling KMS just blanks the screen on boot
<seb128> or episodes
<cbr> it boots, when i presume that X starts, the backlight lights up, but nothing is on the screen
<slytherin> seb128: so what do you suggest? I have got one response on the bug that the repository package does not work and my fixed package works.
<seb128> slytherin: I don't suggest anything so far out of doing a call for testing on jaunty beta
<seb128> ie send an email on -discuss list for example
<seb128> and ask if dvd playing works for people after installing what is required
<kees> Keybuk: fail.
<slytherin> seb128: Ok. I will send a mail.
<seb128> as said it was broken for me
<kees> Keybuk: blkid ran away at 100% cpus, for like 12 instances.  udev did not start my RAID (but did start LVM once I brought the RAID up)
<seb128> and now it works on 2 boxes
<slytherin> hmm
<seb128> so I'm not sure what fixed it there but I can't debug if I don't get the bug
<kees> Keybuk: hardward loading stalled (I assume because of all the stuck blkids, udevsettle never returned)
<slytherin> right.
<kees> s/hardward/hardware/
<slytherin> seb128: last really silly question. I am assuming that you gave gstreamer0.10-plugins-bad installed and resindvd plugin is getting used, correct?
<seb128> yes and I think so
<slangasek> TheMuso: ubuntustudio apparently has some uninstallable packages on the latest ISO, which weren't uninstallable before (http://cdimage.ubuntu.com/ubuntustudio/daily/20090324/report.html), do you know what that's about?
<ebroder> mvo: Question about your fix for bug #147080. Will the AllowThirdParty option work for the Intrepid->Jaunty upgrade? Or just Jaunty->Karmic, etc?
<ubottu> Launchpad bug 147080 in update-manager-core "do-release-upgrade should make disabling third party repositories optional" [Wishlist,Fix released] https://launchpad.net/bugs/147080
<mvo> ebroder: that should work with intrepid->jaunty
<ebroder> Awesome. Thanks again for putting that together
<mvo> ebroder: have you tested it, is there a problem?
<ebroder> mvo: No, I haven't had a change to test it yet. I don't understand the upgrade process very well, so I couldn't tell from inspection if it would work for this upgrade or not
<mvo> ebroder: cheers, no problem. just keep me updated if it works as expected (it should, did fine in my tests :)
<mvo> Riddell: I'm doing a kubuntu hardy->jaunty upgrade now, what version of adept do I need for this to work?
<cbr> -rw-r----- 1 syslog adm  232M 2009-03-24 21:49 messages
<cbr> why is my /var/log/messages file 2.3 million lines long?
<slytherin> cbr: where does it say 2.3 million lines long?
<cbr> when i open it in kwrite or nano
<cbr> $ cat messages | wc -l
<cbr> 2360777
<cbr> shouldn't it be split and compressed or smth?
<slytherin> cbr: wc -l works with filename directly. looks like some problem with log rotation.
<cbr> also user.log is 213 MB
<cbr> and syslog is 256MB
<Nafallo> kees: glibc backtraces to that log. the changelog blames you :-)
<kees> Nafallo: ah! yes, very muchly.  I was getting sick of losing backtraces to vt7.  :)
<Riddell> mvo: https://help.ubuntu.com/community/JauntyUpgrades/Kubuntu/8.04
<Riddell> mvo: the prompt in adept will only work for meta-release not meta-release-devel so cludgy script for beta I'm afraid
<mvo> Riddell: ok, thanks
<kirkland> pitti: okay, i give up ... how do i anglicize my system again?  :-)
<jameswf> jaunty video working in virtualbox soooo happy
<slangasek> kirkland: just how un-English did you make it? :)
<bryce> jameswf: first you must kick the vikings out....
<kirkland> slangasek: German :-)
<bryce> er, s/jameswf/kirkland/
<kirkland> bryce: hehe
<slangasek> kirkland: what did you change to get it into German?
<kirkland> bryce: i'm still working on the visigoths
<kirkland> sladen: LOCALE and LANG
<kirkland> slangasek: ^
<kirkland> slangasek: and i ran some locale-gen
<slangasek> "LOCALE"?
<slangasek> ENOVAR
<kirkland> ah
<kirkland> apt-get remove language-pack-de
<slangasek> that'll do it implicitly, yes :)
<cjwatson> kirkland: just putting LANG back the way it was is sufficient
<cjwatson> LANG=en_US.UTF-8
 * slangasek nods
<cjwatson> assuming you didn't change LC_thingy
<cjwatson> or LANGUAGE
<kirkland> thx
<evand> pitti: hrm, I'll look into it tonight if I can find some time, otherwise definitely tomorrow.  Thanks for the heads up.
<TheMuso> slangasek: on my agenda for this morning. They were installable a day or so ago...
<slangasek> TheMuso: it's the fact that lmms recommends: wine but wine isn't on the ISO; Recommends are expected to be pulled in by default
<TheMuso> slangasek: ah!
<slangasek> at least, that's the problem I see from here
<TheMuso> I'll check that locally
<BlackLukes> is there anyone who is an active developer of ubiquity (or at least knows it quite well)?
<sladen> BlackLukes: yes, but they probably finished work a few hours ago.  Perhaps if you asked what your question/query was you might get somebody else who can help
<BlackLukes> my question is about the code used for the partition bar
<BlackLukes> anyone who would help me please email at luca.91 at hotmail.it, I'm leaving
<slangasek> that's still a metaquestion, not a question. :)
<BlackLukes> maybe I can explain tomorrow, sorry
<bredoto> hia
<bredoto> Need help. How can i make  proper configure file for my sources?
<bredoto> hm anyone
<Snova> What is this for? A personal project, something you're packaging, something else?
<Snova> Also, this isn't really the proper channel, join #ubuntu-programming
<bredoto> personal project. And what is the structure of configure file?
<Snova> They're shell scripts.
<sladen> it's a shell script, generated by autotools
<Snova> Worse yet, they're auto-generated shell scripts, produced from macros (M4, to be precise).
<sladen> Snova: TBH, you probably don't need one
<sladen> Snova: just make a normal Makefile by hand
<Snova> A configure script? Not while I can help it. :) Quick! While you still can! Learn CMake. ;)
<bredoto> does anybody know some tutorials or other source
<Snova> This might be good (for Autotools): http://sources.redhat.com/autobook/
<Snova> Maybe. Just the first thing I found.
<bredoto> thnks
<bredoto> =|
<bredoto> Lets image that i have source file of my progrm: myp.c What is the next step for preparing configure file? Just create  configure file  with "gcc -c myp.c and cp a.out /usr/bin/myp "commands?
<Snova> No, configure doesn't build anything.
<Snova> You need a configure.ac file, which doesn't have to be long, just initialize Autotools and test for a compiler, then generate a Makefile. (Not sure *exactly* how)
<Snova> Then you need a Makefile.am that specifies what to compile, and to what.
<Snova> Then there are various programs that generate more files from those two (there might even be another file or so you have to write, don't think so though).
<bredoto> Snova, thank this is my first step =) iam just a beginner (dummy=)
<Snova> Dang. Sorry about that (again).
<slangasek> kees: full nvclock MIR available now, bug #347813
<ubottu> Launchpad bug 347813 in nvclock "Main inclusion request for nvclock" [Undecided,New] https://launchpad.net/bugs/347813
<Snova> Honestly, I find Autotools to be a gigantic mess. You'd probably be a lot better suited learning something like CMake (I'm partial to SCons, but it might not be quite as good for you).
<slangasek> kees: (if you want it :)
<Snova> bredoto: http://www.cmake.org/
<slangasek> Snova, bredoto: could you please take that discussion elsewhere?  As you noted, it's not really on-topic for #ubuntu-devel
<Snova> bredoto: Only *one* file you have to write, and it's a *lot* simpler.
<Snova> bredoto: Yes, please join #ubuntu-programming
<cjwatson> Snova: cmake: thorough nightmare the last time I had to modify anything written using it (admittedly that was Qt)
<kees> slangasek: I'll likely get to it tomorrow unless you need it rushed?
<slangasek> no rush
<slangasek> it's not going in pre-beta, smartdimmer is on the CDs
<ed___> hi
<TheMuso> slangasek: ok weird. Dispite what the report says, lmms and ubuntustudio-audio install fine with a fresh amd64 disk as of the latest daily. The wine package is kept from the disks by blacklisting, but things install as expected on the disk.
<slangasek> TheMuso: eh, why are you using blacklists for this?  that's a Very Large Hammer
<slangasek> TheMuso: also, we don't want installing from the archive and installing from ISO to give a different experience...
<TheMuso> slangasek: Right, I guess the best approach then is to demote wine to suggests for lmms and fix the seeds
<slangasek> TheMuso: that would be my recommendation
<TheMuso> ok I'll take care of that now.
<TheMuso> slangasek: ok lmms uploaded, pushing the change to the seeds now as well.
<slangasek> thanks
<cjwatson> Riddell: I'll look at your oem-config autologin bug tomorrow - fetching the CD now
<Riddell> cjwatson: thanks
<mdz_> bryce: just in case I wasn't clear...I don't want to block fixing 328035 on getting the patch fixed up; please feel free to rip it out and stop the pain while we discuss what to do after that
<kees> can we deprecate python's "commands" module, please?
<slangasek> mdz_: the fixed xorg-server is already in the beta freeze queue; I'm taking it as an opportunistic fix for beta if something else goes wrong in testing
<mdz_> slangasek: great, thanks
<mdz_> I didn't see the bug updated and so didn't realize
<slangasek> I'm still kicking myself for not having checked debian/patches when I looked at that logging code
<slangasek> sticks out like a sore thumb, *if* you're looking at the right code :)
<mdz_> slangasek: yeah, likewise
<mdz_> I squinted at LogVMessageVerb a bit but it was the unpatched version
 * mdz_ goes to bed
<maxb> I sent email to rt@ubuntu.com complaining about paste.ubuntu.com rejecting pastes containing xml declarations back on 30th January, but nothing's happened. Where can I nag?
<slangasek> ScottK-desktop: what should we say about Kubuntu in https://wiki.ubuntu.com/JauntyJackalope/BetaAnnouncement ?
<slangasek> TheMuso: ^^ same question for UbuntuStudio
<slangasek> cody-somerville: ^^ same question for xubuntu
<slangasek> superm1: ^^ same question for mythbuntu
<slangasek> :-)
<cody-somerville> slangasek, is it suppose to be line breaked like that?
<slangasek> it's a mail draft, so yes
<bryce> mdz: yep, 328035 already has the patch ripped out; just didn't make it for -beta unfortunately
<TheMuso> slangasek: sorry made a typo with the lmms control changes, did a copy and paste, and thought I copied a bracket, but didn't. Uploading a fix now.
<slangasek> ack
<mthaddon> wgrant: can you take a look at bug 335492 - you seemed to be the last to touch the package and just wanted to run my changes by you as I'm kind of new to this
<ubottu> Bug 335492 on http://launchpad.net/bugs/335492 is private
<mthaddon> hmm, I assume that means you can't see the bug...
<wgrant> mthaddon: I might be able to.
<wgrant> Let's see.
<wgrant> I can.
<mthaddon> cool
<wgrant> Because I'm in ~ubuntu-dev.
<mthaddon> :)
<wgrant> mthaddon: That debdiff looks fine.
<mthaddon> wgrant: so what's the process for getting the package updated?
<wgrant> mthaddon: Subscribe ubuntu-universe-sponsors to the bug.
 * wgrant finds the wiki page.
<wgrant> https://wiki.ubuntu.com/SponsorshipProcess
<mthaddon> thx
#ubuntu-devel 2009-03-25
<glaksmono> hi
<glaksmono> why do you guys withdrew from GSoC?
<glaksmono> may i know?
<maxb> seb128: The libbonoboui doc change has had unintended consequences - bug 348228 - ooi, why choose to carry something seemingly so minor as ubuntu delta?
<ubottu> Launchpad bug 348228 in libbonoboui "upgrade broken - files left behind, files missing" [Undecided,New] https://launchpad.net/bugs/348228
<slangasek> maxb: so that our LiveCDs fit on a CD.
<maxb> ah
<JanC> glaksmono: I don't know any official reason, but IIRC there were some "bad experiences" in the past
<UsamaAkkad> hello ,can I add ext4 support to hardy?
<slangasek> UsamaAkkad: it wouldn't be a sane thing to do.  It's not supported by the hardy kernel, or the hardy partitioning tools, or the hardy bootloader.
<UsamaAkkad> :S I've crated one using other os and now I can't use it :)
<o0Chris0o> Hello to all the Ubuntu Devs :) I am trying to get in touch with the devs that have worked on Weather Applet 2.26.0
<o0Chris0o> not sure if this is the right channel to ask or not
<Hobbsee> won't behere
<Hobbsee> you need to find where gnome does their irc
<RAOF> o0Chris0o: The /usr/share/doc/gnome-applets/copyright file should contain the relevant emails, but hitting lits.gnome.org is likely to be much more interesting.
<o0Chris0o> RAOF: thanks :)
<Hobbsee> http://live.gnome.org/GnomeIrcChannels by the looks of it, too.
<ScottK> slangasek: re the beta announcement: I was offline all day today.  We'll have something for you tomorrow.
<slangasek> sounds good
<LordKow> hey the ubuntu devs probably work with local filesystem repos a bit. dput seems to work nicely for uploading to local but is there not an easy way to remove a package from it?
<slangasek> that would be a function of the repo software you're using.
<LordKow> hm, well i guess that would be mini-dinstall.
<sparky_> anybody know what the system-wide folder is for firefox extensions??
<calc> what is the name of the package for git?
<calc> "git" seems to be something else
<calc> is it git-core?
 * calc tries it out
<TheMuso> calc: git-core
<calc> ok
<calc> i saw all the matching verison numbers in dselect and thought it was probably that one
<icarus> i guess theres not much ubuntu developement going on anymore
<icarus> thats a shame
<TheMuso> icarus: we are coming up to teh beta and final releases, so we are only fixing important bugs
<StevenK> It's also European night, so this channel is quiet around this time.
<calc> cjwatson: wrt the GPT issue again, apparently msdos label has a hard limit of 2TB(?) if so we will hit that limit this year as 2TB hard drives are already available
<calc> cjwatson: saw someone mention there is a limit on ubuntu-devel-discuss
<calc> cjwatson: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-March/007555.html
<TheMuso> calc: thats going to screw many windows users over who want 2TB drives IMO.
<TheMuso> Unless Vista 32 can also work with GPT
<calc> TheMuso: aiui vista works with gpt but doesn't boot from it except for 64bit, they will probably patch that soon i would imagine
<TheMuso> calc: They'll have to.
<TheMuso> Unless they want even more backlash.
<calc> http://wdc.com/en/products/products.asp?driveid=576
<calc> I think WDC is the only maker with 2TB drives currently, but the rest will catch up soon
<TheMuso> yep
<calc> looks like we probably should default to using GPT for drives > 2TB if the drive is not partitioned, assuming the information in the thread is accurate
<calc> what i'm unclear about is whether it is msdos doesn't support drives > 2TB or just partitions > 2TB
<TheMuso> yeah
<calc> http://www.carltonbale.com/2007/05/how-to-break-the-2tb-2-terabyte-file-system-limit/
<TheMuso> In any case, I think with these sized drives coming on now, we will have to start moving away from the legacy piece of crap that is BIOS.
<calc> that article implies you don't need GPT if you use linux if you have large block device support enabled
<calc> i don't see CONFIG_LBD in our amd64 kernel so not sure if that is a current option or not
<TheMuso> it may have changed nam possibly
<calc> TheMuso: yea, i emailed cjwatson so when he wakes up can take a look at it
<calc> heh large drives are one way to get rid of XP
<calc> XP 32bit only supports up to 2TB disk in total (not per partition)
<TheMuso> yep
<calc> apparently you can't boot off a GPT disk with Vista unless your bios is EFI
<calc> that is bad news
<TheMuso> This was my point earlier
<TheMuso> EFI is needed
<TheMuso> and even then 64-bit vista is the only one that supports EFI./
<Amaranth> TheMuso: Except it doesn't :/
<calc> i see lots of claims that Windows 7 defaults to GPT
<calc> but not anything authoritative
<Amaranth> That'd be cool
<Amaranth> We don't support GPT, do we?
<calc> some regular pc's apparently have uefi though so i can't tell if it just defaults to GPT in those cases or not
<Amaranth> Oh, Vista SP1 added EFI
<calc> Amaranth: iirc we do on systems with uefi
<Amaranth> hmm
<Amaranth> Pretty sure I had to have rEFIt do the sync thing before I could get Ubuntu installed
<TheMuso> Amaranth: yes you would have had to do that.
<TheMuso> However grub has GPT patches
<calc> hmm if you use rEFIt can you install Vista SP1 64bit using GPT?
<calc> hmm nm it seems rEFIt isn't a EFI emulator like I thought it was
<TheMuso> calc: no its not
<TheMuso> The move to EFI in the PC BIOS area will be quite a big job, since lots of drivers will have to be rewritten to work with EFI. Hell I think everyone will just have to get new hardware.
<TheMuso> I don't see manufacturers releasing updates to their video card's BIOS for example.
<calc> apparently MSI sells motherboards with uefi bios available, not sure what it does for video bios though
 * calc gone to bed, bbl
<Amaranth> calc: Most of them just emulate a traditional BIOS so things will keep working
<Amaranth> I think the goal there is later on once everything is updated they can release a patch that just turns off the emulation
<TheMuso> At least someone is thinking ahead...
<TheMuso> Amaranth: I bet those boards also have no legacy components, i.e no COM headers, no PS/2, no ISA bridge of any kind.
<Amaranth> I'm sure
<Amaranth> btw, I think Gateway was the first PC maker to ship machines with UEFI
<Amaranth> which seems really odd so I thought I'd mention it :P
<TheMuso> s/c
<RAOF> I presume that the standard way to get CONFIG_MMIOTRACE set in the generic kernels is to file a bug?
<dholbach> good morning
<slangasek> superm1: what do we do about bug #341898?
<ubottu> Launchpad bug 341898 in mythtv "Mythtv frontend does not display any fonts" [High,Confirmed] https://launchpad.net/bugs/341898
<kaduk> Hi
<kaduk> How to include modules.dep in initramfs for custom kernel ?
<kaduk> Any ideas ?
<pitti> Good morning
<pitti> kirkland: ugh, how did you change it to German so permanently in the first place? usually you just "export LANG=" in a terminal, and if you are done with it, you close the terminal or set it back to en_US.UTF-8; other terminals/apps should have never been affected..
<kirkland> pitti: thanks, uninstalling the langpack seemed to solve it for me
<pitti> kirkland: very strange; you are sure that your system locale is en_US.UTF-8?
<pitti> kirkland: the langpack shouldn't have any effect then
<kirkland> pitti: how do i check that?
<pitti> kirkland: echo $LANG
<pitti> or, better, "locale"
<kirkland> pitti: those look right, en_US.UTF-8
<kirkland> pitti: i think i'm back to normal
<lool> Keybuk: around?
<lool> Keybuk: I think my init just became somewhat broken on armel after today's upgrade; it's not respawning gettys anymore
<lool> The only thing in daemon.log is:
<lool> Mar 25 09:00:52 babbage init: Re-executing /sbin/init
<lool> In syslog I also see immediately thereafter:
<lool> Mar 25 09:06:49 babbage kernel: [159660.980000] udev: starting version 140
<lool> PID 1 is in: select(7, [3 5 6], [], [], NULL
<lool> It seems it's the libc6 upgrade triggering the restart of init/upstart
<ion_> A free geolocation database: <http://blogama.org/node/58>. It could be useful for Ubuntu if theyâre going to provide a server for the mirror method.
<lool> Keybuk: This happened on my two armel installs
<seb128> lool: today's upgrade should be pretty non-update since we are frozen for beta no?
<lool> Keybuk: I did a "touch /etc/event.d/ttyS0", this made upstart go out of the select, scan the file again, but it didn't respawn the getty
<lool> seb128: I think the bug was there before beta, but any libc update which runs "init u" will have triggered it, and there was a libc update just before beta freeze (last friday)
<lool> I'm only upgrading now
<lool> seb128: But right, it's the upgrade which I ran today, not from the updates the archive got today, thanks for clarifying
<lool> running "init u" manually has a larger effect, but still doesn't respawn; /me reboots
<lool> Keybuk: 348346
<lool> Keybuk: Actually not armel specific at all, same issue on my desktop
<lool> Keybuk: At least one dup, perhaps two
<cjwatson> calc: yes, I'm aware of that, the partitioner already defaults to GPT on >2TB drives
<cjwatson> ion_: yeah, I heard of that recently and posted a comment to a related installer bug
<cjwatson> ion_: the database is an 11MB zip file, so we'd certainly have to have a server for it
<siretart`> dholbach: thank you very much! I probably should have written that mail in english in the first place, but OTOH, perhaps it's better that to have it reflected by someone not that much involved
<dholbach> siretart`: no worries - was easy enough to do
<cjwatson> ion_: I'm filing a (non-urgent) request with our sysadmins to set up a service using that database
<ion_> cjwatson: Cool, thanks,
<Toobaz> "not app development on Ubuntu" means "not app development using Ubuntu" or "not app development for Ubuntu"? I'd like to know how to comply with jaunty's new notifications... but if it's offtopic please feel free to tell me (in that case, any hint on where to ask?)
<Hobbsee> Toobaz: the former, I think.  And I believe you want #dx, if people are around at this time of day :)
<Hobbsee> as that's where that team tends to hang out
<Toobaz> Hobbsee: thanks (what is "dx" for?!)
<soren> desktop experience, I believe.
<Toobaz> soren: nice, thanks
<Hobbsee> yes, that
<ogra> mdz, did you file a bug about ubiquity offering to install to the source media ?
 * ogra just got the SD card offered trying an install in the babbage board
<mdz> ogra: bug 347916
<ubottu> Launchpad bug 347916 in ubiquity "Warns user about the fact that the installation medium is mounted" [High,Triaged] https://launchpad.net/bugs/347916
<ogra> thanks
<mdz> ogra: I'm not sure that's the same thing you're talking about though
<mdz> that's about the warning dialog saying that it's mounted
<ogra> well, it didnt offer me to unmount it, but /dev/mmcblk0 was in the partitioner and selected as default target
<ogra> (/dev/mmcblk0 isd the boot devicer for the livefs in my case)
<apw> whats the most concise way to find out what version of a package you have, and if there are any upgrade candidate.  i often see output like below in bugs so i assume its command generate: libdrm2:
<apw>   Installed: 2.4.4-0ubuntu6
<apw>   Candidate: 2.4.5-0ubuntu1
<ogra> cjwatson, want a new bug for it ? or should i follow up on mdz's ?
<Hobbsee> apw: apt-cache policy packagename
<apw> policy, obviously !?!, thanks
<ogra> (on a sidenote, ubiquity does the base install and partitioning fine on babbage now, though we're missing the kernel bits, so there it will fail)
<mdz> ogra: sounds like a different issue to me
<ogra> yeah
<mdz> it's easy enough to dupe later if not
<Hobbsee> apw: yeah.  There always were interesting names in apt-cache.  You're welcome.
<ogra> ok, i dont think ubiquity every took SD cards into account as install media (it didnt hasve to before :) )
<ogra> *have
<apw> pitti, how come apport can still produce notification icon things and be all nice and quiet about its work, and yet that was imposisble for update-manager and it has to hide and jump out at you?
<cjwatson> ogra: your bug is sort of the opposite of mdz's. New bug, yes please
<ogra> on it :)
<ogra> i'm impressed, i didnt even expect it to get that far :)
<pitti> apw: it has always popped up for crashes of your own programs
<pitti> apw: but that's not possible with system crashes which you need root privs for
<apw> sorry yeah thats good and thats all good
<pitti> apw: that issue was on the table, bot not considered jaunty critical, because we'll disable apport in the final release
<cjwatson> ogra: file it on partman-base, please
<ogra> oh, ok
<apw> what i mean is we were forced to accept update-manager without its cute icon and click me to do things interface
<cjwatson> ogra: it needs to be educated about mmcblk*
<apw> and yet apport still can do it.  wondering why update-manager can't do what apport does
<apw> with apport as a good thing
<cjwatson> I hate the way device name handling is spread all over the place :-/
<pitti> apw: I guess the design team doesn't truly like the way apport does it either; but unlike update-notifier/manager, the system crashes can't run as user :(
<pitti> apw: I guess I'll still get my share of a beating from them
 * apw offers you a shield of defence +1
 * pitti gladly adds it to his asbestos pants
<cjwatson> loggerhead is so nice for SRU proposals
<cjwatson> particularly now that the URLs have been made saner
<ogra> GRRR
<cjwatson> just being able to link to http://bazaar.launchpad.net/~ubuntu-core-dev/tasksel/intrepid-proposed/revision/1388?compare_revid=1383 beats having to mess around attaching a debdiff
<ogra> i really dont like jauntys X crashyness
<pitti> cjwatson++
<pitti> ogra: is it really so bad? just after suspend, or on other occasions?
<pitti> I get it after suspend sometimes, but that's finally tracked down
<ogra> pitti, out of the blue
<ogra> but i'm using UXA deliberately
<pitti> ah, I'm not
<ogra> often the mouse pointer still works but the rest is stuck
<ogra> somethimes it kicks me to gdm
<ogra> *times
<pitti> ogra: does upstream know about the bug, logs, registers, etc.?
<pitti> I reported some myself, and although it takes a while, there has been progress
<ogra> no, i didnt find the time to capture anythng yet
<pitti> my workstation often suffers from pipe underruns
<ogra> it seems related to using an external monitor on my laptop together with UXA
<Hobbsee> ogra: oh, i thought X freezing & dying was just me
<jcastro> I just realized mine was dying on resume
<ogra> it doesnt die if i use it with normal resolution on the laptop LCD ... the external one uses 1900x1200 while the LCD uses 1024x800
<jcastro> unfortunately I for the first few times I had assumed that gnome must have given up on session restore completely
<Hobbsee> mine will die while switching to a guest session
<pitti> jcastro: that's the bug I was talking about; fix is avaialble and will land after beta
<jcastro> pitti: yes james_w pointed it out to me thanks
<cjwatson> also 'bzr cat -rtag:foo' much quicker than having to mess around unpacking source packages ...
<pitti> ogra: I'm using an external TFT as well; do you get occasional flickering?
<ogra> no, by my TFT is very expensive, it might have some flicker preventing thing builtin
<pitti> uh, that would be magic
<pitti> ogra: how often does it freeze for you?
<ogra> how doe that flicker manifest for you ?
<pitti> ogra: i. e. if you tried something to fix it, would you notice?
<ogra> every few days
<pitti> ogra: well, the screen jumps for a subsecond and then restores
<ogra> no, i dont see that
<ogra> cjwatson, Bug #348411
<ubottu> Launchpad bug 348411 in partman-base "offers to install to source media in ubiquity if source media is SD (/dev/mmcblk0) card" [Undecided,New] https://launchpad.net/bugs/348411
<cjwatson> taavikko:
<cjwatson> oops, sorry taavikko
<cjwatson> ogra: ta
<ogra> ugh ...
 * ogra just notices he picked the 2G USB key instead of the 4G one for the install test
<ogra> i wonder if that will survive to the end
<Keybuk> lool: what was broken, specifically?
 * pitti looks at the panel and notices that it's 1337 o'clock
<pitti> time for hacking, apparently :)
 * Mithrandir notes pitti lives in the past. :-P
<Mithrandir> 13:38  * pitti looks at the panel and notices that it's 1337 o'clock
 * pitti hugs Mithrandir
<ogra> heh, same here :)
 * Mithrandir ruffles pitti 
<ogra> oh, ubiquity is such a liar on the babbage
<ogra> "less than a minute remaining" .... shown since tem minutes already
<ogra> *ten
<pitti> ogra: there's a typo in "millenia"
<ogra> heh
<ogra> hmm, apt isnt happy about /dev/mmcblk0 being mounted as /cdrom :(
<cjwatson> ogra: why does apt care what's mounted there as long as it has the right structure?
<ogra> hmm, then probably the structure is wrong, sadly the board just crashed
 * ogra starts over ... damned, i was at 89%
 * ogra starts over
<lool> Keybuk: getty wouldn't be respawned
<lool> Keybuk: Or anything else I guess; see the bug report
<lool> Keybuk: I confirmed on my desktop, so it looks like some urgent we want to fix for jaunty
<Keybuk> getty was initially spawned?
<Keybuk> you logged in, logged out, and then it wasn't respawned?
<lool> Keybuk: Yes
<lool> Keybuk: Well after telinit u, no getty would get respawned
<lool> The running ones would still work
<lool> But when I'd logout, new ones wouldn't come up
<Keybuk>  Mar 25 09:00:52 babbage init: Re-executing /sbin/init
<lool> I noticed on armel because we use serial console a lot, but it's the same on my desktop if I login, telinit u, logout
<Keybuk> what killed init?
<lool> Keybuk: libc6 upgrade
<Keybuk> *sigh*
<lool> Keybuk: "init u" is run except for a sysvinit version blacklist
<Keybuk> someone keeps uncommenting that damned fix
<Keybuk> so that's the bug
<Keybuk> don't use init u/telinit u
<Keybuk> it causes upstart to lose all of its state
<lool> Keybuk: What weird is that upstart doesn't seem to honor its config files either
<Keybuk> lool: how do you mean?
<lool> Keybuk: e.g. even if I touch /etc/event.d/ttyS0, no getty is respawned
<Keybuk> sure
<Keybuk> "start ttyS0" :)
<lool> So I guess the triggering event doesn't happen
<Keybuk> touching config files has nothing to do with events
<lool> I never start ttyS0
<lool> So it's something else starting it
<lool> start on stopped rc2
<lool> So I guess upstart should save its state and/or pick up jobs which match the current criterions for being respawned
<Keybuk> err, neither
<lool> Keybuk: If the behavior is that bad on telinit q, it might be worth not killing init and logging a warning that this isn't implemented yet
<Keybuk> lool: I've commented out that line about half a dozen times over the last few years
<Keybuk> someone keeps putting it back
<cjwatson> mdz: since bug 346589 bites UNR quite noticeably, do we need to release-note it for beta?
<ubottu> Launchpad bug 346589 in ubiquity "[Jaunty] Misleading information when installing with mounted partitions" [High,Fix committed] https://launchpad.net/bugs/346589
<mdz> cjwatson: yes
<cjwatson> Keybuk: I've found that glibc changes not committed to bzr have a habit of getting lost
<mdz> cjwatson: or rather, I'd say that bug 347916 needs to be release noted
<ubottu> Launchpad bug 347916 in ubiquity "Warns user about the fact that the installation medium is mounted" [High,Triaged] https://launchpad.net/bugs/347916
<lool> Keybuk: But even if we avoid calling into that, we're at risk until either upstart behaves as expected in face of such use or doesn't do anyting
<cjwatson> mdz: both, surely
<Keybuk> lool: yes
 * RainCT wonders if apport is compatibly with Debian's bug hooks
<lool> Keybuk: So will you remove the kill and log a warning instead?
<lool> Or will you implement state saving/restoring?
<Keybuk> lool: implementing state saving/restoring is planned
<lool> I understand the immediate workaround is to comment out he init q in libc6
<Keybuk> it'll take about a year to write ;)
<lool> Keybuk: Perhaps it's worth it to remove the kill then
<lool> Cause the effects are nasty ATM
<Keybuk> not that nasty really
<Keybuk> the glibc upgrade tells you to restart your system anyway, no?
<lool> No
<cjwatson> Keybuk: I can't find a record of any glibc upload from you since feisty
<lool> Keybuk: It's enough to dpkg-reconfigure libc6 to trigger the bug
<cjwatson> Keybuk: and neither your dapper nor your feisty upload were relevant - are you sure you uploaded these fixes?
<Keybuk> cjwatson: hmm, strange
<Keybuk> cjwatson: maybe you persuaded me not to, on the basis then init would still have the old glibc open
<lool> So can we just replace the kill with a warning for now until state saving is implemented?
<cjwatson> I'm not sure I was aware that it caused breakage
<Keybuk> lool: I'm not sure we should rush into this
<cjwatson> I think the last time I persuaded you to add a dummy 'init u' implementation instead?
<cjwatson> but it was a while back
<Keybuk> cjwatson: yeah, I'm trying to think why I did that at all
<Keybuk> I would have known it stops gettys from respawning :)
 * Keybuk wishes you could grep irclogs
<cjwatson> I have local logs back to early 2007
<Keybuk> bug #188925 apparently
<ubottu> Launchpad bug 188925 in upstart "Upgrade of glibc causes root filesystem not to be mounted ro on shutdown" [Wishlist,Fix released] https://launchpad.net/bugs/188925
<Keybuk> 23 Sep 2008
<cjwatson> try the 2008-09-29 logs
<Keybuk> ohh
<lool> Keybuk: What's the kill good for?  it picks up a new libc or a new ld-linux or a new init; is there any other reason for it?
<Keybuk> now that title explains everything doesn't it ;)
<Keybuk> including why we can't just put a warning there instead
<cjwatson> hah, neat
<Keybuk> ahh
<Keybuk> and then the day after we had that discussion about the scary assertion when upgrading libc6
<Keybuk> because restarting upstart caused it to drop the connection to initctl/telinit
<Keybuk> and it went WAAAH
 * Keybuk remembers now
<Keybuk> lool: so yeah
<Keybuk> there's a rock, and a hard place
<lool> I am afraid one of you two will have to teach me why not re-execing upstart prevents remounting ro; is this because a fd is open on libc?
<Keybuk> take your pick ;)
<lool> Was this only for a particular version of libc6?
<Keybuk> lool: you can't remount a system if you have any "dirty" files open
<Keybuk> dirty files include those files you have opened which have been unlinked
<Keybuk> upgrading libc replaces the libc6 .so
<Keybuk> init would have the old .so open if it wasn't restarted
<Keybuk> so the filesystem is busy
<lool> Can't we re-exec upstart on shutdown only?
<Keybuk> that'd kill the shutdown sequence ;)
<Keybuk> I don't think this is a sky-is-falling bug, since there's a simple command to restart the terminal - and it's fine after a reboot
<lool> Well it happens on all libc6 upgrades, so on all dist upgrades
<ogra> hmm, where is redboot-tools
<Keybuk> lool: most of the time, these tend to require a reboot anyawy
<lool> ogra: I saw it in aptitude when updating earlier
<ogra> i dont see it on the babbage
<ogra> trying to install redboot-tools and redboot-imx here after a fresh atp-get update
<ogra> *apt
<lool> ogra: weird, I could swear I saw it earlier, and I don't anymore
<ogra> i see the source
<ogra> lool, seems the binaries were not published or ports hangs once again
<lool> ogra: the binaries are in NEW
<ogra> ah !
<lool> I must have confused this with the other redboot package
<ogra> well, i'll try without bootloader for now
<lool> Keybuk: So we should probably recommend a reboot when init-u-ing
<Keybuk> lool: agree
<cjwatson> wah, what happened to /dev/kvm
<cjwatson> doesn't kvm load the modules it needs?
<lool> Keybuk: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/92177 looks like it could be closed with the current init u implementation
<Keybuk> no, it cna't
<ubottu> Error: Could not parse data returned by Ubuntu: timed out (https://launchpad.net/bugs/92177/+text)
<cjwatson> Keybuk: bug 340873, if you haven't seen it
<ubottu> Launchpad bug 340873 in acpi-support "[Jaunty] modprobe requires .conf filenames now" [Medium,Fix committed] https://launchpad.net/bugs/340873
<cjwatson> Keybuk: should that be targeted to jaunty?
<Keybuk> ironically there doesn't seem to be a bug that upstart doesn't support reexec properly
<Keybuk> cjwatson: err, I thought I got all those
<lool> Keybuk: You can make the respawn one that bug if you like
<cjwatson> Keybuk: I'll take that as a yes, then
<Keybuk> cjwatson: yeah
<Keybuk> though where does your bluez modprobe come from?
<cjwatson> bluez-utils
<Keybuk> quest bluez-4.25% grep -r modprobe .
<Keybuk> zsh: exit 1     grep -r modprobe .
<ogra> isnt that in the initscript ?
<Keybuk> quest bluez-4.32% grep -r modprobe .
<Keybuk> zsh: exit 1     grep -r modprobe .
<cjwatson> maybe some old version? dpkg -S still lists it, though
<Keybuk> cjwatson: could be
<Keybuk> cjwatson: bluez-utils only contains /usr/share/doc/bluez-utils for me
<Keybuk> bad clean up of a transiational?
<ogra> same here
<cjwatson> but then dpkg -L would not list it ...
<cjwatson> I mean, I can't find it in the source either
<Keybuk> yes it would
<cjwatson> hmm, indeed, it isn't in the .deb
<ogra> dpkg -L gives me /usr/share/doc/bluez-utils and its contents
<Keybuk> dpkg -L includes all files owned by the package
<cjwatson> ok, so it's a stale conffile left around from a previous version
<Keybuk> including any adopted from previous versions
<cjwatson> something should clean it up, though
<Keybuk> cjwatson: sure
<Keybuk> if I upload, they'll queue for after-beta right?
<Keybuk> ogra: can you do irda-utils
<Keybuk> the maintainer scripts are insane, and I'm not going near them ;)
<Keybuk> cjwatson: err, wtf is oss-compat?
<Keybuk> it seems to be utterly irrelevant in ubuntu given our alsa packages
<ogra> Keybuk, hrm for what ? i dont have irda HW to test and am massively busy getting babbage in shape
<cjwatson> Keybuk: queue> yes
<Keybuk> ogra: you touched it last
<ogra> me ??
<ogra> Keybuk, cn that happen after beta, i really dont have a spare minute
<cjwatson> Keybuk: oss-compat> say hello to Hurd compatibility ;-)
<ogra> babbage enablement is my highest prio atm
<Keybuk> cjwatson: but all it does is add lines which are in our own alsa-base file
<cjwatson> several packages seem to depend on it
<broonie> cjwatson: TBF, I suspect it's more for the benefit of BSD.
<cjwatson> mm
<cjwatson> Depends: module-init-tools | modutils | hurd
<Keybuk> cjwatson: I'll let crimsun sort that one out
<cjwatson> ogra: this is certainly post-beta material
<Keybuk> cjwatson: sane-backends and bluez-utils queued
<ogra> ok, then i can do it, if there is a bug, please assign it to me
<Keybuk> ogra: done
<Keybuk> and thanks
<ogra> thanks as well, i wasnt even aware i ever touched it
<cellofellow> I installed libasound2-plugins from the source package to enable the JACK plugin, but apt keeps wanting to update it to the binary version. How do I edit the source so that the version number is higher so that apt won't update it?
<ogra> could someone let redboot-tools out of NEW ?
<mdz> seb128: what's the easiest way to trigger the gnome-keyring dialog?  I don't have a WPA network in KVM
<pitti> mdz: use ssh?
<pitti> mdz: connecting to an sftp or smb server should also trigger it
<ogra> wohoo, babbage is in langpack installation !!
<cellofellow> Current version of libasound2-plugins in both binary and source is 1.0.17-0ubuntu5. Can I change the version in the sourcecode to 1.0.17-0ubuntu5-1?
<cjwatson> cellofellow: edit debian/changelog. You should make it .1 rather than -1 for technical reasons.
<cellofellow> k
<cjwatson> cellofellow: debian/changelog has a fixed format; you may want to install devscripts and use 'dch -v1.0.17-0ubuntu5.1' to edit it
<mdz> pitti: thanks, connecting to an sftp server was the simplest
<cellofellow> http://paste2.org/p/171047
<cjwatson> cellofellow: look carefully and spot your typo
<cellofellow> lol, thanks
<cellofellow> what's the recommended package to build (every webpage I read has something different).
<cjwatson> debuild
<cjwatson> well, that's a command not a package, but you already have the relevant package installed
<cellofellow> yeah, I mean't command
<cellofellow> anyway to pass -j2 to make using debuild (dual threading)?
<cjwatson> cellofellow: see the dpkg-buildpackage(1) manual page and note that you can generally pass dpkg-buildpackage options to debuild as well
<maxb> cellofellow: DEB_BUILD_OPTS="parallel=2" I think
<maxb> though this relies on the package's debian/rules interpreting it
<cjwatson> the suggestion I made shouldn't rely on that
<cellofellow> ok
<cjwatson> dpkg-buildpackage(1) documents an alternative approach
<cellofellow> um, got a gpg error
<cjwatson> ignore it
<cjwatson> use -uc -us options if you would prefer not to get it in future
<cellofellow> well, thanks guys, no more annoying Update Notifier bugging me to update.
<mdz> cjwatson: is the status of bug 44194 correct, i.e. there is still work needed in openssl and wpasupplicant?
<ubottu> Launchpad bug 44194 in zlib "wpasupplicant doesn't start when the network start" [Undecided,Fix released] https://launchpad.net/bugs/44194
<cjwatson> mdz: work's still needed in wpasupplicant. It's an error that the openssl task is still open; I'll fix that
<cjwatson> oh, hmm, apparently I forgot to upload openssl
<mdz> ok, so it's correct
<mdz> that table is impossible to scan visually
<cjwatson> I've uploaded openssl now. I think I forgot that because there was already a .upload file there from the previous PPA upload
<mdz> .upload files are the devil's work
<mdz> for each time they saved me from a harmless error, they have 10 times caused a grievous one
<evand> pitti: I just tested usb-creator with today's ISO (sorry for taking so long, was caught up in ubiquity work), and it's working fine for me.  Do you have any more information?
<pitti> evand: very little unfortunately, just what I wrote on bug 348078
<ubottu> Launchpad bug 348078 in usb-creator "created USB stick does not boot (worked two weeks ago)" [Undecided,New] https://launchpad.net/bugs/348078
<mdz> Keybuk/cjwatson: in bug 341928, is it the fact that a /dev/block name is being returned that is causing the trouble?  or is that a separate issue?
<ubottu> Launchpad bug 341928 in lvm2 "Consistently reproducible "device or resource busy" error on partitioning" [High,Triaged] https://launchpad.net/bugs/341928
<evand> pitti: ok, I'll follow up there
<pitti> evand: I attached an ls -lR, maybe there's some file missing?
<Keybuk> mdz: it could be indicative of a more fundamental underlying problem
<tkamppeter> pitti, I have prepared an Intrepid SRU to fix bug 345183. I have uploaded the changes to my LP BZR repository. Please merge them into the main Intrepid repo for CUPS and upload the package to -proposed. Thanks.
<ubottu> Launchpad bug 345183 in cups "CUPS, foomatic, & pdftopdf fail when printing more than one copy of an image" [High,Fix committed] https://launchpad.net/bugs/345183
<evand> pitti: do you still have the disk in question?
<mdz> Keybuk: should it be a separate bug, or would fixing that fix 341928 as well?
<Keybuk> mdz: I don't know
<pitti> evand: yes, I didn't touch it since the boot test
<Keybuk> there isn't enough information on the bug to tell
<evand> pitti: could you dd it to a file and stick it somewhere I can pull from?  rookery?
<pitti> evand: I could, but it's 1 GB, so it'll take a fair while with my 50 KB/s upstream
<evand> gah
<evand> nevermind then
<pitti> evand: does usb-creator write an MBR and/or install-grub?
<pitti> i. e. something I could check/upload on the first couple of MB?
<evand> yes, the one from syslinux
<evand> it should match /usr/lib/syslinux/mbr.bin
<pitti> nice, is that really 404 bytes
<cjwatson> mdz: the fact that a /dev/block name is being returned is the proximate cause
<cjwatson> mdz: I'm going to look into it more after beta if Keybuk doesn't beat me to it
<pitti> evand: sudo dd if=/dev/sdc bs=404 count=1 | cmp - /usr/lib/syslinux/mbr.bin
<pitti> evand: says it's identical
<evand> pitti: can you elaborate on it not booting?  Does it just sit there, does it give you an operating system not found error, does it give you any other error?
<pitti> evand: the second
<pitti> evand: in particular, I plug it in, choose the stick in the bios to be first priority, but it still boots from hard disk
<pitti> tried it on two different computers
<pitti> on those computers, my other USB stick with an ubiquity install boots fine
<pitti> so I don't think I'm too dumb to drive the bios, or the bios is too dumb to boot from usb
<pitti> evand: I added fdisk -l output to the bug
<mdz> cjwatson: do you need access to a system with the appropriate controller?
<evand> pitti: very odd
<pitti> evand: I'll do an image to my local hard disk, then zero it out and start over again
<evand> pitti: ok, thanks
<pitti> evand: do you know if the partition type is any relevant here?
<cyberix> Is this the right chanel for problems that might have been introduced by some architectural changes?
<cjwatson> mdz: yes, it would be useful, although only if I can get full console-level access
<cjwatson> mdz: inc. ability to boot arbitrary images
<mdz> fader: can you arrange that for cjwatson?
<evand> pitti: you might want to compare the VBR as well.  re partition type> looks ok
<fader> cjwatson: Is this access to the certification hardware that you need?
<cjwatson> fader: yes please. I have to go out now but will be back later
<cjwatson> fader: post-beta though, I don't have time this week
<pitti> evand: vbr?
<fader> mdz, cjwatson: I will see what the process is to get all that access, as it needs to be worked through IS
<evand> pitti: volume boot record
<mdz> fader: all the more reason to start early, so that when he needs it, it's ready
<fader> mdz: absolutely
<mdz> fader: while you're talking to them, it would be worth exploring if we can grant access en masse
<fader> mdz: I'm concerned about coordination of resources if there are a lot of people in there... we have to make sure that nothing gets rebooted while someone is working on it and that enough hardware is left to actually do the certification tests :)
<evand> pitti: the code runs syslinux /dev/sdb1 as well as copies the syslinux mbr to the disk mbr
<evand> as the latter case was necessary to deal with situations like the user having grub on there for whatever odd reason
<mdz> fader: on the flip side, though, we never know who will need it and when, and the harder it is to get access, the less chance it will benefit developers
<fader> mdz: True.  I will find out what the process is/should be as I don't know everything that's involved at the moment.
<cr3> mdz: we have a locking mechanism in place where people can request access to a machine, which then gets locked when all the pending activities have been completed on the hardware
<cr3> mdz: when a lock is acquired, a message is sent to the user who will then have to unlock it explicitly when done
<cr3> mdz: during that time, all activities for that hardware will be enqueued and some might expire depending on the duration of the lock
<pitti> evand: ah, did you use persistency?
<pitti> evand: ISTR I used persistency two weeks ago, but not yesterday
<superm1> slangasek, well i've talked to bryce about it, and given it made it past xorg server 1.6 freeze he advised that we go to xorg upstream before reverting their patches
<superm1> now for mythbuntu disks, that means you can't really use them unless you are using Intel graphics or one of the closed drivers on the reboot, which is less desirable of course
<evand> ah, that might be the difference
<evand> I did indeed
<evand> pitti: testing now without it
<pitti> evand: just done, worked fine
<pitti> evand: so, same .iso, same non-persistency mode, same usb-creator version
<evand> very odd
<jdstrand> mathiaz: hey, so on bug #305264 what in your opinion is needed to close it out? AIUI, gntuls is sitting in -proposed but probably shouldn't be pushed until the openldap SRUs for hardy and intrepid. Is this correct?
<ubottu> Launchpad bug 305264 in gnutls26 "gnutls regression: failure in certificate chain validation" [High,Fix committed] https://launchpad.net/bugs/305264
<pitti> evand: where is that vbr thing? should I diff it (previous image vs. current stick)
<mathiaz> jdstrand: agreed.
<pitti> evand: for kicks, I'll try changing the partition type again
<jdstrand> mathiaz: are you doing the openldap SRUs?
<jdstrand> s/doing/doing and\/or planning on doing/
<pitti> evand: ok, that wasn't it; ok, nevermind that one for now
<ogra> could some archive admin let redboot-tools out of NEW ?
<ogra> we need it on the babbage
<mathiaz> jdstrand: hm - not at the moment.
<mathiaz> jdstrand: that would require backporting the patch to intrepid and hardy version
<mathiaz> jdstrand: although the patch is rather simple it may need some work for hardy
<jdstrand> mathiaz: yes. I thought that is what we were talking about?
<mathiaz> jdstrand: yes. So I can take a look at it.
<jdstrand> mathiaz: ok excellent :)
<davmor2> guys I got an issue with a samba share from hardy server.  If I use places/network I can see it I double click it and it changes to the workgroup,  I double click on that and I get told I don't have access.  However if I click on places/connect to server I can get it to function fine is this a known issue?
<cbr> does ubuntu's xorg support KMS?
<evand> pitti: if you dd the non-working image back on, and then run syslinux -s /dev/sdb1 (or whatever the right value is) does it then boot?
<maco> cbr: dont know about xorg, but ubuntu's kernel doesn't
<seb128> mdz: https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/348428 seems to be an issue similar to the one I was mentionning yesterday
<ubottu> Ubuntu bug 348428 in gdm "Swithing to another user and then to anything else, freezes laptop. Jaunty" [Undecided,New]
<seb128> "exaCopyDirty: Pending damage region empty!
<seb128> *** glibc detected *** /usr/bin/X: double free or corruption (out): 0x0d73de98 ***
<seb128> ======= Backtrace: =========
<seb128> /lib/tls/i686/cmov/libc.so.6[0xb7ba8604]
<seb128> /lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb7baa5b6]
<seb128> /usr/lib/libdrm_intel.so.1[0xb77e6837]
<seb128> "
<seb128> mdz: that seems a different one than yours
<seb128> mdz: especially that in this case there is no suspend or resume and no reason for the clock to go backward
<seb128> bryce, tjaalton: ^ is that a known issue?
<seb128> the crash is a libdrm one
<mdz> seb128: the problem turned out to be memory corruption, so it's hard to say whether it's related. could be fallout from that bug
<seb128> well the timestamp corruption is only when the clock goes backward no?
<seb128> there is no reason to have that on user switching is it?
<cbr> maco: do you know whether i still need intelfb compiled for kms?
<maco> cbr: i dont know, but i have an idea who would...let me see if i can catch him on jabber
<maco> cbr: no, you don't
<maco> cbr: still need CONFG_FB for termnal though, he says
<cbr> oh, then i guess i didnt get my kms working
<cbr> i only see a framebuffer with intelfb
<cbr> without it, it switches off the screen
<kees> seb128: the memory corruption starts with X.org has been running for >28 hours, and when a log message is generated
<kees> i.e. the "seconds" count exceeds 5 digits.
<seb128> I don't think it's my issue
<seb128> I usually reboot daily
 * kees nods
<pitti> evand: trying
<pitti> evand: it's really sdb1, not sdb? i. e. the partition, not the device?
<evand> pitti: yes
<tedg> slangasek: I remember you showed me some trick to make dch behave better, but I don't remember what the trick was... can you point me to it again?
<cjwatson> DEBCHANGE_RELEASE_HEURISTIC=changelog is the usual main one
<cjwatson> in ~/.devscripts
<cjwatson> I recently discovered DEBCHANGE_MULTIMAINT_MERGE=yes as well, which is nice
<tedg> cjwatson: Yes, that was it.  Thank you!
<james_w> I'm starting to wonder why that is not default
<james_w> and if the second does what I think then I think it definitely should be
<pitti> yeah, it's one of those "unbreak it" settings
<pitti> I have that as well
<tedg> It's hazing for new debian packagers ;)
<james_w> I fear it's just a case of the devscripts maintainers not wanting to annoy those who like the current way
<cjwatson> james_w: likewise
<james_w> cjwatson: are you not a devscripts maintainer?
<slangasek> superm1: so is this a recent regression wrt mythbuntu, or was everyone just using intel or closed drivers for the alpha?
<slangasek> superm1: and does this become a release notes item for beta, if we have to round-trip to upstream to get the underlying bug fixed?
<cjwatson> james_w: no, sort of been meaning to get round to that
<cjwatson> I think they'd add me if I asked, given they've nearly said so in the past :)
<james_w> are you a lintian maintainer?
<cjwatson> yes
<james_w> ah, that's it
<james_w> I can bring the issue up if you like
<cjwatson> and debian-policy these days, because apparently I'm mad
<cjwatson> wouldn't hurt
<james_w> heh
<cbr> maco: okay, kms terminal works now too.. it didnt yesterday but now it works.. anyway, Xorg still doesn't play ball
<cbr> so i guess something in jaunty doesn't support it
<cbr> installed latest xorg-intel stuff from xorg-edgers
<maco> cbr: talk to bgamari. you wont find him in any ubuntu channels except #ubuntu because he's a fedora user, but he does some intel work with upstream and is who i usually ask (mostly just because we go to school together...)
<cbr> i see
<cbr> thanks
<cjwatson> ogra: accepted redboot-tools
<ogra> yay !!!
<ogra> cjwatson, i have one odd issue on that babbge that enforces to shut down syslog, i assume we cant get proper installer logs with a clever preseed option anyway ?
<cjwatson> you can do networked syslog
<cbr> Default kernel mode setting to off, add configure flag to enable
<cjwatson> log_host=foo log_port=bar I think
<cbr> in intel driver 2.6.0 changelog
<ogra> hmm, that would require a properly working NIC driver
<cbr> i wonder what's the flag though
<cjwatson> ogra: do you mean that you can't run syslog at all?
<ogra> cjwatson, the kernel spills a ton of USB messages all the time ... that makes syslog/klog/debug grow to 100s of MB ...
<ogra> which in the end makes the system hit oom
<cjwatson> well, you're a bit stuffed then aren't you ;-)
<cjwatson> unless you want to be creative and replace log-output and logger with things that write to files or something, but be careful with log-output's semantics
<ogra> well, we'll need a relatively big howto for babbage install anyway ...
<ogra> one part was to shut down syslog right at the start in beta
<ogra> post beta the kernel should be quieter
<mterry> Is http://summit.ubuntu.com/uds-karmic/interest/ working?  I registered on launchpad last week, but that page still says I haven't
 * slangasek applauds cjwatson's debian-policy madness
<ogra> can anyone remond me why casper removes the hwclock call on shutdown ?
<ogra> *remind even
<Keybuk> ogra: because you don't want a *Live CD* mucking around with the hardware clock of the machine it's into
<Keybuk> the entire point is that you can try Ubuntu without changing your computer
<Keybuk> last thing we want is "I tried Ubuntu, and my Windows clock is now wrong" types of bugs
<ogra> hmm
<calc> grr my disk is acting up again on my laptop, need to do a destructive disk test on it :\
<ogra> Keybuk, my prob on the babbage is that it has no battery to keep the clock ... the capacitor used only holds power for a very short time
<Keybuk> so it's not going to help you anyway
<ogra> well, it would if i could just reboot to have it right
<calc> at least now i get to play with the new security erase feature... easy way to write to all sectors to hopefully kick smart into fixing whatever is wrong
<cbr> hmm.. seems like Xorg is completely oblivious of KMS stuff going on.. the intel driver change log says that it's supposed to automagically enable UXA and everything should be dandy
<cbr> but it aint :(
<cjwatson> ogra: can you give me a one-line description of the computers that will run this imx51 image?
<cjwatson> ogra: like for plain armel, we say "For ARMv5t processors and above."
<ogra> i'm not sure we should mention the manufacturer ...
<ogra> its only running on the babbage boar atm
<ogra> *board
<superm1> slangasek, this is a recent regression, but since a lot of people generally use closed drivers, it wasn't caught until recently.  i think it has to either become release notes item for beta or beta get deferred. still haven't decided what's the better way to go about it
<cjwatson> ogra: I don't mind what we say, just need a description for the web site :-)
<ogra> yeah, i know ... but just "babbage board" might be to less
<slangasek> superm1: unless you expect a fix to be in the pipe by this weekend, I would certainly suggest the release notes option
<cjwatson> ogra: I can just say "iMX51 systems" or something
<slangasek> and even then, you'll be dealing with all of the suddenly-unfrozen stuff landing when you'd be trying to do your beta
<broonie> cjwatson: That's normally misleading, it'll depend very strongly on which i.MX51.
<ogra> cjwatson, there are more imx51 SoCs ... it will only run on the babbage
<superm1> slangasek, OK well i'll discuss with our folks more.  i mean there is the fix in the pipe of reverting those 3 patches, but probably do need to hear what upstream has to say about it before doing so
<broonie> cjwatson: Based on what ogra's just said how about "i.MX51 based babbage board"
<ogra> broonie, sounds good
<superm1> bryce, do you know if the author of those patches, Eric Anholt I think is on IRC at all?  i've not gotten any feedback on the upstream bugs or mailing list posts, so at least getting his opinion on the matter would be good i think
<cjwatson> ogra: http://cdimage.ubuntu.com/custom/20090325-armel+imx51/ should appear shortly
<ogra> cjwatson, i havemt confirmed the preseed fix yet
<cjwatson> ogra: that's OK, we can publish another one
<ogra> (and havent added the change to the script)
<ogra> ah, k
<ogra> thanks then
<cjwatson> please check that the HTML index is suitable
<seb128> re
<seb128>  ok, so how do I valgrind X? ;-)
<seb128>  valgrind doesn't like the X binary setuid
<ogra> that will make elmo happy, another 800M less on my home pn people :)
<ogra> *on
<seb128> slangasek, mdz: ^ any hint? ;-)
<mdz> seb128: just make it not setuid :-)
<mdz> and let gdm start it
 * slangasek nods
<mdz> seb128: slangasek provided a recipe in bug 328035
<ubottu> Launchpad bug 328035 in xorg-server "X server crash: *** glibc detected *** free(): in valid next size (fast)" [High,Fix committed] https://launchpad.net/bugs/328035
<seb128> mdz: I did follow the recipe and hit the setuid issue
<seb128> but I picked the wrong option
<slangasek> I overlooked the setuid part when I was writing the recipe blindly, sorry
<seb128> tried to set valgrind setuid which didn't work
<ogra> cjwatson, hmm, the cd burning guide surely doesnt apply to the .img :)
<seb128> hum
<ogra> cjwatson, the text from http://cdimage.ubuntu.com/ubuntu-netbook-remix/daily-live/current/ would fit better
<seb128> no luck valgrinding X, the log are almost empty
<cjwatson> ogra: feel free to edit directly on antimony
<cjwatson> cdimage/www/full/custom/...
<ogra> ok
<cjwatson> yeah, I should have remembered to copy from something mobile-shaped
<ogra> well, it technically isnt a USB image either
<ogra> i guess i need to write a SD card guide :)
<ogra> gah, the "detecting hardware" part in ubiquity makes my heart stop every time for a beat ... i always think the board crashed
<seb128> slangasek, mdz: I've something weird, the log got created and have the command which is ran
<seb128> but
<seb128>  2531 tty7     Rs+    0:43 X.copy :0 -br -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7
<ogra> (he barbershop animation in the progressbar gets stuck)
<seb128> not valgrind in the process list
<ogra> cjwatson, hmm, ubiquity failed again at the bootloader step ...could it be that the preseed option is ubiquity/configure_bootloader=false instead (or install_bootloader and configure_bootloader)
<BlackLukes> is there anyone who's active in ubiquity development?
 * ogra points BlackLukes to #ubuntu-installer
<cjwatson>         install_bootloader = self.db.get('ubiquity/install_bootloader')
<cjwatson>         if install_bootloader == "true":
<cjwatson> ogra: ^-
<ogra> yeah
<ogra> (i moved over to the appropriate channel btw :) )
<seb128> slangasek, mdz: is xorg supposed to start in a reasonable time under valgrind?
<seb128> when I "sudo valgrind X :1" it doesn't seem to do a lot, or it's taking ages
<directhex> am i right in thinking usplash is on death row, given kernel modesetting magicks?
<TheMuso> directhex: I believe it will be replaced by plymouth in karmic yes
<directhex> no point filing a "this sucks" bug of any kind, then?
<mrooney> "deprecated row" sounds a little nicer :)
<directhex> hm. is jono or jcastro about?
 * jono looks up
 * mrooney waves at jono
<directhex> jono, can we move to /msg?
<jono> directhex, sure
<jono> hey mr_pouit
<jono> oops
<jono> hey mrooney
<mrooney> jono: just waving at you, saying hello :)
<mrooney> I'd say good morning but it probably isn't for you
<pitti> james_w: got a minute to ponder bug 275432?
<ubottu> Launchpad bug 275432 in policykit "libpolkit requires files from policykit for polkit_context_init to work" [High,In progress] https://launchpad.net/bugs/275432
<pitti> james_w: my gut feeling is that we should't assume a default configuration if only libpolkit2 is installed
<pitti> james_w: I'd much rather fix CK itself to get along with PK not being available, and just act as if PK support wasn't compiled in in the first place
<pitti> james_w: i. e. continue to run, but disable the reboot/shutdown functions
<pitti> james_w: WDYT?
<Laney> how do I go about getting/using people.ubuntu.com hosting? Or is it for canonical types only?
<cjwatson> Canonical-only at the moment I'm afraid
<sladen> Laney: bug #149560 IIRC
<ubottu> Launchpad bug 149560 in canonical-website "Rename 'people.ubuntu.com'->'people.canonical.com'" [Undecided,Confirmed] https://launchpad.net/bugs/149560
<LordKow> that shouldnt be too hard considering all that needs to be done is switch the DNS info
<LordKow> same server as far as ping tells me
<LordKow> except there will be a lot of broken links which at first i forgot about
<LordKow> euw, okay nevermind. i go back to building vlc snapshots now.
<Laney> cjwatson, sladen: alright, thanks
<ScottK> mvo: Thank you very much for your python-central change.  I think that will clarify a lot.
<slangasek> seb128: I wouldn't promise 'reasonable time', no...
<seb128> slangasek: I stopped trying to get it working, it stays on an empty screen and valgrind is not listed in the processes list
<mvo> ScottK: cheers, I was suspecting that the reporting was not 100% reliable, now it should be better. I have a zope3 update pending for the other half of the bug, but want to have doko check the diff out before I go ahead with the upload
<\sh> guys, should tail -f <apache-logfile> occupy at least 100% of cpu while tailing the logfile when 6 clients are poking apache with 150 concurrent requests? the load goes up straight to heaven when tail is running...and top tells me that one core of eight is fully loaded with 100% work
<\sh> (no x included...just plain console)
<broonie> That doesn't sound entirely suprising.
<\sh> broonie: for me it was surprising
<broonie> The terminal app will be updating the screen as fast as it can possibly go.
<\sh> broonie: you are talking of the vt1-4 linux console...I thought it still pushes the bytes over irq <whatever> instead of painting the characters ,-)
<broonie> No, I was thinking of an X11 terminal application.
<\sh> broonie: as said, no x involved
<\sh> broonie: it's intrepid server (better: ubuntu-minimal meta)
<broonie> Though if it's a framebuffer rather than text console it's kind of the same deal.
<\sh> bah...now a beer for the magic kernel append param to disable framebuffer and just giving me the old text console
<\sh> sometimes life could be so easy fb=false will be my friend
<\sh> actually it helped a bit but still
<\sh> ok tail is not a good idea ... tail output enabled: load goes up to 5 without tail only 2 cores are fully busy...fun I love stress testing
<\sh> load without tail <= 2
<broonie> You're asking for an awful lot of I/O with tail - look at the volume of logging!
<\sh> broonie: that was just a sideeffect of initial setup testing ;) so tail is already forgotten
<james_w> pitti: that sounds sensible. It's not so much a problem now, except that it says "CRITICAL", when it isn't particularly.
<james_w> pitti: fixing policykit here is hard, so I think making consolekit more forgiving would be good.
<james_w> pitti: have you spoken to Michael about it? he has a pretty good grasp of the situation. I'm wondering if we shouldn't pull consolekit apart and create shutdownkit, which would seem to avoid some of this silliness
<directhex> not enough Kits
<james_w> in this case it is warranted I would say :-)
<tkamppeter> directhex, should I really rename Foomatic to PrintingKit :-)
<slangasek> I know there's a better pun hiding somewhere behind the name "ShutdownKit"
<directhex> tkamppeter, how much cash for such a rename?
 * directhex continues to insist the Kit thing is shamelessly ripped off from BeOS
<tkamppeter> Who is the copyright holder of "...Kit"?
<james_w> DavidKit
<directhex> tkamppeter, http://en.wikipedia.org/wiki/BeOS_API
<directhex> translation kit, now that was awesome
<rniamo> hi
<rniamo> i'm under jaunty and i have no sound (maybe because i have a intel hda soundcard) but i have no sound server (alsa, oss are not present, i have only the null driver of pulseaudio)
<calc> rniamo: which sound codec do you have?
<rniamo> sound codec ?
<rniamo> i'm not sure to understand
 * calc looks for the path
<calc> rniamo: something like /proc/asound/card0/codec#(number)
<rniamo> i don't have /proc/asound
<calc> oh i see :\
<calc> you apparently don't have alsa loaded at all
<calc> dtchen: ^ ?
<rniamo> i only have the null driver
<calc> i'm pretty sure even if it doesn't recognize your codec you should have that much of alsa loaded to see /proc/asound
<calc> so i am not sure what is wrong
<calc> TheMuso: you here? ^
<TheMuso> rniamo: what audio devices are listed when you run lspci? Please pastebin the result of your lspci output if you don't know what you are looking for exactly.
<rniamo> TheMuso : intel hda
<rniamo> 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
<calc> TheMuso: thanks for taking over :) i'm busy trying to unbreak my laptop atm :\
<TheMuso> ian_brasil: when you run lsmod, do you have snd_intel_hda loaded? Oh and what version of Ubuntu are you using?
<TheMuso> ion_: when you run lsmod, do you have snd_intel_hda loaded? Oh and what version of Ubuntu are you using?
<rniamo> no
<TheMuso> ian_brasil: sorry
<rniamo> i'm using jaunty
<TheMuso> rniamo: So no /proc/asound, and no snd related modules loaded at all?
<rniamo> yes
<rniamo> libsound and alsa are installed
<calc> rniamo: did you just now do a full jaunty install, and which *buntu did you install via?
<Errorist> greetings!
<TheMuso> rniamo: Could you please download http://www.alsa-project.org/alsa-info.sh, run it, and opst the URL you are given?
<rniamo> i ran alsaupdater and afterwards no driver
<Errorist> and what's the matter?
<TheMuso> rniamo: But could you please download the script I referred you to, and post the URL you get?
<rniamo> i'm doing it
<Errorist> got troubles with audio drivers/codecs?
<calc> Errorist: TheMuso is helping rniamo debug his system where no alsa drivers are loaded
<calc> doh
<rniamo> http://www.alsa-project.org/db/?f=e7fa52ff8e1582503adb189f865c39f1cdd2827 ... nothing ?
<slangasek> pitti: are you still planning to address bug #264336 in postgresql.conf for jaunty?
<ubottu> Launchpad bug 264336 in postgresql-common "pgsql fails to start due to shared buffer setting greater than kernel allows" [High,Triaged] https://launchpad.net/bugs/264336
<rniamo> ah, sorry : http://www.alsa-project.org/db/?f=e7fa52ff8e1582503adb189f865c39f1cdd28274
<TheMuso> rniamo: thanks looking
<johanbr> rniamo: "alsaupdater" ?
<rniamo> yes, il download tar.gz (alsa-driver/utils/ and another one) and compile it
<TheMuso> rniamo: according to this, you have 1.0.16 of libasound2-dev installed. Is your system completely up to date?
<calc> rniamo: oh so you mean you broke it yourself?
<rniamo> probably
<calc> rniamo: you get to keep both pieces ;-)
<rniamo> yes my system is up to date
<TheMuso> rniamo: have you built any modules against the kernel you have installed?
<calc> rniamo: so it worked until you manually rebuilt the parts with 'alsaupdater'?
<rniamo> TheMuso : non
<rniamo> calc : yes
<calc> TheMuso: is 'alsaupdater' something that is supported?
<TheMuso> calc: I don't even know what alsadata is.
<rniamo> i don't think
<calc> TheMuso: it appears he is saying he updated his alsa from tarballs and it broke
<TheMuso> Well thats not our problem.
<TheMuso> Because according to the kernel source, his machine is supported, and even has a quirk to make sure it works properly.
<calc> TheMuso: ok
<rniamo> in fact i wanted to install alsa from the source because i had drivers but no sound
<TheMuso> rniamo: Did you check your volume with alsamixer first?
<rniamo> yes
<rniamo> evrything was at 100% in alsamixer
<calc> rniamo: if you can get your system back into default state then TheMuso can probably get it working... but using tarballs there is no telling what is wrong
<rniamo> tarballs where offical alsa tarballs
<directhex> installing from tarballs is ~unzipping into c:\windows\system32
<calc> rniamo: yes but they probably don't match what we have kernel-wise, etc
<rniamo> well, can i install a deb to reinstall alsa driver ?
<rniamo> or reconfigure something ?
 * calc has no idea, TheMuso ? :)
<calc> well yea you can fix it but i don't know what all packages you would have to force reinstall
<TheMuso> rniamo: Ok what directories are in /lib/modules/2.6.28-11-generic?
<TheMuso> Its probably a matter of removing the newer modules from the kernel modules dir, running depmod -ae, and attempting to load the hda module.
<rniamo> build              modules.ccwmap       modules.isapnpmap  modules.symbols initrd             modules.dep          modules.ofmap      modules.symbols.bin kernel             modules.dep.bin      modules.order      modules.usbmap modules.alias      modules.ieee1394map  modules.pcimap     updates modules.alias.bin  modules.inputmap     modules.seriomap   volatil
<rniamo> initrd, kernel, updates, vlatile are directories
<TheMuso> whAT do you have in updates?
<rniamo> adm8211.ko       iwl3945.ko              libertas_tf.ko      rt2500usb.ko at76c50x-usb.ko  iwlagn.ko               libertas_tf_usb.ko  rt2x00lib.ko ath5k.ko         iwlcore.ko              libipw.ko           rt2x00pci.ko ath9k.ko         lbm_cw-cfg80211.ko      mac80211_hwsim.ko   rt2x00usb.ko b43.ko           lbm_cw-mac80211.ko      mwl8k.ko            rt61
<rniamo> dkms is a directory
<TheMuso> hrm I don't see any new alsa modules where I'd expect them to be...
<TheMuso> do a search for snd_hda_intel.ko in /lib/modules/2.6.28-11-generic
<TheMuso> so "find /lib/modules/2.6.28-11-generic -name snd_hda_intel.ko"
<rniamo> ok
<rniamo> nothing
<calc> so it removed the alsa that was there and didn't install a new one?
<rniamo> probably
<TheMuso> sorry thats because i gave you the wrong name
<TheMuso> it should be snd_hda_intel.ko
<rniamo> what's the difference ?
<TheMuso> that should be snd-hda-intel.ko
<rniamo> ok
<TheMuso> damn lsmod and using underscores, with modules having dashes in filenames.
<directhex> why IS that?
<directhex> i never worked out the point
<TheMuso> directhex: me neither. :p
<rniamo> nothing but : /lib/modules/2.6.27-9-generic/kernel/sound/pci/hda/snd-hda-intel.ko /lib/modules/2.6.27-11-generic/kernel/sound/pci/hda/snd-hda-intel.ko /lib/modules/2.6.27-7-generic/kernel/sound/pci/hda/snd-hda-intel.ko
<calc> directhex: to confuse people better :)
<cjwatson> you can modprobe using either style, of course
<directhex> i see an obvious solution
<TheMuso> rniamo: Well if you installed from the alsa-driver tarball, I don't know what the problem is, but all I can suggest is you re-install linux-image-2.6.28-11-generic: "sudo apt-get --reinstall install linux-image-2.6.28-11-generic"
<directhex> fork "find" to match - or _ interchangably
<rniamo> ok, i'll try
<rniamo> do i have to reboot after or not ?
<TheMuso> rniamo: probably not, just try "sudo modprobe snd-hda-intel"
<rniamo> the ko is here :)
 * calc wishes ata security erase had a way to monitor progress
<rniamo> alsamixer is back :):)
<TheMuso> rniamo: BUt still no sound?
<rniamo> i'm looking for some sound
<directhex> ehm
<directhex> if i might make a suggestion
<TheMuso> rniamo: try /usr/share/example-content/
<bryce> superm1, yes, 'anholt' is on the #xorg-devel channel on this server.  I think there is also an intel X channel he's active on.
<rniamo> ok
<TheMuso> directhex: And your suggestion is? :)
<directhex> in alsamixer, do you see any controls named something like "IEC958"?
<directhex> it'll be a little toggle, i.e. have no volume knob
<TheMuso> directhex: ah right
<directhex> mute/unmute it (i.e. change its current value)
<TheMuso> afaicr thats not set by default
<bryce> superm1: sorry I'm laggy in responding; I took today off so have been afk
<directhex> TheMuso, some mobos the default is digital
<TheMuso> directhex: ah
<directhex> TheMuso, hence "toggle" not "disable"
<TheMuso> yep
<rniamo> in alsamixer how do i save settings ?
<rniamo> esc ?
<directhex> yes
<rniamo> because master is to 0%, i set it to 100 then i retype alsamixer and master is to 0
<TheMuso> hrm
<TheMuso> rniamo: try rebooting and changing alsamixer settings again, something is probably trying to change sound settings while you are...
<TheMuso> c
<rniamo> ok, i'm coming back ;)
<TheMuso> ok
<rniamo> re
<rniamo> TheMuso : i reboot and everything is at 100% ... and i hear no sound
<rniamo> http://mibbit.com/pb/rk9Lbk is my codec
<TheMuso> rniamo: if you go into alsamixer, change the master, exit, and go back in again, is it back to 0?
<rniamo> no
<TheMuso> ok thats good
<rniamo> it's work after a reboot, but i hear no sound
<TheMuso> rniamo: ok please run http://www.alsa-project.org/alsa-info.sh again and give me a URL. I also suggest you file a bug against linux, and give me the bug number with the alsa URL included in the report.
<rniamo> http://www.alsa-project.org/db/?f=2e77d90e8b79ab301e5c353a49e752185875f8eb
<rniamo> file a bug ?
<calc> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/318942
<ubottu> Ubuntu bug 318942 in linux "no sound from speakers on HP Mini 1000 (hda-intel, IDT 92HD75B2X5)" [Undecided,New]
<calc> rniamo: does headphones work for you?
<directhex> 3stack
<directhex> hm
<rniamo> i'll try headphones
<directhex> rniamo, how many audio connections do you have on the back of your motherboard?
<calc> the only google hits i get for his audio codec are problems, heh
<directhex> looks a bit likt eh codec on my laptop
<rniamo> only one connection, it's a hp mini compaq
<directhex> so it IS a laptop
<calc> rniamo: ah so it is probably the same bug i referenced above
<calc> the bug is about the hp mini 1000 netbook
<calc> it appears alsa 1.0.19 might fix this issue
<calc> according to the bug report
<directhex> sigh, usplash depresses me
<rniamo> ok but to install it , it must be compiled, no ?
<calc> rniamo: that was more a comment to TheMuso :)
<calc> rniamo: see if the headphones bit works for you
<slangasek> calc: what's the current story for OOo on sparc?
<slangasek> it's the only package attached to a couple of the NBS packages
<calc> slangasek: almost always ICEs for Ubuntu... works on Debian (has been this way for years)
<rniamo> headphones doesn't work
<calc> slangasek: i'm not sure if it is a buildd issue or a toolchain issue though
<directhex> my laptop has an IDT 92HD71B7X
<directhex> close but no cigar
<slangasek> calc: "almost always"?  So we fix this by randomly retrying until it sticks, or what?
<slangasek> currently it's a full major version behind
<slangasek> well, "major"
<calc> slangasek: dunno maybe 10% of the time it seems to build
<calc> slangasek: i probably should fix OOo to not build on sparc and then have the packages removed for it
<slangasek> I guess so :(
<directhex> the sad fact is, sun just don't seem to understand sparc enough for OOo to work properly ;)
<calc> if someone with more sparc toolchain experience wants to look into it they can, it works fine on Debian so i'm not sure why it dies for us
<calc> directhex: its either a toolchain bug or the buildd
<calc> directhex: it works fine on Debian
<calc> directhex: ICEs are not the software that is being compiled fault
<rniamo> do i have to change model afterwards options snd-hda-intel ?
<directhex> rniamo, tinkering with model= can sometimes help. what does calc's bug say?
<slangasek> calc: what is bug #271283 a regression relative to?
<ubottu> Launchpad bug 271283 in openoffice "[ooo-build] OpenOffice.org subpixel font rendering broken with new cairo" [Unknown,Confirmed] https://launchpad.net/bugs/271283
<calc> the bug i see is about 2.6.28-4 i386 that claimed at that point to work with headphones
<slangasek> (I don't think 'regression' is one of the standard tags QA tracks; we use 'regression-potential' or 'regression-release')
<calc> slangasek: ah i didn't know what the right tag was, it worked fine in Hardy but does not work anymore
<slangasek> so if it was also broken in intrepid, 'regression-release' is the right tag
<slangasek> calc: https://wiki.ubuntu.com/QATeam/RegressionTracking, for reference
<calc> it was broken with a new upload of cairo shortly before intrepid release
<calc> ok updated tag
<rniamo> how could i do after changing model to load it without a reboot ?
<TheMuso> rniamo: one more thing to try is to do "sudo apt-get --reinstall install libasound2-dev libasound2"
<TheMuso> rniamo: since you appear to only have 1.0.16 of the libraries
<slangasek> calc: thanks
<TheMuso> rniamo: then try logging out and back in, to see if you get sound
<TheMuso> rniamo: try my suggestion first, before trying the model option.
<rniamo> ok
<rniamo> before logging out i have a little question : why under jaunty ctrl+alt+backspace doesn't work ?
<TheMuso> rniamo: its been disabled for jaunty. Someone else can point you to the explanation, I don't know where to find it atm.
<rniamo> ok
<lool> I'd love someone with a taste for python to review the proposed patch at https://bugs.launchpad.net/ubuntu/+source/python-debian/+bug/339466
<ubottu> Ubuntu bug 339466 in python-debian "cron.weekly script produces a warning since the Python 2.6 transition" [Undecided,New]
<rniamo> i'm logging out and i'm coming back
<rniamo> re
<rniamo> TheMuso : http://www.alsa-project.org/db/?f=528ed8b854877742974fb68716bac751a50267e3 it's better but still no sound
<TheMuso> rniamo: ok then either add a comment to the bug calc referred you to above, or if you think your situation is different, consider filing a new bug. Also try different model options./
<rniamo> this is strange : http://mibbit.com/pb/5mHOPc
<dtchen> you're not in the audio group
<dtchen> also, you should try the appropriate test kernel from http://kernel.ubuntu.com/~dtchen/
<dtchen> i believe i've already pulled the necessary fix for the HP Minis
<rniamo> i'm in the audio group
<cjwatson> calc: the other thing that might differ between us and Debian is compiler flags
<rniamo> dtchen : i don't understand what are this deb ?
<cjwatson> though actually I think our default compiler flags are the same as Debian's, so it would just be if the openoffice.org source sets them differently
<calc> cjwatson: i'm pretty sure we don't differ significantly there in OOo rules
<dtchen> rniamo: you need this changeset: http://kernel.ubuntu.com/git?p=dtchen/ubuntu-jaunty.git;a=commitdiff;h=9797e05d142312ec0f4a8a0fd66d68bf4555b942 , which is in my debs. (my debs also contain hw_ptr fixes for PulseAudio, but that's a separate issue)
<rniamo> ok, i'm trying
<rniamo> i suppoe i have to reboot ;)
<rniamo> suppose
<dtchen> well, yes
<greg-g> heh
<rniamo> si let's reboot ;)
<dtchen> rniamo: please follow up with me in #ubuntu+1 if you have issues, as this symptom is not specific to Ubuntu development. Thank you.
<rniamo> re
<rniamo> headphones work !!!!!!!!!
<rniamo> but not front
<cjwatson> calc: in general, the first thing to experiment with for ICEs does seem to be optimisation levels, if only because it usually significantly helps to localise the compiler bug
<cjwatson> obviously you'd want to reduce it down to something resembling a small test case first, unless you want it to take all year
<calc> yea
 * calc wonders how much ubuntu sparc compiler differs from debian's
<cjwatson> gcc-4.3 (4.3.3-5ubuntu1) jaunty; urgency=low
<calc> its been fairly consistent at ICEing over the past couple years
<cjwatson>   * Merge with Debian; remaining changes:
<cjwatson>     - Built from upstream tarball, regenerate the control file.
<cjwatson>     - On armel, configure using --with-arch=armv5t --with-tune=cortex-a8.
<cjwatson>  -- Matthias Klose <doko@ubuntu.com>  Sun, 01 Mar 2009 17:06:09 +0100
<cjwatson> so I would say not hugely ...
<rniamo> dtchen : does your patch work for front speakers ?
<cjwatson> getting a small test case will help a lot, I should think
<calc> cjwatson: yea, i'll see if i can find a way to reduce it to a test case
<dtchen> rniamo: depends whether you booted with or without them plugged
<rniamo> dtchen : well, can you explain me a little bit more please ?
 * calc hopes running the security erase helped to remap his bad sectors or fix whatever else was wrong with the drive
<dtchen> rniamo: i'm happy to discuss in #ubuntu+1
<rniamo> ok
<LordKow> gnome-settings-sound.desktop from capplets-data and gnome-volume-control-settings.desktop from gnome-volume-control-pulse both have the name "Sound" :-/
<seb128> LordKow: right they are the GNOME 2.24 and 2.26 equivalent softwares
<seb128> LordKow: you are not meant to use both and only one is installed by default
<LordKow> seb128, capplets-data: Candidate: 1:2.26.0-0ubuntu1, gnome-volume-control-pulse: Candidate: 2.26.0-0ubuntu2 :-/ they are not the same and provide different options/settings
<seb128> LordKow: ...
<seb128> LordKow: as I said they are the GNOME 2.24 and 2.26 equivalents
<seb128> LordKow: the 2.26 variants works only on pulseaudio and pulseaudio just doesn't work for many users so we didn't want to hard depends on it
<LordKow> ah okay.
<seb128> LordKow: so we use the 2.24 tools which work with alsa only too and have the pulse variant available for those who really want it
<LordKow> and with that being settled... time to boot a test kernel.
<rniamo> dtchen : it doesn't work
<dtchen> rniamo: remove the quirk altogether, then
<rniamo> i try with hp-m4 and without options snd-hda-intel model=xx
<dtchen> rniamo: i will follow up in the bug report; i'm very busy ATM
<rniamo> it is not urgent, thanks for your help
<rniamo> where could i look to know if it an update will correct it ?
<dtchen> rniamo: i will follow up in the bug report named above (318942)
<rniamo> ok, thank you very much
<rniamo> dtchen : i've installed als-driver 1.0.19 = everything is ok :D
<rniamo> TheMuso : will alsa-driver 1.0.19 be included in next kernel ?
<TheMuso> rniamo: no
<TheMuso> alsa 1.0.19, or even alsa 1.0.20 will be in Karmic.
<rniamo> and for jaunty it will be "only" 1.0.18 ?
<TheMuso> yes
<TheMuso> but with some fixes pulled from 1.0.19
<rniamo> ok. becase 1.0.19 works fine
<rniamo> becase sorry
<rniamo> because
<rniamo> good night everybody, see you.
#ubuntu-devel 2009-03-26
<calc> anyone object to me doing bug 299161 for after beta?
<ubottu> Launchpad bug 299161 in memtest86+ "RFE : Please upgrade to Memtest86+ 2.11 (Jaunty)" [Wishlist,Triaged] https://launchpad.net/bugs/299161
<calc> if possible anyway, it adds support for a lot of newer chipset (including mine)
<slangasek> I hope that throw-away comment on IRC isn't meant to pass for a freeze exception request :)
<calc> no just wanting to make sure there wasn't any obvious objection before i file for a freeze exception
<calc> i noticed it in particular due to needing to find out why my laptop is dying
<slangasek> calc: when preparing the request, please do a test build and let us know how the package size compares with the current version, since this is a package that goes on all CDs
<calc> slangasek: ok will do
<calc> its already packaged in debian but we have a changeset to merge, i should have something available by tomorrow (barring any more hardware failures)
<CodyT07> hey
<Hobbsee> greetings
<CodyT07> hope u dont mind, where can i start on learning how to be an ubuntu developer?
<CodyT07> im strongly curious on how u guys make this awesome os
<cjwatson> http://wiki.ubuntu.com/ContributeToUbuntu http://wiki.ubuntu.com/UbuntuDevelopment
<cjwatson> ha. bug 338788 is an excellent demonstration of how including helpful features can make problems harder to debug
<ubottu> Launchpad bug 338788 in newt "can't enter polish character in jaunty alpha 5 netinstall" [High,Confirmed] https://launchpad.net/bugs/338788
 * slangasek sighs.  Yes, opening display preferences causes the intel driver to generate log messages... so don't launch it when in the middle of drafting the technical overview when X has been running for > 28h. :/
<cjwatson> that really is an embarrassing bug
<CodyT07> one more question, pyhton the language to learn?
<Snova> Yes.
<CodyT07> much appreciated
<Snova> If you have prior programming skills, it is used in many places in Ubuntu; if you don't, it is a good language to begin with.
<cjwatson> CodyT07: Python is one possible language to learn which is likely to come in useful, but Ubuntu developers need to work with several languages on a day-to-day basis
<cjwatson> CodyT07: so my advice is to stay flexible
<CodyT07> i try, languages arent exactly my 'thing'  but i give it a try
<cjwatson> the language you'll find yourself working in most depends very much on what your "thing" is
<CodyT07> im better at finding answers to a sitatuion. E.g debugger
<CodyT07> i cant write anything in php. but if something is broke i am usually good at finding what it is
<calc> anyone else seen weird graphical issues on intel video on jaunty amd64 (today's cd)
<calc> i'm not sure if it is a sign of my laptop dying or bugs somewhere
<calc> i was getting graphics corruption and fonts not displaying in the right color (seemed to be background color)
<nixternal> are we in freeze right now, or do we have a bit of time left? like say a few more hours?
<cjwatson> we have been in beta freeze for some days
<cjwatson> see ubuntu-devel-announce@
<cjwatson> what is the problem?
<nixternal> string freeze is today/26th
<nixternal> odd that it sould be the same day as the beta release
<nixternal> s/sould/would
<cjwatson> if in doubt, drop a mail to the translators/documenters list s
<cjwatson> lists
<nixternal> oh well, I will just wait until after beta release to upload the kubuntu-docs...nothing life threatening
<calc> when i reinstalled my laptop i used gpt, seems to work nicely with grub :)
<doctormo> Does trackerd have an irc channel? or a place where developers go?
<crdlb> doctormo: #tracker on gimpnet perhaps
<slangasek> zul: could you please have a look at Debian bug #521225 for jaunty?
<ubottu> Debian bug 521225 in samba "samba: mishandling of mapped read-only attribute causes failed profile sync" [Critical,Open] http://bugs.debian.org/521225
<dholbach> good morning
<DanMcGoo> Hi
<DanMcGoo> I am trying to build my first debian package and I got some little problem
<DanMcGoo> Someone can help me ?
<RAOF> #ubuntu-motu is a better channel for that.
<DanMcGoo> ok thanks
<pitti> Good morning
<pitti> james_w: problem> it still is, since it causes CK to exit, and thus CK doesn't work at all
<pitti> james_w: shutdownkit> yes, nobody except William particularly liked this functionality in CK in the first place for this reason; and hal == shutdownkit, too
<pitti> slangasek: 264336> I plan to do something about it in jaunty, yes; either by handling the failure more gracefully at install time, or creating more dynamic defaults. however, I want to consult with upstream about this first
<slangasek> pitti: ok (morning)
<pitti> slangasek: I'm confused; nvclock doesn't build a smartdimmer package, nor does the nvclock binary ship it
<slangasek> pitti: correct, that will happen with the next upload of nvclock - it couldn't happen before the MIR was approved
<slangasek> because smartdimmer is already in main, from a different (obsolete) source
<pitti> ah, it's stil in the sponsoring queue
<slangasek> no, it's in the "Steve isn't uploading this because he doesn't want it accidentally accepted into main because it looks like a universe package" queue
<pitti> slangasek: seems we shuold remove the smartdimmer source from the archive then?
<pitti> the only other (except hal) rdepends is acpi-support
<slangasek> yes, but not during the freeze...
<pitti> and I guess that should be obsolete
<pitti> slangasek: right, just planning
<pitti> I won't move nvclock to main either
<pitti> I just saw the MIR approval
<slangasek> FWIW, I have a handle on this on my end and am ready to push the buttons once beta is out
<ogra_> slangasek, do you have any idea what tool cjwatson used to copy my babbage image in place ?
<slangasek> ogra_: other than 'cp'?  no
<ogra> well, its owned by cdimage
<ogra> and only writeable by the user
<slangasek> is that unusual?
<ogra> i'd like to do one update (there was one preseed option added to the cmdline, its tested and ok, but i cant copy the img (while i can edit the html in the dir)
<slangasek> probably 'cp', in any case
<ogra> i'm not the cdimage user :)
<slangasek> do you not have sudo access?
<ogra> i'm only in its group
<ogra> i cant sudo to cdimage, it asks for a pw
<ogra> tried that already indeed
<slangasek> ok, I'll change the perm to match the other files
<ogra> thanks
<slangasek> done
<ogra> hmm, now the dir name doesnt match anymore indeed ...
<ogra> can i just mv it from 25 to 26 ?
<ogra> ugh, and the md5sum might not ... sigh
<ogra> slangasek, i think we need to wait for cjwatson here, i dont feel safe poking around there on my own
<pitti> james_w: hm, I looked deeper at the PK code, and it already does the right thing if the context is NULL, or the .conf file is absent
<pitti> james_w: if we could fix this robustly in PK, then it would apply to all apps, not just CK
<pitti> well, I'll play around with this a bit
<Meiz_n810> what is the stage of plasma-mid?
 * Meiz_n810 wants to try it on his n810, and wonders when it will be available :P
<pitti> seb128: nice, amd64 retracer caught up, i386 almost
<seb128> pitti: ;-)
<seb128> you rock!
<Kano> hi, is the dkms maintainer here?
<pitti> Kano: that's superm1
<Kano> ic
<tjaalton> asac: hey, I've got issues with an Option GE0301 3G card, it refuses to connect (hso_auth_done(): Authentication failed). Should I blame the kernel?-)
<asac> tjaalton: so you are not using networkmanager? ;)
<asac> or you are not running latest jaunty ;)
<asac> tjaalton: is that a regression?
<tjaalton> asac: using NM, current jaunty
<tjaalton> I've never used the device before
<tjaalton> had to use ozerocdoff to make the driver work at all
<tjaalton> I'll grab the 2.6.29 vanilla deb to see it it's any better
<asac> tjaalton: yes. please check that
<Kano> tjaalton: did you try to compile current karmic git
<tjaalton> Kano: no, it's the same upstream version
<tjaalton> asac: still the same :/
<asac> tjaalton: whats the product/vendor id of that modem?
<tjaalton> 0af0:7011
<Kano> tjaalton: with fixed aufs at least the generic kernels work in live mode. you only need a squashfs-tools cvs package for newer mksquashfs
<Kano> i could not get the server kernel to compile
<tjaalton> uh
<tjaalton> I'm not interested in aufs
<Kano> you dont need live mode ;)
<tjaalton> correction, I don't need aufs :)
<Kano> what do you want to use instead
<soren> Kano: I think tjaalton's point is: Why are you telling him about aufs?
<tjaalton> right..
<soren> I'm wondering the same thing, incidentally.
<Kano> so what do you use instead of aufs in case you want to create a live image
<tjaalton> I've no need to create a live image
<rniamo> hi
<rniamo> is it normal that xorg use 90% of cpu unit ?
<rniamo> 3125 root      20   0  417m  60m  24m R   84  6.1  69:52.53 Xorg
<tjaalton> perfectly normal
 * tjaalton runs for lunch
<rniamo> why ?
<tjaalton> it's probably doing something really important
<rniamo> always ?
<tjaalton> running compiz
<tjaalton> ?
<rniamo> yes
<rniamo> but usually it's work normally
<tjaalton> try not to
<tjaalton> or just file a bug.. 'ubuntu-bug xorg-server'
<rniamo> without it's ok but ... it is withou
<tjaalton> maybe your driver doesn't support some of the fancier effects, and it's falling back to software rendering
<rniamo> ok
<tkamppeter> pitti, hi
<tkamppeter> I am trying to merge the Intrepid CUPS branch back into my branch with LP, but I did not find out how to do the actual merge. I have posted a merge request and approved it, but the merge does not happen.
<Laney> tkamppeter: while in the base branch you do bzr merge <target>
<pitti> hi tkamppeter
<pitti> tkamppeter: as I mailed you, please just "pull", that'll clean up history
<pitti> tkamppeter: the merge won't happen automatically, you need to manually do this
<pitti> tkamppeter: a merge request in LP is someone else asking *you* to review and merge their branch into your's
<pitti> tkamppeter: the thing you mean is called "PQM" (patch queue manager), but we don't use that for most projects
<cjwatson> ogra: so what did you do to custom/20090325-armel+imx51? The timestamp of the image seems to have been updated
<cjwatson> ogra: hmm, and it now matches the one currently in your home directory
<cjwatson> (yes, I read scrollback)
<ogra> cjwatson, yeah
<cjwatson> ok, you generally shouldn't ever change existing files on cdimage
<ogra> but i didnt know what to do for the MD5SUM
<ogra> oh, ok, you said i should edit the html just there
<cjwatson> html fine, but not images
<ogra> ok
<cjwatson> I've moved it to 20090326-armel+imx51
<ogra> thanks
<cjwatson> that'll fix up any mirrors of cdimage that have got confused
<ogra> have you seen bug 348660 ?
<ubottu> Launchpad bug 348660 in ubiquity "ubiquity unsets ubiquity/install_bootloader=false at some point during installation" [High,Confirmed] https://launchpad.net/bugs/348660
<cjwatson> I've also updated MD5SUMS and MD5SUMS.gpg
<ogra> thanks as well
<cjwatson> no, I had a really late night and am just getting started
<ogra> while emmets fix is good, i think there is still some issue with the logic for ubiquity/install_bootloader=false
<cjwatson> I'll look at it
<ogra> thanks
<cjwatson> as Emmet says the real fix is to have a proper bootloader installer component in ubiquity
<ogra> indeed
<ogra> thats fine, but ubiquity/install_bootloader is a boolean so imho "if not (automatic_mode and install_bootloader):" is wrong
<ogra> i'm never in automatic mode by default, so automatic_mode is unset (i guess None)
<ogra> if i define  ubiquity/install_bootloader=false thats translationg to: "if not (None and False):"
<ogra> which in the end turns true
<ogra> which in case where you dont have a system that uses grup will automatically set  ubiquity/install_bootloader=True
<ogra> *grub
<ogra> making the user end up with the exact opposite he selected through preseeding
<persia> ogra, It's *not* wrong.  That's the expected behaviour with preseeding ubiquity if you aren't in automatic mode.
<persia> Mind you, the logic could be a bit nicer, and have some interaction, but that's a separate issue.
<ogra> persia, setting UBIQUITY_AUTOMATIC in /etc/profile ... doing a relogin got me the exact same behavior though
<persia> Hrm!  If you *are* in automatic mode, it should respect the preseed.
<ogra> it doesnt, it still moves on to the function and dies there
<cjwatson> ogra: the point is basically that install_bootloader wasn't really designed for preseeding, but for internal use by ubiquity. Given that, nitpicking its logic is a bit pointless
 * Mithrandir twiddles thumbs as he upgrades his laptop to jaunty.
<ogra> cjwatson, ah, well, we have a proper fix, its just confusing behavior imho ... i doubt i'll ever use it again anywa
<ogra> y
<persia> ogra, My hack is *not* a proper fix.
<persia> I've branched flash-installer, and will look at a proper fix, but it's not going to use "pass".
<ogra> your hack is 80% of the proper fix we have to do in ubioquiry
<ogra> *ubiquity
<seb128> is anybody working on openchange in ubuntu?
<seb128> bug #338982 is a frequent evolution-mapi crasher
<ubottu> Launchpad bug 338982 in openchange "evolution crashed with SIGSEGV during MAPI authentication" [High,Confirmed] https://launchpad.net/bugs/338982
<seb128> supposed to be fixed in openchange and libmapi 0.8.2
<persia> ogra, No, it's not.  It's about 3%.
<cjwatson> ogra: your percentages are different from mine
<ogra> persia, the rest is copy paste from one of the above functions and adjusting the binary name
<cjwatson> perhaps because I have actually implemented this stuff before
<cjwatson> ogra: I've done this before. Trust me
<ogra> i do :)
<persia> ogra, The majority of the work is making flash-kernel-installer not expect that the udeb postinst will be run, and still working.
<ogra> thats nothing you have to do in ubiquity
<persia> Beyond that, it's just creating a FilteredComponent to drive it, and then, yes, just a quick change to install.py
<ogra> right, thats what i'm referring to
<cjwatson> it might as well be in ubiquity. ubiquity has to incorporate flash-kernel if it's going to use it like this.
<ogra> i agree that we have to do massive changes to flash-kernel-installer but thats not beein in my scope
<ogra> *been in
<persia> Indeed, and flash-kernel needs to be investigated to make sure that it's compatible with the way ubiquity is built.
<ogra> no, flash-kernel wont be touched by ubiquity
<persia> Yes it will.  That's how ubiquity works.
<ogra> its either run by flash-kernel-installer directly or only from the linux-image postinst as its done on all other armel platforms
<cjwatson> persia is correct
<persia> The flash-kernel-installer is created from the flash-kernel package.  The flash-kernel package will need to be split, or it will need to be embedded entire within ubiquity.
<ogra> why would we change its default behavior ?
<cjwatson> there's no need to split it
<persia> (this is because udebs are not installed during a live install).
<persia> cjwatson, That's good news.  I hadn't tested a build yet.
<persia> ogra, Because right now flash-kernel-installer is 90% postinst, and we're not going to run the postinst.
<cjwatson> you just arrange for that bit of d-i/source/ to be built only on armel. There are list files for this
<ogra> flash-kernel-installer needs to dump redboot in place with the proper offset and then call flash-kernel (which is anyway done by the linix-image package)
<ogra> *linux
<persia> cjwatson, I was more concerned about not wanting to include the contents of the flash-kernel package, but just the flash-kernel-installer udeb, and then add flash-kernel to bootloader-depends.
<cjwatson> persia: sounds like makework to me
<ogra> if we change flash-kernel-instaler that massively we should probably just do a new script
<persia> ogra, That's not what flash-kernel-installer does at all.
<cjwatson> persia: I have a fix for the preseeding logic in bug 348660. Do you want to keep that bug open for the flash-kernel work, or shall I just close it?
<ubottu> Launchpad bug 348660 in ubiquity "ubiquity unsets ubiquity/install_bootloader=false at some point during installation" [High,Confirmed] https://launchpad.net/bugs/348660
<ogra> persia, but thats what we need (additional to the kernel-img.conf work it already does)
<persia> cjwatson, Feel free to just close it, if you're changing the logic.  The stuff I was looking at is easily separable.
<cjwatson> persia: there's actually nothing necessarily wrong with just running the postinst, is there?
<cjwatson> it looks a plausible enough approximation to what we'd need to run
<persia> cjwatson, I haven't dug in much, but I renamed the postinst to flash-kernel-installer, added a postinst that called that, and installed it with an install, which gives us /usr/bin/flash-kernel-installer
<ogra> right, it just needs to grow something that dumps redboot in place ... and if its a call to an additional redboot-install script or something
<ogra> the rest can go as is
<persia> I thought that would be easier to trigger from FilteredCommand.
<cjwatson> persia: that sounds unnecessary. See the stuff in debian/rules that handles {kboot,yaboot,silo}-installer
<cjwatson> all you need to do is install the postinst under /usr/lib/ubiquity/ somewhere
<persia> cjwatson, Oh, I see.  Indeed, that would be simpler.
<tkamppeter> pitti, thanks, then it seems that "Request Merge" is simply a messaging system between the two branch owners and nothing to do web-interface controlled operations on the branches.
<pitti> tkamppeter: exactly
<cjwatson> I think I'll leave the bug open after this preseeding work since it does actually appear that most of the work belongs in ubiquity
<tkamppeter> pitti, branch is merged back now. Thanks.
<zul> slangasek: done
<cjwatson> ogra: so given that preseeding doesn't work, what are we doing about the image? Are you applying persia's quick hack to your image for the time being?
<ogra> well, its not doing any harm (since its teh very last step anyway), i just noted it on the wiki
<cjwatson> no, it is not the very last step
<ogra> well, before the reboot message which users need to ignore anyway to set the bootloader
<cjwatson> after boot loader installation comes: installing any additional required packages (e.g. language packs); removing packages that are not required (e.g. the installer itself); copying log files; and a few other bits and pieces
<ogra> not here
<cjwatson> I'm looking at the damned code
<ogra> my langpacks get installed, removal is done
<ogra> weird
<ogra> i had all that
<cjwatson> well, I don't know how on earth you can possibly have that
<cjwatson> that stuff is clearly after configure_bootloader
<ogra> very weird
<ogra> well, i'm not sure how to apply that fix from my script since i cant access the squashfs
<cjwatson> you might just have to copy it off to another machine where you have root
<ogra> or squashfs-tools
<ogra> hmm
<cjwatson> oh, I could RT that
<ogra> that would be cool
<ogra> seems helpful to have on antimony anyway
<cjwatson> RTed and asked #is
<maxb> Who can I chase up a problem with paste.ubuntu.com with, after mailing rt@ubuntu.com resulted in no response?
<highvoltage> ask in #canonical-sysadmin
<cjwatson> ogra: 12:25 <agy> cjwatson: done
<ogra> thanks :)
<ogra> i'll look at the script after the meeting
<cjwatson> ogra: careful though, do armel and amd64 have the same endianness? can you in fact safely build a squashfs for the former on the latter?
<ogra> no idea, i'll try it
<cjwatson> ogra: ISTR that squashfs' format is independent of the creating architecture but I know this changed a while back and I can't remember the direction in which it changed
<cjwatson> mksquashfs has -le and -be options in case you need to override it
<ogra> ok
<directhex> amd64 is little endian
<pitti> seb128: ah, tail of  apport-retracer-amd64-hardy/log_dupcheck.txt is music in my ears :)
<pitti> seb128: however, it seems that invalid bugs just account for half of the slowness; I'll track this down further this afternoon then
<pitti> seb128: seems some bugs like bug 332378 don't have a coredump and no needs-*-retrace tag
<ubottu> Launchpad bug 332378 in miro "miro.real crashed with AttributeError in handle_play_movie()" [Undecided,New] https://launchpad.net/bugs/332378
<pitti> weird
<lool> ogra: I don't think flash-kernel should install redboot
<lool> cjwatson, persia: poke
<lool> cjwatson: So basically we're abusing flash-kernel
<ogra> lool, thats why i proposed a redboot-install script
 * cjwatson would like to hear the problem statement before the solution proposal
<lool> cjwatson: the board has this special behavior that it will run redboot from SD and have a flash directory in SD, while it's usually in soldered on flash
<ogra> but being called by flash-kernel-installer
<lool> cjwatson: There's a switch on the board; either you boot from soldered internal flash (which is tiny so not an option anyway for now) or you boot from SD (what we do)
<lool> cjwatson: Now problem is that we're starting an install from SD and we would like to offer an installed system in the end; but usually we don't overwrite the install media
<lool> So we had multiple options; one is to ask for an USB SD reader and install on another SD as the target, but this also requires installing redboot and special hardware
<ogra> which we need to do in this case to get something like a lilo bootfloppy
<lool> The option we're currently aiming at is to install the target kernel and initramfs on the install medium: the SD, hence erasing the ones from the installation live SD card
<lool> cjwatson: (does that make any sense until now?)
<liw> in /proc/mounts, should the kernel encode mount options that contain spaces? (ref. https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/112272)
<ubottu> Ubuntu bug 112272 in update-manager "ValueError: too many values to unpack (DistUpgradeControler.py stack trace)" [Medium,Confirmed]
<lool> cjwatson: Now if we try to fit flash-kernel in this picture, it's usually meant to write to mtd devices; I changed it to use dd and fis to write to specific offsets of a hardcoded /dev: the SD cards
<lool> cjwatson: It's ugly at various levels, one being that we shouldn't hardcode that /dev in flash-kernel itself IMO
<lool> That's one issue
<mvo> liw: that would be nice indeed - I think this problem is "fixed" in the code in u-m, it will ignore lines it can not parse
<ogra> we could just rip your changes out of flash-kernel and stick it into a redboot script
<lool> Another issue is that we need to pass the initramfs size in the bootscript launching the kernel, the redboot bootscript, and update it when it changes
<liw> mvo, oh right, I meant to say that, too
<ogra> it could well be its own
<lool> cjwatson: I think this can be solved more elegantly, I'm reluctant to let flash-kernel parse and update the bootscript on each upadte-initramfs update
<ogra> but we're to late to fix it differently imho
<lool> Finally, there are two side issues which I'd better mention: it seems flash-kernel is sometimes called before the initramfs has been generated (discussed in debian in the past I think) due to triggers, and the other is that we need a redboot udeb if we want to support installation into a fully bootable SD card
<cjwatson> lool: I tend to think that introducing a new component is going to be more trouble than it's worth, and if it can be crowbarred into flash-kernel in a way that isn't completely unreasonable, we should do that
<mvo> liw: yep, just confirmed
<liw> mvo, me too; alas, I'm not sure that makes it OK to close the bug, since perhaps it should be reassigned to the kernel
<mvo> liw: right, I agree
<mvo> liw: I wonder what mount does in this case
<liw> mvo, does mount parse /proc/mounts? and not /etc/mtab?
<lool> cjwatson: Ok; I didn't really consider a new component so far; I had in mind that perhaps we should have a flash kernel config for the /dev hardcoding issue, and a redboot udeb -- that qualifies as a new component -- if we care about installing to a SD card, but it's harder than just redboot
<cjwatson> lool: redboot-udeb in itself would be rather trivial; it would basically just ship the binaries, right?
<lool> cjwatson: Basically, a sense of taste is welcome for the current flash-kernel hacks we're doing, and we also need help on the initramfs size issue
<mvo> liw: I would have to look at the code to know that :)
<lool> cjwatson: No, I had in mind that it would allow installation of redboot at the right place on a SD card
<cjwatson> lool: the installer integration logic is the expensive bit that is worth not duplicating
<ogra> cjwatson, and a dd command to punch it in place
<lool> cjwatson: Currently, we don't install redboot
<lool> Just kernel and initramfs
<mvo> liw: I closed the u-m task for the bug now, but we should probably open onefor the kernel
<lool> cjwatson: I see
<cjwatson> lool: but wouldn't that involve a sequence of bootloader installation steps?
<cjwatson> redboot, then the kernel
<mvo> liw: or use mtab if that is correctly encoded
<ogra> the order doesnt matter, but yes
<lool> Personally, I don't care much with install redboot; I see it's useful, but our hardware is a corner case and it can be done without the help of the installer
<lool> cjwatson: Yes, that's correct
<cjwatson> lool: in general, the way d-i works means that there must be one package responsible for bootloader installation (on a given subarch, blah)
<lool> cjwatson: Aha, we kind of faced this situation when we wondered whether flash-kernel would qualify as a bootloader
<cjwatson> lool: the installer will not cope very well if you try to have a sequence of packages, so it will work better if you have flash-kernel-installer do the lot
<cjwatson> flash-kernel-installer qualifies as a bootloader installer in this sense
<ogra> flash-kernel is similar to update-grub while we'Re missing grub-install
<lool> cjwatson: Perhaps it's best if we implement the flash-bootloader feature in flash-kenrel then, but only for some subarches and only when redboot is available and only when a debconf entry is set
<cjwatson> apart from anything else, it Provides: bootable-system
<cjwatson> which is the key thing that d-i uses
<lool> cjwatson: What makes the babbage different here is that the bootloader is on the installation medium and it's not clear whether it's reused to boot the target system or not
<cjwatson> lool,ogra: you can tweak the logic using isinstallable scripts, but it tends to be easier if you keep it to one bootloader installer per subarchitecture
<lool> Usually, the bootloader is in the plaform's soldered flash
<cjwatson> by "bootloader installer" in d-i in general I include "bootloader configurator"
<cjwatson> the task is to make the system bootable
<cjwatson> whether the bootloader is there already is a distraction, at that level
<persia> The interesting bit is that flash-kernel-installer installs additional packages that get used by flash-kernel.  The same sort of logic could be used to install redboot, if required.
<lool> cjwatson: The thing is that you can remove this SD card and swap it with the kernel one
<cjwatson> something that provides bootable-system should just get the job done whatever way it needs to
<lool> Or you might want to keep booting from the install SD card
<persia> As long as running flash-kernel does the right thing later on.
<liw> mvo, I just checked: mtab is correctly encoded, but I still think this is a kernel bug
<cjwatson> lool: sure, it makes sense to me that you'd want the kernel SD card to be bootable if possible
<lool> cjwatson: So if we care to support both scenarii, we need to have some prompting for it I think
<cjwatson> why not just make both bootable?
<lool> cjwatson: I don't think we can distinguish a SD in USB mass storage from an USB disk though
<ogra> there is only one SD slot :)
<ogra> which carries your install media
<cjwatson> so you need a step involving switching media?
<cjwatson> how is that going to work while the installation medium is mounted on /cdrom?
<lool> cjwatson: We could make both bootable I guess indeed; we need a way to run flash-kernel twice on the two devices
<ogra> wont work with live images i guess
<cjwatson> which it will be
<ogra> right
<cjwatson> I don't think it will work even with d-i
<lool> cjwatson: switching media after boot
<lool> Not during install
<ogra> the only way is to either use a USB SD reader as target
<mvo> liw: thanks, just open a task for it then please
<ogra> or to wipe your install media
<liw> mvo, just figuring out how to do that :)
<lool> cjwatson: A bit like you would install to an external USB SATA enclosure, then take the disk out of the enclosure and boot your laptop on it
<mvo> heh :)
<lool> +if
<persia> lool, Let's call that a separate case.  Let's have 1) modification of the installation medium to boot the installed system with no changes, and 2) modification of a boot target from an installed system.
<cjwatson> ogra: you can't wipe the install media, it's mounted during installation, surely?
<cjwatson> medium
<ogra> cjwatson, i can wipe the bootloader parts
<cjwatson> sure
<ogra> and thats what *i* am aiming for atm
<lool> persia: Yes, that's what I wanted to do in the beginning, but cjwatson raised two points: we should implement that in a single component, and also we could simply make the two things bootable
<ogra> since thats the only sane setup
<lool> cjwatson: The part which we touch isn't mounted: it's a special partition at the beginning of the media which holds the redboot data
<cjwatson> it seems to me that when doing 2) you have the same general goal
<persia> lool, See, I'd consider case 2 to be well outside "The installer", and just be an end-user use-case.
<ogra> all others will require hoops to jump through like "install to usb cardreader"
<cjwatson> you just want to make the thing bootable
<lool> the redboot partition table, redboot, the redboot config, the kenrel and the initramfs
<cjwatson> you don't want to have to jump through multiple hoops to do it
<persia> And I don't think we can "simply make the two things bootable" since we can't know whether a given target *can* be made bootable.
<ogra> right
<cjwatson> you can tell whether redboot is already there, and otherwise warn
<ogra> my target is to make the SD a "lilo like bootfloppy"
<lool> persia: We can still make it bootable and it will be if it's SD
<ogra> which a) means we wont need to dump redboot in place at all
<cjwatson> on the initramfs size, if redboot simply has to be told, then I don't see any way around having to invoke flash-kernel after every update-initramfs
<cjwatson> or something that will update the configuration
<ogra> and b) only means to update the initramfs and redboot script
<lool> cjwatson: So on my thecus that's not needed
<ogra> yes, thats clear
<lool> cjwatson: I copied the logic to do padding like the N2100 one in flash-kernel
<cjwatson> lool: this is why flash-kernel is insanely system-specific, though?
<lool> cjwatson: and tried passing initrd= and mem= to the kernel, and it didn't help
<lool> cjwatson: I don't mind doing padding, but I hate having to parse a boot script, just like a grub menu.lst, each time we upgrade the initramfs just because it seems I can't figure out how to tell the kernel or redboot that this is a padded initrd
<ogra> well, there isnt so much parsing
<ogra> the option cant move around
<ogra> and in the end its only one single value we change
<lool> ogra: It's possible, but you'll have to handle space, tabs, the user removing the -s etc.
<ogra> comparing that to update-grub is a bit much
<ogra> the user cant remove the -s
<ogra> then it wont boot
<pitti> seb128: i386 retracer crashed, I'm looking into it
<cjwatson> does the redboot configuration file format have any support for including other files, setting variables ...?
<lool> cjwatson: http://lists.debian.org/debian-arm/2009/03/msg00122.html
<seb128> pitti: thanks
<ogra> cjwatson, cmdline can change
<lool> cjwatson: No; it's an array of typed values (bool, int, string, bootscript) and the bootscript lists the commands which redboot runs
<lool> cjwatson: There must be something I'm doing wrong which explains why it works on N2100 and not on iMX51
<cjwatson> you're way out of my league here
<ogra> cjwatson, http://paste.ubuntu.com/138253/
<ogra> what we catively change is only "bootscript_data"
<ogra> and of that we only change the last line
<ogra> (usually even only the value for -s)
<ogra> (ignore oqwi74239 ... thats from me playing)
<lool> cjwatson: Ok; so you recommend a) changing flash-kernel to also install redboot + b) falsh-kernel to both target device and to install SD
<lool> cjwatson: What about config, /etc/flash-kernel.conf ok?
<lool> (to have a way to tell flash-kernel to flash either device and to tell it what to write)
<persia> lool, How can you tell if the install medium is an SD?
<lool> persia: i can't
<lool> persia: But we could have a knob for it, and do it unconditionally
<cjwatson> doesn't it show up in /sys?
<persia> I think it's best to concentrate on the simple case first.
<lool> cjwatson: it will show as usb mass storage
<cjwatson> lool: what configuration?
<lool> cjwatson: the dev to flash; currently I hardcode /dev/mmcblk0
<lool>                 # XXX allow for other devices than SD
<lool>                 dev="/dev/mmcblk0"
<cjwatson> ah, yes
<ogra> well, given that the actual flash is to small and we can only boot from SD ... whats the issue here ?
<persia> Might make sense to get the value from debconf, and default to /dev/mmcblk0 for now.  That makes it easy to add an interface later, if desired.
<cjwatson> hmm
<ogra> we do not have any other bootdevcie
<cjwatson> persia: I don't think that's easy to do given that flash-kernel's interface permits it to be called without a debconf frontend
<lool> ogra: If the value ever changes; I'm not too confident the name doesn't change
<cjwatson> well, I suppose it could operate standalone
<ogra> lool, thats totally not jaunty though
<cjwatson> but it'll produce lots of junk on stdout
<persia> cjwatson, I was thinking of flash-kernel-installer vs. flash-kernel.
<lool> cjwatson: So what I'd expose in the config: a) what components do you want to flash b) where to flash it
<cjwatson> persia: won't help with the post-installation case
<lool> cjwatson: actually it's to stderr
<cjwatson> lool: probably depends on frontend
<persia> Don't we need flash-kernel to be installed post-installation anyway, just to handle update-initramfs?
<cjwatson> you could use debconf-communicate
<cjwatson> not very nice, but could work
<cjwatson> but I think a configuration file would be more elegant
<lool> ogra: I don't think having a flash-kernel.conf is hard
<cjwatson> persia: yes
<lool> cjwatson: the other option for the components to install or the target device would be to extend the command line flags of flash-kernel
<lool> That would allow for running flash-kenrel on the two SDs and writing redboot to one
<lool> But only once
<persia> So when run during install, you could install the bootloader to several places, but once installed it just updated it?
<lool> Yes
<lool> Once installed it would only update the current place
<lool> Bah I'm just not convinved wiht this whole two SD approach, it makes things more complex and ugly
<persia> I think it's easier to just overwrite the contents on the media from which you booted in the simple case.  Those who want to do a two-SD solution may well be served by documentation.
<ogra> ++
<persia> s/the contents/the boot configuration/
<liw> mvo, if you have time: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/116465 -- edgy to feisty upgrade, no duplicates, no info from other people than reporter; I can't seem to easily test that upgrade, but my guess would be that there was something broken back then, in some cases, but it's fixed since -- what do you think?
<ubottu> Ubuntu bug 116465 in update-manager "Update to feisty failed on 3 different computers" [Medium,Confirmed]
<cjwatson> lool: in general I have no problem with programs having both configuration files and command-line flags :-)
<persia> lool, All the more so because by default the partitioning scheme for any target device isn't going to match that which is required to be able to install redboot, so you'll have to document a procedure anyway.
<lool> persia: Ah thanks for saying aloud what I was thinking from the start (with two SDs)
<persia> As long as the end-user is *able* to point flash-installer at an alternate medium post-install.
<mvo> liw: yeah, agreed. back in those days the qt frontend was not very stable
<lool> Ok; then I don't need to make flash-kernel write redboot either
<lool> I mean I can, it's nice, but not required
<liw> mvo, I'll close it then
<ogra> yeah
<cjwatson> lool: you do for the installer side of things, don't you?
<mvo> liw: it probably just crashed somewhere in qt, no python backtrace nothing
<persia> That means that a sufficiently motivated end-user can partition a second SD just so, and then run the appropriate commands to install a bootloader on the alternate SD, and update their kernel and initramfs on the alternate SD, and boot from that, if they like.
<ogra> cjwatson, no, we have everyting on the install media we need
<ogra> cjwatson, we just change the config
<ogra> for that ambitioned user i can easily cut out the necessary snippets fom my builder script
<ogra> and another big big plus is that fconfig doesnt actually need to grow an init command for jaunty
<persia> ogra, Well, as long as the end-user can do the right thing later.
<ogra> with my script snippet and the fconfig.bin blob
<ogra> no prob
<ogra> persia, http://paste.ubuntu.com/138266/ thats all thats needed
<lool> cjwatson: I personally think the dual SD install involves a lot of masoshism from us to support it: we would need to teach the installer about creating a special partition to protected the redboot data, then init the redboot partition, redboot config, copy redboot and tell flash-kernel about this non-standard SD card location; if however we drop that usecase, and hence overwrite the SD installation media as the target boot media, we just need ...
<lool> ... to run flash-kernel as I wrote it
<liw> is linuxmce well known?
<lool> But then that dual SD card has been brought up over and over and I thought we had to deal with it, but given the above discussion I'm inclined to kill it from installer
<persia> ogra, The fconfig.bin blob is included in the redboot-tools, package, right?
<ogra> no
<ogra> its published on http://cdimage.ubuntu.com/custom/20090326-armel+imx51/
<cjwatson> lool: oh, right, of course the install medium already has redboot
<cjwatson> I forgot about that
<ogra> it has everything, thats the big plus here, we just need to modify whats there
 * maxb applauds Hobbsee's comment on bug 332945
<ubottu> Launchpad bug 332945 in update-notifier "[Jaunty] Removal of Update Notifier is WRONG" [High,Confirmed] https://launchpad.net/bugs/332945
<liw> mvo, https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/122197 -- edgy to feisty, no duplicates, log files from someone else but they didn't give any info, can't quickly find anything else wrong than a conffile prompt in the bug reporters log files -- what do you think?
<ubottu> Ubuntu bug 122197 in update-manager "Upgrade Manager failed from 6.10 to 7.04" [Medium,Confirmed]
<pitti> seb128: hah; turns out that the remaining inconsistency cases in the dupdb consolidation is a p-lp-bug apparently :) it works fine with launchpadlib
<ogra> cjwatson, sigh ... "create_inode: could not create character device squashfs-root/dev/agpgart, because you're not superuser! Success"
<ogra> so unsquashfs isnt an option :/
<cjwatson> isn't there a fuse-squashfs thing?
<cjwatson> I guess antimony might not have fuse
<ogra> it has
<ogra> but i'm not in the group
<ogra> (i guess nobody is)
<ogra> its loaded though
<cjwatson> just sync it elsewhere then, you'll have to
<ogra> well, then i can as well roll the image at home :(
<cjwatson> time is short ...
<ogra> yep
<cjwatson> I can't think of any quick workarounds :(
<ogra> me neither ... what i fear is that my laptop wont survive and my nslu2 install is at pkgsel after 4h already ...
<ogra> but well, no risk, no fun
 * ogra pulls filesystem.squashfs
<istaz_> hey
<istaz_> I have  noticed a reccuring bug since migrating from intrepid to jaunty
<istaz_> python (2.6) can't seem to find certain packages
<istaz_> I had the bug happend with python-msn and python-elisa
<istaz_> reconfiguring the packages with dpkg-reconfigure fixed the problem in each case
<cjwatson> they probably need to be rebuilt against 2.6
<istaz_> yes probably
<istaz_> when imported in python2.5 they work fines I forgot to mention
<cjwatson> bug 348752 for pymsn, but you should file a bug on elisa for the other one
<ubottu> Launchpad bug 348752 in pymsn "pymsn doesn't work with Python 2.6 in jaunty" [Undecided,Incomplete] https://launchpad.net/bugs/348752
<cjwatson> just saying "needs to be rebuilt for 2.6" would be quite sufficient I imagine
<istaz_> cjwatson: yes I was the one who reported  that bug
<istaz_> cjwatson: oh you meant the package itself need rebuilding
<cjwatson> istaz_: yes
<cjwatson> istaz_: routine for new python versions
<istaz_> ok I will do that
<istaz_> thanks for you informations
<cjwatson> istaz_: I'm not sure you can, you don't have upload privileges
<cjwatson> oh, unless you mean "will file a bug on elisa"
<istaz_> cjwatson: yes I mean that
<BUGabundo> hi
<BUGabundo> good afternoon everyone
<BUGabundo> anyone here covering wubi?
<BUGabundo> something I noticed recently: if a machine requires no acpi to work, wubi will install and then fail to boot
<BUGabundo> messing both OSs some times and leaving new and no so experienced users (the target of wubi)
<BUGabundo> with no way out!
<cjwatson> I don't believe that any of the wubi experts are here. File a bug?
<BUGabundo> cjwatson: seems ill have
<BUGabundo> but this was more of discussion then bug
<BUGabundo> the bug it self is hw support
<BUGabundo> but I wanted to know if wubi would do some preliminary testing before install
<BUGabundo> to check for this prb
<cjwatson> xivulon only has very patchy IRC access. You should find other non-IRC ways to have a discussion about it.
<tkamppeter> pitti, I want to ask you something about Apport. See bug 348316. There are three lines of the error_log in the initial posting from Apport, but the complete error_log is not attached. I think it would be nmice to have the complete error_log.
<ubottu> Launchpad bug 348316 in cups "Printer (HWModel Name) May Not Be Connected" [Undecided,New] https://launchpad.net/bugs/348316
<BUGabundo> will do cjwatson
<BUGabundo> will email installer ML then
<istaz_> hum apparently for elisa I still had the ppa version of intrepid. Changelogs for the official packet in jaunty claim to have fixed the packet. bug 337438
<ubottu> Launchpad bug 337438 in pigment-python "elisa - python 2.6 transition " [Medium,Fix released] https://launchpad.net/bugs/337438
<ebroder> Anyone from motu-sru around? We've got a bug in Hardy proper that's causing a regression in a backport: bug #348865
<ubottu> Launchpad bug 348865 in gsasl "[hardy] libgsasl7-dev missing dependencies on libntlm0-dev, libkrb5-dev" [Unknown,Fix released] https://launchpad.net/bugs/348865
<ebroder> (bug 348865?)
<ebroder> Oh, never mind
<cjwatson> istaz_: yes, so it has. I was looking at the wrong version myself by mistake
<liw> mvo, what's DelCount in MyCache in update-manager? (https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/144773)
<ubottu> Ubuntu bug 144773 in update-manager "update-manager crashed with AssertionError in saveDistUpgrade()" [Medium,Triaged]
<ogra> cjwatson, just fyi whilÃ¶e i see it, there is a "/etc/.pwd.lock" file in the squashfs ... i dont think that belongs there
<mvo> liw: the amount of package that are marked for removal
<liw> mvo, hmm... testing that with assert seems sub-optimal (that and BrokenCount); is this tested earlier so that the UI can say something useful?
<mvo> liw: agreed, let me check the code
<cjwatson> ogra: I suspect it's harmless since I have that on my installed system too
<ogra> indeed
<cjwatson> my guess at the source would be lckpwdf()
<ogra> ah
<BUGabundo> question: is spark still supported and actively developed? some one asked on #identica
<ScottK> It's a community supported architecture.  No official Canonical support.  For Jaunty the port seems (from the outside) to be in reasonably good shape.
<BUGabundo> thanks ScottK
<liw> mvo, I need to go now, but I'll read any comments you add to the bug about this, or message me privately, but in the meanwhile I closed #115131 :)
<ogra> cjwatson, test install running with changes syslog.conf and the two-liner in ubiquity
<ogra> *changed
<cjwatson> ok
<ogra> i'll rsync it up to my dir on antimony alongside
<philsf> has the beta been released yet?
<ogra> sent 99 bytes  received 20 bytes  79.33 bytes/sec
<cjwatson> no
<ogra> total size is 584148992  speedup is 4908815.06
<pitti> seb128: retracers operational again, including sourceful stack trace FYI
<cjwatson> philsf: subscribe to ubuntu-announce@ to be notified
<ogra> wow, that was fast :)
<Ghennadi_> :-)
<seb128> pitti: waouh!
<cjwatson> ogra: that looks suspiciously like a null rsync ...
<philsf> k thanks
<ogra> cjwatson, two lines in ubiquity and three lines in syslog.conf
 * ogra checks md5sum
<cjwatson> oh, well, md5sum it to be sure but don't complain I suppose :)
<ogra> hmm, you are ringt
<ogra> *right
<cjwatson> bigon: your pymsn upload should be versioned 0.3.3-0ubuntu3, not 0.3.3-0ubuntu2build1. buildN is useless for packages that already have an "ubuntu" substring in their version
<ogra> hmm
 * ogra wonders why it doesnt work
<ogra> ah, touching the file helps ... silly rsync
<kany> hi hi
<kany> need help badly
<kany> :( if anyone is here that could pm me and walk me through the steps of connecting to the internet through kubuntu i would be very pleased. i kno wi sound lazy i have tryed everything and cant connect. So if there is anyone here who has time i would really appreciate the help
<kany> I have a talktalk cd and i think i also have the key /
<DktrKranz> kany: this is not the right channel to ask, #ubuntu is a better place :)
<kany> :( if anyone is here that could pm me and walk me through the steps of connecting to the internet through kubuntu i would be very pleased. i kno wi sound lazy i have tryed everything and cant connect. So if there is anyone here who has time i would really appreciate the help
<kany> oh ok
<sistpoty|work> mvo: regarding faumachine and fault injecting for blocks on a cdrom: this might take a bit longer than expected, the cdrom controller code is pretty ugly and needs a major face lift :(
<kany> cant join #ubuntu im on a proxy
<kany> ffs im screwed :( lol
<kany> :X
<mvo> sistpoty|work: thanks for looking into that! no problem, I will just burn a regular one and use a sharp instrument to simulate a faul I guess :)
<sistpoty|work> mvo: ok :)
<calc> slangasek: ping
<ogra> calc, dont wanke him up !
<ogra> *wake
<calc> ogra: oh he went to bed late?
<ogra> 7h ago and he will release if he gets up ...
<calc> ah lol
<ogra> cjwatson, ok, i'm at the restart message of ubiquity, publishing the current image from my home is fine
<cjwatson> ogra: thanks, done (20090326.1-armel+imx51). could you please put the patches you applied in that directory as well?
<ogra> ugh
<ogra> xant i just link to the fix in the bzr branch for ubiquity ?
<ogra> *cant
<ogra> (i agree on syslog.conf)
<cjwatson> ogra: that's OK too if you're specific (i.e. link to the diff rather than the branch)
<ogra> good
<ogra> god, that netsplitting starts to get on my nerves
<cjwatson> ogra: although that might go away if the branch is deleted ... but perhaps persia can promise not to do that :)
<ogra> ah, well, i'll put the two diffs in to prevent probs
<ogra> cjwatson, ok, both copied
 * ogra twiddles thumbs ... nslu2 install at 69% of pkgsel after 6h ...
<jcastro> slangasek: assuming you're the one writing it, I think it would be useful to point users to the appport-best practices mdz pointed out in the release announcement, what do you think?
<cjwatson> ogra: can you give me a brief description of what the syslog.conf patch is for?
<ogra> cjwatson, "suppressing all kernel messages that are not debug state in logfiles"
<cjwatson> ta
<mdz> jcastro: it's already in the release announcement, see https://wiki.ubuntu.com/JauntyJackalope/BetaAnnouncement
<cjwatson> ogra: "non-debug kernel messages" then?
<ogra> yeah
<ogra> better
<jcastro> mdz: ah, thanks!
<cjwatson> ogra: ok, HTML syncing out
<mdz> ogra: can you give me a link to the installation instructions for babbage?
<ogra> mdz, http://cdimage.ubuntu.com/custom/20090326.1-armel+imx51/ its linked from the download page ... direct link is https://wiki.ubuntu.com/BabbageJauntyBetaInstall
<ogra> i'm not 100% finished yet
<ogra> (though the notes are tested, but the phrasing could need some love)
<mdz> ogra: thanks
<cjwatson> I like the recent change in LP to show bug summary changes in the log
<cjwatson> https://bugs.edge.launchpad.net/ubuntu/+source/pkgsel/+bug/348393
<ubottu> Ubuntu bug 348393 in pkgsel "[jaunty] Installing in a language other than English will not install appropriate language packs if they aren't on the CD" [High,Fix committed]
<sbeattie> hrm, should linux-firmware really be in main and not restricted?
<ion_> Itâs not exactly software, but more like a part of your hardware.
<cjwatson> IIRC that was intentional; the Ubuntu licensing policy explicitly says that we will consider firmware on a case-by-case basis
<sbeattie> cjwatson: it gets included in a free-software only install, which IMO is a bug.
<ion_> sbeattie: Does the free-software-only install demand open-source hardware?
<cjwatson> sbeattie: that's a matter of opinion, I think.
<ion_> sbeattie: Your BIOS and processor microcode are already likely to be non-free, for instance.
<cjwatson> sbeattie: the free-software-only install is defined as main(/universe) only
<cjwatson> sbeattie: so I think if it meets *our* definition of main, that's where it should stand
<cjwatson> besides IIRC there was a practical upgrade problem with putting linux-firmware in restricted, although I'd have to go and check the logs
<cjwatson> dinnertime, anyway
<sbeattie> cjwatson: okay, thanks.
<sbeattie> ion_: I personally do not care, as I'm not dogmatic about using free software only; but I find it somewhat dubious to ask for only free software to be installed and then get handed a pile of binary firmware blobs.
<allquixotic> Anyone know how to stop Firefox from trying to open *all* files in OpenOffice.org? :( Extension is irrelevant; if it's a file and I download it, it tries to open it (or even the containing folder!) in OpenOffice. Nautilus' mime types are fine, and in the Applications tab of FF, I don't see anything borked there either
<calc> allquixotic: for me it does nearly the opposite, won't open documents even if they are OOo type, heh
<ogra> cjwatson, oh silly me ... the babbage ubiquity apt error is cuased by the fact that mcopy doesnt copy the subdirs in dist/ from the iso into my image ...
<calc> allquixotic: i think it has to do with the /usr/lib/mimetype stuff
<LaserJock> Keybuk: nice blog post, gave me some food for thought
<Keybuk> LaserJock: :-) that's the intent
 * Keybuk likes to stir up pleasant debate
<LaserJock> I'm just a hobbyist programmer, so everybody told me to do everything in Python
<LaserJock> but after having to rewrite some data analysis code for my PhD in C I can definitely see your point
<ogra> LaserJock, haha ... hobbyist
<slangasek> calc: contentless pong
<ogra> LaserJock, nobody belives you
<calc> slangasek: oh yea sorry about that, i updated the bug report, let me find the number
<calc> slangasek: bug 299161
<ubottu> Launchpad bug 299161 in memtest86+ "RFE : Please upgrade to Memtest86+ 2.11 (Jaunty)" [Wishlist,Triaged] https://launchpad.net/bugs/299161
<LaserJock> ogra: I don't stand up to the likes of you anyway :-)
<calc> slangasek: not sure who i should subscribe it to
<calc> slangasek: i haven't uploaded it yet obviously but it is ready on my hd
<ogra> LaserJock, come on, you're doing edubuntu just fine
<slangasek> jcastro: I think the best practices need to be referenced from the website we already point users to for bug reporting, instead of adding more links to the release announcement
<LaserJock> ogra: well, distro development is != app develoment exactly :-)
<ogra> often very close though
<slangasek> ah, apparently this has been addressed by changing which link we point to ;)
<calc> apparently this new memtest even supports the intel chips coming out later this year (yipee) :)
<calc> slangasek: is there anything else i need to do wrt bug 299161?
<ubottu> Launchpad bug 299161 in memtest86+ "RFE : Please upgrade to Memtest86+ 2.11 (Jaunty)" [Wishlist,Triaged] https://launchpad.net/bugs/299161
<slangasek> calc: can't say, no time to look at it today
<calc> slangasek: ok no problem
<calc> wow git has a progress meter, thats nice esp on this 100MB repo
<slytherin> can any of the archive admins please clear jack-audio-connection-kit from queue?
<cjwatson> slangasek: ^- is jack-audio-connection-kit OK to accept? I would default to "no" since it's on the studio CDs
<slangasek> cjwatson: let's call it a "no", there's no hurry on it it's just NBS cleanup
<slangasek> (well, and out-of-date fixing)
<cjwatson> that's what I thought, shame Onkar didn't bother to say why he wanted it ...
<slytherin> any maintainer of fusa here? the logout confirmation dialog shows icon for shutdown, should I file a bug?
<cjwatson> 19:18 <cjwatson> slangasek: ^- is jack-audio-connection-kit OK to accept? I would default to "no" since it's on the studio CDs
<cjwatson> 19:18 <slangasek> cjwatson: let's call it a "no", there's no hurry on it it's just NBS cleanup
<cjwatson> 19:18 <slangasek> (well, and out-of-date fixing)
<cjwatson> slytherin: ^- re your request earlier
<slytherin> cjwatson: I was asking from point of view of fixing gst-plugins-bad0.10 FTBFS on some arch. Anyway, I will wait.
<slangasek> yes, that's the same reason I uploaded it - but it's covered by the beta freeze currently :)
<slytherin> slangasek: fine.
<slytherin> Can anyone advice me on this fusa issue?
<jtisme> who is in charge of regression testing kde
<ScottK> jtisme: Kubuntu development questions are better on #kubuntu-devel.
<jtisme> I agree but do we (ubuntu community) perform any type of regression tests on kde before deploying?
<ScottK> Yes.
<ScottK> In the Kubuntu context though.
<ScottK> So the people most likely to answer any questions you have are less likely to be on this channel than #kubuntu-devel.
<jtisme> Ok, sorry I mis read you original post saw it as Kde devel will go there thanks
<jtisme> will go to #kubuntu-devel that is
<ebroder> Anybody around who could look at bug 348865?
<ubottu> Launchpad bug 348865 in gsasl "[hardy] libgsasl7-dev missing dependencies on libntlm0-dev, libkrb5-dev" [Unknown,Fix released] https://launchpad.net/bugs/348865
<Aquina> Is it ok to advertise other distros often in launchpad /Ubuntu?
<directhex> hm, have i just found a bug in scp?
<ScottK> Aquina: What do you mean?
<Aquina> Exactly (literaly) what I told you. There is a person advertising a dirsto named "Volvix" (I think) at times.
<Aquina> (https://launchpad.net/~tomdavies04)
<ScottK> I'm pretty sure there's no rule against that.
<ianm_> is it known if/when Wacom tablets will work fully (eg. the eraser side and the extra buttons on the tablet itself) ?
<Aquina> ok
<cjwatson> directhex: yes
<directhex> cjwatson, like i said in #ubuntu-motu, i'm boring and unoriginal in my bug discovery. boo!
<cjwatson> directhex: my observation was purely statistical
<slangasek> haha
<Hobbsee> maxb: :)
<ebroder> Is there a way to search for the list of packages that build-dep on a package? It doesn't seem like aptitude search is able to do it...
<TheMuso> ebroder: grep-dctrl I think it is can do that.
<Hobbsee> yes, but it involves grep-dctrl
<ebroder> Ah, ok, sure
<Hobbsee> grep-dctrl -F Build-Depends libsoprano-dev -s Package -n /var/lib/apt/lists/*_Sources for searching for packages which have a build-depend on libsoprano-dev
<Hobbsee> ebroder: my notes say ^.  Modiy as appropriate
<ebroder> Yep. That's exactly what I'm looking for. Much thanks
<Hobbsee> that should probably go into a script for ubuntu-dev-tools, too
<TheMuso> Hobbsee: I'd agree with that. Make it check all the sources list files etc.
<cjwatson> seems a bit overkill, I think there should just be a grep-sources symlink in dctrl-tools that operates on /var/lib/apt/lists/*_Sources
<cjwatson> anything more than that will be too specific
<cjwatson> (note the existence of grep-available, grep-aptavail, grep-status)
<[reed]> is jaunty beta still today?
<slangasek> yes
<slangasek> coming soon to a mirror near you
<TheMuso> heh
<TheMuso> That always sounds so "promo/marketing"
<TheMuso> to me at lesat.
#ubuntu-devel 2009-03-27
* slangasek changed the topic of #ubuntu-devel to: Archive: feature freeze | Ubuntu 9.04 Beta released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<tkamppeter> Cansomeone approve my uploads (ghostscript, hplip, system-config-printer, hal-cups-utils)? Seems that the beta freeze did not get deactivated.
<slangasek> tkamppeter: the freeze is still in effect; when it's over, all the packages will be released from the queue.
<tkamppeter> slangasek, why is the beta freeze still active with the beta already being released and announced.
<JanC> tkamppeter: are all the images built already?
<slangasek> because it gives us a grace period after the announcement when the jigdo files remain valid, and when we can respin a new image for something we overlooked if we absolutely have to
<slangasek> JanC: and released
<tkamppeter> OK. Thanks.
<directhex> i think i had some sponsorships pending that the freeze got in the way of
<wgrant> slangasek: I've often wondered why you can't declare a set of Soyuz publishings to stick around for a while. It would seem not too hard to implement, and would make downloading images much nicer.
<DaemonFC> Who would be the person to talk to about maybe getting Ubuntu to use Smolt eventually?
<directhex> smolt?
<directhex> fedora's hardware database?
<DaemonFC> yes, and it's not just for Fedora
<DaemonFC> other distributions contribute
<DaemonFC> Suse does
<DaemonFC> I was wondering who I could make a suggestion to about a monthly Smolt checkin like other distributions do
<DaemonFC> with user consent of course
<directhex> a package might be a starting point
<DaemonFC> currently, Ubuntu doesn't seem to be participating in that or kerneloops, though kerneloops probably makes less sense in Ubuntu
<DaemonFC> (as more Ubuntu kernels will be tainted)
<slangasek> Ubuntu is participating in kerneloops.
<DaemonFC> oh?
<slangasek> sure, http://www.ubuntu.com/testing/jaunty/beta#Kerneloops :)
<DaemonFC> oh, it's just not there by default
<slangasek> correct
<slangasek> there were some integration issues that prevented us from shipping it by default for 9.04
<DaemonFC> I'm running a vanilla kernel, so I would suppose they'd be interested upstream if my kernel oopsed
<directhex> as long as it doesn't bother upstream over every little oom
<DaemonFC> I noticed that Ubuntu tends to stay behind one kernel and cherry pick
<directhex> DaemonFC, kernel version is picked fairly early in the release process
<DaemonFC> I've been running 2.6.29 since rc5
<twb> Ubuntu has a branch of a package (midori) I maintain for Debian.  How do I find out who maintains this branch?
<dtchen> twb: as a universe source package, MOTU do collectively. See #ubuntu-motu
<twb> dtchen: well, nominally that's the case, but in the past I got the impression of other packages that there were one or two people who actually did the work.
<twb> I'll take it to -motu, thanks.
<DaemonFC> sandeen: Just because I'm curious
<DaemonFC> I'm going to download and install the Ubuntu kernel
<DaemonFC> and compare bootup performance
<DaemonFC> errr, wrong channel
 * calc thinks a spiffy resource monitor like in win7 would be nice on gnome
<calc> whoa win7 has no way to turn off, just hibernate and sleep from the look of it
<maco> calc: not like vista where it has that little arrow thing to choose other options?
<maco> ...i hope they at least encrypt pagefile.sys then
<calc> it has options just none that equate to new boot the next time you turn on the system
<calc> unless the main shut down button means off instead of hibernate
<calc> it has sleep, hibernate, restart, logoff, etc
<calc> it has "shut down" with an arrow beside it that you can select specific options
<calc> ah i think that whatever it says on the main button is what it does, so it just doesn't show it in the menu
<Amaranth> right, they got rid of the stupid button that did random things
 * calc deletes win7 its slightly improved over vista but not worth the time
 * calc will stick with xp for OOo testing
<Amaranth> I'd say if you have to use windows it is at least the best choice
<Amaranth> Or will be once they release it
<calc> it still uses a lot more ram than xp
<calc> and ubuntu :)
<dholbach> good morning
<slangasek> pitti: the changed conflicts in gnome-themes-ubuntu look wrong to me; eliminating the conflict based on the presumed contents of package versions that don't exist yet?
<slangasek> dholbach: morning
<dholbach> hiya slangasek!
<pitti> Good morning
<Hobbsee> morning pitti
<pitti> slangasek: it's from one of the authors of community-themes, the themes we ship in ubuntu-themes now will be removed from there
<pitti> slangasek: it's a little brittle, I know; if it concerns you, I'll revert this
 * pitti hugs Hobbsee
<slangasek> pitti: doesn't concern me enough to worry about a revert, just caught my attention while looking through the queue
<Hobbsee> :)
<pitti> slangasek: congratulations for the beta release!
 * pitti didn't see it on the list yet, just spotted the topic
<slangasek> on ubuntu-announce?
<slangasek> thanks - looks like a pretty happy beta
<StevenK> slangasek: I note UNR was not mentioned in the announcement, did I miss it?
 * slangasek ponders the seahorse upload in the queue, which appears to break feature freeze and UI freeze
<slangasek> StevenK: it was linked from the announcement; I didn't include explicit highlights for it
<StevenK> It's in /releases/jaunty/beta which is what I care about. :-)
<Mithrandir> congrats on the beta.
<Hobbsee> siretart: ping?
<pwnguin> i wonder why ubuntu-devel ML is considered an appropriate venue to broadcast to all Ubuntu Members
<Hobbsee> pwnguin: it's not - it's just a member of the ubuntumembers team.
<Hobbsee> pwnguin: it got sent to all ubuntu members too
<pwnguin> ah
<Mithrandir> the linkedin spam?
<pwnguin> well that and hobbsee's lwn announcement
<Hobbsee> Mithrandir: yeah
<Hobbsee> pwnguin: it was copied from jono's blog, but yes
<infinity> slangasek: Any qualms about me completely disabling antimony's cdimage cron for a bit (seems like less hassle than trying to surgically remove all the buildlive bits) while I upgrade the livefs buildds?
<slangasek> infinity: disabled
<infinity> slangasek: I was just going to save it and crontab -r, but that works too. :)
<slangasek> this way we at least know if there's anything going on with some of the alternate builds
<Mithrandir> infinity: you know the master copy is saved in /home/cdimage/etc/crontab?
<infinity> Mithrandir: Yeah, but I'm all about preserving current state.
<Mithrandir> next time you'll be telling me you have backups too
<Mithrandir> s/time/thing/
<infinity> Mithrandir: Having backups would involve "learning from my mistakes", which is something I'm less good at. :)
<Mithrandir> :-)
<infinity> Mithrandir: My general theory is that I make sure anything REALLY important lives on remote systems that someone else can worry about backing up.
<infinity> Mithrandir: And if I lose any of my local stuff, it sucks, but I move on.
<superm1> slangasek, i just uploaded a mesa upload that fixes bug 341898.  hopefully it won't be too late to re-roll disks with that?
<ubottu> Launchpad bug 341898 in mesa "Mythtv frontend does not display any fonts" [Undecided,Fix committed] https://launchpad.net/bugs/341898
<slangasek> superm1: hmm, archive is already coming unblocked, and the livefs buildds are also currently down for maintenance :/
<slangasek> so there'd be more of a delta wrt the rest of the beta than just mesa, by the time we could reroll
<superm1> slangasek, oh :(
<dholbach> please don't use ubuntu-devel@lists.ubuntu.com in the Maintainer field, THANKS!
<superm1> slangasek, okay well at least having it as a web update for those people post-install will be beneficial then.  i'll make sure our release notes are updated for that
<siretart`> Hobbsee: pong
<siretart`> morning, folks
<pitti> hey siretart`
 * siretart` hugs pitti :-)
 * pitti hugs siretart` back, wie gehts?
<dholbach> does anyone know why I'd have to run "LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so skype" to make video stuff in skype work?
<dholbach> http://ubuntuforums.org/showthread.php?t=976467
<james_w> because skype is closed source?
<james_w> it can't be patched to decode the video stream now that the kernel no longer does it
<siretart`> pitti: thanks, fine! (a bit tired, and we just had a blackout in the room students are writing their examination. A really fun friday morning here...)
<siretart`> "vordimplom", of course...
<dholbach> james_w: alright, thanks :)
<mvo> pitti: in bug #347019 the attached log seems to be corrupted, do you have any idea if that is a apport upload problem?
<ubottu> Launchpad bug 347019 in python-defaults "package python 2.6.1-0ubuntu4 failed to install/upgrade: " [Undecided,Incomplete] https://launchpad.net/bugs/347019
<mvo> (I have seen some of those corrupted logs)
<dholbach> james_w: I wasn't saying that anybody of us is not doing their job properly - just wondered why I suddenly had to do it :)
<james_w> dholbach: I couldn't resist the chance to troll now could I?
<dholbach> james_w: hope you enjoyed it ;-)
<james_w> are you using the latest version? I was under the impression that newer versions were fixed
<dholbach> james_w: 2.0.0.72-1
<pitti> mvo: indeed, that's weird; never saw it
<pitti> dholbach: ekiga! :-)
<pitti> (while we are on the subject of trolling)
<mvo> pitti: I think I saw it when I submited a bugreport with links or w3m (can't remember which one)
<pitti> mvo: I submitted bug reports through w3m before
<pitti> but no package install failures
<dholbach> seb128: do you know of any strange bugs atm where metacity takes up a lot of CPU?
<seb128> dholbach: no but I'm using compiz nowadays
<seb128> didn't read any launchpad bug about that though
<dholbach> ah ok
<dholbach> seb128: seems my brother has the problem right now
<seb128> dholbach: is he using the composite manager there?
<seb128> dholbach: does it get it every time, ie does it come back if the restart it?
<dholbach> seb128: no compositing manager
<dholbach> seb128: he says he gets it since a few days
<seb128> that's weird that package didn't change in a while
<seb128> ie 1.5 month now
<seb128> I would recommend opening a GNOME bug
<seb128> be careful if you want to attach gdb to it don't do it from the running session
<dholbach> seb128: I'm sure it's something else, what could be sources for that sort of mayhem?
<seb128> that would freeze ie and let you no way to switch the focus or open anything on screen
<seb128> dholbach: random guess X ....
<seb128> brb session restart
<DreadKnight> crap... totem crashing
<DreadKnight> Segmentation fault (core dumped)
<DreadKnight> actually here's a better error log http://paste2.org/p/172274
<DreadKnight> miro not starting; error log http://paste2.org/p/172278
<mvo> TheMuso: I uploaded a small fix for ubuntustdio-control, if you want it in bzr, please let me know, I will merge it then
<mdz> cjwatson: where does /testing/jaunty/beta come from?  it differs from the email announcement in at least one important way (bug reporting instructions are wrong)
<tjaalton> nxvl: looks like the change in aterm was wrong (remove the alternatives link to /usr/bin/aterm)
<Mithrandir> me, unicode(1) is broken in hardy.
<Mithrandir> anybody know why our python is compiled without support for wide unicode characters?
<lool> bryce: Around?
<lool> bryce: Pigment/Elisa upstream contacted me about a serious mesa issue with drivers using DRI
<lool> bryce: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/349127
<ubottu> Ubuntu bug 349127 in mesa "Elisa displays video with greenish/purplish colors" [High,New]
<lool> bryce: It affects more than just elisa though; he says it's a recent regression, and would like it to be fixed for jaunty; he thought he had bisected a patch, but was incorrect
<lool> bryce: Should I milestone this for final?
<lool> bryce: I will leave it to you to decide and review a candidate patch if he finds one
<seb128> bah
<seb128> python2.6 is broken
<seb128> $ python -c "import gtk"
<seb128> ImportError: /var/lib/python-support/python2.6/gtk-2.0/glib/_glib.so: undefined symbol: PyUnicodeUCS4_DecodeUTF8
<seb128> note to self, don't upgrade just after beta next time ;-)
<seb128> that's going to be fun for users since update-manager can't start now
<seb128> they will never get upgrades again
<infinity> seb128: Is that broken in Beta, or a post-beta build?
<crdlb> too bad update-notifier won't be able to notify them :P
<seb128> infinity: post beta build
<infinity> seb128: Ahh, could be worse then.  Quick, phone doko and yell at him. :P
<seb128> infinity: I got a python2.6 update this morning I guess that's due to it
 * infinity hopes this doesn't end up in some manual bootstrap annoyance...
<james_w> doko is at pycon with limited connectivity
<infinity> james_w: Convenient!
<seb128> he should really learn to test upgrades
<james_w> though enough connectivity to upload
<seb128> or wait to be around before doing such changes
<james_w> http://launchpadlibrarian.net/24209669/python2.6_2.6.1-1ubuntu4_2.6.1-1ubuntu5.diff.gz
<directhex> if update-manager is broken, i wouldn't wait for doko
<directhex> IMHO
<james_w> -		--enable-unicode=ucs4 \
<james_w> ^ that's my guess
<seb128> yeah, I would guess so too
<crdlb> do you think? :)
<james_w> I can't see that it was intentional
<seb128> but really he should be testing upgrades
<seb128> *shrugÃ¹
<seb128> james_w: can you test if that fix the issue?
<seb128> I can sponsor the change
<james_w> I don't have the issue yet :-)
<seb128> upgrade python2.6 to current jaunty
<james_w> doing so now
<infinity> james_w: Neither of the two ./configure changes seem to reconcile with the changelog.
<infinity> james_w: Though, maybe without-cxx was required for the debug build...
<infinity> james_w: (or, removing it, rather)
<tkamppeter> pitti, hi
<mvo> changelog? why bother
<directhex> changelogs are for people too lazy to read the source. evidently!
<seb128> testing? why bother? ;-)
<seb128> bug #349467
<ubottu> Launchpad bug 349467 in pygtk "update-manager fails to install todays updates due to "undefined symbol: PyUnicodeUCS4_DecodeUTF8"" [Undecided,New] https://launchpad.net/bugs/349467
<james_w> is it worth denying access to the broken package?
<mvo> probably
<james_w> is that something for IS?
<mvo> it will look really bad if we release beta and the first update breaks all of our python gtk apps :/
<mvo> yes
<seb128> elmo, mdz, cjwatson: ^
<seb128> mvo: the annoying part is that with the new update-manager design user will just never notice and never get any update
<mdz> seb128: aren't you sitting a few meters away from elmo?
<seb128> or rather they will not notice update-manager crashing
<mvo> right :(
<seb128> mdz: he's not there to be seen, dunno if he always work from the office
<pitti> meh, python is broken
<seb128> pitti: ^ read backlog
<pitti> sorry, just rebooted
<mvo> urgh, lets just revert the entire upload
<mdz> seb128: on the phone with Ng right now
<seb128> mdz: thanks
<mdz> he's responding
<maco> pitti: the backlog is "uh oh the update-manager is crashing like mad so itll never open"
<mdz> seb128: on the plus side, update manager will only pop up after two weeks now by default, right? :-P
<seb128> mdz: right, which means not many users should get the broken update ;-)
<mdz> seb128,james_w: can you confirm unambiguously to Ng that the package to clobber is python2.6_2.6.2-1ubuntu5?
<james_w> I would say libpython2.6 as well
<seb128> let me downgrade to be sure
<james_w> without taking the time to investigate which binary actually triggers it
<Ng> ok
<pitti> is that really python itself, or python-gtk?
 * mvo builds a update that reverts the previous diff
<pitti> python -c 'import gtk'  -> crashes
<seb128> pitti: it's python itself, read backlog ;-)
<pitti> importing other stuff works
<mnemo> pitti: at least "aptitude changelog pygtk" shows no recent changes
<mvo> hm, maybe its enough to rebuild pygtk?
<seb128> pitti: doko dropped --enable-unicode=ucs4 from the configure option in the update
<pitti> seb128: did we ascertain that reverting python will fix the problem?
<pitti> oh, ok
<pitti> thanks, I'll shut up now
 * Ng detects some remaining ambiguity
<james_w> mvo: that may be true, but I'd rather we knew what the extent of the problem was first
<cjwatson> mdz: newz2000 copies it from JauntyJackalope/TechnicalOverview
<mvo> james_w: agreed, good point
<Ng> I've blocked python2.6_2.6.1-1ubuntu5_amd64.deb and python2.6_2.6.1-1ubuntu5_i386.deb - is that not sufficient?
<mdz> cjwatson: gar, I missed that one
<james_w> Ng: libpython2.6 of those versions as well please
<Ng> ok
<mdz> Ng: confirmed what james_w says
<cjwatson> mdz: are you correcting it or shall I?
<mdz> cjwatson: I have corrected the wiki page, but do not know how to update the website - do you?
<cjwatson> mdz: "wait for newz to get up", I think
<mdz> cjwatson: I used to have the necessary super powers
<cjwatson> mdz: I don't think it can be that urgent, directions to bugs.launchpad.net/ubuntu/+bugs have been around for years
<seb128> Ng, mdz: python2.6 and python2.6-minimal
<seb128> downgrading those fix the issue
<mdz> cjwatson: no, it's not urgent
<mdz> Ng: python2.6-minimal as well please
<cjwatson> I used to have website editing ability as well, but they took it away at some point
<Ng> mdz: done
<seb128> Ng: thanks!
<james_w> thanks Ng
<mdz> can someone prepare a python2.6 upload which reverts the patch, so we can test it?
<seb128> mdz: I think mvo is on it
<mdz> mvo: confirm?
<mvo> mdz: uploaded already
 * seb128 hugs mvo
<james_w> oh, thanks mvo
<mdz> mvo: bless you.  reverting the patch fixed it for you?
<seb128> james_w: reading backlog even if a pygtk rebuild was enough that's a compatibility breakage
<mnemo> ah, apport is written in python too right so that's why apport fails to report this PyUnicodeUCS4_DecodeUTF8 bug... man that's a really nasty bug, it both breaks update manager so you cant get a fixed version and it also breaks apport so you cant report the bug :)
<infinity> mvo: I'll push the build ASAP as soon as it's actually accepted.
<mdz> is there a bug report open about this yet?
<mvo> mdz: I just upload -0ubuntu4 again with a higher version number (and the changelog from doko). that is the version we shipped in beta and there were no issues
<seb128> mdz: bug # 349467
<mnemo> mdz: https://bugs.launchpad.net/ubuntu/+source/python2.6/+bug/349467
<seb128> mdz: bug #349467
<ubottu> Ubuntu bug 349467 in pygtk "update-manager fails to install todays updates due to "undefined symbol: PyUnicodeUCS4_DecodeUTF8"" [Undecided,New]
<ubottu> Launchpad bug 349467 in pygtk "update-manager fails to install todays updates due to "undefined symbol: PyUnicodeUCS4_DecodeUTF8"" [Undecided,New] https://launchpad.net/bugs/349467
<mvo> bug number is what seb128 said (he is just too fast :)
<james_w> infinity: is it in the archive admin queue?
<infinity> james_w: Shouldn't be, we're not frozen.
 * mdz adjusts the importance somewhat ;-)
<mdz> cjwatson: can you confirm that mvo's upload is on its way?
 * infinity checks the queues anyway.
<cjwatson> mdz: it's in the incoming queue, yes
<infinity> Yeah, it's just waiting on the :40 cron run.
<cjwatson> the publisher's still running, so I don't think there's any point in me byhanding it
<infinity> Nah, there's not.  It needs to build anyway.
<infinity> (And building doesn't rely on the source being published)
<cjwatson> right
<infinity> There we go.  Pending.
 * infinity fiddles build records.
<mdz> mvo: is there any workaround for people who are affected?
<mnemo> upgrade using apt-get maybe?
<mvo> yeah, apt-get or aptitude or synaptic
<mdz> should work once the update is available
<mvo> or downgrade
<mvo> if its still in their /var/apt/cache/archives
<mvo> I don't know anything else
<mdz> has anyone been in touch with doko?
<seb128> james_w said that he's at a conference
<mdz> oh, he's gone to PyCon, hasn't he
<mdz> gah
<mdz> mvo: how will the dist-upgrader react to the 403?  will it roll back?
<tkamppeter> piiti, in bug 348427 the OP tried to add an Apport log to the bug and Launchpad told that it is too long.
<ubottu> Launchpad bug 348427 in cups "pdf printing leads to blocks in text" [Undecided,Incomplete] https://launchpad.net/bugs/348427
<mvo> mdz: it will error out and people will not be able to upgrade. but it will just roll back to the previous system state (so no harm done)
<mdz> mvo: thanks
<mvo> mdz: I'm testing this to be 100% sure now, but I'm 99% confident
<lool> python2.6 forbidden download?
<mvo> lool: yes, break pygtk
<mvo> s
<lool> k
<mdz> lool: bug 349467
<ubottu> Launchpad bug 349467 in python2.6 "update-manager fails to install todays updates due to "undefined symbol: PyUnicodeUCS4_DecodeUTF8"" [Critical,Fix released] https://launchpad.net/bugs/349467
<pitti> tkamppeter: 'add' -> 'attach'?
<infinity> mdz, mvo, cjwatson: It's building on the primary arches at least.
* lool changed the topic of #ubuntu-devel to: Python 2.6 issue #349467 | Archive: feature freeze | Ubuntu 9.04 Beta released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<tkamppeter> pitti, I only saw
<tkamppeter> I followed the suggestion in https://wiki.ubuntu.com/DebuggingPrintingProblems and attached the bug report below, but Launchpad things this is too long.
<ogra> Keybuk, cjwatson, i want to report the "useradd doesnt cope with date set to 01011970" bug, do you guys remember what package we exactly identified to be at fault ?
<tkamppeter> I do not know what he actually did.
<cjwatson> ogra: shadow, IIRC
 * ogra was hit by that bug on the NSLU2 install as well yesterday
<ogra> ok
<pitti> tkamppeter: perhaps he tried to paste the entire log into a comment
 * ogra filed Bug #349504
<ubottu> Launchpad bug 349504 in shadow "if system date is set to 01-01-1970 users are enforced to update their password" [Undecided,New] https://launchpad.net/bugs/349504
<cjwatson> mvo: I realised last night that we forgot to do anything about bug 290234 despite it being in the 8.10 release notes
<ubottu> Launchpad bug 290234 in ubuntu-release-notes "Intrepid: Netboot locks up at 2% installing the selected edubuntu desktop" [Undecided,Fix released] https://launchpad.net/bugs/290234
<cjwatson> mvo: I'm testing a tiny apt patch for it now
<infinity> ogra: Heh.  I noticed that when netbooting my arm buildds over and over again until I got ntpdate happy. :)
<assasusonic> hi everyone
<ogra> heh
<assasusonic> where can i get the beta build in order to have a test run?
<ogra> infinity, yeah, i have a bunch of arm devices without NIC ... there i have to set the hwclock manually
<cjwatson> assasusonic: http://www.ubuntu.com/testing/jaunty/beta
<mvo> cjwatson: oh, right. thanks for taking care of this
<infinity> ogra: Ick.
<cjwatson> assasusonic: where did you manage to find an announcement of the beta that *didn't* include download URLs? :-)
<maco> so uh, i just got about 15 emals saying the pidgin debdiff i sent for uploading error'd on translations...but i didn't change the translations. what gives?
<tjaalton> lool: about bug 349127; sounds weird, since for me it's the opposite, nvidia is broken because of vdpau, and they say the colors should be fixed in the app configs
<ubottu> Launchpad bug 349127 in mesa "Elisa displays video with greenish/purplish colors" [High,New] https://launchpad.net/bugs/349127
<cjwatson> maco: is it just telling you that you didn't update po-revision-date?
<tjaalton> lool: so maybe the elisa guys are optimizing for the wrong driver ;)
<mnemo> tjaalton: I can repro the greenish video on intel G45
<tjaalton> mnemo: what player?
<maco> cjwatson: yes. can i ignore that?
<cjwatson> maco: yes, you can - that's a known lp bug for which a fix is in progress
<maco> cjwatson: ok, thanks
<mnemo> tjaalton: I was using the video.py sample from the pigment-python library
<mnemo> tjaalton: pigment is the toolkit that elisa uses
<assasusonic> cjwatson: on distrowatch
<cjwatson> maco: bug 331094
<ubottu> Launchpad bug 331094 in rosetta "Accept PO files with unchanged revision dates" [High,Triaged] https://launchpad.net/bugs/331094
<tjaalton> mnemo: ok
<maco> cjwatson: thanks
<assasusonic> well i keep getting error 503
<cjwatson> assasusonic: I just checked, distrowatch has the download URLs quite prominently
<assasusonic> cjwatson: error 503 all the time
<cjwatson> though for some reason they are linking to obscure mirrors
<BUGabundo> pitti: ping
<cjwatson> assasusonic: use the links in the URL I gave (there are several alternatives) or use the bittorrent downloads
<BUGabundo> can't do much for bug 347874 now! bug 349462 is messing things
<ubottu> Launchpad bug 347874 in apport "double click on .crash doesnt work" [Undecided,New] https://launchpad.net/bugs/347874
<ubottu> Launchpad bug 349462 in python2.6 "ImportError: /var/lib/python-support/python2.6/gtk-2.0/glib/_glib.so: undefined symbol: PyUnicodeUCS4_DecodeUTF8 (dup-of: 349467)" [Undecided,Confirmed] https://launchpad.net/bugs/349462
<ubottu> Launchpad bug 349467 in python2.6 "update-manager fails to install todays updates due to "undefined symbol: PyUnicodeUCS4_DecodeUTF8"" [Critical,Fix released] https://launchpad.net/bugs/349467
<cjwatson> assasusonic: their primary links are to mirrors we don't operate
<infinity> mvo: A bit late now, but disabling the test suite on that build might not have made me terribly sad.
<infinity> mvo: You know, future reference for the next time you need a lightning revert on python. :)
<assasusonic> cjwatson: good idea, didn't think about torrents
<mvo> infinity: yeah, sorry for that - I think it would have been a good idea
<mvo> I was not aware that it takes *that* long
<infinity> mvo: Halfway through the suite on the fast buildds now anyway, so no point "fixing" that.
<mnemo> infinity: if there is a test suite, how come this crippled version got through in the first place?
<cjwatson> because the test suite doesn't catch this one, of course :)
<cjwatson> it only tests python itself rather than its interaction with pygtk ...
<infinity> mnemo: Two reasons... 1) The suite disables/ignores tests based on configure options... And more importantly, 2) I'm pretty sure the package ignores suite failures. :P
<mdz> mnemo: the crippling issue is that this version broke compatibility with extension modules
<wgrant> Is it actually crippled, or did it just break ABI due to the Unicode format change?
<mdz> mnemo: the modules built with python itself (and tested by the test suite) naturally aren't affected
<mdz> wgrant: the latter
<wgrant> mdz: Right.
<wgrant> So the test suite couldn't catch it.
<infinity> wgrant: ABI break, as well as breaking anything relying on certain unicode functions... But the suite wouldn't catch the former, and probably doesn't test the latter when said functions are intentionally disabled.
<geser> what about packages which got build with the "broken" python? need they a check if they still work with the fixed python?
<mdz> geser: good point, we should check if there are any such packages
<wgrant> infinity: Mm, indeed.
<mdz> infinity: can you check if any extension modules were built with -1ubuntu5?
<infinity> mdz: I'll look into it.  That might require cprov DB magic.
<mnemo> I guess/hope somebody will write a sanity test that runs on each upload that makes sure this bug can't happen again
<infinity> mdz: cprov and I are on it.
<mdz> infinity: thanks
<mvo_> mdz: just confirmed that update-mnager on release upgrade will show a error (403) but rolls back just fine
<pitti> BUGabundo: I know, just wait until the fixed python is in
<mdz> mvo_: thank you
<BUGabundo> okay
<mdz> seb128: have you notified pedro about the python2.6 issue?
<seb128> mdz: he didn't start his day yet
<seb128> mdz: I will do when he's online
<mdz> I guess he will want to know about it when he starts looking at bugs :-)
<seb128> right
<seb128> good point, I will do when he's there
<BUGabundo> really bad timing ... since its beta! ppl will be lockout of updates if they get it!
<BUGabundo> hope not to many new users testing beta! or they will learn the hard way how to use CLI and APT eheh
<seb128> BUGabundo: the binaries have been blocker for download
<seb128> blocked
<BUGabundo> I got them
<BUGabundo> and so may have users who upgraded before the 403
<BUGabundo> or if some mirrors have rsynced them
<seb128> BUGabundo: right, some have
<seb128> nothing we can do about that now
<BUGabundo> yep
<BUGabundo> np, we are aware on +1
<BUGabundo> and letting users go their way, just fine
<seb128> they can easily use synaptic to upgrade though
<BUGabundo> seb128: New Users is the key word
<BUGabundo> synaptic is a bit advanced for them
<Laney> seb128: I will review and sponsor libpst shortly
<BUGabundo> but then again UM and Update-notifier now don't work
<seb128> BUGabundo: right, but as said not a lot else we can do for those who have the new version
<BUGabundo> so probably they will update in a week
<seb128> Laney: thanks!
<infinity> mdz, cjwatson: What do we want to do about binaries that were built with the bad python?  Blind rebuilds?
<james_w> BUGabundo: we can publish instructions about fixing up the problem once it is fixed
<james_w> infinity: anything Architecture: any might as well be rebuilt
<mdz> james_w: I updated the description of the bug with preemptive instructions for when the update is available
<mdz> infinity: james_w++
<james_w> ah, thanks mdz
<BUGabundo> james_w: unfortunately new users DON'T subscribe to announce ML
 * james_w realises he isn't subscribed
<mdz> I think an email to ubuntu-devel-announce is probably in order
<BUGabundo> mdz: unfortunately new users DON'T subscribe to announce ML
<james_w> BUGabundo: I didn't say where
<mdz> BUGabundo: you said that already.  if you want to post somewhere else, please feel free.
<BUGabundo> eheh even james isn't
<maco> mdz: agreed
<james_w> and we can spread the information around
<infinity> james_w: Okay, looks like our only arch:any fallout is python-hildon on lpia.
<maco> maybe devel-discuss as well?
<BUGabundo> is any forum moderator around?
<maco> with a pointer to please subscribe to -announce
<BUGabundo> most new users go there!
<mdz> maco: agreed
<maco> BUGabundo: me!
<BUGabundo> maco can you push the info there?
<dholbach> BUGabundo: microblog it! :)
<maco> yep
<mnemo> the most important thing is to create a regression test at the gates so that this cannot happen again... a bug that breaks both update-manager and apport at the same time is worth taking some time to prevent
<BUGabundo> dholbach: was jyust going to do it
<BUGabundo> LOL
<maco> dholbach: james did and 3 of us have redented it
<mdz> mnemo: yes, though that can wait until next week
<maco> anybody still using twitter?
<maco> the twitter ubuntu users should be told too...
<BUGabundo> done
<BUGabundo> just got done on identica jaiku, qaiku, twitter
<BUGabundo> identica got it 4x
<mdz> dholbach: james_w could you hit the mailing lists?
<mdz> er, one of you ;-)
<BUGabundo> we need users, annount, devel-discuss
<BUGabundo> I don't have permitions for announce
<james_w> mdz: sure thing, I was going to wait for the fixed binaries to be available at least on the primary mirror, what do you think?
<maco> http://ubuntuforums.org/forumdisplay.php?f=352 <-- hows that?
<dholbach> james_w: sounds like a good idea
<BUGabundo> maco: please state its BETA
<BUGabundo> it will grab more attention
<james_w> maybe this would be a good time to re-visit bug 240445 :-)
<ubottu> Launchpad bug 240445 in update-manager "Please provide an informative error message when an update is restricted due to having severe regressions" [Wishlist,Triaged] https://launchpad.net/bugs/240445
<maco> its in the jaunty forum
<BUGabundo> and mention the bug report
<BUGabundo> and copy the instructions
<maco> ok the dent version is all ive seen so far, so lemme scroll up and find what youre talking about
<wgrant> maco: Can we point other threads to that for instructions when it's fixed?
<maco> wgrant: i'm going to lock it but any mod can update it while its locked
<mdz> james_w: ok by me
<wgrant> maco: Great.
<BUGabundo> ok even twitter has now been hit twice
<BUGabundo> that just leaves MLs
<maco> ok i cant find the long version of the instructions
<infinity> james_w: While you're feeling helpful, want to do a rebuild-only upload of python-hildon?  I've already ensured the buildds won't build anything against the broken python.
<BUGabundo> maco bugs 277903
<ubottu> Launchpad bug 277903 in usb-creator "Missing Operating System [message at boot]" [Undecided,Confirmed] https://launchpad.net/bugs/277903
<maco> what am i supposed to say for the -v on that thread?
<BUGabundo> bug!! worng bug
<dholbach> bug 349467
<ubottu> Launchpad bug 349467 in python2.6 "Many python programs fail with: "undefined symbol: PyUnicodeUCS4_DecodeUTF8"" [Critical,Fix released] https://launchpad.net/bugs/349467
<james_w> infinity: sure thing
<BUGabundo> thanks
<BUGabundo> maco:  users are already asking for more info on the forum
<maco> i see that
<maco> i just locked it and replied to the one asking about un-upgrading with a dpkg --force-downgrade explanation
<BUGabundo> thread closes
<BUGabundo> *closed
<BUGabundo> "The problem is corrected in version 2.6.1-1ubuntu5.1. Note that since Update Manager is one of the affected programs, users affected by this bug will need to upgrade using apt-get in a terminal: $ sudo apt-get update && sudo apt-get dist-upgrade"
<BUGabundo> from the bug report would suffice!
<lool> tjaalton: erf :)
<lool> tjaalton: let's just forget about nvidia, but it affects the opensource dri drivers; at least mplayer gl output and elisa
<tjaalton> lool: yeah, hopefully 7.4 fixes it
<cjwatson> mm, I don't think we need to advertise --force-downgrade here, it could get pretty complicated
<lool> tjaalton: I'm counting on them to identify the issue though; they say the upstream tree works
<lool> tjaalton: are we moving to 7.4??
<tjaalton> lool: hope so
<tjaalton> it's a bugfix release
<lool> Crap, I told Intel we wouldn't
<cjwatson> surely not a new upstream release of X for Jaunty now, after beta?
<tjaalton> a bugfix release of mesa
<tjaalton> we have the first devel release of that series
<maco> BUGabundo: i didnt know the bug #
<maco> BUGabundo: there were like 4 bugs linked
<wgrant> maco: You could point out that python2.6 and python2.6-minimal are the relevant packages.
<tjaalton> even numbered ones are bugfix releases
<maco> cjwatson: ok, ill remove that
<BUGabundo> maco all top new posts of the forum are related to python breakge
<lool> bryce: Around the 17th of February you told we would go with 7.3?!?
<tjaalton> lool: that was loong ago :)
<tjaalton> no 7.4 in sight
<lool> Yeah, but I committed to it for Intel developing their psb driver
<tjaalton> how does it concern psb?
<lool> They have a mesa backend for it
<cjwatson> 17th of February> i.e. before feature freeze, which now is distinctly not
<mdz> python2.6 is built for amd64, i386 still building
<tjaalton> ok, so another release of a devel series of mesa?
<maco> alright alright, the thread now says what buga posted along with "your mirror might not have it yet. here's how to check" and apt-cache policy stuff
<mnemo> the most important thing is to create a regression test at the gates so that this cannot happen again... a bug that breaks both update-manager and apport at the same time is worth taking some time to prevent
<mnemo> ops sry
<tjaalton> I won't waste time merging it if there's no hope to get it in
<mnemo> didnt mean to retype that :o
<cjwatson> the only facilities we have for testing are things which are done in the package build
<cjwatson> in general a package build can do pretty extensive things, but python can't easily go off and install pygtk
<maco> BUGabundo: people dont read the danged stickies *grumble*
<lool> tjaalton: I personally don't want to judge the quality of 7.3 versus 7.4; I don't have the slightest idea of the size of the diff between one and the other, it's just that I'm a bad position that I confirmed we would use 7.3 devel release -- which actually surprized Intel folks
<cjwatson> so the test would have to be quite carefully targeted
<mdz> tjaalton,lool: this is probably worth discussing on ubuntu-devel@, surely not something we would take a quick IRC decision on
<lool> Anyway it's looking unlikely that we get psb *in* jaunty so probably no weight in release matters
<lool> tjaalton: If you think there's value for mesa 7.4, can you bring it up on @-devel?
<tjaalton> mdz, lool: ok, I'll see what the diff looks like and post something
<tjaalton> but upstream is very strict to only include bugfixes
<tjaalton> for instance they declined to bump the max texture size for i965
<tjaalton> er, include the commit to bump it
<mdz> tjaalton: even bugfix releases can have massive regressions :-)
<tjaalton> mdz: yes, but in this case I doubt it could go worse ;) (there are a number of bugfixes for intel)
<mdz> pitti: where can I get a copy of your mutt config which colors the index according to bug status etc.?
<pitti> mdz: http://piware.de/tmp/muttrc
<mdz> pitti: thanks!
<pitti> mdz: you're welcome
<pitti> mdz: the original idea is from bryce, but I don't see his config on his people.u.c.
<jpds> mdz: Prehaps: http://bryceharrington.org/files/lp-mutt-colors ?
<infinity> mdz: Publishing i386, amd64, lpia, and hppa right now.
<mdz> infinity: thanks
<geser> https://lists.ubuntu.com/archives/ubuntu-devel/2008-December/027019.html has an example how to do the colouring in mutt based on the LP header instead of scanning the whole body
<mdz> geser: that's handy
<mdz> and more accurate
<mdz> geser: there is a typo on the second line (mismatched single/double quote)
<mdz> it doesn't match duplicates though
<mdz> that doesn't seem to be in the headers
<Mirv> Ng: (ping blog.ubuntu-fi.org fixing?)
<mnemo> infinity: how long until I should be seeing the python fix in apt-get ?
<infinity> mnemo: 20ish minutes, maybe?
<infinity> mnemo: I'll poke #-devel when it's pushing to mirrors.
<mnemo> okok
<mnemo> great
<BUGabundo> nice to know
<Mirv> (well, I was on wrong channel but anyway, message delivered)
<slytherin> Considering that grub-installer is supposed to offer grub2 as an option, shouldn't grub2 be in main?
<liw> mvo_, https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/147758 looks like a temporary problem in some packages in gutsy beta, since fixed, and could be closed -- do you agree?
<ubottu> Ubuntu bug 147758 in update-manager "upgrade from feisty to gutsy beta errors" [Low,Confirmed]
<mvo_> liw: agreed
<seb128> liw: can you get those computer-janitor translation issues fixed to jaunty
<liw> seb128, aye, I'll do that next
<seb128> thanks
<BUGabundo> do 8.04 users upgrading also get it by the python bug?
<infinity> New python2.6 binaries are being pushed to mirrors, FWIW.
<james_w> thanks infinity
<seb128> infinity: when will the index be updated?
<infinity> seb128: As in Packages.gz?
<seb128> infinity: ie when can I apt-get update and get those?
<seb128> infinity: yes
<infinity> seb128: It's updated too.
<infinity> seb128: Just a question of when the mirror pulse is done.
<seb128> infinity: apt-get update doesn't agree
<seb128> oh ok
<infinity> seb128: Yeah, cause you're not using cocoplum. :)
<seb128> right
<infinity> seb128: Give it a few minutes at least. :P
<liw> hm, launchpad doesn't show the bug to me anymore
<apw> pitti, in the unlikely event you go to review my suspend-apport fixes branch, could you just hold off.  i may have just figured out how to trigger the apparent false-positive
<cjwatson> slytherin: grub-pc is in main, and that's the package grub-installer actually installs. grub2 is a transitional package.
<pitti> apw: oh, I didn't get a merge request, so I wasn't going to
<cjwatson> slytherin: see e.g. 'apt-cache show grub2'
<pitti> apw: I'm currently working on apport, though, I'll probably do another upload today
<apw> ok thanks ... i have something which is triggering falsies, if you would could you check in with me before you close the upload
 * liw seems to have entangled himself in too much launchpad complexity (long url, complicated search) and goes back to simple search
<pitti> apw: check what?
<apw> just let me have a chance to sneak a change in if its ready :)
<pitti> apw: sure, no problem
<apw> the bug has been causing a lot of false reports, or so it was thought, if its found to be really false
<apw> it would help to get them squashed, a simple 1 line fix
<apw> though i may have just figured out how it really can be triggered.  if so its real
<BUGabundo> apw: btw after suspend/resume cycle I got a kernel oops window asking me to report it!
<BUGabundo> is that normal?
<apw> after a good one?  what was the oops?  too slow?
<Mithrandir> pitti: hmm, vaguely offtopic here, but I'll risk it.  What's really the purpose of the indicator applet?  Its description is roughly "display stuff", which doesn't say why it's useful and why I want it on my panel.
<BUGabundo> apw: no idea!
<BUGabundo> the window wasn't very clear
<BUGabundo> only showed two lines of text at time
<BUGabundo> making it hard to read
<slytherin> cjwatson: right, my mistake. sorry for bothering.
<directhex> Mithrandir, you don't like stuff?
 * apw watches to see if Mithrandir gets an answer ... as i have an envelope in there and it won't go away
<pitti> Mithrandir: it tells you about incoming pidgin messages, or mails from evo (doesn't work for my setup, though)
<BUGabundo> apw: I did send it, so you should have a log of it some where!
<mnemo> python fix available through main apt-get (not sure about mirrors)
<BUGabundo> lunch now... back latter
<pitti> Mithrandir: it's not doing a lot yet, though
<seb128> pitti: it indicates emails count from evolution for INBOX only and when evolution is not focussed when you do receive those
<seb128> ie, click send&receive, switch workspace
<pitti> ah, ok
<pitti> I don't keep evo open
<pitti> I had expected it to listen to e-d-s
<seb128> e-d-s doesn't do emails right now
<Mithrandir> pitti: I removed it from the panel, but I still seem to get notifications just fine?
<seb128> Mithrandir: it's orthogonal to notifications
<pitti> Mithrandir: yeah, notifications and messaging indicator are orthogonal
<apw> pitti, if it shows an envelope forever is that something i should file as a bug
<pitti> apw: please do
<pitti> apw: it seems to be erratic for me
<pitti> sometimes I have the envelope with just "pidgin" in it
<pitti> sometimes (like just now), I don't
<Mithrandir> I have the envelope with just pidgin, since I don't use evo.
<seb128> you should get the icon when pidgin is running
<Mithrandir> and it looks like it's highlighted all the time, which is odd.
<apw> yeah i think it has an odd box round it or something
<pitti> well, I shouldn't really get both the pidgin and MI icon in my tray
<seb128> Mithrandir: the idea is that unread messages will be listed in the applet
<seb128> with the timestamp of when you received those
<Mithrandir> pitti: sorry for being dense, what do you mean by notifications and messaging indicator are orthogonal?  It should basically duplicate what the pidgin icon in the tray is doing already?
<mdz> I've got the python update, and can confirm that it doesn't break the world (I never installed the broken version)
<apw> seb128, so its interaction with pidgeon must be broken as i have none
<mnemo> i had the broken python and the update fixed by system... totem, apport and update-manager now works again
<Mithrandir> seb128: should it then always have an icon visible when I don't have any "unread" messages in pidgin?
<seb128> mdz: how did you do that! is there a proxy in the office or something? I still don't get it there
<seb128> Mithrandir: yes, an email icon
<pitti> Mithrandir: notifications are the bubbles that pop up if something happens; MI collects instant messages/emails which you got while you were away/not seeing evo/pidgin window
<seb128> when you have something unread you get an another icon
<mdz> seb128: I got it from archive.ubuntu.com
<mnemo> seb128: do you have a mirror configured in software sources?
<mnemo> (i got if from apt-get)
<seb128> Mithrandir: in new installs pidgin has no notification area icon
<mdz> seb128: I am at home
<seb128> Mithrandir: the indicator is the way to open the buddy list
<Mithrandir> seb128: ok, that makes more sense then, except the icon is about three times as wide as any other icon.
<seb128> mnemo: no
<Mithrandir> and it has a border around it.
<seb128> Mithrandir: that's a bug ;-)
<Mithrandir> (and is drawn in a different style than all my other icons.)
<slytherin> Mithrandir: in short, you could say it does not match other icons from the theme. :-D
<liw> so is there a package I can download to fix the Python "PyUnicodeUCS4_DecodeUTF8" problem while waiting for my mirror to get updated?
<ScottK> liw: Presumably you get get the .deb off of LP.
<Mithrandir> liw: it's updated on archive.u.c now, so just use that?
<liw> Mithrandir, duh, of course
<ma10> sd
<mdz> slangasek: release meeting in a few?
<slangasek> mdz: yes
<pitti> hey slangasek
<asac> ogra: you saw that font regression for which we added the "no-bitmaps" thing
<asac> ogra: do you remember which site?
<apw> pitti was there a bug for the 'tags arn't very sensible on suspend/hibernate/resume apport bugs' do you know
<pitti> apw: I haven't seen one
<pitti> I don't think so
<apw> ok tha
<apw> t
<apw> thanks, will make one
<pitti> thanks; please sub me to it
<kwwii> cjwatson: funky question, but it's only happened to me once and I can't exactly test the experience. Assuming you are the person to ask:  when you boot and there is a file system failure does it go back to a console and show the text or is it displayed on the usplash bg?
<cjwatson> kwwii: pitti implemented this - but IIRC it's displayed as text in usplash
<cjwatson> oh, if it actually fails, that drops you to a shell prompt
<cjwatson> as in a non-correctable failure which requires manual action
<cjwatson> this is in /lib/init/usplash-fsck-functions.sh
<kwwii> cjwatson: right, exactly...that is what I thought. thanks!
<pitti> right
<sladen> kwwii: you can replicate this quite easily by selecting 'ext4' doing install ;)
<sconklin> pitti: during an upgrade from intrepid to jaunty, when apport was updated It falsely detected a kernel crash and wanted to submit a report. Is there upgrade logic to avoid resubmitting old reports?
<kwwii> sladen: lol, right...anything for documentation!
<pitti> sconklin: hm, where did the kernel crash came from then?
<pitti> sconklin: we don't currently have such a logic, no
<pitti> sconklin: I guess we could teach update-manager to remove all .crash files on upgrades, but I'm not sure whether that would have some unintended consequences
<sconklin> pitti: I'm trying to figure out. Sadly it was very early this morning and I just said 'no' before I thought to investigate.
<sconklin> pitti: then it was certainly an old crash file left over from testing I was doing weeks ago. I'd hate for us to get resubmissions of things from upgrades.
<sconklin> Plus, it might be confusing to some to get a "your kernel has crashed" pop-up during an upgrade
<pitti> yeah, I wonder how that happened
<pitti> if you saw the report before, it shouldn't have been showed a second time
<pitti> sconklin: it could happen by something that touch /var/crash/*, but that sounds unlikely for any .postinst script
<sconklin> pitti: what if the crash happened while the previous config was set to not submit, and the new one has that enabled by default?
<pitti> sconklin: oh, of course; that would do it
<pitti> sconklin: /etc/default/apport only controls the signal and python crashes
<pitti> if something else writes .crash files, such as apw's suspend testing script, those wouldn't have been reported in intrepid
<pitti> but then they were never displayed before
<sconklin> I have a .crash file from the linsmith package in /var/crash
<sconklin> But the dialog that popped up said kernel crash
<apw> pitti, nope it doesn't
<pitti> mvo_: how easy would it be to rm /var/crash/* on upgrades? I'm a little hesitant to do it in apport's postinst based on version comparison, since that would break backports
<mvo_> pitti: trivial
<mvo_> pitti: on release upgrades I assume?
<pitti> mvo_: yes
<mvo_> pitti: it just needs to check for the ones that happen during the upgrade I guess
<sconklin> pitti: I vote for removing it. If we end up trying to debug reports against a system that's been upgraded since the crash, we could waste a lot of time
<pitti> mvo_: I'm not really sure how else to do that without killing legitimate ones
<mvo_> pitti: so rm right when the upgrade starts (before the first package is installed)
<pitti> mvo_: is there a time when we know that we'll start the upgrade, but didn't install any packages yet?
<pitti> mvo_: i. e. coudl they be removed at that time, so that we wouldn't loose package failures during upgrade, but get rid of old .crash reports/
<pitti> sconklin: agreed
<pitti> mvo_: exactly
<mvo_> pitti: ok, I will add this
<pitti> mvo_: want a bug report for this?
<mvo_> pitti: no, I just add it now
<BUGabundo> pitti: can't reproduce bug 347874 anymoe
<ubottu> Launchpad bug 347874 in apport "double click on .crash doesnt work" [Undecided,New] https://launchpad.net/bugs/347874
<pitti> mvo_: many thanks! *hug*
<pitti> sconklin: ^ seems that's done then
<pitti> BUGabundo: so much the better :)
<BUGabundo> both from cli and double click it works
<sconklin> nice, thanks!
<BUGabundo> shall I or you close the bug?
<pitti> BUGabundo: please do; thanks for checking again
<BUGabundo> I could reproduce it repetedly during almost one week
<directhex> hm, "could not install adduser" on an upgrade from intrepid
<directhex> ditto libkeyutils1
<directhex> lots of things infact
<ScottK> directhex: Does it start with Python something not being installable?
<marctww> Anyone here have experience with what looks like a redraw-bug with nvidia-177.82 driver in Ubuntu 8.10?
<directhex> ScottK, i don't think so. i don't have the bad version available in apt-cache policy
<ScottK> OK.
<slangasek> dtchen: is bug #330814 the same as bug #343254?
<ubottu> Launchpad bug 330814 in linux "snd_pcm_avail_update() returning absurd values causes PulseAudio to abort" [High,Fix released] https://launchpad.net/bugs/330814
<ubottu> Launchpad bug 343254 in linux "pulseaudio: alsa-util.c: snd_pcm_avail_update() returned a value that is exceptionally large" [High,In progress] https://launchpad.net/bugs/343254
<marctww> any ideas?
<directhex> "apt-get -f install" seems to have rescued dpkg from the brink of "aborting!"
<marctww> ?
<directhex> marctww, i know 180 drivers have a redraw bug. didn't think 177 did
<marctww> yea :(
<marctww> Apparently it does
<marctww> directhex: it does man
<directhex> terminals not updating properly?
<sbeattie> seb128: can you look at the debdiff in bug 270374 (see comment 32) and see if its worth uploading or comment?
<ubottu> Launchpad bug 270374 in tsclient "Workflow report: tsclient - on inputing a computer name then hitting enter, list stays on screen and steals input" [Medium,Confirmed] https://launchpad.net/bugs/270374
<marctww> directhex: Not just terminals, everything.
<marctww> Then after a while, window decorations fly out the window.
<marctww> I restart X and world domination returns.
<seb128> sbeattie: is there any hurry?
<cjwatson> liw: FYI, Matthew Garrett got a patch into the kernel upstream to default to relatime unless you explicitly say strictatime
<cjwatson> liw: so that may be less relevant in computer-janitor in future
<sbeattie> seb128: only that I'd like to be able to stop tracking it (it's tagged as a regression) and have it fixed for jaunty; it has a debdiff that people claim works for them (which is a one-liner patch), so hopefully doesn't require significatn review.
<seb128> sbeattie: it's on the sponsoring list and I will have a look but not right now
<seb128> thanks for pointing it
<hyperair> is anyone noticing that vim is not symlinked to vim.tiny in the livecd?
<sbeattie> seb128: that's fine.
<sbeattie> thanks.
<directhex> yay, World of Goo no longer causes X to segfault. there's one Jaunty feature for the changelog
<bluefoxicy> http://stackoverflow.com/questions/175854/what-is-the-funniest-bug-youve-ever-experienced/175997#175997
<pitti> seb128: handling current i386 retracer failure (hash sum mismatch); I'll fix it properly this time
<seb128> pitti: ok
<bluefoxicy> ^^^ I don't know about that, but for the longest time I thought the icon for Update-Manager was supposed to be a representation of someone giving me the finger
<bluefoxicy> like, for 2 whole releases
<directhex> bluefoxicy, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276144
<ubottu> Debian bug 276144 in mozilla-thunderbird "mozilla-thunderbird: Breaks formatting of cowsay-based signature" [Minor,Closed]
<bluefoxicy> directhex:  haha
<directhex> ooh, i have a new bug to file
<directhex> which package contains those new gtk themes?
<asac> heh cowsay fun.
<directhex> asac, it was your bug!
<cjwatson> hyperair: that was an intentional change; vim-tiny is much more like vi than vim. Just use vi
<directhex> asac, back in 2004, when i were a lad
<cjwatson>   * [f7bfa57] Don't install vim alternatives for vim-tiny.  vim-tiny is built
<cjwatson>     to act like vi, so the vim alternative just causes more confusion than
<cjwatson> from vim 2:7.2.049-1
<cjwatson>     it's worth (by default).
<hyperair> cjwatson: i see.
<asac> directhex: yeah. 2004 feels like yesterday ;)
<asac> to me
<directhex> in 2004 i was just starting out, fresh-faced, on loonicks!
<directhex> partly due to enhanced framerates in UT2004 compared to Windows
<directhex> anyway, bug filin' time
 * hyperair pokes dholbach -- bug #349678
<ubottu> Launchpad bug 349678 in nautilus-share "Please sync nautilus-share (0.7.2-4) from Debian unstable" [Undecided,New] https://launchpad.net/bugs/349678
<dholbach> hyperair: I'm a bit busy right now - I hope somebody of the other sponsors will pick it up in a bit or I do it later on
<hyperair> dholbach: oh okay
<mterry> Does http://summit.ubuntu.com/uds-karmic/interest/ work for anyone?  Still says I'm not registered, but I registered quite a while ago
<Keybuk> -Wextra is insane
<Keybuk> "put braces around empty if statement" WHY?! WHY?! WHY SHOULD I DO THAT?!
<calc> slangasek: do you have time to look at bug 299161?
<ubottu> Launchpad bug 299161 in memtest86+ "RFE : Please upgrade to Memtest86+ 2.11 (Jaunty)" [Wishlist,Triaged] https://launchpad.net/bugs/299161
<cjwatson> ah, that one I agree with
<cjwatson> if (foo); { } is an easy typo to make
<cjwatson> but anyway, -Wno-empty-body
<seb128> slangasek, pitti: opinion on the python-gnome2-desktop gnomeprint and gtksourceview1 binary splits
<seb128> gnomeprint has 1 rdepends in the archive
<seb128> gtksourceview 5 rdepends
<seb128> I mean the python binding for those
<Keybuk> cjwatson: but I don't do that
<Keybuk> I do
<Keybuk> if (foo)
<Keybuk>     ;
<Keybuk> it shouldn't warn about *that*
<seb128> that would win us some space and allow to move libgtksource libgnomeprint libgnomeprintui out of the CD
<pitti> seb128: getting rid of gnomeprint is a win by its own, too
<cjwatson> Keybuk: yeah, I very much doubt the optimiser can spot that. I think I've probably attuned my coding style to -Wextra a little. :-)
<cjwatson> optimiser? I mean whatever produces the warnings
<cjwatson> it'll be working off the AST
<Keybuk> -Wall -Wextra -Wno-empty-body -Wno-missing-field-initializers -Wno-unused-parameter
<seb128> pitti: right, slangasek was just a bit concerned that the change might break thing which depends on the unsplitted versions out of the archive
<Keybuk> seems the most sensible combination so far
<pitti> apw: I'm about to do an apport upload; shall I merge anything?
<pitti> apw: if not, don't worry, I can always upload another one (apport uploads are cheap)
<apw> i am still testing ... will there be a chance for another upload later
<apw> fair enough then
<pitti> apw: I just want this update in ASAP, to get the retracer in top shape for the expected beta crash reporting flood
<pitti> apw: sure, no hurry
<apw> yeah don't wait if its something cool going in
<Keybuk> cjwatson: I think I'd be less hateful about -Wempty-body if I didn't *also* use -DFORTIFY_SOURCE=2
<pitti> seb128: okay, I think apport-retrace properly catches Packages.gz hash sum mismatches now
<seb128> pitti: excellent
<cjwatson> Keybuk: mm, that one I'm not going to attempt to justify :-)
<directhex> oh hells yes. jaunty usplash seems to understand how not to look like distilled ass when faced with a high-res widescreen framebuffer
<directhex> *there's* a reason to upgrade
<Keybuk> though shouldn't if (foo); { } warn you about the anonymous block?
<pitti> kwwii: ^ speaking about that, I noticed the same on my wife's 1920x1200 monitor; looks really good now
<cjwatson> Keybuk: anonymous blocks are sometimes useful as a container for more-local-than-function-scope variable declarations
<cjwatson> at least in pre-C99 code
<Keybuk> cjwatson: but the syntax for anonymous blocks is ({ ... }) :p
<kwwii> pitti: hehe, yeah..I added configs up to 1920 (the size of my new monitor)
<Keybuk> tests/test_node.c:573: error: ânodeâ may be used uninitialized in this function
<Keybuk> *sigh*
<cjwatson> Keybuk: err, sorry, I misunderstood what you meant. { } in the example above is not an anonymous block, then
<cjwatson> it's just a block
<Keybuk> cjwatson: but you can't just have a block suspended in mid-air in C
<directhex> who to thank for that...
<cjwatson> sure you can
<Keybuk> cjwatson: you really can't <g>
<directhex> usplash (0.5.30) jaunty; urgency=low
<directhex>  -- Martin Pitt < martin.pitt@ubuntu.com>   Wed, 04 Mar 2009 21:41:36 +0100
<Keybuk> C != C++
<directhex> cake for pitti!
<cjwatson> Keybuk: cite
<cjwatson> I can't find my K&R but I am quite certain it's valid
<Keybuk> cjwatson: you may be right according to C99, sorry
<cjwatson> I am right according to C89
<Keybuk> then why do people use do { ... } while (0) when they're trying to be "standards compliant" ?
<cjwatson> http://paste.ubuntu.com/139043/
<cjwatson> people don't use that for standards compliance
<apw> Keybuk, thats about making it behave like a statement
<cjwatson> they use it so that macro expansion won't screw up
<cjwatson> if (foo) BAR;
<apw> right
<Keybuk> apw: according to C99 a block *is* a statement
<cjwatson> Keybuk: this is a FAQ
<Keybuk> cjwatson: I don't follow?
<cjwatson> Keybuk: it doesn't quite work the same in all contexts
<cjwatson> let me dig up the reference for you
<apw> Keybuk, yes, _but_ it has no ; at the end
<apw> so a {}; is two statements
<Keybuk> true
<apw> a do{}while(0); is one
<apw> and thats the reason
<Keybuk> but an empty statement is allowed in C too ;)
<cjwatson> why is the C FAQ site so slow just when I need it?
<Keybuk> cjwatson: I was thinking the same thing ;)
<cjwatson> oh yes of course
<cjwatson> if (foo) BAR; else other(stuff);
<cjwatson> misparse if BAR is just a block
<Keybuk> ahh
<Keybuk> that does make sense
<apw> cjwatson, :)
<Keybuk> cjwatson: neat, thanks
 * Keybuk goes back to figuring out how to persuade gcc that the variable *really* cannot be used uninitialized and that it's silly optimiser is WRONG
<apw> Keybuk, assign something to it at init and be happy
<Keybuk> apw: yeah, but I keep having to do that all the time
<Keybuk> and it annoys me
<Keybuk> something about the optimiser doesn't like my "count mallocs and run that many times" loop
<apw> the optimiser only looks to see if there is a route thorugh the code from the init to a use which has no init
<apw> i doesn't work out if there is a possible route
<Keybuk> but there isn't a route to one which has no init
<apw> Keybuk, got an example
<apw> pastebin it?
<apw> if nothing else i can say, yep its stupid sorry
<Keybuk> http://pastebin.ubuntu.com/139046/
<cjwatson> Keybuk: (C FAQ 10.4, BTW)
<cjwatson> now I've managed to get at it
<apw> Keybuk, its stupid, so you have written some 'before and after' clauses for the thing
<slangasek> seb128: does gnomeprint still have any reverse-deps, or was that fixed with the gnome-games upload?
<sladen> apw: can't you just hit with an __attribute__ ?
<slangasek> seb128: I think whatever I said before when we talked about this is probably still valid; I think that was "gnomeprint: yes, gtksourceview1: no"}
<seb128> slangasek: what I said before, 1 rdpends for gnomeprint
<Keybuk> apw: which is stupid? gcc or my macros? :p
<apw> the compiler, i think what i am seeing is some code to put things before and after the block which will follow in the source
<Keybuk> apw: exactly
<apw> and it will happly analyse that as "if i take the first branch every loop then its not defined, bad"
<apw> even though its patently false
<Keybuk> but it isn't used in the first branch
<Keybuk> the weird thing is that the simplest "int" expression of this I can do doesn't exhibit the bug
<apw> right but you use it _after_ the loop
<apw> so it can decide the output lloop only took the third way and the ineer only the first
<apw> and that means you use unitialised data.  its wrong
<Keybuk> right, it doesn't seem to observe that the inner if will always have all three expansions
<Keybuk> but it's the outer loop it really seems to have an issue with
<Keybuk> because the warning is still there if you take the inner loop out
<Keybuk> TEST_ALLOC_FAIL {
<Keybuk>   node = x;
<Keybuk>   // do something with node;
<Keybuk> }
<Keybuk> fails ;)
<slangasek> calc: is the comment in the bug description about needing gcc-4.1 still applicable?
<slangasek> calc: because that would be a deal-breaker; gcc-4.1 is universe-only, and we're not going to re-promote it to get a newer memtest86+ in the archive
<calc> slangasek: it was worked around by iirc colin with -O1 which made it work
<calc> slangasek: yea colin fixed it with O1 in 2.01-1ubuntu2
<slangasek> calc: ok, and that fix is verified to also solve the problem for 2.11?
<calc> slangasek: yes, i tested it and it works
<calc> slangasek: when miscompiled it shows up as lots of errors in the tests, i read through the bug report to check on that part
<slangasek> calc: did you also test a known-broken version to be sure the problem manifests on your hardware? :)
<calc> slangasek: this is essentially just a merge from debian with the only part still being applied being no stack protector
<calc> slangasek: didn't test with -Os, no
<mathiaz> stgraber: what's the state of openvz in jaunty?
<calc> slangasek: i can recompile it in broken form to see if it fails in the same manner as the old version
<slangasek> calc: might be a thing to try just to be sure; but not a blocker for the FFe
<calc> ok
<calc> i'll see what it does here in a minute
<calc> ok, brb, going to test via my laptop
<MacSlow> pitti, hi there
<MacSlow> pitti, what's the latest time today to hand over a new release-tarball of notify-osd?
<calc> slangasek: yep immediate failure with Os
<slangasek> calc: ok, cool
<calc> it works but it causes athe tests to fail
<calc> so eg the ui shows up but as soon as the tests run continous red failure messages scroll by
 * slangasek nods
<calc> slangasek: what is the next step before i upload the package?
<slangasek> calc: uh... sign it? :)
<slangasek> calc: I acked the bug
<calc> slangasek: oh ok :)
<calc> slangasek: thanks
<IntuitiveNipple> If I need to provide a custom-kernel for testing and the user is only able to use live-CDs, is it enough for me to replace the kernel images and supporting files in an ISO image, or will I also need to rebuild the casper squashfs?
<jordi> Hi,
<jordi> slangasek: I don't know how useful this would be or if it's way too late in the game for jaunty, but today I uploaded nano 2.0.9-2 which changes a default option by popular demand both in Debian and Ubuntu, and would fix issues Ubuntu people have been having with line wrapping in config files.
<jordi> slangasek: http://packages.qa.debian.org/n/nano/news/20090327T123206Z.html
<calc> slangasek: done
<stgraber> mathiaz: I have someone looking into it here (Michael Jeanson) though we're mostly working on scripts for LTS releases rather than spending too much time on the kernel work for non-LTS releases
<cjwatson> IntuitiveNipple: replacing the kernel image will be fine if the module ABI is compatible with the existing one, but otherwise you'll need to rebuild the squashfs to cope with the kernel modules in there
<stgraber> mathiaz: upstream OpenVZ is willing to help for LTS releases, for others we could easily provide vanilla kernels patched with OpenVZ and some drivers from Ubuntu's kernel but patching on top of a regular Ubuntu kernel is almost impossible
<cjwatson>    * As we're modifying the manpages, we need to temporarily build-dep
<cjwatson>      on groff.
<cjwatson> jordi: blink. why?
<stgraber> mathiaz: due to a number of issues with apparmor and other big patches like that
<cjwatson> do you ship postscript versions of the manual pages or something?
<IntuitiveNipple> cjwatson: Thanks alot... that will help enormously then
<cjwatson> jordi: it's a shame there's no --wrap option, if nowrap is to be made the default
<pitti> MacSlow: I can still upload it
<jordi> cjwatson: .html versions are generated at build time
<pitti> MacSlow: is it released already?
<cjwatson> jordi: ah
<jordi> cjwatson: you can use unset nowrap, or meta-L to toggle it while inside nano
<jordi> cjwatson: gotta go, I just wanted to point this in case you want to consider it before it's even more late i nthe game
<kirkland> evand: https://bugs.launchpad.net/bugs/349440  .... really?
<ubottu> Ubuntu bug 349440 in kvm "SDL window disappears overnight" [Undecided,New]
<kirkland> evand: that sucks, haven't seen that one
<kirkland> evand: any messages in the terminal where you launched kvm?
<IntuitiveNipple> kirkland: that's an interesting one. I *think* I may have experienced that a while back now but thought nothing of it since there were some nvidia issues at the time.
<pitti> good weekend everyone
<kirkland> IntuitiveNipple: interesting ... i wonder if its something power-management related
<IntuitiveNipple> screen-saver maybe?
<kirkland> like the guest turning off the monitor
<kirkland> and qemu's monitor emulator says, "okay, sure, i'll power off the monitor...take that!"
<IntuitiveNipple> I wonder if there's anything in the .xsession log
<cjwatson> apw: FYI I put bug 290153 on the jaunty bug list since it was in the 8.10 release notes
<ubottu> Launchpad bug 290153 in linux "Fails to find boot device in Intel D945Gnt" [High,In progress] https://launchpad.net/bugs/290153
<fabbione> Nafallo: ping?
<apw> cjwatson, nnng thanks
<Nafallo> fabbione: pong
<cjwatson> pgraner: do you know if the issue "Cannot reactivate Intel 3945/4965 wireless if booting with killswitch enabled" from http://www.ubuntu.com/getubuntu/releasenotes/810 has been fixed in jaunty?
<fabbione> Nafallo: just got your invitation.. are you going to sponsor me to London for a party? ;)
<Nafallo> fabbione: lol. no. I only selected my Ubuntu group and invited everyone in case someone would be in London during those days :-)
<fabbione> Nafallo: yeah i did guess that much :)
<fabbione> Nafallo: have fun there
<Nafallo> fabbione: I bet we will have :-)
<cjwatson> asac: did we get round to re-enabling ath5k in network-manager? I'm assuming that the driver that was in backports for intrepid is in jaunty proper (though haven't checked)
<asac> cjwatson: we didnt disable ath5k
<OsamaK> Hello. Where can I find the recent Ubuntu Documentation source code.
<cjwatson> asac: oh, ok, so no further work needs to be done there?
<asac> cjwatson: not on network manager side
<asac> i think ath5k is still much better in backport modules
<asac> same for iwagn
<asac> i will check with rtg if there is anything we can do
<cjwatson> OsamaK: https://code.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-jaunty
<cjwatson> asac: if there's anything to be done for jaunty, please make sure there's a bug filed and targeted for jaunty
<cjwatson> asac: (just going through 8.10 release notes)
<asac> cjwatson: right ;)
<asac> cjwatson: you need to check with rtg what went into mainline from backport modules
<cjwatson> pgraner: similarly, "Wireless doesn't work after suspend with ath_pci driver", but there's no bug for that in the 8.10 release notes. Do you know if that's been fixed?
<cjwatson> surely it would all have been backported from something older than what we have in jaunty now?
<pgraner> cjwatson: rtg would be the best one to ask, I do think the killswitch was fixed.
<OsamaK> cjwatson, great. thanks.
<pgraner> cjwatson: we don't have madwifi in Jaunty (its all moved upstream now) something tells me its fixed. rtg would know for sure, he's out today but will be back on Mon.
<cjwatson> ok
<OsamaK> cjwatson, is there anyway to get the old po files? about-ubuntu (and others) is bit changed, and I want to add the newly-added thing without retranslate the whole strings.
<cjwatson> OsamaK: I haven't looked and I'm not a documentation guy myself, but I'm sure they could be extracted from bzr
<cjwatson> OsamaK: try #ubuntu-doc?
<kirkland> slangasek: do you a git commit hash for http://launchpadlibrarian.net/24416880/mdadm-316670.patch ?
<slangasek> kirkland: no, I pulled it from the debdiff
<slangasek> git, icky :)
<kirkland> slangasek: hehe
<kirkland> slangasek: i'll find it
<kirkland> slangasek: i'm building sbeattie a new deb, with just your pruned patch for his verification
<kirkland> slangasek: apw has confirmed that the other raid-degraded bug is in fact a kernel race condition
<apw> kirkland, yep.  i think i have the actual bug nailed now.  just building you some test kernels so you can confirm my testing
<kirkland> apw: cheers
<IntuitiveNipple> kirkland: that patch is 43aaf431
<kirkland> IntuitiveNipple: awesome... you must be a git fiend?
<IntuitiveNipple> I have my moments :)
<cjwatson> bryce: is there a bug report for "Hangs with desktop effects on Intel 830MG and 845G video cards" in http://www.ubuntu.com/getubuntu/releasenotes/810, and has it been fixed?
<apw> git blame perhaps
<IntuitiveNipple> no, I just did: git log -S'if (!avail)' -- Incremental.c
<apw> aother good options
<bryce> cjwatson: 259385
<bryce> cjwatson: upstream does not really work on 8xx card support any longer so I would not expect it to be solved yet
<cjwatson> bryce: yeah, I'd gathered, but as a matter of form we should continue to track issues from the 8.10 release notes. I know you're aware of this but I'll target that bug to jaunty so that other people are too
<cjwatson> (I'm doing this for all bugs from the 8.10 notes)
<evand> kirkland: no messages
<kirkland> evand: okay
<kirkland> evand: it is a kvm crash of some sort
<bryce> cjwatson: fwiw, it is very likely that support for i830 and i845 will be dropped upstream.  I'm concerned this bug will have to be carried along indefinitely.
<kirkland> evand: was the guest doing anything overnight?
<evand> just sitting there, minding its own business
<evand> it was a livecd
<cjwatson> bryce: acknowledged
<cjwatson> bryce: if you decide there's no alternative, you have the option of marking the bug wontfix (with appropriate measures taken elsewhere to notify users etc.); I'm not retargeting bugs that are invalid/wontfix/fixreleased
<cjwatson> bryce: but with all the usual caveats
 * bryce nods
<bryce> well, i830/i845 are such old cards it's hard to justify putting canonical resources into it aside from working around the problem as mvo has done, however I would love to see some community form around providing support for these old -intel chips.
<bryce> cjwatson: I'll bring this up with rick and see what he thinks.
<cjwatson> bryce: "not Canonical" is more ct-rev than wontfix, really
<cjwatson> anyway, dinner ...
<kirkland> evand: i'll start up 10 KVMs and leave them run overnight tonight
<kirkland> cjwatson: if you remember, i added some prerm magic to ecryptfs-utils to keep it from being removed if it was in use....
<kirkland> cjwatson: just for the record, it's equally unwise to remove mdadm on a raid-using system, and reboot
<evand> kirkland: heh, ok
<kirkland> evand: would you mind doing something similar over night tonight?
<evand> kirkland: perhaps try the desktop CD, just to see if that's triggering it
<kirkland> evand: crank up some number
<kirkland> evand: and see how many survive the night?
<evand> kirkland: sure, though I don't know how much time I'll have to report back to you.  I leave for Dubai in the morning.
<evand> I'll be bringing my laptop though
<evand> so I'm sure I'll find some time to update the bug report
<kirkland> evand: sweet, vacation?
<evand> ja
<kirkland> evand: nice
<slangasek> pitti: while we're discussing gnome-python-desktop, do you think we can drop bugbuddy.py from the package (letting us kick bug-buddy out to universe)?
<bryce> cjwatson: actually it looks like you do  not need to carry 259385 forward.  (Indeed I think the 810 release notes are listing it unnecessarily)
<bryce> cjwatson: compiz has a blacklist for these two chipsets already as a workaround:
<bryce> T="$T 8086:3577 8086:2562 " # Intel 830MG, 845G (LP: #259385)
<bryce> so the problem that the release notes describe will not actually occur in practice
<bryce> the compiz fix on that bug solves the issue.  (If it didn't, then the compiz task should be reopened.)
<bryce> slangasek: do you know if seb128 re-enabled the 96 dpi forcing in Gnome?  (refbug #349140)
<slangasek> bryce: asac did
<bryce> slangasek: oh.  was there a bug report on that?  (for duping purposes)
<bryce> slangasek: or mailing list post or irc log or something to reference...
<slangasek> bryce: libgnome changelog should show
<cjwatson> bryce: ok, please do appropriate things to the bug so that we don't need to worry about it then
<cjwatson> bryce: thanks for looking into it
<cjwatson> http://qa.ubuntu.com/reports/bug-fixing/jaunty-fixes-report.html says 3230; http://qa.ubuntu.com/reports/bug-fixing/intrepid-fixes-report.html says 3459
<cjwatson> so 229 to go until we surpass intrepid; I wonder if we can beat it by a noticeable amount
<bryce> cjwatson: is adding ct-rev sufficient for taking it off your list?
<cjwatson> bryce: marking it wontfix for jaunty will reopen a non-targeted task
<cjwatson> something will need to be done with the actual status of the jaunty task in order to get it off the release team's list
<bryce> cjwatson: ok cool, will do
<cjwatson> ta
<jordi> cjwatson: back
<jordi> cjwatson: is there any tag I can add to the bug to get it considered for this release?
<jordi> ah, nominate
<bryce> cjwatson: wow, I didn't know about those reports, kewl.  Looks like I've fixed exactly twice as many bugs in jaunty as I did in intrepid.  :-)
<liw> cjwatson, re mjg59 & relatime: ack, I saw his blog entry, and I've marked it on my list for things to consider for karmic
<dtchen> slangasek: they are caused by the same bug that has been fixed in the latest linux upload
<dtchen> (the linux tasks, that is)
<dtchen> i opted not to mark dupes because of different debug spew to syslog
<slangasek> dtchen: ok - could you close out the bug with that explanation then, if you haven't already?  (no longer have the bug numbers in front of me at the moment :)
<dtchen> ye,s i'm planning to close all the bugs referenced in the e-mail to kernel-team
<kirkland> cjwatson: still around ?  adduser question for ye
<sistpoty> asac: got some time to look at FFe bug #340435? looks like that's your domain ;)
<ubottu> Launchpad bug 340435 in adblock-plus "FFe request for adblock-plus 1.0.1" [Undecided,New] https://launchpad.net/bugs/340435
<ahasenack> hi, I'm trying to build a source package (debuild -S). The package is for jaunty, and I'm on intrepid. I thought it should work, but it fails when trying to include a file from debian/rules that doesn't exist. Should it be possible? Here is the log: http://pastebin.ubuntu.com/139178/
<ahasenack>  /usr/share/python/python.mk doesn't exist on intrepid (or I don't know which package installs it)
<ahasenack> the reason I want the source package is so I can upload this to ppa and get a binary for jaunty
<sistpoty> ahasenack: I guess #ubuntu-motu might be a better place to ask ;)
<ahasenack> sistpoty: ok
<the99zChris> can anyone help me? i restored my xorg file (didn't help original problem) but now i can't set my screen resolution low enough to play games...(hardy
<sistpoty> the99zChris: then you're screwed (just kidding :P)... please try #ubuntu
<the99zChris> k thanks
<nixternal> ArneGoetje: I uploaded the kubuntu-docs package yesterday and the translations need to be approved as they are waiting to be imported...thanks :)
<kirkland> kvm is apportin'
 * kirkland braces for the new infusion of bugs
<cjwatson> kirkland: not really - is it quick?
<kirkland> cjwatson: nah, check my last upload of adduser
<kirkland> cjwatson: it's functional, and it causes no harm
<kirkland> cjwatson: you might have a stylistic preference of solving it another way
<cjwatson> not on lp yet
<kirkland> cjwatson: goal is to remove /var/lib/ecryptfs/$user, if doing deluser --remove-home
<cjwatson> unless you mean 3.110ubuntu2
<kirkland> cjwatson: no
<kirkland> cjwatson: ubuntu4
<kirkland> cjwatson: there's a debdiff attached to the bug it fixes ....
 * kirkland finds it
<cjwatson> ok, I'll look at it later when it lands
<kirkland> cjwatson: faird enough
<cjwatson> bug 347970?
<ubottu> Launchpad bug 347970 in adduser "deluser --remove-home leaves /var/lib/ecryptfs/<username> behind" [Low,In progress] https://launchpad.net/bugs/347970
<kirkland> cjwatson: http://launchpadlibrarian.net/24314131/out.diff
<kirkland> cjwatson: that's the one
<cjwatson> I have a stylistic preference for no whitespace damage in patches ;-)
<cjwatson> +if ( $File::Find::name !~ /^\/var\/lib\/ecryptfs\/$user/ ) {
<kirkland> doh
<cjwatson> you should quote variables when substituting them into variables unless you mean metacharacters to be interpreted - \Q$user\E
<kirkland> cjwatson: strike 2, okay.
<cjwatson> and I'd recommend m[^/var/lib/ecryptfs/\Q$user] to reduce leaning toothpick syndrome
<kirkland> cjwatson: alrighty then ...  fail
<kirkland> cjwatson: i'll get this cleaned up
<kirkland> cjwatson: any arguments with my method?
<cjwatson> I'm just looking at the context
<kirkland> cjwatson: okay, you can put this off for later, if you wish
<kirkland> cjwatson: i considered several different approaches
<kirkland> cjwatson: this one was the fewest lines of code to be changed
<cjwatson> I find it quite confusing as-is
<cjwatson> I think I would prefer a separate ecryptfs_match
<cjwatson> I realise it's a style thing to some extent
<kirkland> cjwatson: that's fair, that's the feedback i was looking for
<cjwatson> mostly just because the remainder is pretty short
<kirkland> cjwatson: it's a fair bit of duplicated code doing it that way
<cjwatson> not really, it's about half a dozen lines?
<kirkland> cjwatson: i was looking for a previous debdiff, don't see it immediately
<cjwatson> oh, a bit more, sorry, misread
<cjwatson> well, there's another possibility
<kirkland> cjwatson: there's also the question of whether this behavior is even appropriate ...  there's also a delete-all-files option
<kirkland> cjwatson: pitti could have perhaps used that
<cjwatson> have a variable declared in a scope outside home_match, and have the home_match function check that variable to determine what to do
<cjwatson> as I said, delete-all-files is really, really slow
<cjwatson> I'm sort of inclined to say that the ecryptfs bit is like your home directory
<kirkland> cjwatson: okay, fair enough.  i ack'd the bug, and felt the same way
<cjwatson> TBH, though, I think if it were me I would favour the duplicate code over making it less clear
<cjwatson> but I wouldn't veto the other approach, it's just a preference
<kirkland> cjwatson: gracious for your review, i'll rework it now
<Laney> does apport somehow remember previous reported crashes?
<Laney> and not trigger for the same crash again?
<Laney> (after reporting)
<nixternal> ArneGoetje: just caught your thread on the translators list. I am the maintainer for the kubuntu-docs package and will do the imports when complete. Been doing it since Dapper, so yes, we would like to have the kubuntu-docs translatable in Rosetta for Jaunty..thanks!
<Laney> -- because I cancelled a report after uploading to LP so that I could resubmit with debugging symbols installed
<Laney> but now apport won't trigger again and nothing is written in /var/crash
<Laney> got it
<cody-somerville> Does anyone know the udeb with the modules for squashfs?
<kirkland> cjwatson: okay, i have a cleaner one now
<slangasek> infinity: since you've saturated the build queues, could you bump jack-audio-connection-kit to the front? :)
<infinity> slangasek: Done.
<slangasek> thankee
<Nafallo> haha
<robbiew> slangasek: hey...is there an internal server that I can grab the UNR beta image from...instead of waiting the hour to download from cdimages?
<slangasek> robbiew: mm, there's a mirror of cdimage somewhere that internal QA testers can use for speedier access, but I don't remember where to get it
<robbiew> ah fooey
<robbiew> :P
<robbiew> no worries...just being impatient
<robbiew> heh
<slangasek> you could bittorrent!
<robbiew> true
<slangasek> then it will still take you an hour, but you'll spend the first 10 minutes feeling like you're doing something
<robbiew> heh
<robbiew> right
<diegoe> bryce: around?
<bryce> yes
<diegoe> may i bug you about the patch in lp #349113
<ubottu> Launchpad bug 349113 in xserver-xorg-video-intel "blurry-dancing fonts on 855GM with intel 2.6.x" [Undecided,New] https://launchpad.net/bugs/349113
<bryce> diegoe: if you wish
<diegoe> just wanted to attract your attention to it, i was just enjoying the bisect experience
<diegoe> I wonder if you would like additional confirmation or if you have any thought about it, I wouldn't swear the problem is in every 855GM, but I guess mine's not that much different
<bryce> heh 855
<bryce> I think anholt has a dislike for the 8xx cards :-/
<nxvl> bryce: i'm preparing the debdiff for that package, will upload any minute
<diegoe> nxvl: work!
<bryce> diegoe: you've confirmed that with those two patches reverted, that your issue is resolved?
<diegoe> yes, but let's wait for nxvl debdiff and I will re-confirm with a package built from his new sources
<bryce> from anholt's comments it doesn't appear his change is intended to actually fix a bug, just remove code he feels is no longer needed... which due to the existence of the bug may be incorrect
<bryce> alright
<diegoe> it's curious because in his comment he says this was there since beginning of time
<bryce> wait
<diegoe> although this font problem never popped
<bryce> maybe I've misunderstood - you're saying those patches are *needed* for fixing it?
<bryce> sorry, your comments on the bug report confused me
<diegoe> let's say patch, since the second one is just a forgot line of the first one
<diegoe> sorry :-)
<bryce> ok, I'll wait until I see the debdiff :-)
<diegoe> without the patch, the intel driver exhibit this funny fonts problem
<diegoe> with the patch applied, it doesn't
<bryce> diegoe: it's possible that some other change elsewhere in the code triggered the problem
<bryce> sometimes there can be two bugs that cancel each other out, and fixing one reveals the other
<bryce> nxvl: feel free to assign the bug to me once you have a debdiff to sponsor, and I'll make sure to shepherd it in
<diegoe> mmm, well git bisect took me there and i retested going to a clean master, checking out to the commit *before* the suspected fix
<diegoe> the commit before this one shows the funny fonts, from this commit and on the fonts are no problem
<nxvl> bryce: ok
<Hobbsee> cjwatson: I haven't found the killswitch bug for iwl3945 to be fixed (which you asked pgraner), fwiw
<pgraner> Hobbsee: you have a bug number?
<Hobbsee> pgraner: i thought cjwatson gave you one....
<Hobbsee> i don't have one here
<pgraner> Hobbsee: nope he just mentioned the issue, he gave me a bug number for a different issue
<Hobbsee> pgraner: oh.  I've not gone looking for one so far, i just answered off the symptoms.  I'll go looking for one in a bit, unless you beat me to it
<nxvl> diegoe: the code your patch is removing is not present in the ubuntu package
<pgraner> Hobbsee: we've squashed several kill switch issues, I was hoping that was one. I would check the next kernel coming out it will have one more killswitch fix I just don't remember if it was for that one, ping apw he might know as he was working on a few.
<diegoe> nxvl: that's bad
<diegoe> nxvl: all of it or just parts?
<slangasek> cjwatson: what's left to do on bug #44194 for wpasupplicant? the daemon is already in /sbin and so are the libs it uses?
<nxvl> diegoe: i don't find anything of it
<ubottu> Launchpad bug 44194 in openssl "wpasupplicant doesn't start when the network start" [High,Fix released] https://launchpad.net/bugs/44194
<nxvl> diegoe: and when generating a quilt patch for it to be packages i get a patch including that code in the package
<nxvl> diegoe: instead of removing it
<diegoe> weird
<diegoe> i see here that such code is in since 2007
<Hobbsee> pgraner: ahhh, OK.  it may be fixed for other people.  I'll take a look and report mine, as once I hit the kill switch, i can't reativate hte wifi, at all, until i get back to the bios / boot windows, iirc.
<nxvl> diegoe: not in the debian package
<nxvl> well, i'm gone
<nxvl> feel free to prepare a debdiff
<diegoe> ok thx
<diegoe> bryce: looks like 2.6 branch already removed such code since 704177b5dd0ab7a5f5bef937eac53d725bc509b5
<diegoe> which leaves me clueless...
<diegoe> i have seen the problem since 2.5 (which fedora included), and now in ubuntu's 2.6.x; but not in git master, git bisecting master took me to the commit we were talking about, but turns out 2.6 doesn't have that code already
<diegoe> i will bisect in the 2.6 branch and let you know
 * diegoe thought the problem was already cornered, sigh
<pgraner> Hobbsee: thanks
<Hobbsee> pgraner: oh, and thanks collectively to the kernel for making my hibernate work again :)
<Hobbsee> s/again/properly/
<pgraner> Hobbsee: no worries
<bryce> diegoe: you could also doublecheck differences in how the code is configure'd
<diegoe> bryce: ?
 * diegoe is unable to build the 2.6 branch :-/
<diegoe> ah there's a fix in the .deb
 * diegoe gives up
<bryce> well, at least forward the bug upstream for some additional advice
<bryce> actually nevermind, if the bug isn't reproducible in the git tree, they won't care
<diegoe> i can't build the 2.6 branch
<cody-somerville> pgraner, Do you know if there is a udeb with the squashfs kernel modules?
<bryce> diegoe: why not?
<diegoe> ftbfs
<bryce> diegoe: that's hardly helpful
<diegoe> :P
<bryce> diegoe: "Doctor, my arm hurts?"  "Why?"  "Because there's a pain in it"
<bryce> diegoe: builds fine for me
<diegoe> from git 2.6 branch or from the .deb?
<bryce> from the deb
<diegoe> i was gonna try bisect in 2.6 branch on git
<cody-somerville> Whats the cause of the FTBFS diegoe?
<diegoe> http://pastie.org/429494
<diegoe> i guess i have something too recent for the commit i'm trying to build, which is circa 2.6.1
<bryce> libdrm got updated to 2.4.5 in order to allow 2.6.3 to build
<bryce> so perhaps downgrading to a pre-2.4.5 libdrm*-dev would enable it to build
<diegoe> -.-
#ubuntu-devel 2009-03-28
<cjwatson> slangasek: wpa_supplicant tries to log to /var/log, and is going to need to log to syslog instead
<slangasek> ah yes
<calc> http://marc.info/?l=linux-kernel&m=123819275025401&w=2
<calc> that post implies our firefox might have issues? since we don't have that option linus mentioned
<calc> or at least i don't see it in my about:config
<Pollywog> I am getting crashes from Konqueror in Hardy but there are no debugging symbols and no konqueror-dbg  or -dbgsym packages.  Is there something I can do to enable debugging?
<Laney> bah, why leave so quickly
<TheMuso> calc: BTW you said the other day that you couldn't find the CONFIG_LBD kernel config option. I am guessing you are running amd64, and 64-bit systems don't need that option so far as I understand it, since they are able to handle large block devices natively. 32-bit systems need that option, I'm guessing again because particular code is needed to allow for that support.
<calc> TheMuso: ah ok
<lamont> I wonder.  how do I get do-release-upgrade -d to _not_ download all the -dbg packages?
<ScottK> Uninstall them first?
<lamont> they're not installed
<lamont> nor are they in the local mirror...
<lamont> nor do they show up in /var/log/dist-upgrade/*, they just show up when it bitches that it failed to download them
 * lamont smacks it with strace -ff
<lamont> is apt actually installing Suggests now? or am I just missing where it's stronger?
<lamont> APT::Install-{Suggests,Recommends} "false";  <-- FTMFW
<GuyFromHell> so it appears NotifyOSD's wiki page lies, can someone tell me if this is a feature or a bug? if a bug i'll fix the wiki. It appears that replaced_id has to be set as well (in addition to title and coming from same program) for concatenation to work, which is not what "https://wiki.ubuntu.com/NotifyOSD#Concatenating existing bubbles" says
<GuyFromHell> pretend i spelled the important parts of that correctly >_>
<ScottK> GuyFromHell: #dx or #ayatana are probably better channels to ask as that's where the developers of notify-osd hang out.
<GuyFromHell> ScottK, dx and ayatana? random enough names but i'll head on over there...
<ScottK> dx is short fo 'desktop experience'.  No idea about the provenence of the other one.
<ScottK> fo/for
<GuyFromHell> ScottK, I see, lets see if they know anything. In the meantime I'll patch pidgin-libnotify for the hell of it :P
 * ScottK declines to give an opinion on that.
<calc> anyone around that wants to a few syncs? :) 350070 350071 350072
<calc> er want to do a few syncs
 * calc needs to proofread his irc messages
<calc> robbiew: good evening
<robbiew> calc: hi
<calc> robbiew: hey i meant to ask you before did you know a guy named Seth Burgess when you went to TAMS?
<robbiew> calc: heh...yeah
<robbiew> can't match the face right now...but remember the name for sure
<DaemonFC> hmm, I did some benchmarking in Jaunty and found that XFS is still beating everything else
<DaemonFC> including Ext4 :)
<calc> robbiew: he lived in my neighborhood and i went to school with his younger brother at our local Math/Sci magnet school, heh
<robbiew> calc: :)
<GuyFromHell> DaemonFC, you try btr or r4 in there by any chance? i'm curious :P
<robbiew> calc: small world
<calc> robbiew: yea, i noticed you went there when looking at your facebook profile a while back
<DaemonFC> Ext3/4, ReiserFS, JFS, and XFS in boot time and disk I/O
<DaemonFC> XFS ate everything else for breakfast
<robbiew> calc: yep...proud class of `94! :P
 * calc 's wife is watching mama mia, and is astounded she has never heard ABBA before
<calc> robbiew: i graduated in 95 :)
<DaemonFC> strangely Ext3 beat Ext4 in disk throughput
<DaemonFC> 51 MB/sec for Ext3, and 41 for Ext4
<DaemonFC> compared with 57 for XFS
<calc> robbiew: so was that equivalent to graduating from HS in 92 or did they have a HS graduation and then the next 2 years for college (i never looked into how that worked)
<DaemonFC> Ext4 seems to be a regression in some cases
<calc> DaemonFC: it looks like the kernel guys (upstream) are working on getting things working better, see the lkml 2.6.29 several hundred post thread, very funny in places
<DaemonFC> GuyFromHell: ReiserFS tied with Ext3 for disk throughput, but took almost twice the time to boot
<DaemonFC> due to reiserfsck
<robbiew> calc: well..we had a graduation ceremony, but left with around 60 college credits
<calc> DaemonFC: last time i used XFS it also ate itself for breakfast :\
<GuyFromHell> DaemonFC, and i believe reiser mount time is utter carp in general but i'm sure if you tested only small files it would be the other way ;)
<calc> robbiew: ah ok
<DaemonFC> calc, that bug was fixed in 2007
<DaemonFC> according to eric Sandeen
<robbiew> calc: so pretty much like leaving in '92, but we had to take certain courses to meet Texas Education Agency requirements
<calc> DaemonFC: yea, still kept me from wanting to try it again :\
<calc> robbiew: i see
<robbiew> calc: so I ended up with a lot of wasted credits...for a CS degree :P
<DaemonFC> http://izanbardprince.wordpress.com/2009/03/28/comparing-boot-performance-of-ext3-ext4-and-xfs-on-ubuntu-jaunty/
<robbiew> calc: like pre-med biology....world history...etc
<calc> robbiew: wasted credits just makes you more well rounded :)
<robbiew> calc: ;)
<DaemonFC> http://img135.imageshack.us/img135/5469/reiserboot.png
<DaemonFC> notice how Reiser flatlines
<DaemonFC> when it gets to reiserfsck
<GuyFromHell> DaemonFC, so i'm a bit curious, i thought there was an outstanding bug on XFS not being able to be used for the grub partition
<DaemonFC> and then gets going agin after about 10 seconds
<DaemonFC> lol
<DaemonFC> GuyFromHell: In Ubuntu's setup, yes
<DaemonFC> Debian has supported that since Etch
<GuyFromHell> DaemonFC, huh, you mean i was using ext2 there for no reason >_>
<DaemonFC> I filed a bug on that and it was fixed the same day oddly enough
<DaemonFC> in Ubuntu
<DaemonFC> right before Jaunty Alpha 5
<DaemonFC> about 5-6 days before
<DaemonFC> yeah, Debian supports booting on XFS, so does Mandriva, Ubuntu does now
<DaemonFC> Suse will complain about it and tell you you need to make a boot disk
<DaemonFC> but using xkill on that prompt it goes and isntalls GRUB on the hard disk anyway
<GuyFromHell> >_>
<DaemonFC> heh
<DaemonFC> I like XFS, and I trust that Eric Sandeen knows what he's talking about
<GuyFromHell> DaemonFC, you should cover btrfs and reiser4 too if you're still bored :P
<DaemonFC> he's the lead file system engineer at Red Hat and before that he worked at SGI on XFS
<calc> i'll stick to ext3 until i see progress from the current flame war, it looks like something positive might result from the discussion
<DaemonFC> Ubuntu doesn't support either
<DaemonFC> or I would have
<GuyFromHell> DaemonFC, lol, i don't think anything "supports" either :P
<DaemonFC> Fedora does
<DaemonFC> BtrFS anyway
<DaemonFC> in 11 Alpha
<DaemonFC> type icantbelieveitsnotbtr on the installer line
<DaemonFC> I tried it and I didn't really like it
<GuyFromHell> btr?
<DaemonFC> it's really really slow at this point
<DaemonFC> yes
<GuyFromHell> DaemonFC, it is still like alpha
<GuyFromHell> so i mean
<GuyFromHell> it's to be slightly expected
<DaemonFC> yeah
<DaemonFC> that's why I'm not benchmarking it til it's reasonably "there"
<DaemonFC> I don't want to drag its name through the mud while it's still pre-alpha
<DaemonFC> XFS reads at platter speed on all my stuff
<DaemonFC> so I don't think BtrFS is going to improve on it in speed
<DaemonFC> That was such a nuisance when Ubuntu was setting up GRUB to be stupid though
<ScottK> This really doesn't have a lot to do with actual development of Ubuntu.
<DaemonFC> one big reason GRUB didn't used to support XFS is because XFS puts the Superblock at the first sector of the root partition
<DaemonFC> and GRUB couldn't deal with that
<ScottK> There is #ubuntu-offtopic for general chitchat.
<calc> ScottK: is there anything special i need to do for sync requests at this time in the cycle? i pointed to the bug that the three requests help to resolve in their bug reports, wasn't sure if anything else would be needed
<ScottK>  calc: Is it a bugfix only change?
<calc> ScottK: yea only new debian revisions no new upstream changes
<ScottK> calc: Then no, just subscribe the archive as usual.
<calc> hmm actually one of the packages is newer than what we have, they are dictionaries though so can't really explode
<calc> newer upstream i mean
<calc> ScottK: ok
<ArneGoetje> nixternal: thanks. approved.
<nixternal> ArneGoetje: no, thank you :) very much appreciated!
<lamont> \o/  slapd failed to upgrade.  yay slapd
<slangasek> lies, slapd never fails to upgrade
<lamont> gah.  WTF turned on color in vim?
<lamont> slangasek: well, to be fair, there is no slapd.conf.
<lamont> OTOH, it would help if the upgrade noticed that it WASN'T RUNNING BEFORE
<slangasek> hmm :)
 * lamont goes looking to find the magic option to make vim shut up
<lamont> there.  "syntax off"
<lamont> love.
<lamont> I guess one of these days, I should start using vim as vim, instead of as an overly weighted not-quite-the-same nvi
<lamont> slangasek: truthfully, one could consider it a bug that if slapd was not running before the dist-upgrade, it shouldn't be started after the dist-upgrade
 * lamont can hardly wait to see if  his laptop boots into jaunty
<slangasek> lamont: if you don't want the service started, that's what policy-rc.d is for
<lamont> meh.  bind and postfix both notice and DTRT
<lamont> as the result of bugs filed against tehm
<lamont> then again, that was before policy-rc.d
<slangasek> no, bind and postfix both notice and do what you want, not TRT :)
<slangasek> (well, or what you agreed to do in response to bugs :-)
<lamont> well, what the submitter wanted
<lamont> so is the login screen _supposed_ to look like 5 vertical blue lines?
<lamont> sigh.  inspiron 1520 doesn't like what jaunty is doing to it.
<lamont> dear squid.  when I say init.d/squid STOP, I mean really stop, not sit around for 30 seconds before stopping.  kthx
<DaemonFC> I got rid of Apparmor out of init, I compiled my own kernel but it was still trying to load the stupid Apparmor module :P
<lamont> slangasek: is it known that jaunty doesn't like 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
<IntuitiveNipple> lamont: That migh be bug #312677
<ubottu> Launchpad bug 312677 in xserver-xorg-video-intel "[i915] [i965] [Jaunty] Text consoles corrupted on GM965" [Undecided,Fix released] https://launchpad.net/bugs/312677
<lamont> /usr/bin/X11/X: symbol lookup error: /usr/lib/xorg/modules/extensions//libdri.so: undefined symbol: atiddxAbiDixLookupPrivate
<lamont> giving up.
<lamont> xinit:  Connection refused (errno 111):  unable to connect to X server
<lamont> xinit:  No such process (errno 3):  Server error.
<lamont> X optional is what it is
<lamont> and then it doesn't want to switch to a VT after that's all done
<slangasek> uhm... symbol errors don't sound like a known error
<IntuitiveNipple> That's bug #345669
<ubottu> Launchpad bug 345669 in fglrx-installer "X server failed when start - undefined symbols in libdri.so(ATI problems)" [Undecided,Invalid] https://launchpad.net/bugs/345669
<lamont> slangasek: it's current as of beta release (I thought), but has 229MB of dist-upgrade it want's to fetch...
<lamont> which, without a working screen, is gonna be more painful
<slangasek> lamont: i386 or amd64?
<lamont> amd64
<slangasek> checking
<lamont> wtf
<lamont> i386
<lamont> well, i686
<slangasek> heh, checking that instead then :)
<slangasek> lamont: that symbol isn't referenced by the beta version of xserver-xorg-core on i386
<slangasek> lamont: so what owns that lib on your system?
<lamont> yeah, now that I think about it, the laptop was pretty much the last i386 install I did... haven't gotten up the effort to reinstall it yet
<lamont> diversion by xorg-driver-fglrx to: /usr/lib/fglrx/libdri.so.xlibmesa
 * lamont fires fglrx
<slangasek> that seems like something you don't want on an i386 system, no :)
<slangasek> er, s/i386/intel/
<slangasek> (i965! that thing!)
<lamont> what a cute gdm screen...
<lamont> \o/
<lamont> and total love, I get my 1680x1050 screen back
<lamont> not sure how/why fglrx got dragged in at intrepid, but glad to kill _that_ minor annoyance
<lamont> anyway, bed for me.  thanks again slangasek for nudging me in the right direction
<slangasek> n/p
<slangasek> night :)
<mcas> hi is a ubiquity developer here?
<cjwatson> mcas: what's the problem? (I'm sort of here.)
<mcas> hi cjwatson
<mcas> i have ab problem with a bug in ubiquity
<mcas> in ubuntu-bugs no one could help me
<mcas> so it is about bug https://bugs.launchpad.net/bugs/349173
<ubottu> Ubuntu bug 349173 in ubiquity "wrong german translation of buttons in ubiquity" [Undecided,Confirmed]
<mcas> i am not quite sure if the buttons are wrong only in german or in english too
<mcas> and because the "main" ubiquity bug was fixed yesterday i want to tell you about this problem because i cannot say if the wrong button label is the same problem
<cjwatson> mcas: that should be covered by the fix for English buttons
<cjwatson> certainly the partition mounting one; the password dialog is a separate bug
<mcas> ok
<cjwatson> well, if it's a bug at all
<cjwatson> the corresponding question in d-i is a boolean question so I agree that that should be Yes/No in ubiquity
<mcas> ok
<mcas> i ask some guys before filling this bug if they think the buttons are correct ;-)
<cjwatson> mcas: I've updated your bug to describe the part not already covered by other bug reports
<mcas> thank you cjwatson
<cjwatson> ... and fixed, since it's trivial
<mcas> thank you :-D
<hunger> Is there any known trouble with /tmp getting filled up in jaunty at this time?
<hunger> df and du disagree on how full /tmp is here: df says it's 9.9GB and 100%, du says it is 24MB.
<stooj> !jaunty
<ubottu> Jaunty Jackalope is the codename for Ubuntu 9.04, due April 23rd, 2009 -  Schedule in https://wiki.ubuntu.com/JauntyReleaseSchedule - Lots of breakage between now and April - Please join #ubuntu+1 for discussion and support.
<soren> hunger: You probably have files open in there that have been deleted. They still take up space (as reported by df), but are visible on the filesystem (so du can't count them).
<soren> Oh, he left.
<soren> Bah
 * soren does the same
<kees> Keybuk: uhm, your bluez-utils preinst is wrong.  :P  preinst isn't run with "configure".  Also -- shouldn't you be checking that the conffile is unmodified?
<diverse_izzue> Does somebody with packaging experience have a few minutes to give me a hand - i'd like to build an xserver-xorg-core package with a set of patches applied (bug #283128) and cannot figure out how to do it.
<ubottu> Launchpad bug 283128 in xkeyboard-config "Keyboard indicator shows additional layout "null"" [Medium,In progress] https://launchpad.net/bugs/283128
<ScottK> diverse_izzue: I'm on my way out the door, so not me.  Generally your odds are better if you ask specific questions, "I tried foo, bar bad thing happened, I'd appreciate a suggestion about what to do next?"
<LaserJock> hmm, is Conflicts really appropriate for brasero/nautilus-cd-burner?
<savvas> LaserJock: I was wondering about the same thing
<LaserJock> I mean, sure you end up with 2 burn-to-disc items in the context menu, but in order to get nautilus-cd-burner back I have to get rid of all of brasero
<savvas> LaserJock: I think it's because of bug 317756
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/317756/+text)
<ScottK> If it's just both showing up in the menu, that's not what conflicts is for.
<savvas> I'm not sure though, it wasn't linked with the bug
<pochu> bug 317756
<ubottu> Launchpad bug 317756 in nautilus-cd-burner "installation of both nautilus-cd-burner and brasero results in two "Write to disc" menu entries" [Low,Fix released] https://launchpad.net/bugs/317756
<LaserJock> I'm just a bummed as I liked nautilus-cd-burner better for burning .isos, but brasero does a lot more so I don't want to remove it either
<crdlb> eh? the only difference I see is that the dialog is slightly different
<LaserJock> I've not had very good success with brasero's version
<crdlb> ah, you mean the implementation, not the UI?
<LaserJock> mostly yes
<LaserJock> I can't remember if the nautilus-cd-burner dialog had more options or not
<savvas> http://lwn.net/Articles/316015/
<LaserJock> I don't have it in front of me for obvious reasons :-)
<savvas> "New module decisions for GNOME 2.26"
<LaserJock> right
<LaserJock> but nautilus-cd-burner is in the archives and in Main even
<savvas> "directly conflicts with nautilus-cd-burner feature-wise" < heh
<savvas> so I guess there isn't anything that deprecates it, other than the fact that they both serve the same thing :P
<savvas> should I file a bug to lift the conflict? or does this mean that nautilus-cd-burner will not be maintained anymore?
<LaserJock> well, I see the point of the conflict, it'd just be nice if we had a more elegant solution
<LaserJock> it's not exactly the proper use for Conflicts but it does the job I guess
<ScottK> LaserJock: I'd suggest if there's no file level conflict it's a policy violation.  If brasero needs to swapped in upgrade, mvo should add logic for that in update-manager.
<LaserJock> ScottK: yeah, that seems like a much better way of handling it
<ScottK> We did it that was for multiple packages for kubuntu-desktop.
<ScottK> was/way
<savvas> ScottK: but will nautilus-cd-burner be supported upstream? if not, wouldn't it be better to ask for a package removal? Or is it too early for such action? :\
<ScottK> savvas: Generally we let it drop to Universe and stay until it's not supportable.
<ScottK> savvas: The idea in Ubuntu is to have one supported way, but let options stay in Universe.
<savvas> aaah, ok, I'll file a bug against brasero then :)
<ScottK> savvas: Also file a bug against update-manager asking to have them swapped out.
<savvas> ScottK: will do!
<kees> Keybuk: you around by any chance?  I'm trying to debug a dbus permissions issue with network-manager-pptp
<savvas> ScottK: separate bugs or just link it? bug 350523
<ubottu> Launchpad bug 350523 in brasero "Policy violation - Conflicts: nautilus-cd-burner" [Undecided,New] https://launchpad.net/bugs/350523
<directhex> hmph. which bit of code would i go digging in if i felt that gnome's mouse sensitivity settings were dim?
<directhex> i can only make my mouse controllable if i pull down the DPI setting
<directhex> which sorta defeats the idea
#ubuntu-devel 2009-03-29
<John64> is storm used much in the real world outside of launchpad?
 * ScottK guesses this probably isn't the best place for people who would know.
<John64> well, it is an Ubuntu developed platform.  oh well, thanks anyway
<Hobbsee> s/ubuntu/canonical/
<ScottK> John64: It's nothing to do with Ubuntu.
<Hobbsee> you'd probably need to contact canonical directly.  I believe there are addresses on canonical.com
<John64> ohkay, well, i wouldn't say it isn't 'nothing to do with ubuntu'
<ScottK> John64: From a development perspective it is nothing to do with Ubuntu.
<ScottK> Ubuntu uses it and it is built on Ubuntu, but Ubuntu has nothing to do with LP development.
<John64> since it is the basis of launchpad, and launchpad is a huge part of ubuntu, it is part of the development.  either way, thanks for your info
<wgrant> It has nothing to do with Ubuntu except being primarily developed by Ubuntu's sponsor.
<wgrant> *prime sponsor
<wgrant> We can't see Launchpad's source, so what Launchpad uses has nothing whatsoever to do with us.
<Hobbsee> wgrant: he's gone, fwiw
<wgrant> Damn.
<Hobbsee> you could always /query it to him, though
<ebroder> Ugh. I can never keep the procedure straight. If I'm asking for a Debian sync now, that's just for bugfixes (i.e. feature freeze shouldn't apply), who should I subscribe to the bug?
<ScottK> ebroder: Main or Universe package?
<ebroder> universe
<ebroder> (bug 350470)
<ubottu> Launchpad bug 350470 in openafs "Sync openafs 1.4.8.dfsg1-3 (universe) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/350470
<ScottK> ebroder: ubuntu-universe-sponsors
<ebroder> Ok. That's what I thought, just wanted to make sure they were still the right group this far into the release
<ebroder> Thanks
<OsamaK> Hello. Which package contains the new confriming message on shutdown, restart, logout?
<OsamaK> I just wnat to translate it.
<Hobbsee> OsamaK: oss-notify, i think?
<OsamaK> Hobbsee, is it a GNOME package?
<Hobbsee> i'm not sure
<wgrant> OsamaK, Hobbsee: It's fast-user-switch-applet
<wgrant> Hobbsee: You were thinking of notify-osd?
<Hobbsee> wgrant: er, yes, i probably was.
<wgrant> Took me a while to remember that one.
<wgrant> And I still think that indicator-applet is notification-applet
<OsamaK> wgrant, is it GNOME?
<wgrant> OsamaK: Those dialogs are not part of GNOME.
<wgrant> I'm not sure about FUSA itself.
<OsamaK> thanks.
<OsamaK> wgrant, what about the 'shutdown' icon on the top right corner?
<wgrant> OsamaK: The separate one, not FUSA?
<OsamaK> wgrant, can you please link Jaunty Jackalope's fast-user-switch-applet page on launchpad?
<OsamaK> (to get me directly into the needed translation)
 * wgrant looks.
 * wgrant hasn't dealt with Translations in a looong time.
<wgrant> https://translations.launchpad.net/ubuntu/jaunty/+source/fast-user-switch-applet
<wgrant> OsamaK: ^^
<OsamaK> great! thanks :)
<StevenK> asac: Gah, you broke firefox in Intrepid!
<StevenK> asac: Now when I shade the window, it comes back fullscreen without window decorations.
<StevenK> zul_: If the cheetah upload you performed didn't actually change anything, it should be -2build1.
<asac> StevenK: what dies  "shade the window" mean?
<StevenK> asac: So it's just the titlebar -- when I unshade it, it does that
<StevenK> Now that I have your attention, it isn't. Bah.
<asac> StevenK: i still dont know what "shade/unshading" means ;)
<asac> minimizing?
<StevenK> asac: No, it isn't minimising
<StevenK> asac: Think of it as pulling down or putting up a windowshade
<asac> StevenK: ah so compositing? compiz or metacity?
<StevenK> asac: Compiz, yeah
<asac> StevenK: so window decoration going away and ffox starting in fullscreen with titlebar behind panel has been reported in the past with compiz.
<StevenK> asac: Ah ha!
<asac> i think we fixed something in compiz, so its less frequent ... but personally, i never could reproduce it#
<asac> StevenK: if you can reproduce it might make sense to open a compiz bug about it, so we can take a another poke at it;)
<StevenK> asac: I can't even reproduce it now :-(
<asac> heh
<asac> ;)
<lifeless> kees: ping
<lifeless> kees: I want to mark a function pointers as warn_if_result_ignored
<Mithrandir> lifeless: __attribute__ ((warn_unused_result))
<Mithrandir> lifeless: http://blog.rlove.org/2005/10/with-little-help-from-your-compiler.html is quite ok.
<lifeless> Mithrandir: and it just works for function pointers too?
<lifeless> Mithrandir: concretely, I mean
<lifeless> struct {
<lifeless>   int (*method) (void);
<lifeless> } foo;
<lifeless> ...
<lifeless> myfoo->method(); <- this line is the one I want to blow up.
<lifeless> Mithrandir: ah yes, it does.
<lifeless> thanks. [I know how to do it for regular functions, was just shy, shoulda jjust tried on the fptr)].
<kklimonda> does enyone use vmware with ubuntu 9.04? i have a problem with automatic bridging..
<kklimonda> anyone* ;/
<hyperair> this really isn't the place to ask
<kees> lifeless: yup, what Mithrandir said.  :)  Out of curiosity, where are you using it?
<Superdweeb> hai guys, does anyone out there that you know, have a script that when executed downloads and executes everything required to totally recompile an ubuntu installation from source?
<Superdweeb> I'm getting a gentoo itch but wubi only works with ubuntu and my pentium M does not support hardware virtualization.
<ebroder> Even if there were such a script, why would you want to do that? Ubuntu doesn't have USE flags or anything, so you'd just be wasting your time
<ebroder> You wouldn't get binaries that are different from the binary distribution in any meaningful way
<Superdweeb> no use flags?
<Superdweeb> I can't tweek the sheet out of it?
<Superdweeb> How about the kernel, I read some of the text from that big meeting you guiz had
<Superdweeb> you've compiled support into the kernel for tons of stuff
<Superdweeb> Any easy way to get rid of the modules?
<Superdweeb> There should be a GUI for that.
<ebroder> Why? Are you crunched for disk space? Modules don't get loaded if you don't need them
<Superdweeb> well I use only super-old computers that happen to be just new enough to work ok.
<Superdweeb> I tweaked the shit out of the services and stuff.
<Superdweeb> why the * does standard desktop ubuntu have rsync automatically running?
<savvas> does anyone know how to get the screensaver status through dbus, as root for another user?
<savvas> or should user-run applications send that status to root applications/services?
<AakashPatel> hi everyone
<AakashPatel> who here has developed for the APT system on ubuntu?
<AakashPatel> lol 259 people on this channel...and no one?
<cody-somerville> What do you want to ask them?
<AakashPatel> I am developing an APT like system for Android OS
<jdong> that kind of activity ratio should suggest that a lot of developers listen on this channel for important discussions pertaining to Ubuntu development.
<AakashPatel> and i dont get how the apt system get's a list of all apps...
<AakashPatel> (this is releated to who it was APT works on ubuntu)
<jdong> this is a basic support question that's best answered by the APT support lists, or even -devel-discuss.
<jdong> it's not on topic for this channel
<AakashPatel> ubuntu-devel-discuss ?
<AakashPatel> #ubuntu-devel-discuss ?
<jdong> ubuntu-devel-discuss is a mailing list.
<AakashPatel> errr...
<jdong> have you tried APT's documentation for answering these questions?
<AakashPatel> where is it?
<jdong> http://www.debian.org/doc/manuals/repository-howto/repository-howto.en.html
<jdong> that should answer your question on where APT gets its package list.
<jdong> (from the Packages file in a repository)
<AakashPatel> thanks
<jdong> http://www.debian.org/doc/manuals/apt-howto/index.en.html
<jdong> the Debian APT howto provides a great overview of APT's functionality too, though probably not as useful to answer your questions
<AakashPatel> err...whats the ubuntu main repo url?
<AakashPatel> im not on my linux comp right now...
<cody-somerville> archive.ubuntu.com
<jdong> for example, see http://us.archive.ubuntu.com/ubuntu/dists/intrepid-updates/main/binary-i386/
<ebroder> Hey jdong: would you be up for looking at bug #348865?
<ubottu> Launchpad bug 348865 in gsasl "[hardy] libgsasl7-dev missing dependencies on libntlm0-dev, libkrb5-dev" [Unknown,Fix released] https://launchpad.net/bugs/348865
<jdong> ebroder: looking
<jdong> ebroder: yeah, definitely a bug that needs to be fixed; would you like to prepare the SRU debdiff or ask the OP to do the same?
<ebroder> There's a debdiff in the first ocmment
<jdong> oh look at that :)
<ebroder> Thanks :)
<jdong> sure thing
<UsamaAkkad> hello, if some one want to do minimal install cd for Mint or similar Ubuntu based distribution. what file should he change ?
 * hyperair wonders if someone could look into bug #349768
<ubottu> Launchpad bug 349768 in ubuntu "Wakeup timer doesn't work on HP Compaq" [Undecided,Confirmed] https://launchpad.net/bugs/349768
<hyperair> shit wrong bug
<hyperair> bug 349678
<ubottu> Launchpad bug 349678 in nautilus-share "Please merge nautilus-share (0.7.2-4) from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/349678
<hyperair> yeah that.
<nysosym> hi there
<lfaraone> james_w: ping (or anyone else in ~ubuntu-archive, I have a license question for ye)
<jdong> (directly asking the question works well in here; people actually read their scrollback)
<UsamaAkkad> hello, if some one want to do minimal install cd for Mint or similar Ubuntu based distribution. what file should he change ?
<lfaraone> james_w: would a package which as a rule does not allow binary/source modification (unless you change the package's name) but a special exception has been made for Ubuntu packaging (anybody else who made further changes would have to rename the package) be acceptable in universe, or only in multiverse?
<lfaraone> jdong: understood.
<jpds> lfaraone: Sounds like http://changelogs.ubuntu.com/changelogs/pool/multiverse/s/spim/spim_7.4-0ubuntu1/spim.copyright
<slangasek> mdke: why is the gnome-user-guide not split by language?
<lfaraone> jpds: kk. spesifically, it's truecrypt.
<lfaraone> jpds: which, while technically "FOSS" has a terrible license.
<jpds> Yes, I know.
<calc> slangasek: ping
<calc> slangasek: debian-bug 521741
<ubottu> Error: Launchpad bug 521741 could not be found
<calc> slangasek: looks like that might be ugly, i assume that is something we probably should fix before release?
<calc> slangasek: despite the package it is assigned to in debian it is not just a OOo bug
<calc> slangasek: rene just reused the same bug report apparently and reassigned later to OOo
<james_w> lfaraone: that's the sort of thing which would be multiverse material, but I believe truecrypt has other problems that may keep it from the archive.
<lfaraone> james_w: oh? such as?
<james_w> http://lists.freedesktop.org/archives/distributions/2008-October/000273.html
<james_w> http://lists.freedesktop.org/archives/distributions/2008-October/000276.html
<lfaraone> james_w: I see.
<james_w> not a definitive ruling, but it shows that there may be more to it than the usual restrictions
<mdke> slangasek: do you mean split into separate packages?
<mdke> slangasek: if so, I don't know. Neither gnome-user-docs nor ubuntu-docs splits into different languages, it's never been done that way. i guess the packaging for gnome-user-docs originally came from debian, but that's about all I know
#ubuntu-devel 2010-03-29
<rawkasaur> Does anyone know where the config for devicekit/synaptics touchpads are stored?
<psusi> hrm..... the man page for mke2fs says that -E lazy_itable_init defaults to 1 if not specified, but it doesn't....
<psusi> it also doesn't seem to set the lazy_bg flag when enabled, which it should...
<skydrome> can you echo $? of the 2nd to last command?
<ebroder> Hmm...if I want to get the new release of openafs into Lucid, how hard do I have to work to convince myself that it's just bugfixes?
<lifeless> very
<ebroder> :(
<ebroder> In all honesty, new openafs releases tend to do a *lot* for stability, so it would definitely be nice to have. I guess I'll see if I can pull an FFe together
<lifeless> well
<lifeless> start with the ffe
<lifeless> and make the case in that
<jdong> "I *swear* they're just bugfixes"
<jdong> someone needs to invent a launchpad tag for that :)
<micahg> jdong: it's called regression-update ;)
<RAOF> micahg: Any joy on gjs? :(
<micahg> RAOF: ugh, that's what I wanted to do this weekend....
<micahg> RAOF: I'll take a look tonight
<micahg> RAOF: I think I know what it is, the question is how easy will it be to fix
<micahg> RAOF: know anything about gnome-chemistry-utils?
<RAOF> If you don't have time, feel free to hand that potato on to someone else :)
<RAOF> I know nothing about gnome-chemistry-utils.
<RAOF> I don't even know what sort of chemical utils gnome *could* provide :)
<micahg> RAOF: I'm having trouble with it trying to verify a DTD on sourceforge at build time
<lifeless> micahg: you can'ty
<lifeless> micahg: no internets when building
<micahg> lifeless: I know that :)  Somehow it wasn't doing it before with the same code
<micahg> now it wants to
<lifeless> ah
<RAOF> I've seen that happen to a number of packages, but I can't remember the fix.
<lifeless> generally a mismatch
<lifeless> there is a local dtd
<lifeless> in the dtd path
<lifeless> but the package upgrades to a newer dtd
<lifeless> which isn't yet available locally for reference
<micahg> lifeless: does that mean I have to have the DTDs updated?
<lifeless> assuming my memory is right
<lifeless> check the diff between the last time the package built and your problem copy
<lifeless> if it doesn't change the xml ref anywhere, then check the packages it depends on
<micahg> lifeless: would you know offhand which package: http://pastebin.ubuntu.com/405453/
<lifeless> if its a docbook DTD docbook-xml looks promising
<lifeless> otherwise - no idea
<micahg> lifeless: k, I'll take a look, thanks
<lifeless> I'm going from 10 year old memories of working with xml stuff in cygwin
<pitti> Good morning
<RAOF> pitti: Good afternoon :)
<micahg> good late night :)
<xnox> Good early Morning =)
<dholbach> good morning
<cjwatson> skydrome: no, the shell only stores one; but you can assign $? to some other variable and check that later
<mdz> cjwatson, was it you who confirmed you had seen the thrashing during apparmor upgrades as well?
<ion> I have been encountering the problem, too, in case you need information about it.
<ion> mdz: Looking at IRC logs, he seems to have encountered bug #458299 indeed.
<ubottu> Launchpad bug 458299 in linux "apparmor_parser: page allocation failure. order:5" [Medium,Confirmed] https://launchpad.net/bugs/458299
<mdz> ion, thanks!
<mdz> I've never seen that error, but if it's using up a lot of kernel memory, it could very well have the same root cause
<cjwatson> mdz: yes
<t3rm1n4l> hi
<t3rm1n4l> how to download from lp using bzr
<t3rm1n4l> from this link
<t3rm1n4l> https://launchpad.net/~apachelogger/+archive/ubuntuone-kde
<t3rm1n4l> is ubuntuone client source code open ?
<mdz> t3rm1n4l, I think that corresponds to https://code.edge.launchpad.net/ubuntuone-client-kde but I'm only guessing
<t3rm1n4l> no its just a connector
<t3rm1n4l> actual dbus service and daemon is some other package
<mdz> t3rm1n4l, ask apachelogger, I guess
<t3rm1n4l> okay
<t3rm1n4l> i got the repo
<t3rm1n4l> lp:ubuntuone-client
<directhex> i wonder how brave i feel over upgrading this office PC to lucid. everything's always so much more painful on the mac than the other systems when it comes to upgrades.
<xnox> directhex, my Macbook refuses to upgrade to Snow Leopard. It tells me "can't install on this volume"
<xnox> silly thing =)
 * xnox is to lazy to back up Lucid & reinstall just to upgrade to Snow Leopard
<directhex> i can't expense an upgrade to macos, and never boot the thing into fringe OSes anyway
<xnox> directhex, well thanks to MacOS I was introduced to UNIX for the first time =) and that's why it now runs lucid and I have @ubuntu.com email address ;-) so can't complain it was a saviour for me =)
<pitti> james_w, lifeless: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/NewUpstream doesn't really say how to do a new upstream release; is that the correct command to use: bzr mu --version 1.6.0 -v ../gvfs_1.6.0.orig.tar.gz ? Will that do pristine-tar etc.?
<pitti> it seems to work fine, anyway; I'll add that to the wiki page once I get your "that's ok"
<pitti> superm1: nautilus-cd-burner has been obsolete for quite some time; would you mind dropping the recommends from dell-recovery?
<pitti> superm1: (should be brasero)
<pitti> seb128: ^ FYI
<seb128> pitti, thanks
<directhex> oh, looks like i can't upgrade... hash sum mismatch
<directhex> naughty repo.
<juliank> mvo: I just attached a merge directive to bug #548623 - feel free to pull it in the ubuntu branch & upload it.
<ubottu> Launchpad bug 548623 in python-apt "Attribute 'FindFile' of the 'apt_pkg.Configuration' object is deprecated" [Medium,Confirmed] https://launchpad.net/bugs/548623
<directhex> hm, weird upgrade failure today: keyboard/mouse have stopped responding
<davmor2> directhex: you mean you're not using psychic links like the rest of use ;)
<directhex> davmor2, wireless mice use psychic power, right?
<directhex> sigh, i wish xorg.0.log was timestamped
<davmor2> directhex: no that would be psycho power, similar but slightly more dangerous :D
<mvo> juliank: thanks
<mvo> juliank: much appreciated!
<juliank> mvo: Did you base aptdaemon 0.11+bzr342-0ubuntu1 on the 0.2.x branch?
<mvo> juliank: yes
<mvo> juliank: it should probably be a 0.20.x branch ideally
<mvo> juliank: because we use 0.11 currently
<lamont> http://paste.ubuntu.com/405960/ <-- against what do I file that bug?
<lamont> boring repetition that / has errors
<lamont> 'twould be nice to get a shell so I could, you know, do what it tells me to.
<lamont> would that be mountall, or something else?
<directhex> that was actually less painful an upgrade than i expected. loss of input devices notwithstanding
<juliank> mvo: Just ported aptdaemon to the new API.
<pitti> lamont: mountall seems not entirely wrong at least
<mvo> juliank: cool! trunk/ ? glatzor will love this
<juliank> mvo: 0.2.X.
 * mvo nods
<mvo> juliank: python-apt uploaded
<lamont> pitti: ta
<juliank> mvo: Great.
<directhex> 0% [Working]*** glibc detected *** aptitude: free(): invalid pointer: 0x0000000001fd8dc0 ***
<directhex> meep
<mvo> directhex: bug #517797 maybe?
<ubottu> Launchpad bug 517797 in apt "apt does not time out during initial update" [Medium,Confirmed] https://launchpad.net/bugs/517797
<mvo> directhex: eh, sorry
<mvo> directhex: wrong bug number
<directhex> i guessed
<directhex> annoyingly, apport won't report it
<sladen> zul: those bugs are with vmbuilder in lucid and with the branches on Launchpad
<sladen> zul: vmbuilder is completely shagged
<zul> sladen: k...ill let soren now
<sladen> zul: any idea what timezone soren is on?
<zul> sladen: central european
<james_w> pitti: yeah, that wiki page is misnamed, I intend to move the existing one to "NewPackage" or something and explain how to merge a new upstream on there. You got it right though.
<pitti> james_w: ah, thanks for confirming
<Riddell> tedg: ping
<tedg> Good morning Riddell
<Riddell> tedg: I have a patch from agateau to update the namespace for status notifiers from org.freedesktop to org.kde, I believe this need coordinated with you
<tedg> Riddell: Yeah, I think we've already released it on the GNOME side.  So it should be good.
<Riddell> groovy, I'll do that with kde 4.4.2 then
<tedg> Riddell: Great!  Thanks.
<superm1> pitti, i had left it as an alternative so the deb could be installed on old versions of ubuntu and still functional.  will it cause archive problems to leave it in place?
<pitti> superm1: oh, I see; no, that's fine
<pitti> thanks
<caeee> hi, where can I find the patch from ubuntu packages linux-source-2.6.24-26 to linux-source.2.6.24-27
<qense> pitti: You're maintaining the work-item overviews, right?
<pitti> qense: yes
<qense> pitti: I think I have found a bug in the QA one.
<qense> pitti: http://people.canonical.com/~pitti/workitems/canonical-qa.html says that jeremyfoshee has two open tasks and no closed, but on https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-lucid-bug-handling you can see he has DONE three.
<pitti> qense: "canonical-qa" reports are obsolete
<pitti> we use canonical-platform-qa now
<qense> pitti: ah, that explains
<pitti> http://people.canonical.com/~pitti/workitems/canonical-platform-qa.html
<qense> pitti: thanks
<pitti> but I was asked to keep the canonical-qa ones around for a while
<qense> ok
<nigelb> so is there something that keeps ALL developers busy after release and before UDS?  I'm planning for a patch review day then
<nigelb> expected date is May 5th, but if its bound to be a busy day, I'll have to make adjustments, so can people let me know your comments?
<LaserJock> I thought that was "party 'til you're so drunk you rm -rf / yourself" time :-)
<micahg> nigelb: core devs are usually trying to get the toolchain for next release in I think...
<nigelb> LaserJock, can't do that in ubuntu anymore, its patched (test at your own risk though)
<nigelb> :D
<nigelb> micahg, oww
<nigelb> micahg, but well, the targets are mostly MOTU plus hoping-to-be-MOTU
<nigelb> if core-devs can give 1 hour of their time, I'd be happy :)
<juliank> mvo: I Just filed Bug #550934 with a merge directive
<ubottu> Launchpad bug 550934 in software-center "Please merge software-center 1.1.21debian2 from Debian incoming (brings python-apt 0.8 API support)" [Undecided,New] https://launchpad.net/bugs/550934
<juliank> There are no new features in it; so it should probably be OK.
<james_w> doko__: can you confirm binary or source in bug 549320 please?
<ubottu> Launchpad bug 549320 in ironpython "removal of the ironpython binary package in lucid" [Undecided,New] https://launchpad.net/bugs/549320
<james_w> it sounds like the title is wrong
<jdstrand> kirkland: fyi, the md/ext4 bug we talked about is bug #543617
<ubottu> Launchpad bug 543617 in linux "very slow filesystem I/O" [High,Confirmed] https://launchpad.net/bugs/543617
<doko__> james_w: binary package only
<kirkland> jdstrand: thx
<pitti> sbeattie: any chance you could give the karmic-proposed devicekit-disks a try? (bug 445852); that's pretty urgent, to avoid even more HD damage
<ubottu> Launchpad bug 445852 in devicekit-disks "devkit-disks-probe-ata-smart causes HSM Violations on SSD, and potential hardware death" [Critical,Fix committed] https://launchpad.net/bugs/445852
<pitti> sbeattie: i. e. the disk utility shouldn't show smart data any more, but automount etc. should still work
<james_w> doko__: eh? If the binary is built from dlr-languages we don't need to remove it
<sbeattie> pitti: reading.
<doko__> james_w: hmm, yes, I meant source :/ don't trust me, do the right thing ...
<james_w> doko__: ok, great, thanks
<pitti> sbeattie: don't bother reading the entire bug, though :) I'm happy to give you a summary if you need one
<sbeattie> pitti: note that I don't have any ssds
<pitti> sbeattie: you don't need one; I think the main point of verification here is that the package still by and large works
<pitti> sbeattie: if you get an usb stick automounted, that should be sufficient
<pitti> sbeattie: the only change is disabling the smart prober in the udev rules (a text format), no code changes
<pitti> sbeattie: so we just need a quick check for "misbuilt/toolchain bug" etc.
<sbeattie> pitti: okay. I'll get it done today.
<pitti> sbeattie: I. e. this is a quick stopgap workaround until we have a real fix
<bigon> james_w: for bug 549234 I have upload rights to universe actually
<ubottu> Launchpad bug 549234 in hellanzb "Please sync hellanzb (0.13-6) from debian unstable" [High,Confirmed] https://launchpad.net/bugs/549234
<pitti> sbeattie: thanks, appreciated
<james_w> bigon: well you didn't state that it should be synced so I missed it
<bigon> oh I only changed the subject
<geser> james_w: bug #550262 updated
<ubottu> Launchpad bug 550262 in db4.2 "Remove db4.2 from lucid" [Medium,New] https://launchpad.net/bugs/550262
<james_w> thanks genii
<james_w> geser
<barry> does anybody know if it's possible to get more information out of the installer when a step like grub-install fails?
<james_w> barry: there's /var/log/installer IIRC that might help
<barry> james_w: ah, i found /var/log/syslog
<free> pitti: ping
<jussi01> pitti: ping
<jussi01> free: hehe, he's a wanted man :)
<free> jussi01: yeah.. :)
<pitti> free, jussi01: contentless pong (please just ask the question, don't ping)
<free> pitti: oh fine
<jussi01> pitti:  could you take a look at the ircc thing here: https://blueprints.launchpad.net/ubuntu/+spec/irc-council-lucid-plans and let me know where we went wrong that it says 0% here: http://people.canonical.com/~pitti/workitems/canonical-community.html ?
<free> pitti: so, upgrading from hardy to lucid doesn't seem to restart the old dbus service, so applications relying on dbus won't quite work before rebooting
<free> pitti: is that expected or is it a bug?
<pitti> free: after an upgrade, pretty much nothing will work
<pitti> you absolutely need to reboot after an upgrade
<free> pitti: I've tried to manually kill the old dbus and start the new and it worked though
<pitti> it's expected, yes; we can't restart the system d-bus easily, and even less so the session ones
<free> pitti: I see
<free> pitti: the problem is that with the landscape-client we'd need a working dbus enviroment before and after the dist-upgrade
<free> pitti: so I guess it would be very bad if we implemented some hackish workaround like the manual one above (killing the old dbus and starting the new one)
<pitti> jussi01: ah, the problem is that you arne't in the canonical community team, so your WIs won't appear there
<pitti> free: that's the system d-bus, right?
<free> pitti: rright
<pitti> free: so, until hardy, stopping the system dbus would tear down your entire system
<pitti> free: it doesn't do that any more in lucid, since we switched X.org from hal to udev
<free> pitti: so that means the desktop would crash?
<pitti> so I guess the desktop would survive it
<free> pitti: anyway you wouldn't recommend it at all?
<pitti> but it's still not been tested at all, and changing that at this point of the release cycle is too brittle IMHO
<free> pitti: agreed
<pitti> free: no, I wouldn't; there's much more than this which doesn't work after a system upgrade, I'm afraid; you do need a reboot
<james_w> free: what about dbus doesn't work after the upgrade?
<james_w> free: it should still be working, just the old version
<pitti> free: but what does actually break?
<free> pitti: alright, thannks for explaining
<free> pitti, james_w: https://pastebin.canonical.com/29788/
<pitti> jussi01: http://people.canonical.com/~pitti/workitems/all.html#jussi01 has your's, FYI
<free> I'm not very familiar with the dbus internals, but starting the newly installed dbus from lucid makes it work
<free> note that we're starting a different process
<free> not the old one which was connected to dbus *before* the ugprade
<james_w> well, "Failed: Success" is odd to start with
<free> james_w: yeah :/
<pitti> free: right, that moved to /lib/dbus-1.0/dbus-daemon-launch-helper
<pitti> but the old d-bus would still try the old path
<pitti> as a workaround we could ship a symlink in lucid (which we could drop in lucid+1)
<free> james_w: I believe that comes from d-bus itself though, it's the exception text
<james_w> yes, it's calling strerror(0) apparently
<jussi01> pitti: ok, but why the 0% on there on the one I mentioned?
<free> pitti: I'm gonna try to put the symlink manually as a start
<pitti> jussi01: it's just counting the WIs for people in that team
<pitti> free: testing with the symlink is highly appreciated; if that works, I'm fine with adding that as an upgrade workaround
<pitti> free: thanks for catching!
 * pitti -> dinner, bbl
<free> pitti: and thanks for the hint!
<jussi01> pitti: ahh, thanks
<ejat> anyone know why this happen http://paste.ubuntu.com/406057/ ?
<chrisccoulson> ejat, your file system has gone read only
 * barry -> lunch
<pecisk> kenvandine, ping?
<kenvandine> pecisk, pong
<pecisk> kenvandine, take a change on patch? :)
<kenvandine> pecisk, i haven't had a chance to try it yet... sorry
<kenvandine> been chasing a pretty nasty bug in gwibber :/
<cnd> cjwatson: do you know how the initramfs is generated?
<amitk> cnd: hehe, that's like asking Darwin if he knew about Biology
<cnd> amitk: just checking
<pecisk> kenvandine, will take a look later today? :)
<cnd> I need to figure out how to get a script into the initramfs
<kenvandine> pecisk, yeah, will do :)
<pecisk> kenvandine, thanks. Keep rocking :)
<amitk> cnd: putting it in /etc/initramfs-tools/scripts doesn't help?
<amitk> and regenerating the initramfs, ofcourse
<cnd> amitk: I think the proper place is in /etc/initramfs-tools/hooks
<cnd> but I can't seem to get stuff to get put in the initramfs when I invoke update-initramfs -k `uname -r` -u
<amitk> cnd: then I'm out of ideas
<lamont> asac/ogra: buttercup/cushaw/gourd are online now, the remainder are probably post-8 april.  turning down kandis/korlan to start the migration
<cjwatson> cnd: if you're producing a package, the script that actually runs in the initramfs goes somewhere under /usr/share/initramfs-tools/scripts/ depending on when it should run, and you normally also want a script in /usr/share/initramfs-tools/hooks/ that copies the relevant files in
<cnd> cjwatson: I figured my issue out, and I realized I didn't need to muck with changing anything in the initramfs
<cnd> thanks though
<cnd> cjwatson: however, I do have another issue if you have some time to help?
<cjwatson> cnd: I'm about to get pulled away to watch TV with the family, but you can leave a message and either somebody will beat me to it or I'll answer when I get back
<cnd> cjwatson: simple non-kernel package maintenance: We need to add a special modprobe.d file and script to be run when vga16fb tries to load
<cnd> I figured I'd stuff it into module-init-tools, since that's where the other modprobe.d stuff is
<cjwatson> cnd: I strongly, strongly advise discussing it with Keybuk first
<cnd> I'm not too familiar with the dev process outside of the ubuntu kernel, so I wanted to confirm that I should check the source out from lp, and then upload my changes to my own branch, and create a review for the branches?
<cjwatson> that stuff is all very delicate and it's easy to compromise boot time
<cnd> cjwatson: agreed, though I'm trying to figure out the best way to show what I'm thinking
<cjwatson> sure, the process you describe is reasonable; the best branch to use depends on the circumstances of course
<cnd> yeah, ok
<cnd> cjwatson: thanks
<cjwatson> (it's also perfectly fine to send ordinary patches if you want, though of course branches have the opportunity to be merged more smoothly)
<cnd> cjwatson: I'm partially curious to know how the foundations team usually works
<cnd> is it through lp branches and merge requests?
<cnd> or through patches?
<cjwatson> cnd: we're flexible
<cnd> cjwatson: cool
<cjwatson> cnd: the growing preference is to use bzr; we're not quite there yet across the board
<cnd> I think I prefer bzr+lp too
<cjwatson> cnd: mostly it's a question of having bzr imports of all the packages we work on, which is a big job - mostly there but not quite
<cnd> yeah
<arand> cjwatson: What is the status of swap-onf-file atm? https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-karmic-swapfile is old, still valid? Is hibernation-to-file the current blocker?
<zyga> hello
<jdstrand> mvo: hi! so, I am running into bug #502641 (or a variant of it) but I have an up to date apt (0.7.25.3ubuntu4)
<ubottu> Launchpad bug 502641 in apt "[Lucid] apt-get source always selects highest available version instead of the specified one" [High,Fix released] https://launchpad.net/bugs/502641
<mvo> jdstrand: thanks, could you add some details to the bugreport or create a new one? with sources.list and what exactly you run?
<jdstrand> mvo: ok, I tried to file a bug and there were a bunch that looked the same, so I thought I'd ask. I'll file a new one and give it to you. thanks
<mvo> jdstrand: thanks, I know that its still not 100% where it was, but I would appreciate a good report to reproduce it
<cjwatson> arand: I think the status is documented in the spec; I don't know any more than that.  It's still valid though and I'd like us to do it at some point, so please don't close it out or anything like that
<arand> cjwatson: Ah, cool, I was just wondering if there were any news in general, or a new bp or so.
<jdstrand> mvo: bug #551178
<ubottu> Launchpad bug 551178 in apt "apt-get source pkg=version downloads the wrong version" [Undecided,New] https://launchpad.net/bugs/551178
<jdstrand> mvo: I attached both kees' sources.list and mine (we both are seeing this)
<mvo> jdstrand: thanks, that looks good, I hope I can reproduce it, you use file:// urls that I don't have access to
<jdstrand> mvo: well, kees uses file://. I use a local debmirror
<jdstrand> mvo: via http
<mvo> jdstrand: ok
<jdstrand> mvo: I also use sources.list.d, and I put all mine in a tar.gz
<jdstrand> (as an attachment in the bug)
<mvo> jdstrand: thanks, I milestoned it
<jdstrand> mvo: thanks! :)
<mvo> jdstrand: thanks for reporting :)
<jdstrand> sure thing :)
<cjwatson> jbebel: you were right about it being partman-base's fault, but I was right that it was coincident with moving to parted 2.x rather than due to the alignment change. :-)
<Laney> cjwatson: hey, the ubuntu-mono ML was deleted from the other team now, should be good to go
<cjwatson> Laney: excellent, that worked, pending confirmation
<Laney> cool
<Laney> cjwatson: done it. Could you run that script now to subscribe the team to all of the packages? (do you want a link again?)
<cjwatson> Laney: link me please, yes
<Laney> ok, one sec
<amanda1> http://www.mdhjakten.se/dela/?id=dti2d6s
<amanda1> nice svhool
<Laney> cjwatson: http://pastebin.com/NuNw7qGm
<dutchie> hey folks, just looking at fixing bug 523822 in the "right" way. ought I use something in debian/patches, or should I just change the file in the main bit. (I've branched lp:ubuntu/<package>)
<ubottu> Launchpad bug 523822 in software-center "software-center crashed with TypeError in __init__()" [Undecided,Incomplete] https://launchpad.net/bugs/523822
<dutchie> where <package> = aptdaemon
<dutchie> hmm, looks like it may make more sense to file a bug on aptdaemon
<cjwatson> dutchie: use whatever patching method is already in use in the package you're working on
<jbebel> cjwatson, Good to know.  I'm glad you were able to reproduce it.
<dutchie> cjwatson: it seems to be fixed in upstream aptdaemon
<dutchie> also, I'm enormously unfamiliar with patching systems
<cjwatson> jbebel: I actually didn't directly, but I'm close to certain that my fix will cover it given what I now understand of the problem
<cjwatson> jbebel: also, I've just done a successful end-to-end test of automatic LVM+encryption partitioning with my change
<jbebel> Excellent.  I look forward to testing it as well.
<cjwatson> well, successful modulo some text being spat out at boot time that shouldn't be, but I'm going to declare that Not My Problem for today
 * cjwatson wonders if we should silence the LVM fd leak warnings for lucid release
<jbebel> It would make it less frightening.
<cjwatson> Laney: done, seemed to work: http://paste.ubuntu.com/406184/
<Laney> cjwatson: thanks a lot, +packagebugs looks good now
<Laney> that script might be useful for you in the future for other similar teams
<cjwatson> yeah, I'll keep it lying around
<sebner> Laney: cjwatson : \o/
<cjwatson> slangasek: cryptsetup's passphrase prompt is displayed as "Enter passphrase: :********" in the plymouth details plugin, which isn't too pretty.  Is that a bug in cryptsetup or plymouth or both?
<slangasek> cjwatson: I thought those LVM fd leak warnings *were* silenced once upon a time, and have since regressed
<slangasek> cjwatson: "isn't too pretty" - the double colon?
<cjwatson> yes
<cjwatson> well, I fixed the fd leak warning induced by cryptsetup, at any rate
<slangasek> I think that's a plymouth bug
<cjwatson> so the interface is meant to involve passing a string terminated by ": "?
<slangasek> IMHO the presence or absence of a trailing colon should be up to the caller
<slangasek> and in this case, certainly, I think it's a bug to have :*** with no space after the colon that details.so is appending
<dutchie> does "bzr push lp:~jshholland/ubuntu/aptdaemon/fix-beginn" look right for pushing a fix to lp:ubuntu/aptdaemon?
<cjwatson> slangasek: well, yes ...
<cjwatson> dutchie: lp:~jshholland/ubuntu/lucid/aptdaemon/fix-beginn
<dutchie> ok, thanks
<slangasek> cjwatson: for comparison, the ubuntu-logo theme does not append a colon there, and I think we still want it
<slangasek> cjwatson: but I'm happy to be persuaded that I have no sense of aesthetics instead :)
<cjwatson> note that lp:ubuntu/aptdaemon is an alias for lp:~ubuntu-branches/ubuntu/lucid/aptdaemon/lucid - the fully-qualified pattern is lp:~OWNER/DISTRIBUTION/SERIES/PACKAGE/BRANCHNAME
<cjwatson> slangasek: I don't care either way
<dutchie> OK, pushed. Will it end up being reviewed, or do I need to subscribe someone or do a merge request?
<cjwatson> dutchie: you'll need to file a merge request if you want anyone to see it; nobody is automatically told about new branches
<dutchie> alrighty
<Laney> do you need to subscribe sponsors to merge requests?
 * Laney has never done it from that side
<Laney> ah, you request a review from them
<cjwatson> the merge request UI asks you for a reviewer
<dutchie> is this even if I committed with --fixes?
<Laney> that just links it to the bug report
<Laney> you need to ask for sponsorship too
<cjwatson> linking it to the bug report will cause mail to be sent
<cjwatson> so explicitly asking isn't quite so required, but it doesn't hurt to get your change onto the organised sponsorship list anyway
<dutchie> so file a merge request?
<Laney> I guess it depends who will read that mail
<Laney> but yes, that's safe
<sebner> Laney: you uploaded mono yourself?
<Laney> yes
<sebner> Laney: cool :)
<Laney> hopefully we can sync again soon
<Laney> would have done this time, but with ries (ftpmaster) being down, ...
<sebner> Laney: yeah, I heard it might be back tomorrow
<Laney> starts getting close to freeze time
<slangasek> Laney: yay, thanks for the mismatch-cleaning upload :)
<Laney> no worries
<jdstrand> kees: fyi, the hard lockup when doing lvm snapshotting bug is bug #551264
<ubottu> Launchpad bug 551264 in linux "lvm dies while snapshoting" [Undecided,New] https://launchpad.net/bugs/551264
<kees> jdstrand: okay, cool.
<cjwatson> marjo: any chance http://people.canonical.com/~marjomercado/isotestingbugs.html could be updated?
#ubuntu-devel 2010-03-30
<jbebel> Did the amd64 partman-base fail to build?  It didn't show up in the pool.
<cr3> anyone happen to be running lucid desktop in virtual box? I'd really appreciate having the output of a command from that environment
<jbebel> cr3, I have a lucid desktop in vbox.
<cr3> jbebel: awesome! could you send me the output from running the command /usr/share/checkbox/scripts/udev_resource?
<jbebel> cr3, http://paste.ubuntu.com/406265/
<cr3> jbebel: excellent, that confirms a bug reported. can you also pastebin the output of: ls /sys/devices/virtual/dmi/id
<jbebel> cr3, http://paste.ubuntu.com/406267/
<cr3> jbebel: would you mind if I asked you to make a modification to /usr/share/checkbox/scripts/udev_resource and try again?
<jbebel> Sure
<cr3> jbebel: simply replace line 392 with: type = int(self._attributes.get("chassis_type", "0"))
<cr3> jbebel: then, try running again and let me know if you still get an exception
<jbebel> No exception
<cr3> jbebel: awesome! I'll submit that fix
<nixternal> Hobbsee: 20:27:44 [ nixternal] I miss hobbsee   - we need you back :~(
<ScottK> +1 for Hobbsee's return.
<lifeless> she's gone?
<ajmitch> just a bit inactive, I thought
<ScottK> Quite a bit.
<AlTheKiller> Hi, is there a quick way to determine what configure flags were used to build a package?
<hdon> hi all. i am having a problem building a release version of Go on Ubuntu Karmic: http://pastebin.mozilla.org/711474
<hdon> it looks like /usr/include/gnu/stubs.h are trying to include "gnu/stubs-32.h" and not finding it
<nixternal> slangasek: for that bug 551290 - that means I need to lame out the theme right? can't use no good colors
<ubottu> Launchpad bug 551290 in kubuntu-default-settings "[lucid] Kubuntu theme on nvidia card too ugly" [High,Triaged] https://launchpad.net/bugs/551290
<pitti> Good morning
<nixternal> mornin' pitti
<slangasek> nixternal: well, I don't know how Keybuk intends to handle selecting a different image for VGA vs. drm; perhaps you should wait and see what develops there
<nixternal> oh, well that is good to know....
<pitti> hi nixternal
<nixternal> so I take it aubergine was a nightmare on nvidia crap hardware?
<tjaalton> slangasek: hey, got a minute for the backport ffe?
<slangasek> tjaalton: looking at it now
<tjaalton> slangasek: cool, thanks
<slangasek> nixternal: no, aubergine still looks fine in VGA, but the logo is dithered
<nixternal> damn, gotta DMB meeting at 10am....just my luck, I volunteered to chair...10am is to early
<nixternal> slangasek: hrmm
<nixternal> so much for my theme where distro logos come in, and then get smashed by the kubuntu logo :p
<apachelogger> good plan it was though
<nixternal> hehe
<dholbach> good morning
<slangasek> ArneGoetje, pitti: livefs build failure today, file conflict between language-pack-gnome-de and language-pack-de (/usr/share/locale-langpack/de/LC_MESSAGES/clutter-1.0.mo)
 * slangasek waves to dholbach 
<dholbach> hola slangasek
<ArneGoetje> slangasek: gaa... another template moved... shall clutter be in -gnome or in the common langpacks?
<slangasek> ArneGoetje: wherever you think it belongs? :)
<ArneGoetje> slangasek: I don't know clutter. Is that a gnome specific thing or a generic thing?
<slangasek> ArneGoetje: it's GTK-specific, but not very GNOME-specific; it does appear to be in both ubuntu-desktop and ubuntu-netbook, and not in kubuntu-netbook, though, so I guess -gnome is the right answer
<ArneGoetje> slangasek: ok, thanks
<ArneGoetje> slangasek: that needs new -base language-packs. I will rebuild them.
<free> pitti: creating a symlink /usr/lib/dbus-1.0/dbus-daemon-launch-helper -> /lib/dbus-1.0/dbus-daemon-launch-helper solves the hardy-to-lucid upgrade problem (new processes can't connect to dbus anymore after the upgrade)
<free> pitti: do you want me to file a bug or can you just make a new revision of the dbus package?
<lifeless> persia: ping
<dholbach> persia: "The DMB currently meets every two weeks in #ubuntu-meeting at 15:00 UTC." isn't very clear (https://wiki.ubuntu.com/DeveloperMembershipBoard) - should that be "ever 2nd and 4th tuesday of the month" - also does fridge say 14 utc
<dholbach> or geser, soren, stgraber, cody-somerville ^ :)
<geser> dholbach: fridge got confused with the DST change, the DMB meeting is still at 15:00 UTC
<dholbach> ara: ^
<geser> dholbach: as the DMB meetings alternate with TB meetings, you would also have to set the TB meetings to 1st and 3rd Tuesday to let it work without collisions
<dholbach> geser: I don't know - I was just looking at the page and thought it's a bit unclear
<pitti> free: can you please file a bug and assign to canonical-desktop-team?
<pitti> free: great to hear that it worked!
<dholbach> either you explain the rule or mention when the next meeting is going to be :)
<geser> dholbach: else the schedule shifts in months with 5 tuesdays (like this month where the DMB meetings happened on 1st, 3rd and 5th Tuesday)
<dholbach> ah
 * Ng wonders why we don't just run fsck -y when it says it needs to be run manually
<geser> dholbach: mentioning the next meeting seems to be easier (would mentioning it on the Agenda page be clear enough?)
<Ng> exactly who ever runs fsck and doesn't just say yes to all the things it wants to fix? ;)
<Ng> other than Ted
<dholbach> geser: yeah, probably
<alkisg> Hi, could someone help with bug #491940?
<ubottu> Launchpad bug 491940 in ltsp "Patch for LTSP clients to properly reboot/shutdown" [Undecided,Confirmed] https://launchpad.net/bugs/491940
<alkisg> I've committed a patch in LTSP that would solve the problem, if the corresponding patch that I sent to gnome-session was accepted.
<alkisg> The gnome-session patch was neither accepted nor explicitly rejected. In any case, the problem remains:
<alkisg> LTSP clients in Lucid have non-working reboot/shutdown menus. They were working in previous releases with a similar patch in fusa.
<alkisg> As a teacher I think this is really inconvenient for schools, so I'd appreciate it if someone could direct me to a way to deal with this problem.
<dholbach> thanks geser
<lifeless> persia: ping ;)
<pitti> amitk: do you still remember the power saving UDS discussion? one point was "do not enable fingerprint readers unless fprint/thinkfinger are installed", which unfortunately was only put on the beta-2 list
<pitti> amitk: however, there is no specific module for those which could be blacklisted with a modprobe.d file (unless tf/fprint are available)
<pitti> amitk: is there some better way to not enable those?
<lifeless> pitti: are fprint and thinkfinger quivalent ?
<pitti> amitk: also, I don't see the device appear in powertop at all; 80% of wakeups are "rescheduling interrupts" and "load balancing" and "extra timer interrupt" (which all seem kernel related), and 8% is touchpad; the rest seems negligible
<pitti> lifeless: in terms of using the fingerprint scan device they should be?
<lifeless> cool
<lifeless> I'll go for thinkfinger then as it has thinkfinger-tools
<pitti> lifeless: I tried tf in the past, and it worked; fprint is allegedly a more flexible platform, but I haven't ever tried it
<pitti> but I have never actually used this thing
<lifeless> pitti: I has a new laptop ;)
<lifeless> actually has three buttons on the touchpad again (yay!)
<pitti> I type my user name faster than I can swipe my finger, and a fingerprint reader isn't for authentication
<lifeless> but also a fpr reader
<lifeless> its not for auth?
<pitti> lifeless: wohoo; another three years over? which one did you get?
<lifeless> x201s/8G/128G SSD
<pitti> lifeless: my latitude 430 has an fp reader as well
<pitti> lifeless: is that a thinkpad?
<lifeless> yes
<lifeless> pitti: I know, my old D430 is on the floor beside me
<pitti> amitk: http://paste.ubuntu.com/406418/ for the record; it's actually a little disappointing, in jaunty/karmic I got it down to 10 W
<pitti> lifeless: for warming your feet now? :-)
<lifeless> pitti: :>
<lifeless> npviewer.bin die die die
<pitti> lifeless: not for auth> your fingerprints are all over the place, and also conveniently located on the keys, the laptop cover, the wrist rests, etc; not much different than writing your password on a post-it note on the monitor
<lifeless> I thought that the point was to check for a pulse at the same time
<pitti> the ones that they built into notebooks don't have life sign detection
<lifeless> :>
<pitti> they are by and large just an optical scanner
<lifeless> ah
<lifeless> fail
<lifeless> 42% of wakeups 'Load balancing tick'
<lifeless> 18% iwlagn interrupt
<lifeless> 11% firefox
<pitti> I disabled firefox, network, empaty, and almost everythign else except gnome-terminal for that run
<lifeless> this machine is sitting at 12W with nothing disabled
<lifeless> screen at 60% or so
<cjwatson> lifeless: don't suppose you happened to run across any decently-priced non-Thinkpad SSD laptops ...
 * cjwatson looking for recommendations right now
<lifeless> cjwatson: johnf here in sydney is very happy with an hp netbook w/ssd
<lifeless> being extremely cheap as a result of being a netbook
<cjwatson> mm, HP was on my list, although I don't want a netbook - might look into what else they have
<lifeless> cjwatson: I'm not a IBM fanboy per se, but I'm quite happy with this.
<lifeless> why are you excluding thinkpads ?
<cjwatson> I despise the Esc key placement
<cjwatson> (trivial I know, but it has long annoyed me)
 * RAOF opens his thinkpad to check the Esc key...
<pitti> swapping esc and caps lock in ~/.xmodmap FTW
<lifeless> cjwatson: ah yes. its been pissing me off just enough to be a PITA, but not enough to want to return an otherwise great machine.
<pitti> (for all of us happy vim users)
<cjwatson> pitti: ah, the thing is, I like Caps Lock as well
<pitti> cjwatson: oh; I don't know many people who do
<cjwatson> anyway, I suppose this is OT, sorry
<lifeless> heh
<lifeless> tumbleweeds if we were not talking
<RAOF> Hardware lust is *always* on topic. :)
<pitti> at least it never seemed important enough to me to give it such a good and comfortable position on a keyboard..
<pitti> cjwatson: partman-multipath wants to go back to universe, 's ok?
<tjaalton> nooo
<tjaalton> though I've not had a chance to try it yet
<pitti> hm, then perhaps some dependency was dropped?
<cjwatson> wonder how that fell out, I thought I'd seeded it
<cjwatson> I don't think anything ever depended on it
<tjaalton> cjwatson: do you know if someone has tested it on lucid yet?
<cjwatson> tjaalton: I don't know
<cjwatson> not that it's changed much?
<cjwatson> I'm just going to seed it, it's been in main since jaunty
<tjaalton> yeah it worked fine then, will reinstall the shell server with lucid this summer
<tjaalton> it handles ~800 unique sessions just fine
<pitti> cjwatson: related to that, libudev0-udeb wants demotion as well, that doesn't look intended?
<cjwatson> does anything depend on it?
<cjwatson> nothing in the core installer uses libudev
<cjwatson> I assumed it was there because udev-udeb linked against it
<Keybuk> I think I compile udev-udeb static
<cjwatson> it's not static, but nothing in udev-udeb seems to use libudev
<cjwatson> even in the main udev package, it's only input_id
<pitti> I checked ldd, and it doesn't lik against libudev-udeb
<pitti> cjwatson: input_id was fixed in the last upload, or should have been at least
<pitti> yep, seems fine
<cjwatson> I didn't know it was a bug, but OK
<pitti> ok, so it seems that can safely go
<mdz> pitti: hi, I noticed you were looking at apport stuff this morning. did you have a chance to look over my Java crash handler?
<pitti> tseliot: is nvidia-185-modaliases current or obsolete? (it wants to go to universe)
<pitti> mdz: not yet, sorry; I'm afraid this has to wait for a bit (it will take me some time to learn about java stuff)
<pitti> mdz: but if it works for you, I'm happy to merge it
<tseliot> pitti: it's a transitional package and I think we need it in main/restricted (why universe??)
<pitti> tseliot: well, s/universe/not main/
<pitti> tseliot: ah, ok, so we should seed it
 * tseliot nods
<pitti> tseliot: done
<tseliot> pitti: thanks
<mdz> pitti: it's not ready to merge yet; it's just some dead code in the source tree right now (doesn't get tested or installed)
<cjwatson> TheMuso: could you look at bug 551515 and decide whether it makes sense?
<ubottu> Launchpad bug 551515 in casper "[Lucid] need little modify the ubiquity-hooks/30accessibility script with gdm accessibility setting configuration part in Blindness profile" [Undecided,New] https://launchpad.net/bugs/551515
<nosse1> Hello. How can I debug upstart during system startup? I cant inject strace in the init="" kernel string, because that results init/upstart not to become process num 1
<marufaberlin> is there a channel for ubuntu app development? i'm trying to implement a virtual semantic file system for ubuntu
<nosse1> Yes, See #ubuntu-app-devel
<TheMuso> cjwatson: It makes sense to me, I'm not sure whether the proposed solution is sane however.
<marufaberlin> thanks :)
<TheMuso> cjwatson: I need to talk to the desktop fols about this, and will follow up and make changes if necessary.
<TheMuso> folks
<cjwatson> TheMuso: thanks
<Keybuk> nosse1: what are you trying to debug?
<nosse1> Keybuk: Upstart. I have a ARM target which fails sometime during upstart
<Keybuk> nosse1: no, what problem are you trying to debug
<Keybuk> it's unlikely you have a problem with the init daemon itself
<nosse1> Keybuk: Yes, upstart is probably not the culprit. I'm working on an initial bringup of Ubuntu to a new target, so it's likely that its something in relationshop with the kernel
<nosse1> Keybuk: However init="/sbin/init --verbose" does not reveal anything useful
<Keybuk> nosse1: again, what problem are you trying to debug?
<nosse1> My target system won't boot. It hangs somewhere between init and the console login
<Keybuk> with --verbose, what is the last message on the console that you see?
<nosse1> It varies. Sometimes it hangs in the middle of a output line, like "init: module-init-tools state changed from waiting to s"
<\sh> is there a special irc channel for ubuntu one?
<Keybuk> nosse1: did you try booting without "quiet" to get kernel messages?
<nosse1> Keybuk: Yes I'm on a embedded target, so quiet is not enabled per default
<nosse1> No special message there
<Keybuk> if output is stopping mid-way through a line, it really sounds like a deeper problem
<nosse1> I suspect a syscall crashing the system, and I hoped strace could point me in the right direction
<Keybuk> you can't strace init
<Keybuk> and, even if you could, init doesn't make many interesting syscalls; fork() and exec() are all it really does
<nosse1> if I can get strace to follow those forks and execs then that is what I want :)
<Keybuk> right, but you can't strace init
<nosse1> How is that?   strace -p1 wont work?
<Keybuk> right
<Keybuk> the kernel won't let you do it
<nosse1> ah
<nosse1> I'll start peeling of services and see if I can come any closer
<nosse1> upstart will only consider *.conf in /etc/init right? I can rename them to foobar.conf.nope to disable them?
<Keybuk> right
<alkisg> Hi, could someone help with bug #491940?
<ubottu> Launchpad bug 491940 in ltsp "Patch for LTSP clients to properly reboot/shutdown" [Undecided,Confirmed] https://launchpad.net/bugs/491940
<alkisg> I've committed a patch in LTSP that would solve the problem, if the corresponding patch that I sent to gnome-session was accepted.
<alkisg> The gnome-session patch was neither accepted nor explicitly rejected. In any case, the problem remains:
<alkisg> LTSP clients in Lucid have non-working reboot/shutdown menus. They were working in previous releases with a similar patch in fusa.
<alkisg> As a teacher I think this is really inconvenient for schools, so I'd appreciate it if someone could direct me to a way to deal with this problem.
<seb128> alkisg, the gnome-session change you suggest seems rather an hack that's the correct way
<seb128> alkisg, it seems to need some work but that will not be changed in lucid now
<alkisg> seb128: I wouldn't call it a hack - it's the standard way we use in LTSP for the server to communicate to the client
<alkisg> seb128: so the desision is to have broken menus for LTSP clients? Isn't LTSP in main?
<seb128> alkisg, did you address the comments on the bug?
<alkisg> Yes, all of them.
<seb128> k so maybe somebody will review it
 * alkisg doesn't think so, else he wouldn't ask here...
<seb128> that's not a decision rather than how things are turning
<alkisg> seb128: why not just accept the patch?
<seb128> to be honest I don't think so either
<alkisg> Is it so horrible?
<seb128> because it's a hack
<alkisg> Then all of LTSP is a hack
<alkisg> Because that's the way localapps are implemented in LTSP
<seb128> and we have other issues we need to work on now
<seb128> and nobody in the desktop team seems to be interested in doing ltsp work
<alkisg> seb128: I was directed to do it this way by the indicator-applet maintainer
<alkisg> And chrisccoulson has said "yeah, no problem" - so I thought everything was ok
<seb128> ok, so good
<alkisg> I don't know why setting an xprop to be picked up by the ltsp display manager is considered such a bad practice...
<seb128> why do you ask on IRC if everything is ok?
<alkisg> Because it isn't
<alkisg> He probably changed his mind or something...
<alkisg> But I don't know what is wrong, or how would I correct it
<alkisg> Setting xprops is the standard way we use in LTSP to communicate something to the client. Leaving broken menus sound much worse to me.
<seb128> alkisg, reality is that the team is busy with other things right now so review will take a while
<chrisccoulson> hi
<seb128> hey chrisccoulson
<alkisg> Hi chrisccoulson
<alkisg> Sorry if I'm insisting on this too much, but it is a big problem in classrooms
<alkisg> And that xprop will only be set for LTSP clients, so I can't imaging how would that affect normal installations...
<alkisg> *imagine
<seb128> it's not a matter of affecting normal installation
<seb128> but to have new codepath
<seb128> new potential bugs
<seb128> divergence with upstream and debian
<seb128> etc
<seb128> + it requires somebody to review the change and test those
<alkisg> That path was suggested by the indicator-applet maintainer exactly because it's a modification to an *existing* ubuntu patch
<seb128> and I'm not sure anybody in the desktop team has access to ltsp setups for testing
<alkisg> seb128: many people have tested it and reported that it's OK in the bug report
<seb128> ok, good
<seb128> so wait to see if somebody review it now
<alkisg> (I had uploaded a patched gnome-session in my ppa for some months)
<seb128> I'm not really interested by arguing there, I was just giving reason on why it might take a while
<seb128> anyway
<seb128> back to work
<alkisg> I'm pretty sure that if I just wait, nothing will happen, so LTSP will just have broken menus
<chrisccoulson> the patch is incorrect anyway, if it's the same one as posted in the description of the bug report (i don't know if you already discussed that)
<alkisg> seb128: ok, thank you for your time
<chrisccoulson> (i commented on the bug explaining why)
<alkisg> chrisccoulson: how is it incorrect?
<alkisg> I answered to your comments in the bug report
<chrisccoulson> i explained already on the bug report. the additional hook is in the wrong place
<alkisg> You're saying that it won't work from the session dialog, but it does
<alkisg> That place was suggested by tedg
<alkisg> I just did the ltsp part...
<alkisg> It even works if an app directly calls dbus
<alkisg> (e.g. italc)
<chrisccoulson> alkisg, i don't see how it works from the session dialog if you added the extra code to gsm_manager_request_{shutdown,reboot}
<chrisccoulson> those are only callable from the dbus interface
<alkisg> chrisccoulson: 5-6 persons in the bug report are verifying that it does, though
<seb128> you don't use the same session dialogs
<seb128> chrisccoulson means the one you get without the indicator
<alkisg> I'm pressing the shutdown button of my dialog
<chrisccoulson> the patch in your ppa must be different to the one in the bug then if that works
<alkisg> The session dialog comes up, I select power off, and it does
<chrisccoulson> because the one in the bug definately doesn't work
<alkisg> In previous Ubuntu versions, a patch was accepted in fusa that it was working only in fusa
<alkisg> Even if that patch works from the applet + the dbus calls, why would the previous one be accepted, and this one not?
<alkisg> Is leaving non-working menus better?
<alkisg> Because in my classroom I'm ashamed to have to explain to my students why the menus are not working...
<seb128> nobody denies there is an issue
<seb128> but the fact that it was fixed in a broken way before doesn't mean we should keep carrying broken changes
<alkisg> OK, so I'm asking: what would be a better way?
<seb128> not sure, I don't know about ltsp and how it's working
<seb128> and why such hacks are required
<dnivra> Hello. Can someone tell me which package does "network proxy" belong to?
<cjwatson> dnivra: run "network proxy", then in a terminal run 'xprop | grep WM_CLASS', click on "network proxy" window, and you get:
<cjwatson> WM_CLASS(STRING) = "gnome-network-properties", "Gnome-network-properties"
<alkisg> I'm upstream for LTSP, and I'm not aware of any other better way.
<alkisg> It's even better than the one used in previous ubuntu versions
<alkisg> So I'm not sure what more can be done from the LTSP side...
<cjwatson> dnivra: then 'dpkg -S bin/gnome-network-properties' and you get gnome-control-center
<cjwatson> dnivra: so the package name is gnome-control-center
<seb128> alkisg, k, still arguing there is of no real use
<seb128> alkisg, what is needed is somebody having free slot to review your change and work on the issue
<seb128> alkisg, you will not get that by arguing on IRC
<dnivra> cjwatson, that was quick even before I could understand what you were saying. let me try to do it. thanks a lot!
<alkisg> OK, thank you seb128 for your time. I just had to do a last try, as I think the issue is too important to go unnoticed
 * alkisg resigns from this issue, I'll just keep a patched gnome-session in my ppa for greek schools.
<seb128> alkisg, did you try to understand chrisccoulson's comments on the bug?
<alkisg> seb128: to the best of my ability...
<seb128> and to address those rather than reply that it works as it is now
<cjwatson> dnivra: I just wanted to explain the general method because that way you can find out the answer to future questions of the same form
<alkisg> seb128: that code path was suggested by tedg, which works on that stuff. I don't - I'm working on LTSP. I don't think I can find a better codepath myself.
<dnivra> cjwatson, thank you. it was real new info. off to the man page to make more sense of the commands used.
<seb128> alkisg, ted works on the indicators not on gnome-session
<alkisg> chrisccoulson: if you think there's a better codepath somewhere, could you please give me some hint?
<cjwatson> (I'm assuming that the first field in WM_CLASS is always the command name; it generally seems to be but I haven't actually gone and checked the specification for this)
<alkisg> (and, is that actually the problem? Or is it the xprop?)
<seb128> alkisg, we will try to review the bug before lucid but schedule is tight and that's low priority on the tasklists
<alkisg> seb128: I know - I filed it there months ago, though... :-/
<seb128> well as said before nobody in our team uses ltsp or has configuration to work on those changes
<seb128> we just agreed that we don't like the current way the change are done on the bug
<alkisg> Anyway, that's about as much as I can do about it, I don't think I'm able to do anything more. Thank you all very much for your time.
<seb128> alkisg, sorry to be really helpful there, as said it's on our list it's just not high ranked for now
<seb128> we might look at it before lucid still though
<alkisg> chrisccoulson: if you find time to come up with something that needs testing, there are many teachers here available for testing ltsp.
<alkisg> OK. Thanks again.
<chrisccoulson> alkisg, i don't really have any time to spare atm
<alkisg> chrisccoulson: I understand - but if you could only clarify this: if a better code path is found so that it also works from the session dialog, would that be enough to get it accepted?
<alkisg> (because if it's the xprop usage, I don't think we can find any other way unless we patch dbus itself...)
<marjo> cjwatson: http://people.canonical.com/~marjomercado/isotestingbugs.html updated per your request
<cjwatson> thanks!
<happyaron> cjwatson: hi, could you have a look at bug 476269 ?
<ubottu> Launchpad bug 476269 in ubiquity "Chinese, Brazilian Portuguese, and English variant translations aren't shown during Karmic and Lucid installation" [Undecided,Confirmed] https://launchpad.net/bugs/476269
<free> pitti: bug filed, https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/551672, and thanks for your hints!
<ubottu> Ubuntu bug 551672 in dbus "Can't connect to d-bus after upgrading from Hardy to Lucid" [Undecided,New]
<cjwatson> happyaron: not right now, but I've put it on my list to do in time for beta-2
<pitti> free: thanks!
<happyaron> cjwatson: good to hear that, many thanks!
<mdz> mvo: on a related note, do you have a guess about bug 545790? (seen in the same upgrade)
<ubottu> Launchpad bug 545790 in dpkg "package PACKAGE failed to install/upgrade: error writing to '<standard output>': Success" [High,Confirmed] https://launchpad.net/bugs/545790
<mvo> mdz: it may well be a dupe, I have not checked carefully yet. but it does make sense that the frontend goes away and dpkg gets unhappy afterwards
<mdz> mvo: I think it's a dpkg bug that it doesn't show the error code (probably EPIPE or so)
<mdz> it's doing printf (without checking the error code), followed by fflush and ferror
<mdz> then assuming errno is something useful
<mdz> ferror explicitly doesn't set errno, though
<mpt> davmor2, hi
<davmor2> mpt: hello
<mpt> davmor2, <https://wiki.ubuntu.com/SoftwareCenter> has lots of test cases embedded in it. (I keep them there so that I can keep them in sync with the rest of the spec). Is it ok if I replace the contents of <http://testcases.qa.ubuntu.com/System/SoftwareCenter> with instructions on finding them?
<davmor2> mpt: 2 ticks I'll have a quick look
<mpt> davmor2, I could add "sc-nnn"-type numbers to each of them if that would help
<davmor2> mpt: okay so your page the cases don't really leap out.  So the obvious way would be as you say to tie it in with sc-nnn.  I'm not sure how that would tie in then with qa.testcases.  ara ^ any idea
<mpt> davmor2, search for "Test case:" - there's 17 of them
<mpt> I'll number them
<ara> mpt, the problem is that those test cases make no sense without the spec
<mpt> ara, hm, that's probably true for the first couple. I can reword them.
<mathiaz> Riddell: hi! Does kubuntu use autofs to mount usb drives? bug 545384
<ubottu> Launchpad bug 545384 in autofs "automatic mounting of removable devices doesn't work in KDE" [Undecided,New] https://launchpad.net/bugs/545384
<davmor2> mpt: as a side note it may be easier from a testers view point if all the test were together in one section too,  or maybe at the bottom of each section rather than just randomly in the general text, I hope that makes sense
<ara> mpt, nevertheless, I like having all the testcases in the same place. do you know if moinmoin <<include>> statements work across different instances?
<davmor2> ara: schwuk might know
<mpt> davmor2, ara: The accuracy of a test case is inversely proportional to the square of the distance between that testcase and the specification for the feature.
<mpt> As we get more specification coverage, I expect we'll have more test cases in specifications
<mpt> especially for specifications that are in use-case format
<mpt> So, I guess we should figure out a way to extract and syndicate them on qa.ubuntu.com
<ara> mpt, agree
<ara> mpt, right now we include pieces of other testcases into a new one, but always within testcases.qa, I don't know if it would work from content outside
<Riddell> mathiaz: it uses hal I think
<Riddell> not sure what hal uses
<davmor2> ara, mpt: why not name one case sc-010 and see if you can pull it in
<mpt> davmor2, ara: https://wiki.ubuntu.com/SoftwareCenter?action=diff&rev2=360&rev1=359
<ara> mpt, davmor2: right now I cannot try. I will try asap
<mpt> ok, for now I've just added a link and string to search for
<Keybuk> http://reprog.wordpress.com/2010/03/30/a-brief-yet-helpful-lesson-on-elementary-resource-locking-strategy/
<Keybuk> ^ Hilarious, yet insightful
<pitti> *chuckle*
<mdz> ara: I see a lot of bug reports where people copy and paste the output of "lsb_release" and "apt-cache policy <package>", even though they are using apport which includes this information for them. are there instructions somewhere which tell them to do this?
<mdz> ara: (random example: bug 548428)
<ubottu> Launchpad bug 548428 in chromium-browser "Error 107 (net::ERR_SSL_PROTOCOL_ERROR): Unknown error" [High,Triaged] https://launchpad.net/bugs/548428
<ara> mdz, yes, launchpad tell them to add that information
<mdz> ara: maybe it shouldn't say that if there is already apport info attached (I find it makes the report harder to read)
<mathiaz> james_w: hi! Could you import the latest version of the openldap package in the packaging branch?
<james_w> mathiaz: it's working on it now
<mathiaz> james_w: thanks
<mdz> Keybuk: wow, the more links you click, the deeper the sexism goes
<mdz> reddit is pretty low
<jdong> mdz: I hope I'm reading it correctly (with my sarcasm detector going off...)
<Keybuk> mdz: I don't see any evidence of sexism in the author's post
<mdz> Keybuk: the original article is some mild condescension and implied feminine irrationality
<mdz> then the comments kick it up a notch... then the reddit comments go even further
<mdz> s/is/has/
<mdz> there's a theorem in here somewhere
<Keybuk> mdz: you are a very strange person.  The original article that I read has a lot of implied geek irrationality in the face of the poor guy's suffering wife trying to get him to not apply computer science problems to making dinner
<james_w> mathiaz: done
<jdong> I thought it came across witty like the last xkcd
<mdz> Keybuk: yes, I am, but I don't think this is an example of it. :-)
<mdz> I'll save the deconstruction for some other time or channel
<jcastro> mvo: squid guy mail reminder!
<mvo> jcastro: *cough* right
<mvo> sorrrrry
<jcastro> mvo: it's ok I'll just bug you until you do it, heh. Also, I submitted a branch to add more mirrors.
<mvo> jcastro: cool
<Riddell> ArneGoetje: ping
<Riddell> ArneGoetje: you said ubuntu desktop is changing to liberation and I said I'd enquire if that's something we want in Kubuntu.  turns out we do want it.  what needs doing?
<cody-somerville> Aren't you suppose to be able to click through notify-osd notifications? I just tried to and it wasn't letting me. :/
<mrand> pitti: Mythtv packages are still struggling to get good backtraces.  It looks like compile-type=debug doesn't help.  We recently had the opportunity to have two bugs filed on the exact same problem on same machine with same version.  One with debug packages, one without: Bug 549593 and https://bugs.launchpad.net/ubuntu/+source/mythtv/+bug/549459  retracer didn't add any value on either bug, and non-dbg trace was useless.
<mrand> So still looks like we need our purpose built -dbg packages.  superm1 was wondering if you had any ideas?
<ubottu> Ubuntu bug 549459 in mythtv "mythfrontend.real crashed with SIGSEGV in QX11PixmapData::x11ConvertToDefaultDepth() (dup-of: 549593)" [Medium,Triaged]
<ubottu> Ubuntu bug 549593 in mythtv "mythfrontend.real crashed with SIGSEGV in QX11PixmapData::x11ConvertToDefaultDepth()" [Medium,Triaged]
<ubottu> Launchpad bug 549593 in mythtv "mythfrontend.real crashed with SIGSEGV in QX11PixmapData::x11ConvertToDefaultDepth()" [Medium,Triaged] https://launchpad.net/bugs/549593
<LaserJock> any java folks about?
<highvoltage> as if they'll admit it :)
<geser> LaserJock: nobody is in #ubuntu-java?
<cjwatson> Keybuk: how does http://paste.ubuntu.com/406585/ look to you?
<Keybuk> cjwatson: bug# ?
<LaserJock> geser: ah, good point
<cjwatson> Keybuk: don't have one, I encountered it locally and started fixing it first
<Keybuk> what was the bug?
<cjwatson> server install, removed 'splash' from command line, stuck on tty7 after boot; strace revealed that plymouth was segfaulting, further investigation revealed it was segfaulting on trying to access VGA registers
<cjwatson> sorry, plymouthd segfaulting not plymouth
<Keybuk> if you removed splash, why would plymouth be trying to use the vga16fb renderer?
<cjwatson> that I don't knoww
<cjwatson> *know
<Keybuk> moving all that code into activate() breaks a lot of the design separation of the plugin
<Keybuk> I wouldn't want to do that
<Keybuk> VT activation is supposed to be trivial, not complex
<cjwatson> ok, so I should be investigating why the vga16fb renderer is being used instead?
<jumper_> hi
<Keybuk> cjwatson: right, it might be a simple bug that on_vt_active_changed is being called in the first place
<cjwatson> right, I can look into that then.  thanks!
<Keybuk> that being said
<Keybuk> the vga calls should probably be guarded by the map_address != MAP_FAILED check anyway
<cjwatson> (or 0; or else initialise map_address to MAP_FAILED when creating the backend)
<Keybuk> right that too
<Keybuk> though also arguably all that vga stuff should move to the top of flush_head()
<Keybuk> after the set_mode :p
<Keybuk> that's actually probably the right thing
<Keybuk> (as well as finding out why vga16fb was used in the first place)
<Damascene> https://bugs.launchpad.net/ubuntu/+source/vte/+bug/263822
<ubottu> Ubuntu bug 263822 in vte "RTL (right to left) support in terminal (BiDi)" [Low,Triaged]
<cjwatson> Keybuk: AFAICS, it isn't really being used, it's just that open_device sets up the on_active_vt_changed callback, and that's called unconditionally at startup
<Damascene> please help with work around
<Keybuk> cjwatson: the callback shouldn't be called unless a VT change happens?
<Keybuk> james_w: why didn't evan's upload end up in lp:ubuntu/plymouth ?
<james_w> good question, let me look
<james_w> it's currently not touching plymouth as you pushed over the top of it apparently
<Keybuk> yes, you said to
<james_w> right
<james_w> I'm just double checking everything then I'll tell it that that is ok and it should carry on
<james_w> Keybuk: should be there now
<james_w> and it didn't even overwrite your branch!!!!!!
<zul> does anyone have a suggestion for a way for not removing  a user's user database when going from one version to the next (for reference: https://bugs.edge.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/506985)
<ubottu> Ubuntu bug 506985 in rabbitmq-server "Upgrade from rabbitmq-server 1.54 -> 1.7.0 wiped users and vhosts" [High,Confirmed]
<ArneGoetje> Riddell: just seed ttf-liberation in Kubuntu
<Riddell> ArneGoetje: and fontconfig will magically use that as the default?
<ArneGoetje> Riddell: default for what?
<Riddell> for "Sans" and "Serif" fonts
<ArneGoetje> Riddell: no, it won't. Since DejaVu has a better coverage, they will still be the default
<Riddell> ArneGoetje: so ubuntu's gnome has a settings override somewhere to make liberation the default?
<ArneGoetje> Riddell: if you want the Liberation fonts to be the desktop defaults, you'll need to add a fontconfig snippet.
<ArneGoetje> Riddell: no, we don't use it as default in Ubuntu. It's just installed by default, so that users can use it on the LiveCD and in their installation, e.g. in openoffice.org
<cjwatson> Keybuk: according to strace, the VT switch in question is simply due to plymouthd itself calling VT_ACTIVATE 7
<Riddell> ArneGoetje: ah ok
<barry> pitti: ping
<pitti> barry: pong
<barry> pitti: hi!  what i can i do to convince you to approve bug 541990? :)
<ubottu> Launchpad bug 541990 in computer-janitor "[FFe] Upgrade Computer Janitor to 2.0 (dbus edition)" [Undecided,Incomplete] https://launchpad.net/bugs/541990
<Keybuk> cjwatson: which should be in map_to_device, which is after the ioperms call
<pitti> barry: ah, I'll respond to that soon, just didn't get to it yet today
<pitti> barry: (like review the branch, etc.)
<Keybuk> james_w: yays, etc.
<ev> james_w: thanks!
<cjwatson> Keybuk: the only match for VT_ACTIVATE is in src/libply-splash-core/ply-terminal.c:set_active_vt
<pitti> barry: for now, maybe you can make the backend crash and check whether the frontend does something sensible, like shutdown cleanly or respawn it, etc.?
<cjwatson> oh, the call to ply_terminal_activate_vt
<Keybuk> james_w: why did the importer add a .pc directory?
<barry> pitti: cool, thanks. :)  it's a bit of a short day for me today, but i will be around all day tomorrow to answer any questions
<cjwatson> ply_terminal_activate_vt is also called from ./src/plugins/splash/{text,ubuntu-text,details}/plugin.c
<pitti> barry: oh, and can you please expand on the string changes? they seem unrelated to the architecture change, etc.
<Keybuk> cjwatson: which, if used, should mean that vga16fb has been unloaded
<pitti> barry: can these perhaps be reverted? string changes are expensive and detrimental at this point
<cjwatson> ah, that's a piece of information I didn't know
<Keybuk> cjwatson: if we have a bug where falling back to, or even forcing the use of, a text plugin still means the graphical renderer is loaded/active - then we have a bug ;)
<barry> pitti: sure.  i'll do so in the bug task
<cjwatson> Keybuk: right.  perfect.
<Keybuk> cjwatson: so the vga bits are definitely in the wrong place, I'll move those into flush_head as soon as james_w can clean up the mess the importer just made of the branch <g>
<Keybuk> cjwatson: but I think there's still this other bug where vga16fb is being loaded when it shouldn't be
<Keybuk> (or not unloaded)
<Keybuk> james_w: *prod*
<cjwatson> Keybuk: should pressing Ctrl-t (which toggles between PLY_TERMINAL_MODE_{TEXT,GRAPHICS}) also toggle whether the renderer plugin is unloaded/loaded?
<Keybuk> cjwatson: no
<Keybuk> Ctrl-T is one of those curious debugging key presses nobody's supposed to know about ;)
<cjwatson> the reason I ask is that ply_terminal_set_mode (PLY_TERMINAL_MODE_TEXT) would be an awfully convenient place to hook the unload in, since it's already called by all the text plugins
<Keybuk> err
<Keybuk> I suspect you're going too far here
<cjwatson> I don't see how to avoid problems when the splash is selected explicitly, without involving something that the splash plugin calls
<Keybuk> I don't think you're following me
<Keybuk> or maybe I'm not understanding you
<cjwatson> well, we need to either load the renderer plugin only once we're definitely running a splash that requires graphics, or unload the renderer plugin once we're definitely running a splash that requires text?
<Keybuk> no, not necessarily
<nixternal> Keybuk: your post on kms couldn't come at a better time :)  what is your view on the themes for plymouth? I created the Kubuntu theme, and people with nvidia are crying foul with their wonderful $500 video cards displaying the most expensive set of 16 colors ever...should the theme be fairly lame to suit everyone, or should we keep a rockin' theme and tell the nvidia users with the issues to change to nouveau (as I am assuming nouveau do
<Keybuk> cjwatson: it may be simply true that the renderer is always loaded
<Keybuk> and thus the code in vga16fb is a mistake
<nixternal> ooh, I walked in at the perfect time here
<Keybuk> on looking closely, none of the other renderers assume the renderer is actually doing anything at vt activate time
<cjwatson> Keybuk: oh, well that was the assumption I started with, but you said that was wrong :-)
<Keybuk> cjwatson: ah, never assume that I'm always right :p
<cjwatson> so in that case, testing whether the vga registers are already mapped in activate() would be sufficient
<Keybuk> nixternal: in theory, you should be able to have a 16-color alternative to your theme by checking the color depth and stuff - but since we don't have one for ubuntu, I've never tested that - and the renderer might not work right
<Keybuk> cjwatson: yeah
<cjwatson> I don't think there's any need to map them right there, it'll presumably be done later if necessary
<Keybuk> cjwatson: or, as I said earlier, comparing to the other renderers - that kind of thing is probably better off done in flush_head()
<Keybuk> right, indeed, if you're right and the renderer is always loaded - then it'd be dangerous to map them there
<cjwatson> flush_head> mm, right, I see
<cjwatson> especially seeing as that would put it right before setting KD_GRAPHICS
<Keybuk> cjwatson: which is where all the mode set stuff is actually done
<Keybuk> yes
<Keybuk> and we probably really want to set the vga regs after setting KD_GRAPHICS
<Keybuk> in case the switch to that corrupts them again
<cjwatson> point
<cjwatson> well, it's only the ioperm and mmap that were missing really
<cjwatson> that could be done before KD_GRAPHICS
<Keybuk> I think the ioperm and mmap are done in the right place
<Keybuk> they're done on map_to_device
<Keybuk> I think it's the vga regs fiddling that's in the wrong place
<Keybuk> instead of on vt activation, they should be done on flush head
<Keybuk> which would put them in the right place
<Keybuk> (and would still mean they're called on vt activate, since activate calls the flush head function if the device was mapped)
<cjwatson> oh!  right, I see what you mean now
<cjwatson> the last piece then would be http://paste.ubuntu.com/406626/ to ensure that the existing guard in activate behaves correctly
<Keybuk> yes
<Keybuk> agree
<Keybuk> the same change will need to be made to drm and frame-buffer probably :p
<cjwatson> frame-buffer looks OK
<cjwatson> I'm going to freely admit to not understanding drm
<cody-somerville> pitti, I just got from Apport: "The problem report is damaged and got not be processed. IOError(13, 'Permission Denied')."
<cody-somerville> pitti, I wonder if its because the application crashed again after that report was generated.
<cody-somerville> pitti, Eww... the dialogue telling me some packages are out of date doesn't show up in my taskbar or task switcher.
 * cody-somerville goes and files a bug about that one.
<Keybuk> cjwatson: are you sure?  frame-buffer looks to have the exact same bug to me
<cjwatson> oh, the map_address bit, duh
<Keybuk> activate() will call flush_head() if it hasn't been mapped to the device yet
<Keybuk> (cause I stole most of the code out of frame-buffer to write vga16fb obv.)
<Keybuk> drm looks ok though
<Keybuk> since it just iterates the list of heads
<cjwatson> yes, you're right of course
<Keybuk> which is empty
<cnd> pitti: I'm trying to propose new changes for linux-firmware-nonfree using bzr+lp. I branched lp:ubuntu/linux-firmware-nonfree, made commits, pushed to ~chasedouglas/lucid/linux-firmware-nonfree, but now when I go to propose a merge back into lp:ubuntu/linux-firmware-nonfree it says "This branch is not mergeable into lp:ubuntu/linux-firmware-nonfree"
<cjwatson> shall I commit this and send upstream, or would you rather wait for VCS fiddling first?
<cnd> pitti: any ideas?
<Keybuk> cjwatson: commit and send upstream ;-)
<Keybuk> I'm not sure whether the .pc issue is deliberate or not - seems to do no harm
<cjwatson> .pc is a difficult issue with 3.0 (quilt) packages; I commented on it in my blog recently
<cjwatson> if you don't include it (which is my practice), then you have to run a rune after VCS checkout in order to be able to work on the quilt patches, although everything else works OK
<cjwatson> if you include it, then you end up with weird extra junk in commits
<cjwatson> (that touch the quilt patches)
<Keybuk> do you have to bzr add the stuff inside it?
<Keybuk> it's confusing me because I don't have quilt patches
<cjwatson> mm, the difficult thing here is that you have format 3.0 (quilt) and you have a delta against upstream, so dpkg-source thinks it needs to generate an automatic quilt patch expressing the upstream diff
<cjwatson> unless you're actually going to maintain those patches as quilt patches, then TBH I think you would be better off declaring format 1.0 right now
<cjwatson> you're in a sort of halfway house
<Keybuk> I can't declare format 1.0 though
<Keybuk> because some of the added files are .pngs
<cjwatson> oh.  joy
<geser> pitti: if you have some time: could you check if lp-shell from lp:ubuntu-dev-tools still works for you as expected? I've pimped it a little bit: it now supports all known LP instances, all known API versions, anonymous login and tab-completion for objects :)
<Riddell> pitti: seems lex79 found the cause of bug 528907
<ubottu> Launchpad bug 528907 in hal "unable to mount disks in dolphin / hal permission denied" [High,In progress] https://launchpad.net/bugs/528907
<cjwatson> Keybuk: it would help to put 'single-debian-patch' in debian/source/options, so that the patch name doesn't change with every upload
<Keybuk> cjwatson: can you do that ;-)
<cjwatson> sure
<cjwatson> I'm not really sure what will happen with the .pc file - I suspect you may find it's better off removed, but I guess there's no harm experimenting
<Keybuk> if I remove it, the importer will just keep putting it back, no?
<cjwatson> only for uploads not tagged in bzr
<Keybuk> exactly
<Keybuk> so better to just leave it and ignore it, surely?
<cjwatson> maybe, I'm concerned that it will get stale in some odd ways
<cjwatson> like I say though, it would probably be interesting to try it out and see what the failure modes are anyway
<Keybuk> if there's an issue with this being there, then the importer shouldn't add it ;-)
<cjwatson> 10% of Debian is using 3.0 (quilt) now, a bunch of them probably non-trivially, and we need to gain experience of various ways of handling this in bzr
<Keybuk> I do find it sad/amusing/depressing/typical that Debian standardised on the most painful patch management system they could find (quilt)
<Keybuk> surprised Format 3.0 didn't mandate YADA as well
<cjwatson> hm, I actually find quilt works pretty well for this myself, YMevidentlyV :-)
<cjwatson> the only thing I ever found painful about it totally went away when I discovered 'quilt shell'
<Keybuk> it probably depends whether you separate changes out into little discreet boxes
<Keybuk> or just commit as you go
<cjwatson> I think dropping .pc is probably the right answer, but if we do that then we need to solve http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204 somehow, either in dpkg-dev or somewhere else
<ubottu> Debian bug 572204 in dpkg-dev "dpkg-dev: maintainer workflow problems with 3.0 (quilt) and VCS" [Wishlist,Open]
<maco> Keybuk: i found a website thats like a cheat sheet for how to survive adding a patch to a package using quilt. was VERY happy
<Keybuk> cjwatson: but as we just did; I can't drop it - any upload will mean the importer puts it back
<Keybuk> so the importer should not add it
<cjwatson> Keybuk: dropping .pc: I mean in the importer
<Keybuk> ah right
<cjwatson> but, right now, if the importer drops it, you can only work on an auto-imported 3.0 (quilt) package properly if you happen to have a copy of my dpkg-quilt-setup rune lying around
<cjwatson> or something equivalent
<Keybuk> that also seems pessimal
<cjwatson> (the importer would need to .bzrignore it as well)
<Keybuk> since the idea is that bzr co and dpkg-source -x give identical results
<Keybuk> (since one day we won't have sources to -x)
<cjwatson> somebody on debian-dpkg@ suggested that maybe there should be a quilt command to set up the .pc directory, in which case perhaps we could nobble bzr to call it on checkout
<Keybuk> I guess the other side
<Keybuk> does the importer import the result of unpacking the package
<Keybuk> or the result of dpkg-source -x?
<Keybuk> because if the latter, then the patches *are already applied*
<cjwatson> the patches really ought to be already applied.  this is good, it makes bzr blame useful
<Keybuk> which surely makes quilt annoyingly hard, since you have the "can't reverse the patch because it's changed since" problem
<cjwatson> no
<cjwatson> works fine
<Keybuk> how does it work fine?
<Keybuk> let's say I checkout a source
<Keybuk> and I edit it
<Keybuk> and I upload
<cjwatson> you refresh the patch after making your changes
<Keybuk> where does my diff go?
<Keybuk> no quilt commands involved in the above
<cjwatson> let me rephrase: if you're actually *using* quilt, rather than trying to ignore it, then it works fine
<Keybuk> I'm neither actually using quilt, or trying to ignore it
<cjwatson> in your case, dpkg-source would generate one of these automated patches
<cjwatson> so it would end up in debian/patches/debian-changes, as well as applied to the checkout
<Keybuk> should we not rename that to ubuntu-changes for our uploads OOI?
<Keybuk> a package could then conceivably have debian-changes & ubuntu-changes
<Keybuk> ok, that makes sense
<cjwatson> I don't have much of an opinion but my "gratuitous incompatibility" light is going off :-)
<Keybuk> but then don't you run into the issue where, in order to refresh a patch, you first have to pop all the others off
<pitti> geser: great work! looks fine here
<Keybuk> and you have to push them all back again
<cjwatson> if we did that, it should be done upstream and wired into dpkg's vendor mechanism
<lex79> pitti: should I disable also 01_at_console.patch ?
<Keybuk> otherwise you can end up committing some very very weird changes
<pitti> lex79: noo
<Keybuk> cjwatson: I don't think it's any different to our dch behaviour
<cjwatson> yes, but personally I'm fine with that
<pitti> lex79: this would break everything
<lex79> ok
<cjwatson> it means that I keep useful patch files that are forwardable upstream as coherent units
<pitti> cnd: hm, not really; james_w might?
<cjwatson> and can be described with DEP-3 headers
<pitti> cody-somerville: hm, mind filing a bug with the details, which app crashed, etc.?
<Keybuk> cjwatson: right, what I mean is you might accidentally commit an intermediate step?
<cjwatson> I've found this invaluable in getting a handle on openssh's upstream delta
 * pitti -> off for supermarket/dinner, bbl
<Keybuk> I could commit the result of popping patches
<Keybuk> rather then the result of refreshing a patch partway down the stack
<cjwatson> mm, perhaps there should be some kind of pre-commit hook to prevent that
<Keybuk> right, that's along the lines I was thinking
<Keybuk> have bzr check whether the package is sane
<cjwatson> different from dch> I think the difference is that dpkg already has a vendor mechanism, so it would be worth using it
<Keybuk> cjwatson: I don't disagree
<cjwatson> so that our derivatives automatically get debian-changes ubuntu-changes mint-changes or whatever
<Keybuk> I'm just thinking that in practice, where a package has debian-changes already
<Keybuk> we really don't want to modify that patch
<Keybuk> that's wrong
<Keybuk> we want to add ubuntu-changes on top
<Keybuk> and in very much practice, our packages should have ubuntu-changes where there were none before
<cjwatson> I don't really have practical experience of this, since everything I've touched using 3.0 (quilt) has been using specifically named patches instead
<Keybuk> because otherwise Debian will whinge about us claiming they changed things that we really changed :p
<Keybuk> I guess it varies with workflow
<Keybuk> all my packages are directly based off trunk/release branches
<Keybuk> so I can pull/merge directly from HEAD, etc.
<cjwatson> frex, ubuntu/openssh has 39 Debian patches, and then a "# Ubuntu additions" section at the end of debian/patches/series with two Ubuntu patches at the end
<Keybuk> so for me, I find that treating the ubuntu branch simply as a branch is the best way
<Keybuk> so the commits I commit to ubuntu are directly equivalent to the commits that I would commit to trunk anyway
<Keybuk> so are thus directly equivalent to the patches I'd send upstream
<Keybuk> in theory, I could run "git format-patch" over an ubuntu branch of a package I maintain, and mail the lot upstream
<cjwatson> I tend to 'quilt new foo.patch; quilt shell; bzr merge; exit; quilt refresh'
<Keybuk> except bzr doesn't have that command ;)
<cjwatson> bzr send --git
<Keybuk> cjwatson: nowhere near the same thing
<cjwatson> yeah, ok :)
<Keybuk> huh - you add a merge as a patch?! :p
<cjwatson> sorry, reflex response
<cjwatson> I do that because it means I can tell apart things that aren't backports from upstream from things that are
<Keybuk> funny isn't it
<Keybuk> we've invented a brand new system
<cjwatson> and I can put a DEP-3 header at the top of the patch saying it's a merge from upstream and where it comes from and why
<Keybuk> a single way of doing bzr based source packages
<Keybuk> and the two of us already do them in wildly different ways <g>
<cody-somerville> pitti, kk, will do
<Keybuk> dpkg-source: info: building plymouth using existing ./plymouth_0.8.1.orig.tar.gz
<Keybuk> dpkg-source: error: cannot read plymouth-0.8.1.orig.B9r5y0/debian/patches/debian-changes-0.8.1-1ubuntu3: No such file or directory
<Keybuk> cjwatson: ^
<cjwatson> oh, I forgot to change series, sorry
<Keybuk> another bzr wishlist, bzr commit --amend ;)
<cjwatson> fixed
<Keybuk> WFM now
<cjwatson> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/man-db/lucid/annotate/head%3A/debian/patches/man-l-assertion.patch - I find this more useful documentation than a simple merge, FWIW
<cjwatson> particularly given the lack of useful cherry-pick recording in zr
<cjwatson> bzr
<Keybuk> but surely that's the same text you'd put in the commit log?
<Keybuk> I guess again it depends on your POV :p
<cjwatson> Keybuk: it's more usefully exposed to people coming along and looking later - I had very clear feedback from a number of people about openssh that the commit log was too hard to wade through when they were trying to audit changes
<cjwatson> all the information was there, but it was hard to find
<james_w> sorry, was at lunch
<Keybuk> cjwatson: patches in ubuntu for me are either backports from trunk, or too scraggy to go upstream yet
<Keybuk> but I look at trunk first
<Keybuk> I 95% of the time work on trunk
<Keybuk> and get around to updating the packaging branch later
<Keybuk> even with Plymouth, I do all my testing on plymouth upstream GIT, not the ubuntu package branch :p
<james_w> the importer aims to import the same as dpkg-source -x, but I realise that format 3.0 makes this bad in some cases
<james_w> but not doing it is also bad
<james_w> cnd: so you apparently pushed in to the lucid project on LP
<james_w> cnd: you need to push to ~chasedouglas/ubuntu/lucid/linux-firmware-nonfree/<some descriptive branch name>
<cnd> james_w: ok, I'll give that a try
<cnd> james_w: looks like that fixed it, thanks :)
<james_w> np
<cjwatson> Keybuk: I expect that the convergence between our two ways of working will be via looms
<cjwatson> Keybuk: and some kind of per-thread rather than per-commit log, to generate the DEP-3 header
<cjwatson> but I'm not up for using those in production yet
<Keybuk> heh
<Keybuk> I still think that "bzr loomify" should output something
<Keybuk> e.g.
<Keybuk> $ bzr loomify
<Keybuk> Welcome to the age of the Great Guilds!
<Keybuk> --
<Keybuk> ^ lifeless: you should make it so ;-)
<cjwatson> Keybuk: is there an upstream patch pending somewhere for the vga16fb renderer?
<Keybuk> cjwatson: no, not yet
<cjwatson> ok, I'll just send this for frame-buffer then
<Keybuk> yup :)
<zul> slangasek: can you have a look at #506985 and comment on it please? when you get a chance of course
<slangasek> Keybuk: bug #551062 = 530779 - where does that leave us for lucid?  Should the upstart task be targeted to lucid, or do we need to remove / suppress the nih_warn() from mountall?
<ubottu> Launchpad bug 551062 in plymouth "mountall: Could not connect to plymouth (dup-of: 530779)" [High,Triaged] https://launchpad.net/bugs/551062
<ubottu> Launchpad bug 530779 in upstart "init: does not wait for parent to exit when following forks" [Medium,Triaged] https://launchpad.net/bugs/530779
<slangasek> (there's also the infinitesimal risk that the race catches just not the initial plymouth connection attempt, but also a subsequent one when mountall has something important to say)
<slangasek> s/just not/not just/
<slangasek> zul: looking
<zul> slangasek: thanks
<slangasek> Keybuk: oh; reading more closely, I see you're taking out the initial connect, ok - when is that landing?
<cody-somerville> nixternal, You wrote '4' instead of 'for'. How ghetto! :P
<sladen> ha. "A spiffy aubergine paint job won't sell cars whose clutch, brake and accelerator pedals have been shuffled about and mounted in the passenger-side footwell."
<LaserJock> I don't know, maybe Toyota should try it
<LaserJock> "we know your brakes and accelerators don't work properly, but it's aubergine!!"
<Keybuk> slangasek: tomorrow I think
<slangasek> "clutch"?  how insulting, Ubuntu is clearly an automatic and *still* gets better gas mileage
<slangasek> Keybuk: ok
<Keybuk> I think it's pretty hard for the real mountall-has-something-important to miss the connection being opened
<slangasek> Keybuk: with the current architecture, I agree; when you've redone the main loop, I don't know :)
<slangasek> zul: sorry, I was assuming I'd find an FFe here, and it's not :) what part do you want comments on?
<Keybuk> slangasek: that bit shouldn't change ;)
<zul> slangasek: i was wondering how you handle it?
<slangasek> Keybuk: do you want me to undupe 551062 and assign it to mountall so you can get the credit in the QA team's kudos report? :)
<slangasek> zul: hm, at the moment I'm not sure how you're hitting this code path - karmic shipped with rabbitmq-server 1.6.0, which is supposed to be supported; hardy didn't ship it; 1.5.4 shipped with jaunty, but jaunty->lucid upgrades are never supported
<zul> slangasek: i think the LOSA are installing it manually on the servers
<Keybuk> slangasek: not really ;)
<Keybuk> it's only another bug number to waste half an hour trying to look up before inevitably mistyping it in the changelog anyway <g>
<slangasek> Keybuk: heh
<slangasek> Keybuk: would be real easy to look up, it'd be assigned to you and targeted to beta2 :-P
<Keybuk> slangasek: I have 2,400 unread mails in my LP folder
<Keybuk> I daren't go in there
<Keybuk> as far as I know, there are dozens of bugs assigned to me and targeted
<Keybuk> I treat such things like I treat bank statements
<Keybuk> if I don't open them and look, then I sleep better at night
<slangasek> zul: so in that case, I think a reasonable solution within the distro is to make sure the package complains loudly and the admin should fix it up by hand; I don't think the distro package should be trying to find a general solution for a very specific backport scenario
<zul> slangasek: great thats what we thought as well
<slangasek> Keybuk: surely it's more effective to open them and ask your teammates^W friends to take some bugs^W^W^W^W for a loan /before/ you're overdrawn :)
<Keybuk> yeah but then I have to pay them back later ;)
<slangasek> heh
<Keybuk> I really don't look at LP much
<Keybuk> I write down bugs in a notebook, and work off that day-to-day
<Keybuk> I find new bugs by going through the bug list of packages I care about
<Keybuk> so I really don't pay much attention to the whole assigned to thing
<Keybuk> I used to
<Keybuk> but then LP got a whole lot slower
<Keybuk> and mdz insisted we all be bug contacts for packages
<Keybuk> so now I just get too much e-mail to read
<Keybuk> I worked it out, if I actually read every mail from LP, I'd finish for the day without ever getting any work done
 * slangasek notes that https://bugs.launchpad.net/ubuntu/lucid/+bugs?field.assignee=scott is quite quick to load (and quite short) :)
<Keybuk> slangasek: also I find ignoring things has a useful side-effect
<Keybuk> people then *talk to me* about their bugs directly :p
<Keybuk> what's even funnier about that list is that the only bug on it has apparently been fixed by someone other than me <g>
<slangasek> Keybuk: yeah - can I upload that?  It's causing problems for kirkland in upgrade testing
<Keybuk> slangasek: you haven't even committed it yet fwict, despite what the bug status says
<slangasek> hmm
<Keybuk> oh, no, it is there
<slangasek> ok
<Keybuk> but yes, sure, upload away
<kirkland> slangasek: cheers, dude, thanks!
<slangasek> Keybuk: btw, at a glance it appears to me that plymouth now fails entirely on an initramfs-less system, due to relying on /dev/pts; any thoughts on resolving this?
<Keybuk> slangasek: it shouldn't fail - it should just not redirect console
<slangasek> Keybuk: oh, then I think the fallback is broken
<slangasek> before upgrading initramfs-tools, I saw plymouth fail in both the initramfs *and* the root
<Keybuk> please debug and fix ;)
<slangasek> yep, will look
<cjwatson> Keybuk: just to be clear, is the vga16fb flush_head fix on your plate, or on mine?
<Keybuk> cjwatson: oh, it can be on mine if you like
<cjwatson> I'm happy either way, just don't want it to get lost
<Keybuk> but if you have the patch just commit to our branch
<cjwatson> ok, I have the test case in front of me so I'll JFDI then
<cjwatson> (this is all in aid of making sure we have init.d output on server, if you hadn't guessed)
<Keybuk> except for the lack of init.d output ;)
<sebner> jdstrand: thanks for you work on twiki and moin :)
<cjwatson> yeah, but you explained the bit that was involved there on Friday
<cjwatson> so I can at least advance-test it
<Keybuk> yeah, either adding console output to the rc.conf or changing the default
<jdstrand> sebner: sure thing! :)
<jdstrand> sebner: thanks for your work on them :)
 * sebner hugs jdstrand :)
<jdstrand> :)
<cjwatson> Keybuk: BTW, moving all this into flush_head isn't going to make it ridiculously slow or anything is it?
<Keybuk> no
<Keybuk> it's just making sure that the VGA is in the right drawing mode
<cody-somerville> mvo, Is there any way to tell apt to forget about conflicts and what not and just download everything?
<mvo> cody-somerville: like every package in the repository?
<cody-somerville> mvo, No, just the packages requested and all the other packages it would normally download as dependencies or recommends.
<slangasek> cjwatson, Keybuk: that doesn't happen to fix any of our vga16fb segfaults, does it?
<Keybuk> slangasek: that might be the segfault yes
<mvo> cody-somerville: you could just do "apt-get install -d 4g8 -o Dir::state::status=/tmp/empty-file"
<cjwatson> slangasek: it fixes *a* vga16fb segfault
<slangasek> ok :)
<cjwatson> slangasek: I couldn't accurately tie it down to the ones I saw in LP
<mvo> cody-somerville: then it will act as if you had a empty system
<cjwatson> slangasek: if you can, feel free to annotate
<slangasek> cjwatson, Keybuk: also, is there an outcome to the 3.0 (quilt) workflow discussion that I should be aware of when working on this package in the future?
<cjwatson> it should be pretty clear, the segfault was in activate() when calling vga_*
<cody-somerville> mvo, but it'll still die if you try to specify packages that conflict each other.
<Keybuk> slangasek: no, I think we fixed it
<slangasek> "fixed it" - so I just do what I was doing before and everything is Happi?
<Keybuk> yes
<zyga> hello
<mvo> cody-somerville: well, you could dividie it into non-conflicting partitions? what is the use-case? a python-apt script can do with that as well
<slangasek> Keybuk: ok, cool
<Keybuk> well, cjwatson adding more quilt options
<Keybuk> so you should be safe to ignore the .pc thing
<Keybuk> though I expect it'll get wildly out of date repeatedly
<Keybuk> but that shouldn't matter too much, since the source uploads will be fine
<cjwatson> yeah, all I really did was keep importer-induced skew to a minimum
<cjwatson> cody-somerville: you could use 'aptitude download', if all you want is "give me the .debs damnit"
<cody-somerville> Interesting idea.
<mvo> oh yeah, aptitude download will work too, if you just need a single deb
<cody-somerville> Ah
<cody-somerville> I want dependencies and recommends to get downloaded automatically too.
<psusi> so... what is replacing hal?
<soren> psusi: Monkeys.
<psusi> lol... seriously... wasn't it responsible for say, auto mounting a usb stick and launching a nautilus window to browse it?
<psusi> what does that now?
<psusi> nevermind.... reading about it now on the wiki... devicekit eh?  hrm...
<cnd> slangasek: I'm looking into bug 551527, where nouveau through display port hangs plymouth
<ubottu> Launchpad bug 551527 in linux "Dualhead NVidia Mac Mini (3,1) does not boot on clean Lucid beta 1 install" [Undecided,Confirmed] https://launchpad.net/bugs/551527
<cnd> got any ideas what could be going wrong?
<cnd> it could also be nouveau + external monitor, I'm not real sure
<slangasek> cnd: is that bug #533135?
<ubottu> Launchpad bug 533135 in plymouth "System fails to boot with plymouth installed (nouveau driver with >1 display)" [Medium,Triaged] https://launchpad.net/bugs/533135
<cnd> slangasek: ahh, should have done a dupe search first...
<cnd> slangasek: anything I can do to help?
<slangasek> cnd: sure, you can dive into the DRM driver and figure out what's going wrong :)
<cnd> heh, I was afraid of that :)
<slangasek> the plymouth DRM backend is only used on nouveau with multiple display outputs
<cnd> slangasek: how can I debug plymouth to figure out what it's doing?
<slangasek> UTSL
<cnd> hmmm, ok
<slangasek> there are some debugging options you can set on the kernel commandline, but I don't know how useful any of them are going to be to you for this
<slangasek> plymouth:debug, e.g.
<slangasek> cnd: actually, assuming plymouth:debug tells you anything useful about DRM, adding plymouth:debug=file:/dev/plymouth-drm-debug.log to the kernel commandline is probably a good place to start
<cnd> slangasek: thanks, I'll look into that
<cnd> I'll also try the latest upstream nouveau, which will be a challenge in and of itself due to kernel->userspace abi changes :(
<gtlz> alright, who broke gnome in lucid
<medex> How come something like this "sudo bash -s "echo bird | passwd root; su""  drops one to a root prompt?
<meanburrito920> Does anyone here know how many slots Ubuntu has for GSoC students?
<tjaalton> seems like armel buildd's fail to generate -dbg packages
<jpds> meanburrito920: Best person to talk to is dholbach.
<lifeless> persia: pnig
<Gaming4JC> Hey all, I want to know why wvdial was dropped from LiveCD and if we can get it back before Lucid launch.
<Gaming4JC> https://bugs.launchpad.net/ubuntu/+source/wvdial/+bug/400573
<ubottu> Ubuntu bug 400573 in wvdial "[include in live-cd] wvdial (1.60.1+nmu2)" [Wishlist,New]
<Gaming4JC> 93 million Americans still use dial-up (recent survey at a webmaster site) and no one can connect on ubuntu without going on a package hunt in the repos from a windows box.
<Gaming4JC> such a pity.
<beuno> Gaming4JC, I'm pretty sure finding a package is going to be the least of their problems if they have dial up
<beuno> oooops, sorry, thought this was on a different channel
<beuno> ignore me, please
<Gaming4JC> I use dial-up and let me tell you, once you've removed those packages it's a complete pain. lol. :P
<Gaming4JC> kk
<beuno> I thought this was in #ubuntuone
<beuno> I'm tired   :)
<Gaming4JC> ah :)
<slangasek> Gaming4JC: it was dropped because there's no UI for it, so it's not useful to have it installed by default.  It might make sense to put it back in the package repo that ships on the CD so that users who need it (and can make heads or tails of it) can install it from there
<Gaming4JC> that would be the least you could do. :)
<Gaming4JC> Also, gnome-ppp is a great gui - I've no idea why it's not on the repo either
<slangasek> that's for the desktop team to say; though it's a little late in the cycle to be evaluating new UI components for release-worthiness
<LaserJock> I'm guessing the least they could do is remove wvdial from the archives altogether, hello tarball :-)
<slangasek> actually, the *least* I could do would be to ignore this discussion entirely, but that wouldn't be very helpful :)
<beuno> slangasek, that ship has sailed
<slangasek> beuno: not necessarily, I could ignore the discussion going forward :-)
 * beuno senses an infinite loop approaching
<Gaming4JC> Laserjock: I presume they have plans on that. :P
<Gaming4JC> lol
<snow_> hi
<slangasek> cjwatson: ^^ do you see any reason not to put wvdial in the ship-live seed?  (Unfortunately, there doesn't seem to be an analogous component in platform to add this to)
<cjwatson> it sounds exactly the sort of thing that's meant to live in that category
<Caesar> There's something all shagged with the GNOME packages right now, right?
<cjwatson> "stuff you need to get online"
<Caesar> I'm seeing gnome-panel being uninstallable, but I'm failing to see the good reason yet
<slangasek> cjwatson: yah.  Only concern is that wvdial + deps is ~920k
 * slangasek scopes out where we are wrt langpack seeding
<Gaming4JC> only 920 oh so precious kb. :)
<slangasek> Gaming4JC: it's a CD, after all; space is not an infinite resource
<slangasek> Gaming4JC: we *do* include wvdial on the DVD
<Caesar> slangasek: are CDs (not DVDs) still the primary unit of concern?
<Caesar> This whole offline sneakernet thing seems so last decade anyway
<slangasek> Caesar: it appears to be so for Gaming4JC, else I don't think he would be inquiring :)
<Gaming4JC> :)
<slangasek> Caesar: anyway, if you're on dial-up, I'm doubly-sure you don't want to download a DVD ISO
<Caesar> slangasek: yeah. I guess there's still people without infrastructure to net boot
<Gaming4JC> totally agree. :D
<Gaming4JC> lol
<Caesar> There needs to be some sort of WAN PXE boot
<slangasek> (the size difference between CD and DVD does have a non-negligible impact on our milestone validation)
<DktrKranz> slangasek: hi! if you plan to do some archive-admin work, mind adding python-multiprocessing to sync-blacklist, so we know for sure we won't get it in Lucid + 1? TIA
<slangasek> Gaming4JC: ultimately, it would be far better if we could replace wvdial, with its entire set of NIH library dependencies, with a network-manager component that does the job; we don't seem to have such a thing in the archive today
<slangasek> DktrKranz: noted
<DktrKranz> thanks
 * Caesar glances over at libnih
<slangasek> Caesar: it's so ironic it's hip
<Caesar> :-)
<Gaming4JC> slangasek: Yes, that would be more logical. However, gnome-network-manger has several bug reports filed against it for not supporting dial-up anymore either as you probably know.
<slangasek> Caesar: anyway, the whole upstart package is smaller than libwvstreams4.6-extras :)
 * Gaming4JC considers this unbelievable... 
<Gaming4JC> :P
<Caesar> slangasek: fair enough
<slangasek> Gaming4JC: to be honest, my solution to the last problem I had with dial-up was to talk my dad into getting DSL
<slangasek> Gaming4JC: and that was with gutsy - so no, I'm not current wrt bug reports on gnome-network-manager
<Gaming4JC> slangasek: I'd love to. Sadly, where I live we have no mobile, broadband, or dsl access.
<Gaming4JC> I gave up after asking my local government who also said "we can't do anything".
<Gaming4JC> :P
<slangasek> ah, clearly you need to put in a bid for Google Fiber
<Gaming4JC> oh and just ask my neighbors about Huesnet, it's pretty epic when I'm still online and they aren't.  ^^
<Gaming4JC> Google Fiber? :D
 * Gaming4JC googles
<Gaming4JC> off-topic: THAT LOOKS SWEEEETTTT
<Gaming4JC> lol
 * Gaming4JC signs up :D
 * Gaming4JC is sad to find... the deadline is up
<Gaming4JC> :'(
<slangasek> that, and I hear the application process involves either a) debasing yourself on Youtube, or b) getting your mayor to shamelessly rename your community after Google for a day... :)
<Gaming4JC> "We'll collect responses until March 26, and will announce our target communities later this year. Stay tuned."
<Gaming4JC> Is that typical or what <_<
<Gaming4JC> *sigh*
<Gaming4JC> lol
<Gaming4JC> Hmm another question, any chance of getting "dexux" package into the online repo? :)
<Gaming4JC> http://ubuntuforums.org/showthread.php?t=369504
<slangasek> Gaming4JC: the numbers seem to work out; doing a test build now, if it fits as expected then wvdial will be on the CD for beta2
<Gaming4JC> slangasek: Thanks, if it does you're a life saver. :D
<slangasek> Gaming4JC: dexux> you should file a bug against ubuntu in Launchpad and tag it 'needs-packaging'
<Gaming4JC> slangasek: Okie dokie. :)
<slangasek> Riddell, nixternal: does Kubuntu have any replacement for wvdial's functionality on the desktop, or would we ideally seed it in ship-live over there as well?
<slangasek> ah, liveCD build snagged on the gnome installability issue, which I shall now investigate
<nixternal> cody-somerville: yeah, I saw that earlier after I sent out the email....Hey, I am from Chicago, we are a bit ghetto here :)
<cody-somerville> :)
<nixternal> slangasek: i don't know if kde still has a wvdial frontend/functionality...haven't used wvdial since...ummm...the 90s maybe :)
 * nixternal looks
<slangasek> nixternal: well, it's not currently using wvdial /on/ the CD, but there might be a replacement I'm unfamiliar with
<Gaming4JC> KDE use k-ppp, I think that's the a frontend for wvdial but I haven't used it much to know. Also, k-ppp was removed recently as well...
<nixternal> yeah, that was it...ok, so it is still around then
<slangasek> Caesar: so I assume your gnome installability problem is on amd64?
<cjwatson> kppp is still in the archive for lucid
<slangasek> cjwatson: can you bump the build score for gnome-panel/amd64?
<nixternal> yeah, kppp is installed out of the box with kubuntu
<cjwatson> it does not appear to depend on wvdial
<cjwatson> slangasek: done
<slangasek> ta
 * Gaming4JC might switch to Kubuntu... if it comes with working kppp
<Gaming4JC> lol
<Gaming4JC> Ubuntu is so much nicer though ^_^
<slangasek> DktrKranz: blah, so why does python-multiprocessing keep getting reuploaded to Debian and when is it going away?
<slangasek> DktrKranz: blacklisted
<Caesar> slangasek: yes, amd64
<Caesar> (we only tend to care about amd64 these days)
<Caesar> Aha, I see
<Caesar> So I need to wait for the next archive run?
<Caesar> Is there somewhere I can get visibility into the autobuilder-equivalents, for future enlightenment?
<cjwatson> it should all be visible - which bit?
<cjwatson> https://launchpad.net/ubuntu/+source/gnome-panel had links to build records, in this case
 * Caesar looks
<cjwatson> or  rmadison -u ubuntu  is useful
<Caesar> Yeah, I used rmadison after slangasek mentioned amd64
<cjwatson> and https://launchpad.net/builders/ has a buildd activity overview
<Caesar> I mean I'd naively assume from what I saw with rmadison that the next archive run would solve my problem, but I wanted to know how to be sure
<cjwatson> anything uploaded (unless it needs to go through NEW) before the top of the hour will be in ACCEPTED for the publisher run at :03
<cjwatson> and should generally be world-visible by :45 or so
<Caesar> Very cool
<Caesar> So the archive changes hourly?
<jpds> It gets published hourly.
<cjwatson> this applies except in the hour of 0400 (and possibly 0500) UTC, when it tends to be busy generating Contents files instead
<Caesar> We really need to do something about our internal mirroring :-(
<jpds> [Mirrors are generally asked to sync every 6 hours].
<Caesar> jpds: right
<Caesar> But if our last 6 hourly sync was bogus, we have a long time until it gets de-bogusified
<jpds> Caesar: How are you mirroring? rsync?
<Caesar> jpds: currently HTTP, but I want to get it swapped over to rsync in the next couple of days
<lifeless> oh oh oh I smell beta tester
<Caesar> FYI it looks like lithium.canonical.com doesn't have its rsync configured the same way as drescher, prat and jackass. #ubuntu-mirrors for that?
<elmo> the configs are identical AFAICT
<elmo> what are you seeing?
<Caesar> elmo: no banner from lithium
<elmo> lala
<elmo> fixed
<Caesar> :-)
#ubuntu-devel 2010-03-31
<slangasek> cjwatson: hmm, could also use build score bumps for language-pack{-gnome,}-de{,-base}
<Caesar> slangasek: the gssd upstart job, did it ever respect RPCSECGSSOPTS from /etc/default/nfs-common?
<Caesar> Sorry, RPCGSSDOPTS
<slangasek> Caesar: it did, but I noticed that /etc/default/nfs-common didn't set this as a template, and I ran into bug #545673 that can be worked around by making sure to use exec directly instead of 'script [...] exec'
<ubottu> Launchpad bug 545673 in upstart "'expect fork'+'respawn'+script+ENOENT => start/running w/o PID" [Undecided,New] https://launchpad.net/bugs/545673
<slangasek> Caesar: since the recommendation from upstart upstream is to not source files in /etc/default anyway, I would recommend you apply your tunings directly to the upstart job
<Caesar> slangasek: argh
<Caesar> That seems so gross
<Caesar> Okay, so today in Hardy, we tweak RPCGSSDOPTS in /etc/default/nfs-common
<Caesar> Nice, easy to parse and manage file
<Caesar> You/Scott are saying the new "right" way is to munge the upstart job instead?
<slangasek> Scott says that
<slangasek> I remain mute on the subject of whether it's right :-)
<Caesar> I think a little bit of pushback is warranted
<lifeless> are upstart jobs 'config files'
<slangasek> well, quite aside from whether it's right, I can't see another way to not hit that bug with /usr-as-separate-partition + NFS-mounted-at-boot
<slangasek> lifeless: so are init scripts, but nobody wants to have to edit them
<lifeless> slangasek: yeah
<Caesar> slangasek: I'm still trying to get my head around this bug you're talking about
<slangasek> Caesar: so what happens is that when you use 'script', upstart launches a shell to execute the specified script; which means when rpc.gssd fails to start because /usr isn't mounted yet, the exact nature of the failure is masked from upstart
<slangasek> if upstart knew it was execve()->ENOENT, it would handle it gracefully
<Caesar> Can it not handle a non-zero return code from a script fragment?
<slangasek> in general, yes
<slangasek> in this case, something goes Screwy
<slangasek> I haven't looked to see /why/ it goes screwy, though
<Caesar> Oh Upstart, please don't snatch defeat from the jaws of victory
<Caesar> slangasek: I'm sorry, I have conscientious objections to modifying init scripts and upstart jobs fall into the same category
<Caesar> Isn't this why $DEITY invented /etc/default in the first place?
 * Caesar goes and reads the FHS and Debian Policy
<slangasek> FWIW, I think that /etc/default is an annoying indirection; I don't know if I'd go so far as Keybuk has and conclude that upstart's declarative syntax is sufficiently friendly to remove the need for them
<slangasek> but there are certainly many other /etc/default/ files that I expect to become obsolete besides this one
<slangasek> (including, thankfully, all of the START=no ones)
<Caesar> slangasek: what is wrong with Debian Policy 9.3.2 though?
<Caesar> The issue that this tries to address is still there
<Caesar> (third-last paragraph specifically)
<slangasek> "Often there are some variables in the `init.d' scripts whose values control the behavior of the scripts" - sure; except that in this case, the only reason to *have* it as a variable, instead of in-line in the upstart job, is *because* of that file
<Caesar> " As the scripts themselves are frequently conffiles, modifying them requires that the administrator merge in their changes each time the package is upgraded and the conffile changes"
<Caesar> Upstart jobs are conffiles, right?
<slangasek> yes
<Caesar> I think the point is that SUSv3 sh format files are more manageable than upstart job files
<slangasek> given that the next bit says "files in /etc/default may be conffiles", the only justification for having it as a separate file is that it's easier to hand-merge a default file than an upstart job
<slangasek> ... than an initscript, I mean
<Caesar> So out of curiosity, if this was managed by debconf, how would that be managed?
<slangasek> it's also easier to hand-merge an upstart job than to hand-merge an initscript; the question is whether it's easy enough
<slangasek> if it were managed by debconf, wherever you store it can't be a conffile
<Caesar> Right, so that might be /etc/default/foo
<Caesar> So we're right back where we started again
<slangasek> so you get to pick between sourcing /etc/default and managing that, or having an upstart job that's not a conffile and managing that
<Caesar> Okay
<Caesar> Meanwhile, we have an unmanageable rpc.gssd
<satwell> The advantage of /etc/default is that in most cases changes do not need to be merged.
<satwell> Whereas changes to an upstart job do need to be merged.
<cjwatson> the reason /etc/default was introduced (I was there, I remember) was that merging init script changes was often really scary and difficult
<slangasek> is it not sufficient to do 's/^\(exec rpc.gssd\).*/\1 myopts/' ?
<satwell> Upstart jobs need some way to be configured, and directly editing the upstart jobs sounds pretty burdensome.
<Caesar> slangasek: no, that would work
<slangasek> if we have the upstart job *right*, merges will be very infrequent
<cjwatson> slangasek: German language packs rescored
<slangasek> cjwatson: ta
<Caesar> slangasek: so far it's changed a bit during Lucid's development
<Caesar> I think we're going to just have to hold our noses and ship our own Upstart job with Puppet
<Caesar> It makes me sad, because we're going to have notice when the upstart job changes upstream
<slangasek> I'm sorry for that, but if I change it back then the upstart bug makes it impossible for me to dogfood it because the rpc.gssd upstart job will zombify on my system
<satwell> It seems like the ideal solution would be for upstart to be able to read env variables out of /etc/default and pass them on exec lines.
<Caesar> slangasek: isn't the right solution to fix the Upstart bug?
<Caesar> You're kind of papering over it
<cjwatson> papering over bugs is often what happens shortly before release!
<slangasek> upstart should be fixed; I don't think that's going to happen in time for lucid
<cjwatson> anyone here who's never papered over a bug to get a release out, raise your hand
<slangasek> I expect upstart's ptrace handling is implicated here, which Keybuk has just today made warding signs against changing for lcid
<slangasek> lucid
<Caesar> cjwatson: heh
<Caesar> What's better ettiquette for a sync request? A new bug number or tack it onto the bug that's intended to be fixed by the sync request?
<slangasek> the latter, IMHO
<Caesar> goodo
<Caesar> But requestsync isn't geared towards doing that is it?
<slangasek> nope
<Caesar> I'll try to figure out what bits I need to twiddle from a previous sync request
<slangasek> doing whatever you find easier is fine :)  but it should only require subscribing ubuntu-sponsors
<Caesar> ok
<Caesar> I really need to pull my finger out and go for Ubuntu Membership again
<Caesar> slangasek: so I guess retitle the bug report as part of doing the latter?
<slangasek> Caesar: I would do so, yes
<slangasek> (and add the usual information about why to overwrite any Ubuntu delta, etc)
<Caesar> Yep
<Caesar> Fortunately there is no delta
<Caesar> Man, Launchpad is cool
<LaserJock> sweet, 10GB on dropbox for free
<nixternal> how?
<nixternal> tell me now!
<LaserJock> they bumped up the max referrel reward to 10gb
<LaserJock> apparently I already had enough, so I just looked and I had 10GB
<LaserJock> so for a 2GB plan that's pretty kickin'
<nixternal> dang
<nixternal> I had 2.5 from referrals, but it went back to 2
<nixternal> now it says 2.25GB
<LaserJock> nixternal: did you put it on twitter/identi.ca?
<nixternal> no
<LaserJock> that's what really shot mine up
<nixternal> should I?
<nixternal> here we go!!!
<happyaron> jcastro: ping
<cody-somerville> It seems Whenever apparmour gets updated, my computer stats crawling to a stop.
<lifeless> there was some discussion of kernel memory pressure from apparmour
<jdong> cody-somerville: there's a bug on that
<jdong> bug 458299
<ubottu> Launchpad bug 458299 in linux "apparmor_parser: page allocation failure. order:5" [High,Fix committed] https://launchpad.net/bugs/458299
<psusi> am I crazy for thinking that the kernel should... you know... actually HIDE partitions with the hidden flag?
<lifeless> yes
<ion> yes
<jdong> psusi: PSHHHHHHH next you'll say that movie rentals should be non-DRM'ed and based on the O_IPINKYSWEAR bit in the metadata...
<jdong> *ducks*
<psusi> I'm crazy for thinking that the hidden flag should actually do something?
<ajmitch> like PDFs?
<psusi> or that in general, the kernel should pay attention to any of the fields in the partition table besides start and length?
<jdong> ajmitch: haha pretty much. Aren't there actually "cryptographically" enforced ones though?
<jdong> or is that a even more proprietary format?
<ajmitch> no idea :)
 * psusi throws jdong a copy of the e2defrag package to play with
<jdong> hahahaha *takes snapshot*
<jdong> is it ureadahead-aware yet?
<psusi> jdong, I fed it a list transformed from ureadahead's list to prioritize the defragging and it did help, but only so much... it still does not want to move the blocks out of the block group the inode is in, and it doesn't do inode relocation
<jdong> psusi: oh :(
<jdong> psusi: I think one of the most useful optimizations is going to be the ability to say "move this list of files such that they're close to each other"
<psusi> jdong, it also still does not do extents and uninit_bg
<psusi> aye
<jdong> lol isn't that the default creation mode for ext4 in Ubuntu since Karmic?
<ion> It seems the lucid kernel lacks the configuration to load DSDT from initramfs.
<stgraber> ion: that's since karmic ... had to boot a jaunty system to test a DSDT fix :(
<psusi> jdong, yes... and extents also seem to REALLY minimize fragmentation anyhow
<psusi> though I did find that the man page states that lazy_bg_init defaults to on, but it does not... when you specify it the mkfs really goes much faster ;)
<jdong> psusi: it's not file level fgramentation that worries me these days. it's more "logical" fragmentation between groups of related files for tasks.
<jdong> psusi: which is one reason I find Windows (XP, Vista, 7)'s idea of "prefetch packs" to be pretty brilliant
<joshuah> hello everyone, I'm trying to use groundcontrol to check out a project and I get "please enter account details". even if I enter them, I still get that. does anyone know what I might be doing wrong?
<psusi> jdong, right
<jdong> psusi: where they attach a machine learning self-training algorithm to the launch of each executable
<psusi> yea... would be nice if ureadahead could do that.... pack it into one file then tell the kernel to stuff that into the cache for the files it came from
<jdong> of course right now they seem to be hitting the not-enough-cache-to-be-awesome barrier
<jdong> yeah, indeed
<jdong> if there's a way to have ureadahead generate separate packs for bootup, login, starting openoffice, etc
<psusi> don't they also have something where they can put the pack files on a usb memory stick for fast reading during boot?
<jdong> yup
<jdong> ReadyBoost
<jdong> and not just during boot
<jdong> launching programs in general
<psusi> I've been wondering that myself lately... would be nice to at least have a different pack for boot and one for login
<jdong> the Prefetch folder in C:\Windows is full of ureadahead-style strategy files for what blocks are used in what order to start various .EXEs
<jdong> and then, their idle defragger "merges" these packs together and picks the most optimal way to reorder things on disk
<psusi> really?
<jdong> so not only is there ureadhead-style smart reading order per app launch, but ProcessIdleTasks()'s defragger actually repositions stuff on disk
<jdong> and 3rd party defraggers like PerfectDisk read the same Prefetch files and applies a "smarter" layout algorithm for even better (claimed) performance
<jdong> it's such an impressively designed system on paper, I'm slightly surprised it isn't the case that we praise Windows for their IO performance...
<jdong> when reading and talking about this, it kinda does sound like doubleplusuber-readahead :)
<psusi> reminds me of when NT had zero copy async io and TransmitFile and Linus poo-pooed the idea of adding sendfile() to the kernel
<Aquina> must be a long time ago
<psusi> I found an old copy of dd I modified years ago to use O_DIRECT aio with 16 simultanious requests... tried it on my new ssd and actually exceeded the mfr throughput specs ;)
<psusi> I've been playing around with gpt partitions lately and it's upsetting me that it goes to all the trouble of designating really unique type codes for partitions, and explicitly defines a hidden flag, and the kernel pays attention to none of it
<Aquina> You like that hidden flag-thing, huh?
<psusi> well, if they bothered designing the fields in there, they ought to be used
<psusi> I mean if an OEM puts a hidden rescue partition on the disk, it shouldn't show up on the user's desktop for them to go gee, what are all these files?
<Aquina> Well... I dislike that hidden rescue stuff. Reminds me about computers from the supermarket with included M$ OEM CS and a super-duper hidden volume with lot of crap on it (drivers, recovery stuff, etc.).
<lifeless> psusi: the hidden field was important in DOS
<lifeless> psusi: its not anymore
<joshuah> has anyone here used ground control? I can't seem to get it to log in for me
<Aquina> no, sry
<lifeless> psusi: in DOS it was critical to be able to boot parallel installs, because of the brain dead lack of abstraction layers DOS used (C: rather than mount points)
<psusi> lifeless, yea... because nobody respects it... so why did they bother putting it in GPT?  where it is explicitly defined as such, rather than just the high bit of the type that one os decided would be used to hide partitions?
<psusi> for that matter, why use big GUIDs to type the partitions if that information is also totally ignored?
<lifeless> microsoft have a hammer in their APIs
<lifeless> and to them, everything looks like a nail.
<psusi> gpt doesn't have anythign to do with microsoft
<lifeless> orly?
<psusi> yea.. Intel and Apple seem to be the main ones behind it
<psusi> seems a case of "not invented here" to decide to ignore the fields just because someone else designed them
<lifeless> NIH would be doing our own disklabel
<psusi> with msdos partitions it was kind of understandable because there never was any real good design specified, it just kind of grew organically, but with gpt this is not the case
<psusi> for that matter, why the hell did the linux community bother defining msdos partition tags for raid and lvm when they aren't used?  same goes for swap
<lifeless> anyhow, it was intel + ms
<lifeless> uefi consortium
<lifeless> apple is a late comer to it, they just skipped DOS disklabel support entirely in their intel machines
<lifeless> psusi: swap label is used
<psusi> lifeless, by what?  swapon works just fine if the partition is not marked as swap
<lifeless> sure
<lifeless> depends how you define 'used' I guess
<lifeless> anyhow, lunch tmie
<cody-somerville> odd. my selected search engine keeps defaulting back to yahoo!.
<psusi> oh well, at least I managed to get parted fixed so it can manipulate other partitions on a disk that has one mounted again
<Aquina> What do you put under /usr/local/sbin (instead of /usr/local/bin)? I can't decide where to put some of my self-written applications.
<psusi> Aquina, sbin is for system management/maintainance apps
<psusi> i.e. things that the super user would want to run
<cody-somerville> On some setups, users don't even have sbin in their path.
<psusi> aye
<Aquina> man hier and no toher resource mentiones this explicitly though.
<Aquina> but maybe I just had better deduced it from the other /sbin dirs
<psusi> man hier seems to specify that sbin is for system administration
<cody-somerville> Aquina, Do your scripts require to be executed as root?
<psusi> although the entry for /usr/sbin seems wrong... looks like it was duplicated from /sbin since it says contains programs needed to mount /usr
<cody-somerville> lol
<Aquina> some, cody
<Aquina> I'm seperating the system related (which also require root previleges) to /usr/local/sbin
<Aquina> These are not only scripts however. :-)
<Aquina> Yes I also noticed that mistake. You can find it on everal websites. *rofl*
<kirkland> slangasek: around?  i have a few questions about /etc/init/mounted-varrun.conf
<kirkland> slangasek: i think this file is causing Bug #550561
<ubottu> Launchpad bug 550561 in base-files "/etc/motd contains duplicate welcome/documentation blurbs on lucid" [Low,Incomplete] https://launchpad.net/bugs/550561
<kirkland> slangasek: i think /var/run/motd should be cleanly generated by pam_motd now
<kirkland> slangasek: i don't think it needs to be seeded by this upstart script
<kirkland> slangasek: hmm, well, maybe not causing that bug upon closer inspection
<kirkland> slangasek: actually let me take a different approach ...
<kirkland> keybuk: wanna improve bootspeed ever so slightly?  :-)  you can gut the motd parts of /etc/init/mounted-varrun.conf
<tjaalton> can someone bump the build priority on xserver-xorg-input-evdev & -synaptics?
<slangasek> doko__: being able to cross-compile a package is a feature; please respect the feature freeze
<NCommander> Silly question, if I have a package in restricted (or multiverse) that makes free binaries and non-free binaries, can those binaries be placed in main/universe?
<pitti> Good morning
<StevenK> NCommander: No
<NCommander> StevenK: ugh, so I need to split this into multiple source packages :-/
<lifeless> NCommander: how would a single package make both free and nonfree binaries
<NCommander> lifeless: I have an Xorg driver for a vendor, it builds once with free source only (MIT), and again with free source+embedded binary blob for full functionality
<NCommander> lifeless: I was wondering if I need two source packages, or one.
<lifeless> ugh
<lifeless> what card?
<NCommander> lifeless: ARM SoC, not public yet
<lifeless> ah kk
<NCommander> lifeless: I'd just do the embedded binary blob, but I rather have the FOSS driver for the image, then the blob for full acceleration if the user is willing to taint there system
<pitti> tjaalton, bryceh: does either of you have time for bug 539473? (revert the introduction of libutempter); I can take it if you are too busy
<lifeless> yeah
<ubottu> Launchpad bug 539473 in libutempter "libutempter needed as xterm build-dependency" [High,Incomplete] https://launchpad.net/bugs/539473
<lifeless> two packages
<NCommander> lifeless: Its a unique situation, hence why I asked.
<NCommander> lifeless: *grumble*. I'm still talking with the vendor on how we can improve the design
<lifeless> step 1, don't do a binary blob:)
<RAOF> Step 1 is surprisingly hard, judging by the profusion of binary blobs.
<tjaalton> pitti: i can take it
<pitti> tjaalton: thanks
<lifeless> The following packages have unmet dependencies:
<lifeless>   bzr-builddeb: Depends: dpkg-dev but it is not going to be installed
<lifeless>                 Depends: devscripts but it is not going to be installed
<lifeless> thats apt-get install bzr-builddeb reading from the dc archive
<lifeless> any thoughts on why ?
<lifeless> james_w: ^
<tjaalton> pitti: would it be ok to merge xterm 256 as well? here's the upstream changelog http://invisible-island.net/xterm/xterm.log.html#xterm_256
<pitti> tjaalton: looks fine, yes
<tjaalton> pitti: ok, thanks
<dholbach> good morning
<nobuto> pitti: Could you take a look at this bug? it seems change you made cause regression.
<nobuto> https://bugs.launchpad.net/ubuntu/+source/gconf/+bug/531155
<ubottu> Ubuntu bug 531155 in gedit "gedit schemas is not registered during live session" [Low,Invalid]
<pitti> nobuto: it's on my list to look at
<nobuto> pitti: I  feel relieved. thank you.
<kenvandine> good morning pitti
<pitti> hey kenvandine; late for you..
<kenvandine> yup
<pitti> slangasek: what do you think about building openldap against db4.8? (it's one of the last two packages in main still using 4.7)
<\sh> hmm..empathy is gone after last update on lucid somehow
<fale> hello
<fale> I was looking into firefox package, and I haven't seen the point in which is setted the default homepage... Am I looking into the right package'
* mthaddon changed the topic of #ubuntu-devel to: Launchpad will be down/in read-only from 11:00 UTC until 13:00 UTC for a code update | Lucid Beta 1 released! | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://w
<mthaddon> Launchpad down/in read-only 11:00 UTC - 13:00 UTC for a code update | Lucid Beta 1 released! | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
* mthaddon changed the topic of #ubuntu-devel to: Launchpad down/in read-only 11:00 UTC - 13:00 UTC for a code update | Lucid Beta 1 released! | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/He
<mthaddon> let's try that again...
* mthaddon changed the topic of #ubuntu-devel to: Launchpad down/read-only 11:00 - 13:00 UTC for code update | Lucid Beta 1 released! | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWith
* mthaddon changed the topic of #ubuntu-devel to: Launchpad down/read-only 11:00-13:00UTC for code update | Lucid Beta 1 released! | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBug
<mthaddon> and final time...
* mthaddon changed the topic of #ubuntu-devel to: Launchpad down/readonly 11:00-13:00UTC for code update | Lucid Beta 1 released! | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<lifeless> persia: ping
<ScottK> pitti: Would you please rescore kdepimlibs on sparc (the only arch it's not built on)?  It would avoid some other build failures is a few hours if you would.
<pitti> ScottK: done
<ScottK> pitti: Thanks.
 * Keybuk has a sudden epiphany with the mountall prompt issue
<Keybuk> very much of the "the answer's not in the box, it's in the band" variety
<ion> Oh?
<Keybuk> had been trying to work out how to deal with more important prompts replacing less important ones
<Keybuk> how to make sure that if we were bored waiting for /porn, and bored waiting for /warez
<Keybuk> and /porn showed up, we'd replace the message with one about /warez
<Keybuk> but if an fsck failed in the meantime, etc.
<Keybuk> had thought of a complicated message list, which needed continuous grooming, etc.
<Keybuk> then realised much easier way
<Keybuk> just have, on each mount point, a state variable
<Keybuk> after changing that, call a function to "update plymouth"
<Keybuk> that picks the most important message from the list of mounts and shows that one (if not already the one showing)
<ion> I was thinking of dumping all prompts asynchronously to plymouth with priority as an integer and letting it handle them. :-P
<Keybuk> that'd require rather more logic at the other end
<ion> It already needs to handle multiple simultaneous prompts, doesnât it?
<Keybuk> it does, but by blocking them
<Keybuk> which is the exact behaviour we need to avoid in mountall
 * amitk wonders if Keybug is talking about bug 527666
<ubottu> Launchpad bug 527666 in mountall "multiple LVM volumes not mounted in Lucid" [High,Confirmed] https://launchpad.net/bugs/527666
<Keybuk> amitk: I'm talking about a known issue with mountall
<Keybuk> it may or may not be the cause of may of the apparent "bugs"
<sladen> Keybuk: fonts tend to be up your street;  any idea which package the new 'Ubuntu' (not Title) font is in
<Keybuk> sladen: is it packaged yet?
<sladen> Keybuk: this was I was wondering... if not, where do I file visual kerning issues?
<Keybuk> with dalton maag I guess ;)
<Keybuk> though how can you have kerning issues if you don't have the font? :p
<sladen> Keybuk: I have *eyes*.  The spacing between the 'u' and the 'b' is too wide in and the spacing between 'k' and 'u' too narrow
<sladen> Keybuk: it's the same as looking at a boot screen and going "that's slipping down"!
<Keybuk> in the logos?  they may be still using unfinished versions, etc.
<Keybuk> that's an artwork issue
<Keybuk> talk to the art team
<Keybuk> (the font is certainly going to be released aiui, it's just still not finished and such things are being tweaked every day)
<Keybuk> though, if you ask me, the logo is slipping to the right, not down :p
<Keybuk> I wish LP would invest the time into giving themselves the ability to do Live Rollouts
<cjwatson> bdmurray: could we have a page like http://qa.ubuntu.com/reports/team-assigned/canonical-foundations-assigned-bug-tasks.html, except for milestones?  In particular I'd like something like LP's milestone view but that shows assignees as well.  I started trying to produce this, but it looks like you might already have the infrastructure to do this nicely.
<pitti> Riddell, lex79: do you know why KDE dropped the kdesu wrapping for mounting internal drives in the first place? with the recent hal, the policy is very open, and every user/script (including non-admins) can now mess with internal disks
<Riddell> pitti: that was always a patch we added, and we still add it people.canonical.com/~jriddell/tmp/kubuntu_06_user_disk_mounting.diff
<pitti> Riddell: so that broke somehow?
<Riddell> that or hal broke, I've not looked into the issue
<pitti> hal didn't change since karmic
<Riddell> pitti: except that 10_nonpolkit-mount-policy.patch was added?
<pitti> Riddell: no, that's been there since jaunty or so
<pitti> hal has never allowed any user to mount internal disks, until yesterday
<Riddell> pitti: let's wait and see what lex says then
* deryck changed the topic of #ubuntu-devel to: Launchpad down/readonly 11:00-14:00UTC for code update | Lucid Beta 1 released! | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<deryck> having to add an hour to downtime for LP.  sorry.
<pitti> :(
<deryck> I know :(
<pitti> deryck: good luck!
<deryck> thanks!
<cjwatson> foundations team: is it worth holding our meeting today, given that we're all going to be "LP was down and I'm still catching up"?
<Keybuk> cjwatson: I'm happy to skip it
<seb128> deryck, I guess there is no way to bzr pull things during downtime?
<seb128> having launchpad down for 3 hours during work hours sucks
<ttx> seb128: especially on the last day before Freeze
<deryck> seb128, yes, it does suck.  and no, I saw reports this morning that bzr pull did not work, though I thought that was some of the point of read only mode for us.
<seb128> :-(
<lamont> mvo: how come is it that everytime update-manager gets upgraded, I get to re-remove a conffile? (update-motd.d/91-release-upgrade).  If I removed a conffile, it should remain removed.
<lamont> or is that by design?
 * cjwatson is keeping an informal upload queue log in a text file so that he can remember what to commit/upload when LP comes back
<pitti> lamont: hm, it's a symlink, not a real conffile; that might be it?
 * seb128 can't bzr pull so hard to know on what to work
<seb128> or rather annoying to apt-get source to then copy things over
 * pitti is catching up with email
<seb128> I should reply to bugs using the email interface ;-)
<pitti> seb128: that works fine indeed
<ttx> jdstrand, mdeslaur: about bug 537978, there is a regression in debian recent "feature" allowing DHCP to change any hostname in lease renewal. I was pondering if it should not just be reverted, I wonder about security implications... The previous design was limiting the hostname change-by-DHCP to only if it wasn't previously set, which is quite safer.
<ubottu> Launchpad bug 537978 in dhcp3 "Lucid dhclient can't set hostname" [Medium,Triaged] https://launchpad.net/bugs/537978
<ttx> "Feature" was introduced in debian bug 508804
<ubottu> Debian bug 508804 in dhcp3-client "dhclient-script does not set new hostname" [Normal,Fixed] http://bugs.debian.org/508804
<james_w> lifeless: usually not the package you are trying to install's fault. Try installing devscripts explicitly and repeat until you get a better reason than "not going to be installed".
<mdeslaur> ttx: let me take a look, hold on
<msetim> hello
<mdeslaur> ttx: agreed. Dhcp should not change hostname if it is set locally
<mdeslaur> ttx: please revert to non-broken pre-lucid behaviour
<ttx> mdeslaur: will do. I won't ask you to comment on that bug... :)
<mdeslaur> ttx: sure, hold on
<mdeslaur> ttx: let me just check the debian bug first
<ttx> mdeslaur: because you can't :)
<mdeslaur> ttx: I can't what?
<mdeslaur> ttx: hold on a sec, it seems the fix was actually for a bug
<msetim> I have installed ubuntu 10.04 64 bits. It was working fine when I closed my laptop entering in suspend mode and when I opened my laptop he show me the window to type my password, but after first updates it doesn't show window to type my user password and get me back to GDM to start a fresh gnome login =/
<mdeslaur> ttx: the current script doesn't write to /etc/hostname anywhere, right?
<ttx> mdeslaur: no it doesn't
<msetim> the suspend mode continues working, the issue is when ubuntu come back to work (opened laptop)
<mdeslaur> ttx: yeah, the fix is wrong, I would go back to pre-lucid
<ttx> mdeslaur: ack
<mdeslaur> ttx: actually...what's old_host_name?
<mdeslaur> ttx: is it the name the dhcp server _previously_ returned?
<ttx> mdeslaur: I'm not exactly sure. We could honor it for example is /etc/hostname is still empty/missing.
<mdeslaur> ttx: if old_host_name is the previous name returned by dhcp, I like your suggestion in comment #3
<primes2h> msetim: This is not the right channel. Would you like to join testing team and test your laptop. Have a look here. https://wiki.ubuntu.com/Testing/Laptop
<primes2h> s./?
<ttx> mdeslaur: I'd add a check on /etc/hostname to only switch if hostname is not set by config.
<ttx> because old_host_name is controlled by the DHCP server
<ttx> otherwise you're back to enabling the DHCP server to change your hostname if it knows it.
<mdeslaur> ttx: right
<msetim> primes2h, thanks ;)
<mdeslaur> ttx: ok, so if /etc/hostname is set, never change, or else honor dhcp hostname.
<mdeslaur> ttx: makes sense?
<primes2h> msetim: np. :-)
<ttx> mdeslaur: yes
<mdeslaur> ttx: cool
<FeasibilityStudy> I am trying to build a .deb, and I keep getting this error: http://pastebin.com/MbytmVSa
<FeasibilityStudy> can anyone help
<sebner> FeasibilityStudy: mind posting your rules file?
<FeasibilityStudy> OK
<FeasibilityStudy> one sec.
<FeasibilityStudy> http://pastebin.com/632TzTrA
<FeasibilityStudy> Now after messing around a bit with the spaces/tabs, I got it to go past that part.  Now it is stuck at build saying no rule to target
<sebner> FeasibilityStudy: I'd recomment using dh7 with overrides. Less to break imho, give me a sec
<cjwatson> you don't even need overrides for any of that
<cjwatson> rules.tiny and an install file should do fine
<sebner> cjwatson: FeasibilityStudy http://pastebin.com/VBcFELkW
<sebner> cjwatson: hehehehehee
<cjwatson> but if you do use an override target, fix the bizarre indentation.  a single tab is all you need
<sebner> cjwatson: I blame pastebin
<sebner> FeasibilityStudy: should do: http://pastebin.com/dsjNUyQQ
<FeasibilityStudy> getting an error about a file already existing
<sebner> FeasibilityStudy: so you do have a buildsystem?
<FeasibilityStudy> http://pastebin.com/q7bQNmW5
<FeasibilityStudy> I think so.  I believe I installed all of that.
<sebner> FeasibilityStudy: nah, just put the second mkdir under the first one. though it seems you could delete it as well
<FeasibilityStudy> hmm I still get the error
<sebner> FeasibilityStudy: then delete the second mkdir
* mthaddon changed the topic of #ubuntu-devel to: Lucid Beta 1 released! | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<FeasibilityStudy> still get error
<FeasibilityStudy> must be something wrong with the spaces/tabs somehow
<sebner> FeasibilityStudy: that would be another error, paste it again
<FeasibilityStudy> http://pastebin.com/HNKrdY0q
<cjwatson> 46. mkdir -Â­pÂ /home/chrono/Desktop/Development/PyPass/dist/sandbox/pypass-1.0/debian/pypass
<cjwatson> you have two different kinds of hyphens in there
<cjwatson> this is all more work than you need, anyway
<cjwatson> you could just put this in debian/install:
<cjwatson> pypass usr/local
<cjwatson> er, sorry
<cjwatson> pypass.py usr/local
<cjwatson> data usr/local/pypass
<cjwatson> (why are you installing files to /usr/local, anyway?  programs would go in /usr/local/bin)
 * sebner agrees with cjwatson 
<psusi> Keybuk: it looks like the sys5 compat scripts conflict with upstart in runlevel 1.. it's trying to killall, and upstart keeps restarting tasks that rc kills
<Keybuk> psusi: yes, long known bug
<Keybuk> really the bug is that the sysv scripts use killall there at all
<psusi> Keybuk: seems like upstart should handle the killall no?
<FeasibilityStudy> cjwatson: what do you mean I have two different kind of hyphens in there?
<Keybuk> psusi: there should be no "killall" when entering runlevel 1
<hggdh> ttx: I did not preview anything else from what is already there, did not have time
<psusi> Keybuk: why not?  we need to make sure that everything is shut down
<Keybuk> no you don't
<Keybuk> single user mode != no processes running
<psusi> that's kind of the point isn't it?  yea... not no processes, but no processes that aren't set to run in single user mode
<Keybuk> no
<Keybuk> it isn't the point
<Keybuk> the point is that only one user is logged in, and additional users cannot log in
<Keybuk> not that there is nothing running
<psusi> yea... and if other users left background jobs running, then should not be running once switched to single user mode
<Keybuk> why not?
<Keybuk> I don't see anything in the sysv spec about htat
<cjwatson> FeasibilityStudy: your paste shows "mkdir -Â­p"
<Keybuk> (and you could argue the same for any change of runlevel)
<Keybuk> according to sysv, if you runlevel 3 within X, your login session should be logged out, etc.
<psusi> the whole point of single user mode is to make sure that no normal user stuff is running so the admin can perform system maintainence... do things like remount the root ro....
<cjwatson> FeasibilityStudy: I don't know if it's visible in your font, but that's  hyphen soft-hyphen p
<cjwatson> you need to remove the soft-hyphen or it won't work
<FeasibilityStudy> cjwatson: must be the font I am using..
<cjwatson> the font would influence how it's displayed for you, but the stray character is certainly there
<psusi> of user background jobs are not killed, he can't do that
<psusi> s/of/if
<cjwatson> and that's the cause of the error you're seeing
<Keybuk> psusi: no it isn't ;) not according to the spec
<psusi> badly written spec the ;)
<Keybuk> I would agree
<FeasibilityStudy> cjwatson: probably because I copied a template from a .pdf file tutorial and it didnt translate
<Keybuk> this is why Upstart doesn't *do* SysV by itself
<FeasibilityStudy> but I am at a loss of what to do now..
<Keybuk> psusi: arguably the sysvinit script should omit pids managed by Upstart, like the shutdown ones
<cjwatson> FeasibilityStudy: remove the character immediately before "p" in that mkdir line.  It should read "mkdir -p".
<cjwatson> FeasibilityStudy: I don't know how to be any clearer than this - sorry
<psusi> Keybuk: the killall would not be needed if say, when the getty upstart job spawns a user shell, upstart keeps track of this and makes sure it's dead when the getty job is stopped
<psusi> imho that's really the right way to do it
<Keybuk> upstart does do that
<Keybuk> but it allows processes to escape
<psusi> what do you mean?
<FeasibilityStudy> but I am copying what sebner pasted verbatim
<FeasibilityStudy> what he suggested I put in rules..
<psusi> if a user logs into a gnome desktop and spawns a background job, then you stop gdm, does that background process get killed?
<Keybuk> no
<psusi> didn't think so... that's the problem that killall was put there to fix
<cnd> slangasek: I'm trying to figure out how plymouth logging works, shouldn't there be a /var/log/boot.log file?
<cjwatson> FeasibilityStudy: I'm afraid you aren't.  I just rechecked sebner's version and it does not match yours.
<cnd> by default
<FeasibilityStudy> this is odd..I am using nano and I can only see that -- if I move the cursor over it, then it appears
<lamont> pitti: what have you done to me?  http://paste.ubuntu.com/407086/
 * lamont remembers fondly when gnome would actually come up when he logged in.
<lamont> it seems like only yesterday
<cjwatson> FeasibilityStudy: wait, sebner's version is a bit broken, but in a different way
<pitti> lamont: the guest session isn't supposed to have access to other people's home directories; even less so if that person is as important as lamont!
<cjwatson> FeasibilityStudy: OK, look.  DELETE that override_dh_auto_install paragraph entirely.  ADD a debian/install file that contains two lines, as follows:
<cjwatson> pypass.py usr/local
<cjwatson> data usr/local/pypass
<lamont> pitti: I logged in as ME
<FeasibilityStudy> Ok I got the hyphen thing fixed..now the error is cp: cannot stat `data/': No such file or directory
<lamont> pitti: so WTF am I guest?
<pitti> lamont: hm, apparently with using /usr/share/xsessions/guest-restricted.desktop ?
<sebner> cjwatson: what was broken?
<cjwatson> well, that's a matter for you, if you don't have a data/ directory in your package then you shouldn't be trying to copy it :-)
<pitti> lamont: what does "Session" say in ~/.dmrc ?
<cjwatson> sebner: you had some stray soft hyphens
<lamont> pitti: interesting... I dist-upgraded, rebooted, and then logged in.
<FeasibilityStudy> cjwatson: what should my rules file contain?
<cjwatson> sebner: visible in w3m, not in firefox
<sebner> cjwatson: grml, I just copied from him in the first place
<cjwatson> FeasibilityStudy: it should be a copy of /usr/share/doc/debhelper/examples/rules.tiny
<lamont> [Desktop]
<lamont> Session=gnome
<lamont> Language=en_US.utf8
<lamont> Layout=us
<lamont> ^^piti
<lamont> with a leading blank line
<pitti> that looks fine
<pitti> lamont: $ echo $GDMSESSION
<pitti> ?
<lamont> +mix 303 : grep lamont /etc/passwd
<lamont> +mix 304 : id lamont
<lamont> uid=2501(lamont) gid=850(mmj) groups=850(mmj),2502(desktop)...
<lamont> pitti: totally not logged in
<lamont> login works just fine, and then blank screen, still with the gdm background
<FeasibilityStudy> cjwatson: do you recommend /usr/local/bin instead of /usr/local?
<lamont> logging in on a tty? no problem
<cjwatson> FeasibilityStudy: yes
<lamont> so I'm gonna bet that GDMSESSION=null
<pitti> lamont: you see the gdm screen?
<lamont> pitti: I wonder if it has anything to do with the login not being in /etc/passwd?
<pitti> lamont: what does it say when you select your user and look at the "session" picker at the bottom?
<pitti> lamont: perhaps
<lamont> gdm screen (with user pretty faces turned off), click on 'login' (or whatever), type in my name and password, just like all the times before
<pitti> but it should use pam
<lamont> pitti: adding to my fun was that I left my laptop in town last night, so I'm now about 30 minutes from my computer with the issue
<pitti> lamont: right, but if you type your name, you should see a keyboard, loclae, and session selector, while the password input line is shown
<pitti> "locale"
<lamont> LANG=en_US.UTF-8
<lamont>  and all that jazz.  (ssh'ed into the machine)
<cjwatson> mvo: so is dropping files in /var/lib/update-notifier/user.d/ still the way to make notifications appear?
<lamont> ah, buttons. yeah... I can't see 13 miles through walls, though
<pitti> lamont: that was just a typo correction from the previous sentence
<pitti> lamont: can you check /var/cache/gdm/martin/dmrc
<pitti> sorry, /var/cache/gdm/lamont/dmrc
<mvo> cjwatson: yes, but it will only show them after /var/lib/update-notifier/dpkg-was-run got touched (that happens when apt finishes)
<Keybuk> err, wtf
<lamont> pitti: identical to the above
<Keybuk> gcc just "optimised" my code to be in the wrong order
<mvo> cjwatson: or on the next reboot of course (if you do it from the installer)
<cjwatson> dpkg-run-stamp?  ok
<lamont> Keybuk: clearly you haven't informed gcc adequately
<cjwatson> mvo: didn't see it on the next reboot, which is why I asked :)
<Keybuk> lamont: err, wtf?
<lamont> heh
<pitti> lamont: hmm; when's the next time you can log into gdm on that thing?
<Keybuk> 	mnt->error = ERROR_NONE;
<Keybuk> 	plymouth_update (FALSE);
<Keybuk> according to gdb, it did those two statements in the *opposite* order
<pitti> gdb with -O2 screws up ordering all over, though
<lamont> pitti: now that I have my laptop, I suppose I could run back home, otherwise it'll be around 2400 UTC
<pitti> when stepping through, it appears to run almost all statements twice
<pitti> lamont: hm, tomorrow then?
<lamont> Keybuk: gcc vs gdb is always lost on optimized code - gotta look at the actual assembly to see wtf is up
<Keybuk> lamont: I did
<lamont> pitti: sure - I'll be back online about 1100 UTC
<lamont> Keybuk: ew
<pitti> lamont: sounds fine
<lamont> pitti: meanwhile, I miss my desktop. :-p
<pitti> lamont: I thought you aren't sitting on it anyway?
<lamont> yeah, but it still  eats at me
<psusi> Keybuk: wow... so you checked the asm and it actually made the call before the ld?  that's messed up
<psusi> that violates the sequence point rule
<Keybuk> precisely
<psusi> plymout_update is actually a function right?  not a macro?
<lamont> http://paste.ubuntu.com/407093/ <-- pitti the upgrade that killed it, and since
<pitti> lamont: erm, you removed gnome-session?
<mdeslaur> lamont: you removed a bunch of required packages!
<pitti> that's doomed to fail
<lamont> well, that'd do it
<lamont> I didn't remove them... ghome-update did
<pitti> lamont: yes, it'll totally not work without gnome-session
<lamont> er, dist-upgrade did
<pitti> DDTT ;) use upgrade and hold back, not remove
<cjwatson> mvo: definitely not showing it - how should I go about debugging it?  can I kill update-notifier and then run it under strace or something?
<lamont>   ubuntu-desktop: Depends: gnome-applets but it is not going to be installed
<lamont>                   Depends: gnome-control-center but it is not going to be installed
<lamont>                   Depends: gnome-panel but it is not going to be installed
<lamont>                   Depends: gnome-session but it is not going to be installed
<lamont>                   Depends: indicator-applet-session but it is not going to be installed
<lamont> sigh
<pitti> lamont: amd64?
<lamont> yep
<pitti> lamont: there was a soyuz bug which didn't publish gnome-panel and others for half a dsy
<pitti> day
<pitti> this caused a lot of FTBFS :(
<lamont> and nothing in /topic here to warn me that I'd be dead if I upgraded?
<lamont> sihg
<mdeslaur> lamont: you see, it's your own fault :)
<lamont> note to self.  do not sleep through the dist-upgrade
<Keybuk> lamont: the great big THE FOLLOWING PACKAGES WILL BE REMOVED is the warning ;-)
<mvo> cjwatson: it has a --debug-hooks switch  that will print out some output, if you could paste that
<lamont> Keybuk: at least it didn't give me the opportunity to type Yes, do as I say!
 * lamont goes to find a corner to sit in
<mdeslaur> lol
<kirkland> slangasek: could you have a look at (my fixes for) https://bugs.edge.launchpad.net/ubuntu/+source/base-files/+bug/550561
<ubottu> Ubuntu bug 550561 in base-files "FFe: /etc/motd contains duplicate welcome/documentation blurbs on lucid" [Low,In progress]
<cjwatson> mvo: I think it was user error, sorry
<mvo> cjwatson: no worries
<apw> i just did a clean install using 'todays' live-CD and it seemed to be using the network ... downloading several sets of files.  would i expect that, and does it work without the network present?
<cjwatson> apw: language support files; and it should do, modulo bugs
<apw> cjwatson, will try it without the network next time ... thanks
<apw> cjwatson, on a different note, its looking pretty professional
<cjwatson> lool,doko__,mvo,slangasek,james_w: I didn't have time to send out a mail, but I'm cancelling the foundations meeting this week - LP downtime put the Europeans out of kilter in their work days, and everyone should be working on beta-2 bugs
<cjwatson> apw: the new slideshow is very nice
<apw> shame the little minimise icon is a bit crap
<ttx> asac, ogra: about bug 532733, should one of you be assigned to it, or do you need qemu-kvm maintainer to help / be assigned to it ?
<ubottu> Launchpad bug 532733 in qemu-kvm "apt/dpkg in qemu-system-arm hangs if a big task is installed" [High,Confirmed] https://launchpad.net/bugs/532733
<asac> ttx: help much appreciated
<asac> ttx: we are kind of lost how to debug this. we suspect its either kernel or qemu enging having a thumb2 bug (though thats rather unlikely how late this happs imo)
<ttx> asac: you can ping kirkland if that can be of any help. I'm not sure I understand where the problem lies either
<ttx> but having a high/beta2-targeted bug without assignee sounds wrong :)
<asac> ttx: oh yeah. pleas assign to kirkland ;)
<ttx> asac: well, I don't think he can really fix it as it stands
<asac> ttx: but he can ask for more info etc.
<asac> or probably has upstream contacts that might be able to
<james_w> cjwatson: ACK
<FeasibilityStudy> Argh..this drives me crazy..http://pastebin.com/VpHYmvtG
<cjwatson> FeasibilityStudy: if you don't have a data directory, why were you trying to install it?
<cjwatson> FeasibilityStudy: where is the original source that you're trying to package?
<FeasibilityStudy> in the directory I am in
<cjwatson> not on the Internet anywhere so we can look?
<ttx> kirkland: ^ I'll let you comment on that, and assign yourself to it if you think it's the best way to fix this bug
<FeasibilityStudy> cjwatson: No I wrote it
<cjwatson> FeasibilityStudy: so, you were trying to install a 'data' directory.  Where is it?
<kirkland> ttx: i can forward the bug to upstream qemu, and ask if anyone has ideas
<FeasibilityStudy> cjwatson: you told me to add data to /debian/install
<ttx> kirkland: sounds good.
<kirkland> ttx: it would probably take me a lot of time to dig deep into the arm emulation code and actually develop a fix
<kirkland> ttx: which, at this point, it looks to me like some strange issue in the arm emulation code
<cjwatson> FeasibilityStudy: your original rules paste was http://pastebin.com/632TzTrA, and it contained 'cp -r data/ $(CURDIR)/debian/pypass/usr/local/pypass'
<kirkland> asac: is that what it looks like to you?
<FeasibilityStudy> data usr/local/bin
<FeasibilityStudy> is what you said to add to install
<cjwatson> FeasibilityStudy: all I did was copy that over; I'm not telepathic and can't tell what your package looks like
<cjwatson> *no I didn't* - I said 'data usr/local/pypass' which was a *direct translation* of what was in your original rules file
<cjwatson> if you don't have a data directory, just remove that line from debian/install - I don't know why you had that cp -r there to begin with, in that case?
<FeasibilityStudy> cjwatson: because some tutorial said to..
<rbellamy> I need some guidance on linking some c code to a "library support file"
<cjwatson> FeasibilityStudy: that tutorial was no doubt describing how things would work for the application it was dealing with.  You're supposed to adapt these things to meet your particular requirements
<cjwatson> FeasibilityStudy: in that case, just remove that line from debian/install
<rbellamy> the policy manual for library support files states that they should be placed in a subdirectory of the primary library (e.g. /usr/lib/somedir)
<FeasibilityStudy> cjwatson I did
<rbellamy> when I link to that file, and compile, everything works fine
<rbellamy> but then when I try to execute, I get a "cannot open shared object file", since ldconfig doesn't traverse the subdirectories
<rbellamy> so, now to my question:
<asac> kirkland: i would think it has to do with IO in the emulation code. yes
<asac> some deadlock
<asac> kirkland: please get it upstream ... thats the least we can do
<rbellamy> what is the accepted solution for linking only to a support file when then executing?
<kirkland> asac: i'll email upstream today
<asac> kirkland: thanks. please CC me and ogra
<asac> kirkland: and lool
<kirkland> asac: you bet, i'm drafting the email now
<asac> rock
<FeasibilityStudy> cjwatson: any idea why i get this: http://pastebin.com/Jp7irZeq
<kirkland> asac: oh, couple of questions for you ...
<FeasibilityStudy> I mean I know it is not a directory, but why is it wanting it to be a dir?
<kirkland> asac: so this is in a chroot?  or is there a backing disk?
<cjwatson> rbellamy: normally, you'd use -rpath
<kirkland> asac: ah, i see a backing disk, root or qcow2
<rbellamy> cjwatson: I thought I was.... I'll have to review the build settings. No wonder I was confused. :)
<kirkland> asac: okay, are the disks scsi emulated, or virtio?
<asac> kirkland: its a disk. raw
<asac> disc image raw i am told
<asac> makes sense?
<kirkland> asac: first thing upstream is going to ask is if you tried virtio, as that's what they recommend in almost all cases
<cjwatson> FeasibilityStudy: side-effect of how dh_usrlocal works - while I can recommend a fix, the more immediately urgent question, I think, is whether you have a good reason to install into /usr/local/ (or any of its subdirectories) at all?
<kirkland> asac: can you get me the *full* qemu-system-arm command line used (running in ps -ef) when this happens?
<asac> kirkland: ogra will put that command line in bug
<asac> kirkland: we dont know what virtio means ;)
<kirkland> asac: i see something at https://wiki.ubuntu.com/ARM/RootfsFromScratch
<asac> kirkland: yes. wait. we paste you the definitly command line in bug
<rbellamy> cjwatson: dude, that was exactly my problem. Thanks for the pointer.
<kirkland> asac: can you try this:
<FeasibilityStudy> cjwatson: probably not.  Where would you recommend I install?  The program does not need root..Keep in mind I am not installing this for ME..I am just wanting to package it, mainly to leanr how to.
<kirkland> asac: sorry, looks like this is what you're running:
<kirkland> qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel ./vmlinuz -hda arm-rootfs.img -m 256 -append "root=/dev/sda mem=256M devtmpfs.mount=0 rw"
<kirkland> asac: ogra_cmpc: can you confirm?
<cjwatson> FeasibilityStudy: it would be more normal to install into usr/bin
<FeasibilityStudy> ok, would that fix this error?
<asac> kirkland: ok its RootfsFromScratch command line really
<cjwatson> yes
<asac> kirkland: ogra_cmpc has no internet and cannot chat till next week
<asac> i am proxying
<cjwatson> if you absolutely have to install files into /usr/local for some reason, http://paste.ubuntu.com/407112/ would make it work
<cjwatson> but I'd recommend just installing to /usr/bin instead
<kirkland> asac: sorry, i don't know what RootfsFromScratch means
<asac> kirkland: ogra here, follow the instructions on rootfs from scratch to build an ubuntu-minimal setup (use --notarball to get a qemi
<asac> u image)
<FeasibilityStudy> YAY!
<apw> cjwatson, this install is at 95% and is slowly flashing my HDD, any idea what phase that is?  it could do with a message
<FeasibilityStudy> however, it failed to pick up my GPG key..But I didn't use the -k flag.
<asac> kirkland: its a wikipage
<kirkland> asac: url?
<kirkland> ogra_cmpc: hiya, are you around?
<asac> kirkland: its a http://wiki.ubuntu.com/ARM/RootfsFromScratch
<FeasibilityStudy> cjwatson: If one has one's own PPA is it necessary to sign the package when building the .deb, or does uploading it to the PPA do that for you?
<cjwatson> FeasibilityStudy: that's OK, you can just run debsign by hand afterwards if you like
<asac> kirkland: as asac said, i cant get my machine online from here
<cjwatson> FeasibilityStudy: you have to sign it before upload - the PPA system doesn't (and shouldn't!) have your personal key
<asac> <-- ogra
<FeasibilityStudy> because when i created my PPA it created a new GPG key for me.  So I figured it would be redundant to sign it with my personal key.
<asac> ogra_cmpc is my idling machine at home
<kirkland> asac: :-D
<cjwatson> FeasibilityStudy: no, that's not the same
<kirkland> asac: so no human-ogra here right now then?  :-)
<cjwatson> FeasibilityStudy: that's the GPG key that signs the archive so that your PPA's users can trust that somebody evil on their network isn't substituting a different package
<cjwatson> FeasibilityStudy: it's not the GPG key that the archive uses to ensure that the upload really came from you
<cjwatson> the latter is the one you use when you run debsign (or debuild -k)
<asac> kirkland: on the wiki, follow the first reciepe under 'building a root filesystem image instead of a tarball'
<asac> kirkland: then boot that as described under 'Using a qemu image with full emulation'
<asac> kirkland: in the booted VM do: sudo apt-get install ubuntu-netbook^
<asac> and watch it hang somewhere
<kirkland> asac: how long does that take?
<kirkland> asac: the hang
<ninjai> is there anybody that's able to help me with the brightness keys on my laptop not working in lucid beta 1?
<asac> quite a while depending how speedy your host machine is
<asac> kirkland: its relatively fast if yu have a local mirror of ports
<ScottK> ninjai: You want #ubuntu+1 for that.
<slangasek> pitti: openldap> I'm not current on the db compatibility stuff with openldap, that should be checked with upstream before any change
<kirkland> asac: okay, stay tuned ... i'm putting this together now
<asac> kirkland: it usually hangs at unpacking iputils-something or at iso-codes
<slangasek> cnd_mini: there *should* be a /var/log/boot.log file - that didn't work in the past, it does work now
<slangasek> cnd_mini: at least, I have one here
<asac> kirkland: the package seems to vary for different people but is individually reproducable for them then
<slangasek> kirkland: 550561> from the bug description, it doesn't look to me like anything that needs an FFe - it's just a bugfix?
<kirkland> asac: okay, i'll try to reproduce it with scsi emulation first
<kirkland> slangasek: see the debdiff... there's a bit of other cleanup in there, but I definitely feel it's a bugfix;  just looking for a second opinion since it's such a fundamental package
<kirkland> slangasek: and I've tested it thoroughly here
<kirkland> asac: and then i'll try with virtio ;-)
<asac> kirkland: the call rootstock uses to trigger it is similar to whats on teh wiki, lool suggested to try -disk instead and play with some cacing options, which i didnt manage to test yet due to traveling
 * asac .... ogra hands the laptop back to asac
<kirkland> ah, asac was ogra :-)
 * asac reads if bought something ;)
<asac> ogra said he stated that initially
<kirkland> asac: sorry, i missed it
<asac> heh ... all fine ;)
<mdz> I assume I'm not the only one getting spammed with ancient bug comments since the LP rollout?
<slangasek> kirkland: ok; I can look at this in ~1h
<kirkland> slangasek: perfect; i'm sure that qemu-system-arm will consume me until then :-)
<kirkland> asac/ogra: okay, just clarifying ....  I'm following the instructions at https://wiki.ubuntu.com/ARM/RootfsFromScratch
<apw> cjwatson, this install just completed ... and ejected the CD, and puked sr0 errors ... and stopped
<kirkland> asac: where do i get armel-rootfs-200904151837.tgz
<kirkland>  from?
<cjwatson> apw: I doubt that has anything to do with network connectivity
<apw> cjwatson, no ... i suspect not :)
<cjwatson> the general idea is that casper's meant to read everything it'll need into page cache before ejecting the CD
<cjwatson> it may have missed something
<apw> cjwatson, this machine is likely memory 'lacking'
<cjwatson> mdz: I figure I'm going to be getting it for roughly the rest of time
<cjwatson> mdz: though I suppose there's a chance that it'll remind me of some things I should have closed but didn't
<mdz> cjwatson, I've got 20 so far, and it's only on bug 7076
<ubottu> Launchpad bug 7076 in mozilla "Overriding built-in certificate leading to error -8182 (DoS), especially exploitable by email" [Unknown,Fix released] https://launchpad.net/bugs/7076
<mdz> only 500,000 to go
<mdz> cjwatson, #launchpad is just happy it's working ;-)
<slangasek> pitti: should your latest edit to /ReleaseProcess say 'release' instead of 'beta'?
<kirkland> asac: doh, i think rootstock is creating that for me....
<kirkland> :-)
<pitti> slangasek: erm yes, sorry; fixed
<pitti> slangasek: (I replied to dpm's mail about coordination, for the context)
<cjwatson> mdz: I must admit that I am rather looking forward to having useful comment aggregation in LP
<dpm> pitti, ah, yeah, thanks for that
<cjwatson> Caesar: bug 546405: are there multiple LUKS containers here, or just one?  (i.e. multiple passphrase prompts or just one?)
<ubottu> Launchpad bug 546405 in partman-crypto "Can't preseed encryption passphrase" [Medium,Triaged] https://launchpad.net/bugs/546405
<kirkland> asac: hmm, okay ... so rootstock created qemu-armel-201003311032.img for me
<cjwatson> marjo: your lists of ISO testing bugs don't appear to filter out duplicates, e.g. bug 541539
<ubottu> Launchpad bug 541539 in oem-config "[Lucid] after oem-config runs, X appears to hang, instead of restarting and launching KDM (dup-of: 540938)" [Undecided,New] https://launchpad.net/bugs/541539
<ubottu> Launchpad bug 540938 in ubiquity "oem-config-kde does not log out after setup" [High,Fix released] https://launchpad.net/bugs/540938
<kirkland> asac: and now i'm running "qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel ./vmlinuz -hda qemu-armel-201003311032.img -append "root=/dev/sda mem=384M devtmpfs.mount=0 rw"
<kirkland> asac: kernel panics though
<cjwatson> marjo: (filter out, or consider the dup target instead, or whatever)
<kirkland> asac: does not like the root filesystem
<marjo> cjwatson: ack
<marjo> cjwatson: will try to fix by Friday morning
<kirkland> asac: nevermind, owned by root
<cjwatson> marjo: thanks
<FeasibilityStudy> cjwatson can you give me a quick rundown of how to sign a .deb once it has already been created?  Do I need to sign the .deb itself or just the .dsc? or Both?
<zul> pitti: ping about #493593 can you approve python-formencode. I have updated the bug with the required info
<kees> FeasibilityStudy: for uploading? you need to sign the source.changes file (debs aren't signed)
<pitti> zul: I'm just looking at it incidentally
<zul> pitti: ah good...because ttx was bugging me about it incidentally ;)
<FeasibilityStudy> kees: ok clearsign, detached sign or what?
<ttx> ttx is bugging everyone on beta2 targeted bugs :P
<jibel> mvo, hey, when you have a minute could you review apt fix for bug 130289. Thanks.
<ubottu> Launchpad bug 130289 in gnome-terminal "Encode any ":", "@" or "/" within the user and password field in proxy settings." [Medium,Fix committed] https://launchpad.net/bugs/130289
<kees> FeasibilityStudy: "debsign foo_*source.changes"
<dpm> hey mvo, when you've got some time, do you think you could look at bug 552542? It seems that the ddtp translations in Chinese and Japanese have some breakage
<ubottu> Launchpad bug 552542 in ubuntu-translations "DDTP translation strings breakage in Japanese / Traditional Chinese(Taiwanese) / Simplified Chinese" [Undecided,New] https://launchpad.net/bugs/552542
<lamont> asac: btw, the first 3 of 8 armel buildds are the new boards
<FeasibilityStudy> argh, getting an error that secret key cannot be found..I know it exists
<lamont> StevenK: and cushaw fixed.
<cjwatson> FeasibilityStudy: as a simpler alternative to what kees said, you can just run debsign in the source directory
<cjwatson> there are options to debsign to set the signing key id ...
<FeasibilityStudy> OK I had to pass the -k flag to make it work.
<FeasibilityStudy> and enter key ID...
<FeasibilityStudy> thanks
<kirkland> asac: well i'm having a hell of a time getting a network connection inside of this vm
<kirkland> asac: doesn't seem to have enough of a kernel (or modules) to see an emulated network device
<kirkland> asac: okay, i'm rebuilding my image with a bigger seed
<zul> pitti: thanks
 * lamont stabs at dch deciding that I  must be doing an NMU
<mvo_> jibel: thanks, patch is fine, I merge it today or tomorrow
<mvo_> dpm: I check i tou
<dpm> thanks mvo_!
<mvo_> dpm: oh, a line breaks issue
<mvo_> ?
<jibel> mvo: donkult merged it into debian. It would be better to merge this one.
<mvo_> dpm: I milestoned it
<mvo_> jibel: yeah, I noticed. its very similar, I will merge his version (there is also some other bugfixes I need to merge from him today)
 * mvo_ hugs jibel for the fix
<jibel> mvo_, and gnome team merged the terminal fix \o/
<dpm> mvo_, thanks!
<Caesar> cjwatson: just the one
<jibel> mvo_, any objection to replace synaptic's own proxy settings and use gconf settings instead ?
<zyga> hello everyone
<mvo_> jibel: well, it runs as root
<mvo_> jibel: how would it get the users settings?
<mvo_> jibel: cool :)
<mvo_> (g-t fix merge)
<jibel> mvo_, the 'apply system wide' applies settings to root too. If a user is able to run synaptic as root he's able to apply network settings too.
<mvo_> jibel: right, that is fine, but debian does not carry that patch so we still need a way to set it when that is not available
<mvo_> jibel: but in general I like the idea, ideally it would go upstream, but its not currently (the apply-system-wide)
<cjwatson> Caesar: cool, that makes the bug tractable
<cjwatson> Caesar: (otherwise I'd have to invent some way to have different preseedable passphrases for different partitions and argh)
<jibel> mvo_, btw I noticed that apt.postinst doesn't set the proxy auth string. Is it a desired behavior ?
<zyga> Keybuk: hi, kiko asked me to check with you what kind of bootchart solution we're using for lucid
<cjwatson> Riddell: I'm confused about what to do about bug 386099.  Is it plasma-netbook-appletsrc or plasma-netbook-applicationrc (the bug trail mentions both) and what's the difference between them?  What happens if such a file already exists?  What should it contain?  I don't think I'm in a position to answer any of these questions at the moment
<ubottu> Launchpad bug 386099 in ubuntu-release-notes "Kubuntu Netbook OEM install does not create a 'prepare for shipping' icon" [High,Fix released] https://launchpad.net/bugs/386099
<Keybuk> zyga: it's called "bootchart"
<zyga> Keybuk: right but there are maaaany versions
<zyga> Keybuk: I just want to confirm we're using the c+python one
<cjwatson> Riddell: I can see what casper is doing, but that relies on a file in the kubuntu-netbook-default-settings package
<Keybuk> zyga: since we wrote large parts of it, yes ;-)
<Keybuk> though there are at least two variants of the C version <g>
<zyga> Keybuk:  ok that's all I needed, thans
<cjwatson> (which BTW seems like a very weird way for ubiquity to deliver a desktop file)
<zyga> Keybuk: right, apparently there is another one that looks quite promising
<Keybuk> the two C versions are known, colloquially, as the "Keybuk version" and the "mmeeks version"
<zyga> Keybuk: meego one
<kirkland> asac: ogra: around?
<Keybuk> I don't know which one is in M{oblin,aemo,eego}
<zyga> Keybuk: http://meego.gitorious.org/meego-developer-tools/bootchart/trees/master
<Keybuk> that might be an, as yet, undiscovered third
<zyga> Keybuk: custom version rewritten from scratch
<Keybuk> *shock*
<Keybuk> Intel rewrite something from scratch
<zyga> hehe
<Keybuk> I wonder if it's as amazing as their piece of crap readahead rewrite? :p
<zyga> but it seems to be quite good actually, better than what we have
<Keybuk> why better?
<zyga> less cpu/mem required
<zyga> on-the-fly graph
<zyga> no python dependency
<mvo_> jibel: well, sort of. its a bit dangerous as the password is in cleartext
<zyga> pure c
<Keybuk> I quite like the fact the graphing is done in python
<Keybuk> it's a better language for it
<Keybuk> anyway
<Keybuk> in summary, no we're not using that version
<zyga> Keybuk: the architecture is different - we have to keep the data
<Keybuk> we're using the Ubuntu version of bootchart
<Keybuk> and actively contributing to a "one true version" of bootchart project being led by mmeeks
<zyga> Keybuk: they're just graphing the data in svg which seems less IO constrained
<Keybuk> yes, it's amazing how often you want to keep that data
<zyga> Keybuk: each time?
<Keybuk> and how often you don't want to generate svg on the machine you're trying to boot profile
<Keybuk> (I don't at all)
<zyga> Keybuk: well it's certainly an argument but their version has some merits
<Keybuk> but that's not the conversation you started with :p
<zyga> right :D
<Keybuk> we're not using that version
<zyga> no flame required
<Keybuk> I first learned about that version 30 seconds ago <g>
<Keybuk> oh, I'm not flaming
<zyga> neither am I
<asac> kirkland: just quick
<asac> ;)
<kirkland> asac: okay, i have a small rootstock image running in arm qemu, with networking
<zyga> Keybuk: for some rationale (I'm sure you are interested) you can read their readme file: http://meego.gitorious.org/meego-developer-tools/bootchart/blobs/master/README
<kirkland> asac: and now I'm going to try sudo apt-get install ubuntu-netbook, right?
<Keybuk> zyga: already read through it
<Caesar> cjwatson: heh, yeah that sounds like no fun
<Caesar> We're not doing anything particularly crazy on the encryption front
<asac> kirkland: yes. that works
<asac> kirkland: it will hang sooner or later
<kirkland> asac: okay, taking a snapshot of my disk, then trying it
<asac> cool
<kirkland> asac: how much longer are you and/or ogra going to be around today?
<asac> kirkland: i will be here for another 20 minutes ... then we are heading for dinner
<zyga> mvo_: hi, is there any chance you can run that script (update-alternatives) on the repo today?
<kirkland> asac: okay, i probably won't have anything by then, but check in with me if you come back online later
<davmor2> pitti: do you need a copy of the udev log with RB fired up too so you can compare them?
<nigelb> bryceh, if you've got some time, can you update the lp-gm-scripts PPA? (bdmurray had merged a branch of mine in)
<mvo_> asac: oh, the problem with apt-get is actually a qemu bug?
<kirkland> asac: oh, another thing ... i see these are running with 256M of memory
<asac> mvo_: we dont know
<kirkland> asac: is that enough?  especially if there's no swap ....
<cjwatson> Keybuk: so in the process of working through bug 548954, I noticed that upstart doesn't pass INIT_VERBOSE through to jobs, so the stuff in /lib/init/vars.sh to detect it doesn't work.  Is there a way for a job to ask that particular named variables from pid 1's environment be exported to it, or should I just have /lib/init/vars.sh parse /proc/cmdline for INIT_VERBOSE as well as everything else?
<ubottu> Launchpad bug 548954 in ubuntu-meta "Ubuntu servers should display information during boot by default" [High,Confirmed] https://launchpad.net/bugs/548954
<mvo_> zyga: not today, maybe tomorrow, but I'm swamped a bit currently
<slangasek> pitti: hmm, I don't seem to have said mail from dpm
<Keybuk> cjwatson: by design ;-)
<zyga> mvo_: ok, I'll ask again on Friday, maybe you'll have some more time then, thanks
<slangasek> cjwatson: do you want weekly reports to you this week again?
<cjwatson> I assumed that defaulting to a clean environment was by design, certainly
<cjwatson> slangasek: might as well
<slangasek> ok
<Keybuk> cjwatson: add "env INIT_VERBOSE" to rc.conf
<cjwatson> Keybuk: perfect, thanks.  Want a documentation patch for that? :-)
<Keybuk> documentation patch?
<cjwatson>        env KEY=VALUE
<cjwatson>               Defines a default environment variable, the value of which may be overriden by the event or command that starts the job.
<Keybuk> oh, I never documented you could use without the value
<cjwatson> perhaps 'env KEY[=VALUE]'
<Keybuk> please :p
<kirkland> mvo_: do you have any idea how much MEM an apt-get install of ubuntu-netbook might take?
<kirkland> mvo_: seems like some of that operation might be memory-intensive?
<Keybuk> cjwatson: where does INIT_VERBOSE come from?
<zyga> hmm is dying intel graphics a common treat on 10.04?
<cjwatson> Keybuk: I'm assuming the kernel command line
<cjwatson> or /etc/default/rcS, although it isn't documented there - it seems like a command-line override for VERBOSE
<cjwatson> i.e. quiet + INIT_VERBOSE = you get init script output but not vast piles of kernel output
<kirkland> zyga: what do you mean by that?
<kirkland> zyga: i've noted a couple of weird things with my intel graphics in my Thinkpad; wondered if my hardware might be going bad
<cjwatson> which I think is the combination the server team is after; VERBOSE=yes in /etc/default/rcS would work too and I haven't yet decided which would make more sense from an installer POV
<bryceh> nigelb, sorry kind of tied up with other stuff at the moment
<zyga> kirkland: I just ran daily upgrades and my screen got corrupted for a moment (90% black with some junk at the top)
<zyga> this happens quite often, I'm not sure it's related to updates
<zyga> sometimes it lasts
<nigelb> bryceh, any time you get time is fine too :)
<zyga> so if it happens again I can take a photo
<bryceh> nigelb, why don't you ask brian to set you up with access to update the ppa?
<zyga> usually alt-tabbing fixes it
<zyga> kirkland: 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)
<nigelb> bryceh, brian's on vacation.  I forgot to remind to update earlier.
<kirkland> zyga: hrm, mine looks like a glitch in the Matrix
<bryceh> nigelb, ah, ok well hang on for a bit
<zyga> kirkland: so you seen this too?
<kirkland> bryceh: i just heard zyga say that he's had some odd issues with intel graphics... i've seen a couple of things too, that i was chalking up to hardware possibly going bad
<nigelb> bryceh, I just asked kees too since you were busy, so if either of you get the time :)
<bryceh> nigelb, ok great.  Yeah I've not actually updated the ppa so dunno if there's any extra steps to do there
<kirkland> bryceh: the two things ... 1) sometimes (maybe 1 in 20) times I open my laptop lid, the screen is so dark I can barely see it (like way darker than minimum contrast)
<bryceh> kirkland, lp#?
<kirkland> bryceh: and 2) about 3 times in the last two weeks, I've had a "glitch" in the Matrix, where for 1/10th of a second, the screen "glitches", like turning on old tv on, and then it's fine
<kirkland> bryceh: i'm not sure it's a bug; think my hardware might be going bad, but i just happened to see zyga asking about Intel graphics issues, and it piqued my curiosity
<zyga> bryceh: I'm sure it's a bug
<Riddell> cjwatson: bug 386099 wants a plasma-netbook-appletsrc like the "moved_plasma-netbook-appletsrc" one which is used to put ubiquity there, however that needs some changes now because of changes in the default layout
<ubottu> Launchpad bug 386099 in ubuntu-release-notes "Kubuntu Netbook OEM install does not create a 'prepare for shipping' icon" [High,Fix released] https://launchpad.net/bugs/386099
<zyga> sorry, kirkland
<zyga> I dual boot with 9.04
<zyga> never ever on 9.04
<Riddell> cjwatson: I can get it sorted, where's the code that gets run before login for the oem user?
<cjwatson> Riddell: do you mean bin/oem-config-firstboot?  I think your original suggestion of making the change in scripts/install.py was better though
<bryceh> kirkland, yeah dunno, but there's plenty of bug reports about lid issues and glitches so could well be software
<bryceh> kirkland, you know the drill... file bug reports, we'll get to them when we have time
<kirkland> bryceh: will do
<kirkland> bryceh: thanks
<Riddell> cjwatson: that looks like it, I'll fix it up
<kirkland> asac: okay, i *think* i'm seeing the hang unpacking firefox-gnome-support
<lex79> pitti: if I understand, since the nonpolkit-mount-policy patch was in hal from jaunty, this means the patch in kdebase is broken, right?
<lex79> we have to fix the patch in kdebase...
<lex79> ehrm, in kdelibs, not in kdebase
<cjwatson> Riddell: cool, thanks
<Riddell> cjwatson: I might move /usr/share/applications/kde/oem-config-prepare-kde.desktop to /usr/share/applications/kde4/oem-config-prepare-kde.desktop, in the kde/ directory it gets marked as being a KDE 3 app which looks bad
<cjwatson> ok by me
<lex79> doko__: this patch in Qt http://bazaar.launchpad.net/~kubuntu-members/qt/ubuntu/annotate/head:/debian/patches/90_ia64_opts.diff is obsolete since seems you fix the bug also in gcc ?
<doko__> lex79: yes, afaik ScottK did want to remove it
<lex79> doko__: ok, to fix this ftbs https://edge.launchpad.net/ubuntu/+source/qt4-x11/4:4.6.2-0ubuntu3 should we drop the patch then?
<doko__> lex79: enoclue, that is a different one. please investigate
<lex79> oh, ok
<kirkland> slangasek: any chance to look at the motd change?  i'd like to upload it before the freeze goes into effect
<slangasek> kirkland: looking now
<slangasek> kirkland: which part of this corrects the double-printing of motd.tail?
<kirkland> slangasek: the postinst.in part
<kirkland> slangasek: the part that moves the generated motd.tail out of the way
<slangasek> kirkland: so it's not "double-printing of motd.tail", it's "double-displaying of the information we were writing to /etc/motd.tail"?
<kirkland> slangasek: that's linguistically more correct, yes
<slangasek> kirkland: looks good to me
<kirkland> slangasek: thanks man
<soren> I've used mk-sbuild to build an sbuild chroot. When I build a package in there, it gets "Distribution: lucid-amd64" in the binary .changes file. Does anyone know off the top of their head where it gets that value?
<soren> (I launch sbuild like so: sbuild -d lucid-amd64 blahblahblah.dsc)
<geser> I remember reading a discussion about a similar problem, let my try to find it.
<soren> Is it passed as an environment variable or something?
<soren> It seems I can do -d lucid instead and it works it out anyway.
<geser> IIRC this is also the solution
 * soren scratches head a little bit
<geser> soren: see http://lists.debian.org/debian-devel/2010/03/msg00600.html
<Penguin> Can anyone give me a link to a guide on updating deb packages?
<soren> geser: Awesome. Thanks for the link!
<mvo_> jibel: apt fix is commited, I upload in a little bit
<akgraner> hey all - we have a guy in the NC channel who switched to Lucid - he did updates today - and rebooted like it said - now he is in a loop that keeps taking him to his logon screen - I can't help him - but can you all or point me in the right direction to I can tell him?
<akgraner> Hi all - magedragon25 just joined - he is the one from the NC channel - thanks in advance to whomever :-)
<slangasek> akgraner, magedragon25: this is probably bug #516520, which seems to have regressed in the past few days; I've confirmed that it appears to be a gdm bug, but need the desktop team for further triaging
<ubottu> Launchpad bug 516520 in gdm "lucid lynx - login screen stuck in a loop - SYSTEM BROKEN" [Undecided,Confirmed] https://launchpad.net/bugs/516520
<slangasek> chrisccoulson, seb128: either of you still around and have any insight there? ^^
<seb128> I'm around, let me have a look to the bug
<magedragon25> that bug says he could get into console from safe mode....my recovery console won't even come up
<akgraner> slangasek, is there a way he can fix his system or is it a complete reinstall?  and slangasek thank you for looking into the question for us :-)
<slangasek> magedragon25: recovery console may be a whole 'nother kettle of fish right now.  When you get to the login screen, can you hit Ctrl+Alt+F1?  This should take you to a console login prompt; afterwards you can use Alt+F7 to switch back to GDM
<seb128> slangasek, doesn't seem a gdm issue there
<magedragon25> I will have to reboot, i have only one pc and i had to log into win7 to get here for help
<seb128> it seems that the session or xorg crash and they got back to gdm then
<cjwatson> systems are always recoverable without reinstalling; it's just a question of how much effort you want to go to. :-)
<slangasek> seb128: the log says 'conversation failed', which implies that the application-supplied conversation function returned a failure
<seb128> seems another bug which collect different issues
<seb128> some comments say startx doesn't work
<slangasek> seb128: sorry - to be clear, I'm reading from the bottom of the bug rather than from the top.  The bug was originally opened for a separate issue :/
<seb128> ok, let me look at it this way too
<magedragon25> be back shortly if it doesn't work
<slangasek> akgraner: I hope he also comes back if it *does* work, because I have more questions and would like to debug this in realtime with him :)
<seb128> slangasek, gdm didn't really change in the recent weeks
<seb128> out of xkb layout changes from pitti
<seb128> and gdmsetup
<seb128> but neither of those should impact on login
<akgraner> slangasek, let me tell him
<seb128> are you sure it's not something in the pam stack which changed?
<slangasek> seb128: no, I'm not sure; but the 'conversation failed' comes from the application side.  If it's a PAM stack bug, I have a guess where it is, but I need someone who can reproduce the bug to help me narrow it down
<akgraner> slangasek, I sent him a message
<seb128> slangasek, it doesn't help that the bug collect different issues
<seb128> that one seems one and I've no clue about it
<seb128> some other comments looks like users dist-upgraded while things were not installable and removed things required
<seb128> ie gnome-session
<slangasek> heh
<seb128> which leads to GNOME not starting
<seb128> but it's weird, as said gdm didn't change out of xkb and gdmsetup recently
<slangasek> one thing that *did* change recently was the winbind package getting pam-auth-update integration on March 19th; but I don't have any explanation for how that would cause the error shown
<magedragon25> I was able to get into console, but startx didn't work
<magedragon25> I also switched to gdm, but it just went to my login
<magedragon25> slangasek: I am back, I got into console but startx didn't work, it gave me an error about no such process, and switching to gdm just goes to my login
<slangasek> magedragon25: hi - what do you mean, "goes to your login"?
<slangasek> you mean it takes you back to the login screen (which is what I would expect)?
<magedragon25> yes
<slangasek> ok
<magedragon25> sorry
<slangasek> do you have the exact error message from startx?
<slangasek> do you know if you have the 'winbind' package installed on this system?
<magedragon25> there was no number just said no such process, I assume it's installed if it should be....unfortunately I have to switch back and forth on the same pc
<slangasek> magedragon25: winbind is only supposed to be installed if you want to use it; I ask because I'm trying to determine if it's linked in some way to the problems users are reporting
<magedragon25> oh
<magedragon25> then no, i don't have it
<slangasek> a very troubling bug
<magedragon25> slangasek: unfortunately, i am gonna have to bail for now. I have to get ready for my college class tonight. it's a redhat class, and being as i am ahead of everyone else, I might be able to get back on, and have my laptop setup next to me
<slangasek> magedragon25: ok - the next step for troubleshooting this is going to be to try to log in, then switch with Ctrl+Alt+F1 and examine /var/log/auth.log
<magedragon25> ok....I have class at 6pm est, so between 6 and 7, I will know if I can get back on
<Caesar> This whole amd64 builder being way behind the i386 one really bites
<mathiaz> mvo_: hi!
<mvo_> hi
<mathiaz> mvo_: is it possible to add some code to update-manager to modify a conffile?
<slangasek> twitch
<slangasek> why is the package not taking care of it directly?
<mathiaz> slangasek: the use case is an upgrade of mysql from 5.0 to 5.1
<mvo_> mathiaz: what is the use case? it can do that, but as slangasek says, doing it in the package has the benefit that apt-get users are also happy
<mathiaz> slangasek: the skip-bdb option is no longer recognized by 5.1
<mathiaz> slangasek: if skip-bdb is in /etc/mysql.my.cnf 5.1 fails to start and the package upgrade fails
<mvo_> jibel: thanks for lp:~jibel/synaptic/bug.292267 ! rock on!
<mathiaz> slangasek: however /etc/mysql/my.cnf is a conffile
<mathiaz> slangasek: and the debian policy states that maintainer scripts should not modify conffiles
<slangasek> mathiaz: update-manager shouldn't do it either; if you're going to violate policy, best to do it local to the problem ;)
<jibel> mvo_, thanks for merging !
<mathiaz> slangasek: ok - there is an item about skip-bdb in the NEWS file
<mathiaz> slangasek: however users don't seem to read it :/
<mathiaz> slangasek: which causes a lot of package upgrade to fail
<chrisccoulson> slangasek / seb128 - sorry, just got back from dinner
<slangasek> mathiaz: so what policy really says is "local changes must be preserved during upgrade", and "if you're managing a configuration file in the maintainer scripts, it must not be a conffile".  This appears to be a case where an option which is not present in either the old or new version of the default conffile is no longer supported, correct?
<chrisccoulson> did you figure out the issue? (i've not read all the scrollback yet)
<slangasek> mathiaz: I think it's reasonable for the maintainer script to remove the unsupported option on upgrade (in the preinst), making a backup copy of the file, and (optionally) throw a debconf note that this has been done
 * ScottK notes debconf is for questions, not notes.
<slangasek> debconf isn't appropriate for *unconditional* notes; for conditional ones, I think it's suitable, more suitable than anything else
<mathiaz> slangasek: well - skip-bdb is in the default hardy my.cnf file
<mathiaz> slangasek: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/hardy/mysql-dfsg-5.0/hardy/annotate/head%3A/debian/additions/my.cnf
<mathiaz> slangasek: so on upgrade from hardy to lucid, the skip-bdb option needs to be removed/commented
<soren> ScottK: Well, the debconf protocol has a "note" type.
<slangasek> soren: the "note" type is deprecated
<slangasek> (however, "error" is not)
<soren> slangasek: Where does it say that?
<soren> slangasek: I'm not questioning it, I'm just wondering where I could have found out on my own.
<ScottK> Since it affects the default config file, it will affect ~everyone.
<slangasek> soren: in the words of Joey Hess on debian-devel a number of years ago; if it doesn't say this in the manpage, that's a bug
<soren> slangasek: It doesn't.
<cjwatson> it sort of half does
<soren> slangasek: (in debconf-devel(7) at least)
<cjwatson> "It's best to use these only for warning about very serious problems, and the error datatype is often more suitable."
<soren> cjwatson: Fair point.
<cjwatson> I think there do exist situations where "note" is appropriate, but they're rare
<slangasek> mathiaz: so this affects only users that 1) have modified the conffile, and 2) choose "keep my version"?  is that a common case?
<soren> It's the default, isn't it?
<soren> 2) in the case of 1), I mean.
<slangasek> the default is that the conffile hasn't been modified
<mathiaz> slangasek: hm - good point. I don't think so
<soren> slangasek: Assuming it's been modified.
<mathiaz> slangasek: most of the reports/comments I saw were desktop users installing mysql
<slangasek> mathiaz: interesting - why would a desktop user edit this file? :)
<soren> Boredom?
<ScottK> Inquisitiveness in beyond their experience base?
<slangasek> mathiaz: so I think the best way out is mysql-common to have a preinst that checks whether /etc/mysql/my.cnf has been modified (there are copy-waste maintainer script snippets for this, I ca dig one up if you need it); if so, look for skip-bdb; if found, make a backup and sed it out of the file and (if you decide to) send a debconf error message about the change
<highvoltage> sheesh, I missed almost all of #ubuntu-devel today!
<mathiaz> slangasek: ok - I'll think about it
<soren> ScottK: Tomato, tomato?
<ScottK> Something like that
<slangasek> mathiaz: in the unmodified conffile case, dpkg will already handle the update smoothly.  in the modified conffile case, the user is going to get a conffile prompt no matter what we do.  so in both cases, we're free of skip-bdb, without inconveniencing users with the dreaded "what do you mean, 'local version'?  I don't know what that file is!" exerience
<slangasek> +p
<mathiaz> slangasek: do you have an example package that checks whether a conffile has been modified?
<slangasek> mathiaz: acpi-support preinst
<mvo_> jibel: I'm playing with the ~jibel/synaptic/jibel branch but when I search for "apt" I get it rankend relatively low (its not on the first page. the current ubuntu version ranks it higher (also still not on top)
<jibel> mvo_, hm, I'll check that tomorrow.
<mvo_> jibel: cool, thanks.
<zyga> intel gfx drivers crashed/froze my system just now, apport didn't pick it up, is there anything I can look for to trace this?
<lex79> doko__: is there a way to testbuild a package on ia64? in local, maybe with pbuilder? or is there any ppa where I can upload a package to see if build?
<lifeless> james_w: I think its recovered now; it was in a vm - a littly tricky to get to manually
<bdrung_> kirkland: ping
#ubuntu-devel 2010-04-01
<magedragon25> slangasek: are you available? I have about 10 min and I have my pc in tty1 with ps aux | less running, if you want to take time....
<slangasek> magedragon25: hi - please run 'grep gdm /var/log/auth.log'
<magedragon25> ok
<slangasek> and if you have a way to copy-paste the output, that's best - if you have the network up on the laptop, you could install the 'pastebinit' package for this
<magedragon25> slangasek: piped it to less
<magedragon25> no network access for my personal pc here at school
<slangasek> ok
<slangasek> can you visually compare it with the output in https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/516520/comments/37 ?
<ubottu> Ubuntu bug 516520 in gdm "lucid lynx - login screen stuck in a loop - SYSTEM BROKEN" [Undecided,Confirmed]
<magedragon25> I did find a process winbindd running in the ps aux command......
<slangasek> ok
<magedragon25> my output is different...I have a lot of no x11 mode
<slangasek> please try running (as root) the command 'pam-auth-update', and unselect 'Winbind NT/Active Directory authentication'
<bgamari> How is python supposed to find packages in /usr/share/pyshared?
<bgamari> Currently apport is failing on my lucid box due to being unable to find lazr
<bgamari> Is /usr/share/pyshared supposed to be in PYTHONPATH directly?
<bgamari> or is there a missing symlink somewhere?
<magedragon25> slangasek: if you are still available, sorry we had a system crash.....I didn't get the last command you wnated me to run
<slangasek> magedragon25: hi, the command is 'pam-auth-update' run as root
<slangasek> then unselect 'Winbind NT/Active Directory authentication'
<magedragon25> ok, done
<slangasek> magedragon25: now see if you can log in
<magedragon25> nope...already tried it....unless I should restart my pc
<slangasek> shouldn't need to restart, no
<slangasek> ok, so it's not winbind :/
<slangasek> my other guess is gnome-keyring
<magedragon25> is there a way to check installed packages from the cli?
<slangasek> can you run the command again, and scroll until you find "GNOME Keyring Daemon - Login keyring management", and unselect that one as well?
<slangasek> check installed packages> either 'dpkg -l' or 'apt-cache policy <packagename>'
<magedragon25> the keyring option didn't work either
<magedragon25> what is the package name for the desktop? is it ubuntu-desktop? or gnome-desktop?
<slangasek> there's an ubuntu-desktop package
<magedragon25> class is over, and I will be on my way home here shortly, I am going to figure out how to connect to my wireless through cli and reinstall the ubuntu-desktop package...and see fi that might help
* slangasek changed the topic of #ubuntu-devel to: Archive: Beta Freeze, redux | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<mathiaz> slangasek: hi!
<slangasek> mathiaz: hello
<mathiaz> slangasek: I'm about to finish testing a new mysql-dfsg-5.1 package
<mathiaz> slangasek: with some upgrade fixes
<mathiaz> slangasek: I'd like to get it included in beta2
<slangasek> mathiaz: sure - please upload when it's ready
<mathiaz> slangasek: ok - thanks
<micahg> slangasek: do you know when you plan on freezing the archive for beta 2?
<mathiaz> micahg: -10 minutes
<slangasek> micahg: already done, per the /topic change
<slangasek> :-)
 * micahg miss
<micahg> orry
<micahg> slangasek: same process as beta 1 for exceptions?
<slangasek> yes
<micahg> ok, I'll try to get them done before the weekend this time :)
<ScottK> Looks like I got the first upload NOT to make the cutoff.
<wgrant> ScottK: Tried the new queue with package sets yet?
<ScottK> slangasek: The pending kdebase-workspace upload fixes a FTBFS so we get three important bug fixes (from the previous upload) into Beta 2.
<ScottK> wgrant: I just now loaded the page for the first time since it's there.  Very nice.  Thank you.
<lamont> pitti: fyi, gnome-session et al work much better when actually installed.  no  needs here. kthx
<kirkland> bdrung_: pong
<kirkland> bdrung_: please please please forward that qemu-kvm patch upstream, to the qemu mailing list
<slangasek> mathiaz: alas, your upload fuzzies all of the translations of this debconf template.  Given that it's a literal package name, could you search and replace on the .po files from before this change, and rebuild?
<mathiaz> slangasek: ok
<slangasek> mathiaz: thanks - I'll wait for that upload to save us a little build time
<mathiaz> slangasek: yeah - takes a few hours to build mysql
<mathiaz> slangasek: sed -i -e 's/mysql-cluster/mysql-cluster-server/g' debian/po/*po
<mathiaz> slangasek: ^^ that's enough?
<slangasek> mathiaz: if there's only one string that says mysql-cluster in it, that should do the job, yes
<mathiaz> slangasek: yes - there is only one string that refers to mysql-cluster
<ScottK> slangasek: Thanks (for getting kdebase-workspace right in the build queue)
<slangasek> sure thing
<mathiaz> slangasek: hm - well - that sucks. Seems that I've lost access to my build server
<mathiaz> slangasek: so I can't finish up the mysql-dfsg-5.1 upload
<slangasek> mathiaz: ah; let me do it on this end then
<ScottK> Figures.  Now clamav 0.96 goes final.
<lamont> wtf does xchat now think it should always be on the visible workspace?  and how do I correct that?
<lamont> ah, of course, one doesn't select the selected item to toggle it, one selects another item from the menu
<helix> hi, does anyone know if polipo is actively maintained by anyone in ubuntu?
<helix> I am taking over the debian package, but I also work on tor stuff and we have our own debian repository where we provide tor and vidalia packages. I am thinking of just providing the polipo debs for ubuntu there as well but I think it would be better to coordinate with the ubuntu maintainer, if one exists. (I only see Ubuntu MOTU Developers on http://packages.ubuntu.com/lucid/polipo)
<ScottK> helix: It doesn't look like it from the history.  Someone cared enough at one point to do a security update for it.
<ScottK> Let me see who.
<helix> it is the debian changelog
<slangasek> ScottK, Riddell: hum; did the kdebase-workspace 4.4.2 upload drop tseliot's plymouth integration patches?
<helix> I don't think any ubuntu changes have been applied
<ScottK> slangasek: Shouldn't have.
<slangasek> ScottK: debdiff indicates it did - unless the patches were upstreamed
<RoAkSoAx> lamont, ping
<slangasek> ScottK: perhaps a midair collision as I suppose tseliot doesn't have ~kubuntu-members commit access
<ScottK> slangasek: No, he doesn't.
<ScottK> slangasek: Looks like that's exactly what happened.
<ScottK> Urgh.
 * slangasek nods :/
<slangasek> I've reopened the bug
<wgrant> RoAkSoAx: I believe he's asleep.
<RoAkSoAx> wgrant, i think i just missed him then
<wgrant> RoAkSoAx: Yeah, he's not been gone long.
<ScottK> helix: https://bugs.launchpad.net/ubuntu/+source/polipo/+bug/533578 <- The filer of the bug is an Ubuntu person who seems to be interested in packaging updates.
<ubottu> Ubuntu bug 533578 in polipo "Port security patches for Polipo from Lucid to Karmic and below" [Medium,Fix released]
<slangasek> helix: so given that polipo has a Debian version in all current releases, I'd say it's not maintained in Ubuntu - if there's anyone in Ubuntu interested in the package, they've been working directly in Debian
<ScottK> Not sure  how interested.
<RoAkSoAx> wgrant, well I guess I'll have to ping him tomorrow
<wgrant> RoAkSoAx: What do you need?
<helix> weird, who are the ubuntu people in this bug? I don't think they have done anything on the debian package
<helix> but that looks good anyway, it means there are other people who are interested
<helix> which means I don't have to maintain a bunch of ubuntu versions
<helix> excellent
<ScottK> helix: mdesleurs is on the Ubuntu Security team.
<slangasek> helix: mdeslaur is on the Ubuntu security team; I don't think this is an expression of personal interest in the package on his part
<RoAkSoAx> wgrant, well i just wanted him to push the apport hook for bind9, since I;ve been told he usually likes to keep it in sync with debian
<helix> oh
<helix> mmf
<helix> who is the other guy?
<wgrant> Ah, right.
<ScottK> I've seen him around a bit, but don't know him.
<RoAkSoAx> wgrant, so instead of just pushing it for ubuntu, he could push it for both
<helix> basically I would prefer that tor not maintain a bunch of ubuntu debs for this, since it appears to mostly be sync'd from debian, but ...
<ScottK> slangasek: Good catch on the plymouth patches.
<helix> should I just upload to ubuntu too?
<helix> or what is the best approach for this if I want ubuntu users to have current debs
<ScottK> slangasek: Is it important this get fixed tonight?  It's late here and I'm tired.
<ScottK> helix: It's very late for me, I'd be glad to discuss that with you a bit later.
<helix> okay
<slangasek> ScottK: no, it can wait
<ScottK> Excellent.  I'm going to bed.
<slangasek> ScottK: it does need to get fixed again before I can poke the plymouth side to play nice with it, fwiw
<ScottK> Yeah, I'll fix it or get it fixed tomorrow.
<magedragon25> for those that are paying attention....I finally fixed my problem with not being able to log into gnome.....no more loops
<slangasek> magedragon25: how did you fix it?
<magedragon25> I finally got reconnected back to the net, and ran apt-get update, and reinstalled ubuntu-desktop
<magedragon25> I am running update again....and I think the first time I ran it, it uninstalled ubuntu-desktop and I didn't notice it....
<slangasek> ok
<slangasek> you'll want to make sure you re-enable the gnome keyring option that you disabled earlier with pam-auth-update, btw
<magedragon25> it's wanting to uninstall ubuntu-desktop again...not sure why tho
<slangasek> hmm
<magedragon25> I already did that, thanks
<magedragon25> it uninstalled ubuntu-desktop and update-notifier, now it won't let me reinstall either one. It gives me an error about needing update-notifier-common ver 0.99 and 0.99.1 is installed
<slangasek> you're running amd64, I guess
<magedragon25> yes
<slangasek> yeah, it's not safe to do a dist-upgrade on amd64 right now, there are too many out-of-date packages there; according to https://launchpad.net/ubuntu/+source/update-notifier/0.99.1/+build/1595582, it'll be another 12h before it makes it through the backlog
<slangasek> you can manually grab update-notifier-common 0.99 from the archive and reinstall it
<magedragon25> oh...i upgraded to lucid almost a week ago
<slangasek> the latest removal of update-notifier from your system is due to version skew from just today
<slangasek> whichever tool you used to do the upgrade (update-manager, synaptics, apt-get, etc) did so in a mode that said it was ok to remove packages... that's what I mean by "dist-upgrade"
<magedragon25> oh..duh
<Caesar> slangasek: can you approve the FFe for tar (bug 539814) please?
<ubottu> Launchpad bug 539814 in tar "FFe: Sync tar 1.23-1 (main) from Debian squeeze (main)" [Unknown,Fix released] https://launchpad.net/bugs/539814
<ccheney> slangasek: wanted to give you warning of a (hopefully) soon OOo upload, just waiting on oracle approval of the new images
 * ccheney noticed on the blog about hard freeze for beta 2 today and didn't hear back from oracle yet, probably will on thursday
<ScottK> slangasek: kdebase-workspace is up for your review/accpetance (couldn't sleep, so decided to be productive).
<slangasek> ccheney: since there are some massive security builds clogging the queue right now, we seem to have a day or so backlog already - is this upload going to address bug #546797 along the way?
<ubottu> Launchpad bug 546797 in openoffice.org "URE: Component registries might be corrupted" [High,Confirmed] https://launchpad.net/bugs/546797
<slangasek> ScottK: ok, will look in a bit, thanks
<slangasek> Caesar: working on it
<ccheney> slangasek: yes
 * ccheney headed off to bed now, bbl
<slangasek> Caesar: do you know what the effect is of changing the SIGPIPE handler?
<pitti> Good morning
<pitti> lamont: glad to hear that things are back
<\sh> moins
<dholbach> good morning
<mvo> dpm: I have a a11y bugfix for software-center that adds some strings. what would you recommend at this point of the freeze, merge it for the benefit of people with e.g. orca? leave the strings out and merge the rest?
<dpm> mvo, what are the strings? Is there a bug I can read somewhere to have some more context? Without knowing much more about it, I'd say if the feature is an a11y one and it needs new strings to be useful, it's probably important enough to just add the new strings (and communicate it to translators, of course)
<mvo> dpm: bug number is bug #526384
<ubottu> Launchpad bug 526384 in software-center "Pathbutton doesn't expose text to accessibility aids" [High,Triaged] https://launchpad.net/bugs/526384
<mvo> dpm: I added the strings that are added
<mvo> dpm: I'm not 100% positive how to move forward, there are other a11y area where s-c is not doing great, but every bit helps so I'm inclined to merge it
<dpm> mvo, yeah, I also think it makes sense.
<pitti> cjwatson: do you know whether http://people.canonical.com/~ubuntu-archive/component-mismatches.txt says auctex pulls in emacs22? AFAICS it depends on emacs23 | emacs22 | ..., and 23 is in main
<pitti> (auctex is arch: all, so not an architecture specific thing either)
 * pitti goes to clean some NBS
<MacSlow> seb128, I've a updated branch for fixing LP: #546650 so it (hide on mouse-over) works again for the non-composited case... still have to do a test for older gtk+ (and karmic)
<MacSlow> seb128, once that turns out good I'll ping you... will move to the rhythmbox-cover-art bug then
<MacSlow> seb128, if all goes well I'll be able to roll a new notify-osd tarball too later today
<seb128> MacSlow, ok thanks
<bdrung_> pitti: the rebuild of abraca will fail
<cjwatson> pitti: s/whether/why/?  I'll have to look a little later anyway - my server is in go-slow mode and it's making it hell to get anything networky done
<pitti> cjwatson: "why", yes
<pitti> cjwatson: ok, thanks; it seems to act a little strange anyway -- it wants vala because of vala, and nothing else
<pitti> cjwatson: for sure, vala is nice, but I didn't know that c-m was so personally attached to it :)
<directhex> has there been any commitment from AMD to release an FGLRX which works with Lucid before release?
<pitti> directhex: like the one that was uploaded last week? :-)
<directhex> pitti, really? i hadn't noticed that!
<directhex> pitti, i'm in the market for a new gpu, but am busy worrying over ubuntu
<tjaalton> pitti: I've merged mesa 7.7.1 which is a stable release of the branch we've been tracking until now. ok to upload?
<pitti> tjaalton: you can upload, it'll be in unapproved (possibly until after beta-2)
<tjaalton> pitti: oh, tseliot was waiting for it, though that change could then be uploaded separately (to fix ia32-libs, bug 248392)
<ubottu> Launchpad bug 248392 in ia32-libs "32bit libgl search for dri at wrong place on 64bit system" [Low,Confirmed] https://launchpad.net/bugs/248392
<tseliot> tjaalton, pitti: it's ok, I can wait
<tjaalton> tseliot: ok
<cjwatson> pitti: it totally is architecture-specific :) the problem is that emacs23 hasn't built on ia64
<cjwatson> (auctex)
<cjwatson> pitti: vala> component-mismatches has got confused about the reasons because somebody already put the valac binary in main, but without its source
<cjwatson> libdbusmenu Build-Depends: valac
<pitti> cjwatson: ah, thanks; I'll sort that out
<lamont> RoAkSoAx: sup?  Just asking tends to work better than pinging
<dholbach> RoAkSoAx: can you update http://www.roaksoax.com/2010/03/data-loss-after-update/comment-page-1 ? did you get your data back?
<tjaalton> pitti: x-x-i-synaptics conf doesn't match /dev/input/event*, generating errors in the log when it tries to init /dev/input/mouse* etc, ok to upload?
<tjaalton> pitti: also, xorg merge which adds only support for Xreset/Xreset.d for scripts to run after a logout
<tjaalton> though it needs *dm support
<tjaalton> ..too
<bdrung_> can someone unsubscribe u-u-s from bug #553055?
<ubottu> Launchpad bug 553055 in helium "Please sync helium 1.6-6 (universe) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/553055
<bdrung_> dholbach: ^
<pitti> tjaalton: synaptics> sounds fine
<pitti> tjaalton: in general, you can upload stuff; we'll review it from unapproved and accept it for beta or keep it there until after beta
<jpds> lamont: < RoAkSoAx> well i just wanted him to push the apport hook for bind9, since I;ve been told he usually likes to keep it in sync with debian
<lamont> yeah.  I guess that means apport hooks snuck into ubuntu,eh?
<pitti> tjaalton: why does x-x-i-synaptics now ship both an udev rule and a conf.d snippet?
<pitti> tjaalton: (smae vor vmmouse and wacom)
<pitti> tjaalton: wouldn't that lead to input devices being recognized twice? or is xorg clever enough to identify them?
<tjaalton> pitti: udev rules are needed when setting ID_INPUT.tags, and that's used for platform specific quirks here
<pitti> tjaalton: ah, thanks
<tjaalton> vmmouse needs it to recognize the platform, and wacom to set ID_INPUT for serial devices
<tjaalton> and the name, which wacom.conf then matches against
<pitti> right, xorg.conf.d wouldn't be able to do callouts
<tjaalton> yep
<nigelb> can the other tasks in this bug report be closed? bug 429443
<ubottu> Launchpad bug 429443 in cpu-checker "/usr/bin/kvm-ok should be disassociated from kvm" [Medium,Fix committed] https://launchpad.net/bugs/429443
<Keybuk> ok, I've been online for a couple of minutes and nobody's pounced on me
<Keybuk> and the only e-mails I have after "Hot Sale, some-mailing-list-owner! 77% off on top goods"
<Keybuk> I guess I didn't break the world
<Keybuk> or broke it so badly nobody can get on IRC
<ttx> Keybuk: I can hear you, if that's of any comfort.
 * ttx admits not having updated to "OMG Freeze is tomorrow let's upload everything" archive state yet
<qense> I have an old bug report that complains that the apt-pkg API in Ubuntu differs from Debian. It is at least a few years old. Is this bug still true?
<free> mvo: hey, I'm having a problem upgrading from hardy to lucid (a bare kvm with debootstrap package + ubuntu-desktop) https://pastebin.canonical.com/29974/
<free> mvo: any clue why?
<nigelb> Keybuk, oh, you want someone to pounce? :D
<Keybuk> only if they're cute
<nigelb> lol, I'm looking for a bunch of people to work with me.  trying to get number bugs i review down to less than 150
<Keybuk> once I've got the number of bugs I have to review down below 3,000, I'll let you know <g>
<nigelb> :O
<nigelb> its now 225, only a matter of 75 bugs :) but getting debdiff ready and testing is the hard part
<Keybuk> Riddell: you'll need to update the Kubuntu Plymouth theme to depend on plymouth-label I expect
<Riddell> nixternal: ^^
<Keybuk> is just a debian/control change
<ScottK> nixternal: ^^^
<dholbach> nixternal: ^^^^
<nigelb> lol :D, nixternal ^^
<mvo> free: checking
<free> mvo: thanks
<mvo> free: could you mail me the logs in /var/log/dist-ugprade/* and the /var/lib/dpkg/status file?
<mvo> please
<free> mvo: sure
<free> mvo: http://people.64studio.com/~free/hardy-to-lucid-logs.tar.gz
<RoAkSoAx> dholbach, Heya, No I haven
<mvo> free: works for me, maybe your mirror is a bit behind? there is some churn in the archive currently and it may just be not consistent (churn because of a new gnome)
<RoAkSoAx> dholbach, Heya, No I haven't recovered my data... it was weird cause in my trash fooldersers like with <deleted>.1 <deleted>.2.2 <deleted>.2.3 started to appear but after that... nothing that will indicated a bug and it is not reproducible
<RoAkSoAx> i filed one though
<free> mvo: yeah, it could be
<dholbach> RoAkSoAx: that's weird
<dholbach> RoAkSoAx: I hoped it was just that cdbs/nautilus bug
<free> mvo: shall I try with http://archive.ubuntu.com/ubuntu ?
<RoAkSoAx> dholbach, it is indeed.... I thought it was too but it ended up being something else... but as long as I cant reproduced I guess we'll never know
<mvo> free: yes, I think that makes sense, I run it now too and see whats going on, but it may just be a bad day today
<free> mvo: okay, thanks for looking
<mvo> free: the auot-upgraer-tester is now s running, I let you know
<RoAkSoAx> lamont, bug #533601
<ubottu> Launchpad bug 533601 in bind9 "Apport hook for bind9" [Wishlist,Triaged] https://launchpad.net/bugs/533601
<free> mvo: fine, fwiw I just re-tried against the official Ubuntu mirror, same problem
<pitti> kees: will the next linux kernel update fix this sign error? (http://www.kernel.org/)
<cjwatson> haha
<dholbach> pitti: Â¡âOOÏ´ Êâ¥â ZI
<pitti> but xkcd.com is just brilliant
<pitti> dholbach: Ê×ÇÊÄ±uÄ±ÉÇp
<pitti> ÊÄ± xÄ±É oÊ spÇÇu uos×noÉsÄ±É¹É¥É - Ænq xoÉÇÉ¹Ä±É É 'É¹ÇÉ¥ÊÉÉ¹ 'É¹o
 * dholbach sÉnÉ¥ Ä±Ì£ÊÊÄ±Ì£d
 * pitti ÊÉÉq noÊ sÆnÉ¥
 * dholbach sÊoÅ¿Ì£uÇ ÇÉÄ±Ì£Æ® É¹Çpun-uÊop
<james_w> stop it! you're adjusting my brain to that text, I won't be able to read normal text for the rest of the day
<pitti>  {Â¿ÊÉs ÇÉ¥ pÄ±p ÊÉÉ¥Ê } o o Ë
<dholbach> ;-)
 * dholbach shuts up
 * fagan thought it was empathy's fault
<nigelb> dholbach, how did you do that?
<dholbach> nigelb: http://www.xs4all.nl/~johnpc/uniud/uniud.html
<MacSlow> seb128, pitti, kenvandine: LP #546650 is fixed in lp:notify-osd/lucid you can either grab commit rev421 as a distro-patch or wait for the tarball of notify-osd 0.9.28 I'm about to roll.
<ubottu> Launchpad bug 546650 in notify-osd "Unable to click items below notifications" [High,In progress] https://launchpad.net/bugs/546650
<MacSlow> seb128, pitti, kenvandine: whatever you prefer
<seb128> MacSlow, did you fix the rhythmbox issue?
<pitti> MacSlow: thanks! we can just as well wait for the tarball; buildds are clogged anyway
<MacSlow> seb128, I looked into it and could not reproduce it... it's working perfect for me.
<seb128> MacSlow, oh come on
<seb128> MacSlow, just switch track between something having a cover and something not
<MacSlow> seb128, honestly... I tried the whole afternoon... never skipped/dropped a cover-art if one was defined
<seb128> MacSlow, the issue is when none is defined
<seb128> MacSlow, it still displays the previous one
<seb128> try playing a song with a cover
<seb128> do next
<mvo> free: hm, I can not reproduce it here in a chroot. how odd. I will try harder
<seb128> with the next song having no cover
<seb128> and you will get the bubble with the cover from the previous song displayed still
<free> mvo: could it be the particular set of packages installed on this vm?
<free> mvo: it's bare-bones hardy KVM image + landscape-client + ubuntu-desktop
<mvo> free: yes, that is very likely, I give it another try
<free> mvo: the landscape-client hardy package is the non official one from "deb http://landscape.canonical.com/packages/hardy/ ./", however the same problem happens if I remove it entirely, so maybe the issue is in one of its dependencies
<mvo> free: the logs say its having issues with libcamel1.2-14 and evolution. but I can not see right now what the problem is
<free> mvo: I see
<mvo> free: its odd, I use your status file, so it should give me the same error
<mvo> free: hold on a sec, I try something else
 * cody-somerville wonders why update-manager wants to remove update-notifier.
<mvo> cody-somerville: I bet a mismatch between -common and update-notiifer. some buildd lacking behind
 * cody-somerville nods.
<nigelb> kirkland, can I close the other tasks in bug 429443?
<ubottu> Launchpad bug 429443 in cpu-checker "/usr/bin/kvm-ok should be disassociated from kvm" [Medium,Fix committed] https://launchpad.net/bugs/429443
<ttx> slangasek: about bug 546874 -- should we target it to Lucid ? Do you plan to work on it or should someone else be assigned to it ?
<ubottu> Launchpad bug 546874 in samba "passwd - can't login, change password (pam_winbind pam-auth-update profile)" [High,Triaged] https://launchpad.net/bugs/546874
<slangasek> ttx: yes, please target it and assign mee
<ttx> slangasek: do you want it milestoned as well ?
<slangasek> I don't think I'll get to it for beta2
<ttx> ok
<slangasek> hmm, I missed the pam-auth-update call in the postinst too? :/
<slangasek> /that/ part I can fix
<ttx> slangasek: I couldn't see one, and when I reproduced the issue, installing winbind wouldn't update pam.d :)
<slangasek> yah, sorry
 * ttx would like to get rid of the wine -> winbind connection and let winbind in its niche market of skilled admins
<ttx> at least we would get polite bugs.
 * slangasek stares
<slangasek> yes, I think that should be considered a bug
<slangasek> I had no idea wine1.2 was pulling in winbind
<ttx> slangasek: that's the reason there are so many bugs against it
 * ScottK looks at YokoZar.
<ttx> slangasek: most people that run it don't care about it... however it appears to be needed by wine
<slangasek> ttx: I think that's clearly a wrong recommends and should be changed
<slangasek> I suspect it's there for nss_wins
<ttx> I remember talking to YokoZar about it in Barcelona... He confirmed he needed it
<zul> ditto
<ttx> but maybe some hackish package split would get what he needs without pulling the full monty in
<slangasek> ah, it's for ntlm_auth
<ttx> ah, that rings a bell, yes
<ccheney> slangasek: can you tell if xulrunner-dev got kicked out of main intentionally when it moved between source packages?
<zyga> sc
<zyga> hmm, focus stealing failed again
<slangasek> ccheney: I don't know who demoted it; it doesn't happen automatically, and shouldn't have happened if there were still reverse-deps
<seb128> wasn't that binary built by 2 sources?
<seb128> and the xulrunner-1.9.1 demoted or something
<seb128> which might have demoted the wrong binary too
<seb128> just guessing
<micahg> seb128: that could be it, that problem was fixed today with the 1.9.1.9 upload
<ccheney> slangasek: ok will ask around some more
<jibel> mvo, I pushed a slightly modified version of xapianSearch
<slangasek> ttx, ScottK, YokoZar: so I've reviewed the wine code and am convinced that this should be dropped to a Suggests or dropped altogether.  wine doesn't *require* ntlm_auth, it just *uses* it when available - but it doesn't do anything useful *unless you've configured your machine as a domain member*, so there's no point in having wine Recommend it at all
<mvo> jibel: nice, I have a look
<micahg> ccheney: we got the answer it seems
<ccheney> micahg: ok
<slangasek> YokoZar: "this" being the Recommends on winbind
<jibel> mvo, switched XP prefix to probabilistic, increased the weight of XP terms and lowered the qualitycutoff.
<jibel> mvo, results based on software-center test cases http://paste.ubuntu.com/407625/
<ScottK> slangasek: Sounds like 'Suggests'.
<mvo> jibel: woah, that looks impressive
<ttx> slangasek: that would sure cut the number of bugs filed against samba for the next 5 years. I'd estimate 20% of them are about people failing to upgrade winbind that never knew they had it in the first place
<ttx> (though that allowed to catch that pam profile issue, tbh :)
<slangasek> ScottK: I don't think it's even that; it's not "installing winbind enhances the behavior of wine", it's "if you've already configured your machine as a domain member, wine will integrate with that".  Suggests: winbind here is like like Suggests: NT domain authentication
<ScottK> Oh, OK.
<ttx> slangasek: yes, the fact that it plays nice with it shouldn't involve a package dep
<mvo> jibel: I'm not sure I mentioned this, but another idea I had was to have a set<RPackage*> in addtion to the current vector n the packageview to make the hasPackage() call quicker. the current way is a bit inefficient (not sure how much it matters, I have not measured it)
<jcastro> mvo: debian squid guy reminder!
<slangasek> a more bizarre string of nouns, I have never seen
<mvo> lalalala
<jibel> mvo, I quick test of patch attached to 251335 didn't show a lot of improvement but I need to test it harder.
<zyga> I just made a _screenshot_ of intel gfx corruption
<zyga> cool
<zyga> it's nice to finally attach some evidence to this bug
<FeasibilityStudy> what does it typically mean when building a package and get this error:
<FeasibilityStudy> cp: cannot stat `debian/tmp/usr/bin/': No such file or directory
<geser> that you are either missing a mkdir call (or if using dh_installdirs that "usr/bin is missing in debian/dirs)
<FeasibilityStudy> hmm ok
<FeasibilityStudy> I thought putting it in my debian/install file would work
<nigelb> didrocks, I was thinking of asking the user to close cheese instead of the kill call
<didrocks> nigelb: yeah, I'm not very keen on a killall in an apport hook :)
<nigelb> me neither.  Only the upstream dev asked if I could do it automatically instead of using a killall
<didrocks> nigelb: at least, you should look at the return code :)
<pitti> oh sweet, https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=1 shows package sets now
<Caesar> cjwatson: thanks!
<Caesar> slangasek: I do not
<ScottK> pitti: You can thank wgrant for that.
<apparle> can anyone help me with this bug https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/475466
<ubottu> Ubuntu bug 475466 in xserver-xorg-video-ati "[RC410] detects AGP on a PCIE card" [Undecided,Fix released]
<ScottK> apparle: You might try in #ubuntu-x
<bigon> an idea in which package is the gdm theme?
<kees> asac: oh, did the about:config fixes and font fixes not make this firefox upload?
<cr3> in a kvm guest, is there a way to distinguish a device defined as a disk from another device defined as a cdrom when both are defined using virtio?
<cr3> is the type of disk encoded somehow in the device minor number?
<nigelb> kees, are you on top of bug 532852?
<ubottu> Launchpad bug 532852 in policykit-1 "pkexec information disclosure vulnerability" [Low,Confirmed] https://launchpad.net/bugs/532852
<nigelb> (do you want a debdiff?)
<kees> nigelb: sure, that'd be helpful.  it's pretty low priority, so I was going to wait for the beta freeze to clear
<nigelb> kees, I'll get the debdiff in a few days, so you can get it in after beta freeze :)  you probably have more important bugs to fix :)
<kees> nigelb: cool, thanks!
<ccheney> what is the proper source package name to use for release note bugs?
<slangasek> ccheney: none, use the ubuntu-release-notes project
<ccheney> ah ok
<slangasek> doko_: what's the motivation for the dash rebuild-only upload?  It's already built once in lucid, was that done before the toolchain was in?
<doko_> slangasek: that's a lame try to rebuild on arm, seeing varies exit 139s from shell scripts on the buildds.
<slangasek> doko_: ah
<doko_> never could reproduce these locally
<Tm_T> I just hate these: https://edge.launchpad.net/builders/adare
<xnox> Quick go to www.kernel.org it got defaced
<slangasek> looks ok to me?
<ion> Yeah, itâs just fine.
<ScottK> Yeah, not sure what he's talking about.
<xnox> It's upside down?
<xnox> for me at least
<slangasek> may be a problem on your end?
<ion> Are you sure itâs not your monitor thatâs upside down?
 * xnox is uploading screenshot
<chrisccoulson> lol
<chrisccoulson> there is a button to turn it the right way up again ;)
 * xnox looks at the calendar =))))))))))))))
<chrisccoulson> yes ;)
 * xnox got pwand
<chrisccoulson> 1st april
<lucas> bdrung: what's the status of the manual-sync script?
<bdrung> lucas: i did not work on it.
<lucas> ok
<bdrung> lucas: i am waiting for ScottK to release his improvements
<bdrung> and for soyuz to support syncs
<ScottK> bdrung: I'm waiting on pitti to license his original to be distributable.  I can't distribute my update without that.
<bdrung> ScottK: i could write that script from pitti from scratch
<ScottK> Funny.  Now that I diff it, I have a two line diff.
<bdrung> ScottK: two lines?
<ScottK> bdrung: http://paste.debian.net/67039/
<ScottK> I recalled it being more.
<ScottK> It does fix a key issue with some of our .changes files.
<ScottK> You'd also want to add some kind of a -n option for syncing a new package.
<bdrung> ScottK: yes and to provide a library (for our ack-sync script)
<ScottK> OK, so no longer road blocked on me.
<bdrung> ScottK: can you have a look at bug #516249?
<ubottu> Launchpad bug 516249 in hdparm "Please merge hdparm 9.27-2 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/516249
<ScottK> Not right now, no
<rickspencer3> mvo, do you want me to do $update-manager -d to test a karmic -> Lucid upgrade on my daughter's 'puter?
<mvo> rickspencer3: yeah, go ahead please and mail me the logs afterwards (regardless if it works or fails), both is useful infromatoin
<mvo> rickspencer3: I will be offline soonish to hit my bed, but I check mail tomorrow
<rickspencer3> mvo, to avoid any doubt, what specific log?
<mvo> rickspencer3: there seems to be a bit of a plague currently with it failing to calculate the upgrade, if it shows that, there is no harm, it will revert cleanly and write logs into /var/log/dist-upgrade/
<mvo> rickspencer3: /var/log/dist-upgrade/*
<rickspencer3> mvo will do
<mvo> thanks!
<rickspencer3> mvo, you are on holiday until Tuesday, right?
<rickspencer3> enjoy!!
<mvo> yes
<mvo> I will :)
<seb128> slangasek, hey
<slangasek> seb128: hi
<seb128> slangasek, I uploaded light-themes twice, could you accept the new one
<seb128> or rather make sure you review this one
<slangasek> yep - I'll reject the old one now
<seb128> thanks
<seb128> slangasek, should I try to convince you what to accept still or will you still be open with reasonable changes in the current queue?
<seb128> ie things like theme updates
<slangasek> seb128: theme updates> of the kind that break the UI freeze?
<seb128> slangasek, weeeell, it has been decided to change the wm button order for example
<slangasek> I see a lot of icon updates in the queue, and no UIFe trail for these; that's a problem for the docs team
<seb128> slangasek, that too
<slangasek> seb128: oh, argh
<seb128> slangasek, well you guess where the request come from there
<seb128> anyway I did sponsor those so I did my job
<seb128> I will let you do yours ;-)
<ccheney> slangasek: just uploaded openoffice.org 1:3.2.0-4ubuntu3 which resolves the ure warning issue and the splash screen update
<kusum> cjwatson: Could you guide me to a wiki of partman-auto-loop
<slangasek> ccheney: ok, thanks
<Caesar> https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/532633/comments/564
<ubottu> Ubuntu bug 532633 in metacity "[Master] Window Control buttons: position/order/alignment" [Undecided,Confirmed]
<seb128> 564 comments
<seb128> crazy
<chrisccoulson> i don't even dare to click on the link ;)
<chrisccoulson> it will probably take the rest of the evening to open
<cjwatson> kusum: there isn't one
<highvoltage> seb128: heh, I just posted #571, but in my defence it's the first post on that bug and I've been subscribed since before #100
<kusum> can i take lupin's information to be almost similar to it
<cjwatson> kusum: err - they're different components
<kusum> what exactly does it do ?
<kusum> I think i am in a mess here
<cjwatson> why not download the source and look at it? :)
<cjwatson> Package: partman-auto-loop
<cjwatson> Description: Automatically partition using a loop device
<kusum> hehe ok
<kusum> Thank you
<kusum> cjwatson: last question before i run to the code
<kusum> partman runs on wubi side or ubuntu side?
<cjwatson> kusum: Ubuntu side
<rickspencer3> slangasek - do you want someone from the design team to file freeze exceptions and such?
<slangasek> rickspencer3: yes, please - and critically, to notify the docs team
<rickspencer3> I'll try
<kwwii> slangasek: ping?
<ccheney> should packages that are in dapper but non-server still say 'supported' on launchpad?
<wgrant> ccheney: Launchpad has no idea about support timeframes.
<ccheney> wgrant: ah ok
<slangasek> kwwii: hi
<kwwii> slangasek: see my pm, or I can repost it here
<chrisccoulson> slangasek - i've got a beta-2 bug assigned to me for applying the cairo lcd filter patch to firefox to fix the font rendering issue
<chrisccoulson> whats the cut-off date for me to get this in?
<snow_ru> ok
<snow_ru> f
<slangasek> chrisccoulson: should be done before the weekend to leave time for building
<chrisccoulson> slangasek - ok, i will get that done tomorrow then
<chrisccoulson> thanks
<slangasek> chrisccoulson: thank you!
<chrisccoulson> micahg ^^^
<slangasek> chrisccoulson: it was mentioned at a previous release meeting that there might be problems with the actual patch available at that time - has this been resolved?
<chrisccoulson> slangasek, yeah, thats been resolved thanks to mdeslaur
<slangasek> ok, great
<chrisccoulson> the patch is working quite nicely :)
#ubuntu-devel 2010-04-02
<jasonb> Hello.  I have some questions about the Canonical partner repository (just that repository).  I'm wondering what the new package acceptance process is, and what the acceptance criteria are.  So far I have not found any web pages about this.
<asac> kees: please check with chrisccoulson .... if it involves patches we need to talk to upstream as usual. if there is something serious let me know
<lamont> there.  gtk+2.0 now building on one of the new-n-good armel buildds
<lifeless> \o/
<kees> pitti: what do you think of a nautilus work-around for bug 543617 ?  (or in umount itself...)
<ubottu> Launchpad bug 543617 in linux "very slow filesystem I/O" [High,In progress] https://launchpad.net/bugs/543617
<RoAkSoAx> lamont, any word on bug #533601
<ubottu> Launchpad bug 533601 in bind9 "Apport hook for bind9" [Wishlist,Triaged] https://launchpad.net/bugs/533601
<seyacat> Hi ubuntu devel
<seyacat> what is the name of package of text mode ubuntu installer? like ubiquity but in text mode
<arand> seyacat: debian-installer, I would assume.
<kees> pitti: cups> debian 572940 is about CVE-2010-0302, not CVE-2010-0393.
<ubottu> Debian bug 572940 in cups "CVE-2010-0302: Incomplete security fix" [Important,Fixed] http://bugs.debian.org/572940
<ubottu> Use-after-free vulnerability in the abstract file-descriptor handling interface in the cupsdDoSelect function in scheduler/select.c in the scheduler in cupsd in CUPS 1.3.7, 1.3.9, 1.3.10, and 1.4.1, when kqueue or epoll is used, allows remote attackers to cause a denial of service (daemon crash or hang) via a client disconnection during listing of a large number of print jobs, related to improperly maintaining a reference count.  NOTE: some of thes
<ubottu> The _cupsGetlang function, as used by lppasswd.c in lppasswd in CUPS 1.2.2, 1.3.7, 1.3.9, and 1.4.1, relies on an environment variable to determine the file that provides localized message strings, which allows local users to gain privileges via a file that contains crafted localization data with format string specifiers. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0393)
<NinoScript> Hi! the other day, I updated Lucid, and a udev file in which I loaded an experimental driver for multitouch trackpads, changed and I am not able to load that driver again
<NinoScript> the file is "/lib/udev/rules.d/66-xorg-synaptics.rules", the line I used was: ENV{x11_driver}="multitouch"
<ScottK> NinoScript: Help for Lucid is in #ubuntu+1
<NinoScript> ScottK: I asked there yesterday and the day before, but nobody knew (and I'm asking again, now)â¦ as it has more to do with the actual development of the driver, I thought I could ask here :P
<ScottK> You might ask in #ubuntu-x
<NinoScript> Ok, that's useful, thanks! :D
 * kirkland just gives up and assigns all of his bugs to pitti :-)
<nbreen> I maintain a Debian package, grace, that fixed an annoying UI bug (can trap the cursor, have to kill from console; #567323, LP 552681) in the most recent Debian upload.  Any way I can nudge that past the freeze?
<ubottu> Launchpad bug 552681 in grace "Mouse cursor trapped with right-click in menu, lose input control" [Undecided,New] https://launchpad.net/bugs/552681
<nbreen> (Apologies if I overlooked some documentation; my ubuntu-fu is weak, I only found the freeze exception instructions for new *upstream* versions, which this is not.)
<ScottK> nbreen: That's because bug fix updates don't need a freeze exception.  You can request a sync using the requestcync script in ubuntu-dev-tools (which is in Debian now).
<nbreen> Will do, thanks for the pointer.
<apparle> what are the -dbg for?
<apparle> how to use the xserver-xorg-video-ati-dbg package to check the internals of the driver
<jackz> when will 10.04.1 be released normally?
<pitti> ScottK: oh, I wasn't aware that you are blocking on me for the sync script; please add an appropriate license header, I'm really not legally attached to it at all :)
<pitti> kirkland: give up? when you are always constantly beating me? :-)
<fta> tseliot, fyi, jokey failed on a fresh install of lucid while installing nvidia-current: http://paste.ubuntu.com/408038/  i had to do it manually
 * tseliot has a look
<tseliot> fta: well, it's more correct to say that jockey interpreted a warning as an error and claimed to have failed
<fta> tseliot, yep, but after a restart of X, it failed, the kernel module wasn't there
<tseliot> fta: are you sure about that? the log says that the module was built and installed. Maybe it didn't set the correct alternative. Either way a reboot is required
<fta> i had to --reinstall nvidia-current and reboot (as restart kept on using nouveau, probably due to DKMS
<tseliot> fta: the problem is that nouveau was preventing nvidia from being loaded
<tseliot> updating  the initramfs would have been enough
<fta> tseliot, maybe. it's not a problem for me, i quickly managed to sort this out, but i assume lots of people will face this
<tseliot> pitti: logging.error(err) in oslib.py (line 248) shouldn't cause jockey to fail, right? Is there anything else that could be causing this?
<tseliot> fta: I think we have a bug report about it and it's definitely something I'll have to fix
<fta> ok, good
<tseliot> fta: I think it's bug #552653
<ubottu> Launchpad bug 552653 in jockey "[Lucid] Jockey fails to install nvidia hardware driver" [Medium,Triaged] https://launchpad.net/bugs/552653
<fta> tseliot, yep, that's it
<tseliot> ok
<fta> tseliot, btw, why isn't libvdpau1 a dep of nvidia-current?
<tseliot> fta: programs that use vdpau should have it as a dependency. It's not really specific to nvidia
<fta> i thought vdpau was nvidia specific..
<lifeless> no
<lifeless> other implementations exist now
<tseliot> the nvidia specific bits are in nvidia-current
<fta> ok :)
<Cheery> hi
<Cheery> while ago I started to wonder.
<Cheery> why does ubuntu have duplicate keyboard layouts?
<Cheery> ones for xorg and others for terminal
<cjwatson> it doesn't
<cjwatson> the terminal layouts are automatically generated from the X layouts, and have been for over three years
<cjwatson> any differences are simply because the Linux console's support for some things isn't quite as rich as X's
<Cheery> so you already generate terminal layouts from X layouts.
<Cheery> what prevents from using X layouts in terminal directly?
<cjwatson> different file formats
<cjwatson> why bother doing all the work to make the kernel support XKB, when we can just as well convert things on the fly in userspace?
<cjwatson> some things are better done outside the kernel
<cjwatson> and, honestly, what difference does it make?
<Cheery> some apps ignore the X layouts.
<Cheery> and switching layout from X doesn't switch the layout kernel is using
<cjwatson> um.  what do applications have to do with it?  keyboard layouts are at a lower level
<cjwatson> 'dpkg-reconfigure console-setup' changes both of them system-wide
<ScottK> Would a buildd admin please rescore qscintilla2 and kde4libs.  The fact that they are lagging on ports is going to cause a number of other problems.
<cjwatson> it's intentional that it's possible to have a different per-user layout - it's entirely possible on multi-user systems that different users might prefer different layouts
<Cheery> aah. yet per-user layouts.
<cjwatson> ScottK: done (insofar as it'll make much difference on ia64 :-/)
<ScottK> cjwatson: thanks.
<Cheery> cjwatson: though X is ancient, how come it has 'better' keyboard layout stuff than kernel?
<cjwatson> XKB is not all that ancient; it's of approximately the same vintage as the kernel's keyboard layout handling, possibly even a little later
<Cheery> likely older than unicode as well, right?
<cjwatson> and one might expect XKB to support a wider variety of layouts, given that there are some complex scripts the kernel can't cope with displaying on the console
<cjwatson> Cheery: incorrect
<cjwatson> both XKB and the Linux kernel's keyboard layout support date from the early-to-mid-1990s, after Unicode started
<cjwatson> first version of the Unicode standard was 1991, predating both of them
<cjwatson> but I'm going out so I'm afraid you'll have to do the rest of the research yourself :-)
<Cheery> cjwatson: thank you anyway. it was fun and interesting topic.
<primes2h> tseliot: Hello, I reported a bug about plymouth bug #553954
<ubottu> Launchpad bug 553954 in plymouth "[Lucid Beta 1] plymouth has a non translatable string coming up on screen" [Undecided,New] https://launchpad.net/bugs/553954
<primes2h> tseliot: you wrote that script, didn't you? :-)
<primes2h> Is bug description correct?
 * tseliot has a look
<tseliot> primes2h: yes, it's correct. Plymouth isn't localised. Is mountall localised?
<primes2h> tseliot: it has just been fixed bug 390740
<ubottu> Launchpad bug 390740 in mountall ""Routine check of drives"message is not localized" [Low,Fix released] https://launchpad.net/bugs/390740
<primes2h> tseliot: what do you think about the bug?
<tseliot> primes2h: each plymouth theme e.g. the one for ubuntu, kubuntu, etc. will have to be modified so as to allow localisation
<ScottK> Sounds like step on is a bug on the relevant packages then
<primes2h> tseliot: it would be better to put that string in an outer package, wouldn't it?
<primes2h> like all others
<tseliot> primes2h: I'm not really sure about how we should do this. I'll think about it
<primes2h> tseliot: Ok, thank you. :-) unfortunately it's a annoying bug because the string is very visible (and quite big)
<tseliot> I know, I'll see what I can do
<primes2h> ScottK: what do you mean? are you talking about this bug?
<primes2h> bug #553954
<ubottu> Launchpad bug 553954 in plymouth "[Lucid Beta 1] plymouth has a non translatable string coming up on screen" [Undecided,New] https://launchpad.net/bugs/553954
<ScottK> Yes.
<ScottK> If each plymouth theme needs updatiing, then there ought to be a bug against each one
<primes2h> ScottK: Sure, or take the string out to another common package, like others.
<cody-somerville> Why is Ubuntu's plymouth theme seeded in standard?
<ari-tczew> please sponsor bug 421684
<ubottu> Launchpad bug 421684 in obexd "[SRU] bluetooth send malformed files" [Undecided,Confirmed] https://launchpad.net/bugs/421684
<bdrung> ari-tczew: k
<bdrung> ari-tczew: done
<kirkland> pitti: around?
<souffledev> https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/513745
<ubottu> Ubuntu bug 513745 in chromium-browser "pdf documents (probably other mimetypes too) not opened by chromium-browser" [Undecided,Confirmed]
<souffledev> that's my problem. anyone? :)
<souffledev> damnit :/
<kirkland> nice, "maverick", i dig it!
<kirkland> http://www.markshuttleworth.com/archives/336
<LaserJock> kirkland: although I have a hard time imagining a maverick meerkat
<LaserJock> they seem almost borg-like on TV
<LaserJock> warm and fuzzy borg, but still :-)
<mdeslaur> Since my last dist-upgrade, plymouth now displays in text mode even though I have kms on my thinkpad T30
<mdeslaur> how would I go about figuring out why?
<slangasek> mdeslaur: are you missing the plymouth-theme-ubuntu-logo package?
<slangasek> mdeslaur: themes were split out to a) discourage users from selecting themes that don't play well with mountall, b) let server team drop the graphical splash they don't want; ubuntu-standard currently Recommends: -theme-ubuntu-logo
<mdeslaur> slangasek: let me check, hold on a sec
<mdeslaur> slangasek: it's installed
<mdeslaur> oh, I think I'm getting a kernel oops
<mdeslaur> does plymouth fall back if there was en error?
<slangasek> oh, splendid
<slangasek> if it's an error it's able to catch, yes
<mdeslaur> ok, let me investigate a bit
<LaserJock> I noticed I've got a fair amount of boot funkiness after the last kernel
<mdeslaur> yeah, I've got a kernel oops from an updated thinkpad bios warning...so I guess plymouth is falling back to display the error
<jdstrand> slangasek: heh, I see the text mode on my T42 too. I don't have an 'WARNING's in my dmesg
<jdstrand> s/heh/hey/
<jdstrand> slangasek: I have plymouth-theme-ubuntu-logo installed
<slangasek> jdstrand: the only time text mode is ever used is if you 1) boot without 'splash' (and then it's the 'details' plugin), 2) plymouth can't find a working drm or fb interface, 3) you don't have graphical themes installed/configured
<jdstrand> slangasek: well, this is a fresh install from yesterday's daily. 1) [    0.000000] Kernel command line: ... quiet splash. 2) radeon/kms/compiz is working now with 19.28, so I drm is ok (at least for X) '[drm] radeon kernel modesetting enabled' 3) plymouth-theme-ubuntu-logo, plymouth-theme-ubuntu-text are installed
<mdeslaur> slangasek: so, I have "splash"...my /proc/fb contains "0 radeondrmfb"
<jdstrand> slangasek: I am unfamiliar with the 'details plugin'
<mdeslaur> slangasek: how do I know if the graphical themes are configured?
<jdstrand> $ cat /proc/fb
<jdstrand> 0 radeondrmfb
<jdstrand> mdeslaur: does it feel to you like we are ganging up on slangasek?
<hyperair> hmm, maverick meerkat?
<slangasek> jdstrand: the details plugin is the plymouth plugin that shows all the console text, in addition to any prompts that it needs for interaction
<slangasek> mdeslaur: ls -l /etc/alternatives/default.plymouth
<mdeslaur> jdstrand: yes, but I'm guessing he's gotten used to it by now
<slangasek> jdstrand: what precisely do you see at boot time?
<slangasek> jdstrand: do you see the "Ubuntu 10.04" text + *s below?
<jdstrand> /etc/alternatives/default.plymouth -> /lib/plymouth/themes/ubuntu-logo/ubuntu-logo.plymouth
<mdeslaur> slangasek: that points to /lib/plymouth/themes/ubuntu-logo/ubuntu-logo.plymouth for me as well
 * slangasek nods
<jdstrand> slangasek: yes, but they seem like throbbing dots more than '*'s
<jdstrand> (they are teeny though, so maybe I am blind-- I didn't get much sleep last night ;)
<slangasek> close enough, we'll attribute the difference to my fallible memory :)
<jdstrand> slangasek: does it help if when I see you name in irc all I see are stars?
<slangasek> jdstrand, mdeslaur: is cryptsetup installed on these systems?
<slangasek> heh
<jdstrand> that *may* be unrelated
<jdstrand> slangasek: not here, I am currently just using ecryptfs on this laptop
<mdeslaur> slangasek: no cryptsetup...I'm not using any of that security crack :)
<jdstrand> slangasek: I *do* see other text at the bottom of the screen, and it's line breaks aren't right (familiar stair-stepping), but they fade to almost gone just before gdm comes up
<jdstrand> s/it's/its/
<slangasek> jdstrand, mdeslaur: please try running: echo FRAMEBUFFER=y | sudo tee /etc/initramfs-tools/conf.d/plymouth  && sudo update-initramfs -u, and tell me if the behavior changes
<jdstrand> I hate security. It's *always* in the way :P
<slangasek> hmm. what version of plymouth, and what version of plymouth-theme-ubuntu-logo, do you have installed?
<jdstrand> slangasek: 0.8.1-3 for all
<slangasek> ok
 * jdstrand reboots laptop
<mdeslaur> I've got 0.8.1-4 for all
<jdstrand> slangasek: no effect. shall I upgrade and try again?
<mdeslaur> slangasek: no effect for me either, still text mode
<slangasek> don't see that an upgrade would help
<slangasek> is this with the -19 kernel?
<jdstrand> 19.28, yes
<jdstrand> $ cat /proc/version_signature
<jdstrand> Ubuntu 2.6.32-19.28-generic 2.6.32.10+drm33.1
 * mdeslaur kicks plymouth in the face
<slangasek> do you see the same problem if you boot an earlier kernel?
<slangasek> I suspect radeondrm regressions
<jdstrand> slangasek: is -18 early enough? (probably)
<slangasek> maybe?  I don't know, I don't have radeon here to compare with
<jdstrand> 19 had the drm radeon fixes for us
 * jdstrand tries
<LaserJock> this is where you go straight from grub to gdm without getting the boot splash?
<jdstrand> LaserJock: no logo, but have some ascii
<mdeslaur> slangasek: with -17 kernel, I still have text mode plymouth
<jdstrand> slangasek: -18 too
<jdstrand> (unsurprisingly)
<LaserJock> I got something like that with -intel but only recently
<mdeslaur> -16 gets text mode also...
<jdstrand> slangasek: I know it did work for me a couple of weeks ago, but I can't be more specific-- like I said, I reinstalled yesterday
<jdstrand> LaserJock: yeah, this is recent here too
<LaserJock> mine flickers a few times like it's trying
<LaserJock> but I end up with text stuff -> gdm
<jdstrand> slangasek: fyi, the installer is the same-- text after the first (what I assume to be non-plymouth) bit
<slangasek> LaserJock: the question is, what text stuff?  The bug they're having is that they see 'Ubuntu 10.04' in text when they should see the graphical splash; there are also known cases where the splash just never gets around to getting started before X starts
<LaserJock> slangasek: ah, ok, that's what I was trying to figure out. Mine is the latter
<slangasek> LaserJock: known bug, won't be fixed for lucid because the fix available in that timeframe is at odds with boot performance goals
<LaserJock> I see
<LaserJock> one of those "if we boot fast enough people won't notice" :-)
<jcastro> LaserJock: you're too fast for plymouth dude
<LaserJock> jcastro: the problem is booting keeps getting slower :(
<LaserJock> earlier in Lucid it wasn't noticable much, but now it's taking a bit more time and I start to wonder if something happened
<slangasek> for maverick, we'll tell *grub* to put up the splash, and if plymouth doesn't start before X, no big loss
<ScottK> Maverick is going to take me a while.  I keep seeing Tom Cruise flying jets.
<elmo> hahaha
<LaserJock> ScottK: I keep thinking John McCain
<LaserJock> at least it wasn't Rogue ;-)
<james_w> with a silent M?
<ScottK> I'm also old enough to remember the TV show with James Garner.
<LaserJock> ScottK: oh heck yeah
<LaserJock> one of the best ever
<slangasek> james_w: oh, is that how you pronounce 'mbrola'?
<ScottK> Yep.
<mdeslaur> ScottK: because of you, I now have "Danger Zone" stuck in my head
<ScottK> \o/
<LaserJock> mdeslaur: thanks :/
<mdeslaur> LaserJock: welcome :)
<jcastro> mdeslaur: Is that why you fly the way you do? Trying to prove something?
<mneptok> ICEMAN, CHECK SIX!
<mdeslaur> jcastro: What's your problem, Kazanski?
 * ScottK notes: productivity destruction goal for today met.
<jcastro> heh, it's friday.
<mneptok> mdeslaur: http://bit.ly/iQYS
<mdeslaur> lol
 * mneptok invents a new Ubuntu Community rickroll
<jdstrand> mdeslaur, slangasek: is there a bug on the radeon/text boot issue?
<mdeslaur> jdstrand: not yet (from me)
<jdstrand> I don't see a reference in backscroll...
<mdeslaur> jdstrand: I was attempting to downgrade plymouth to see where it started
<mdeslaur> jdstrand: not a good idea, btw :)
<jdstrand> mdeslaur: heh, I was just going to say 'good idea' :P
<mdeslaur> jdstrand: newer mountall dies with older plymouth, so be warned :)
<jdstrand> mdeslaur: I'm not looking at it atm
<jdstrand> mdeslaur: so go with God
<jdstrand> :)
<jdstrand> of course, I'll complain if it isn't fixed, so don't worry about my feedback ;)
<mdeslaur> jdstrand: would you mind opening the bug? my laptop is unbootable to do the ubuntu-bug
<jdstrand> mdeslaur: sure
<jdstrand> mdeslaur, slangasek: fyi file bug #554143
<ubottu> Launchpad bug 554143 in plymouth "text logo theme used instead of graphical with radeon 7500" [Undecided,New] https://launchpad.net/bugs/554143
<nigelbabu> james_w, hey got a minute for jcastro and me?
<mdeslaur> jdstrand: thanks, I just confirmed it
<jdstrand> s/file/filed/
<jdstrand> thanks
<Sarvatt> jdstrand: I had a similar issue with the text theme showing always on a native res inteldrmfb  in the past week and removing all of the extra themes and just reinstalling those two fixed it
<mdeslaur> Sarvatt: which ones are "those two"?
<mdeslaur> Sarvatt: plymouth-theme-ubuntu-logo and plymouth-theme-ubuntu-text?
<jdstrand> Sarvatt: which extra themes? I've got plymouth-theme-ubuntu-logo and plymouth-theme-ubuntu-text. are there others I should be looking for, or are you suggesting I remove plymouth-theme-ubuntu-text?
<Sarvatt> yep
<jdstrand> Sarvatt: nm, I see the others, but the are already not installed
<Sarvatt> in response to mdeslaur that is, I had solar and spinfinity installed as well and all I did was remove all of the themes and just install those two again and it was fixed afterwards
<jdstrand> I could try to reinstall...
<Sarvatt> it only happened when I packed plymouth in the initrd though so it might not be related :D
<jdstrand> yeah, I already tried to update the initramfs
<akk> I'm getting error messages in lucid from /etc/acpi/sleep.sh, missing files in /var/lib/acpi-support.
<akk> In karmic those files were part of the acpi-support package, but they aren't in lucid any more (e.g. /var/lib/acpi-support/system-manufacturer)
<akk> I'm having trouble figuring out what script is looking for those files.
<jdstrand> Sarvatt: didn't work
<Sarvatt> do you see the text renderer over vgacon for a split second before the screen changes resolution and then it's offset in the drmfb as well?
<jdstrand> I see the underscore flash a few times before the text mode changes. there are 3 distinct flickers, then I see the underscore flash again (still unchanged), then text mode plymouth kicks in
<Caesar> Hmm, is it too late to be trying to get a new debmirror into Lucid?
<Caesar> I note that what's currently there predates all of the new work done to it
<jdstrand> Caesar: you might want to talk to kees since he has been doing the bulk of the work for ubuntu (and I believe upstreamed almost all of it to Debian)
<Caesar> jdstrand: thanks, kees, you around?
<james_w> nigelbabu: of course
<nigelbabu> jcastro, looks likes james is around after all :D
<jcastro> james_w: we want to start scheduling patch days, where we collect people to look at pending patches in lp.
<jcastro> james_w: when in the cycle do people generally start doing merges?
<jcastro> james_w: we'd like to time it around that time
<nigelbabu> right now, the date I've come up with in wed, may 5th
<nigelbabu> (the day before toolchain release)
<james_w> jcastro: pretty much as soon as lucid releases
<james_w> it ramps up from when the archive opens
<nigelbabu> archive opens on 6th right?
<james_w> haven't looked
<james_w> sounds about right
<james_w> it's never an exact date, but it's pretty quick
<nigelbabu> the next thu after release day ...
<cjwatson> it's not that rigid
<cjwatson> it's whenever we can get enough of the stuff on NewReleaseCycleProcess done
<cjwatson> don't believe the release schedule pages on this, they're just a guideline/target this early
<jcastro> cjwatson: yeah we just want to do it around the general time
<nigelbabu> jcastro, but we dont want the archive open if you ask me
<cjwatson> right, I'm just trying to help nigelbabu understand that it isn't a fixed thing
<jcastro> ok
<nigelbabu> cjwatson, I understand... now :)
<nigelbabu> anyway, our first priority would be to send those patches upstream so they can integrate in
<nigelbabu> and we can either just backport from the git or just get the new release some time later in the release cycle
<nigelbabu> jcastro, so 5th sounds good enough or you want to move it?
<nigelbabu> I was hoping to have something done before lucid, so we can brainstorm on either we're we need to change exiting workflow during lucid
<ccheney> what was the default version of kde in hardy?
<kees> Caesar: hi! yeah, it's behind.
<kees> Caesar: upstream didn't take any of the rsync work I did, unfortunately.
<kees> Caesar: was there a specific feature you needed from the more recent version?
<kees> Caesar: this what needs merging: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455082
<ubottu> Debian bug 455082 in debmirror "enable more efficient batching" [Normal,Open]
<nigelbabu> bryceh, might want to take a look at http://pastebin.ubuntu.com/408255/
<Caesar> kees: my concerns are that there was a lot of upstream work done last year, and none of that is going to be in Lucid
<Caesar> In particular what I'm interested in is the ability to mirror the installer
<kees> Caesar: I welcome a merge :)
<ion> tjaalton: Yay for the backported InputClass stuff. :-)
<Caesar> kees: I just wonder what's better, an already 3 year old debmirror, or a newer one sans your batching changes
<ion> My xorg.conf with Wacom calibration. http://gist.github.com/353570
<Caesar> It sounds like merging is going to be difficult (but I haven't looked yet)
<kees> Caesar: the main issue is that the batching merge isn't easy.  the rest of the fixes I already broke out (though upstream seems to be ignoring) in that above debian bug
<kees> Caesar: I haven't had time to get the rsync batching done, but I'd love it if someone could help.
<bryceh> nigelbabu, ok what am I seeing?
<kees> Caesar: the basic issue is: don't fetch one file at a time with rsync.  :)
<nigelbabu> bryceh, list of packages with patches attached
<nigelbabu> the number is the total of open bugs with patches per package
<Caesar> kees: I'll see what I can do
<bryceh> nigelbabu, ok, interesting
<nigelbabu> bryceh, jcastro just got the good folks in #launchpad generate it
<kees> Caesar: if I didn't have a stack of other work, I'd commit to spending time on it, but that seems unlikely at this point.  :P
<bryceh> nigelbabu, fwiw the list of patches I'm working through is at http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/patches.html
<Caesar> kees: Yeah yeah, join the club :-)
<bryceh> nigelbabu, it's nicely been growing shorter and shorter :-)
<nigelbabu> bryceh, oh great.  thats one team on top of their patches
<kees> Caesar: heh :)
<nigelbabu> bryceh, so we'll just skip the X bugs in review queue
<bryceh> nigelbabu, strangely, it shows more patches than https://edge.launchpad.net/~ubuntu-x-swat/+patches does, but I think deryck has been looking into that
<bryceh> nigelbabu, yeah the reason xserver-xorg-video-openchrome is at the top of the list is because upstream posts patches to our launchpad queue for folks to test
<nigelbabu> bryceh, thats nice :)
<nigelbabu> bryceh, I like https://edge.launchpad.net/~ubuntu-reviewers/+patches
<bryceh> I found that it's not the case that they want those patches *in* ubuntu, they just want users to test them, then they can decide to include them upstream and we get them next time we sync
<nigelbabu> they're using as lab rats? :D
<bryceh> so a totally different patch workflow than everything else.  But it works for them I gather
<jcastro> that's pretty handy though
<bryceh> nigelbabu, that does look nice
<nigelbabu> its the new code I guess since I see that only in edge
<slangasek> jdstrand, mdeslaur: may be useful to boot with 'plymouth:debug=file:/var/log/plymouth-debug.log' and grab that log file (if plymouth succeeds in outputting it)
<mdeslaur> slangasek: thanks, will try once laptop is reinstalled
 * jdstrand will try now
<mdeslaur> jdstrand: argh, you're always one step ahead :)
<jdstrand> mdeslaur: heh, will you stepped 'ahead' of me by downgrading plymouth
 * bjf is taking a break, my dad just walked in
<jdstrand> slangasek: the text theme did not display with that invocation. is that expected?
<jdstrand> this may be it:
<jdstrand> ply_open_module:Could not load module "/lib/plymouth/renderers/x11.so": /lib/plymouth/renderers/x11.so: cannot open shared object file: No such file or directory
<jdstrand> slangasek: ^
<slangasek> jdstrand: unless you're setting 'export DISPLAY=:0.0' in your initramfs, that shouldn't matter :)
<slangasek> jdstrand: you could try installing plymouth-x11 though, just to see what changes
<slangasek> but - the text theme didn't display? what did you get instead, just text output?
<jdstrand> slangasek: I got what looks like the output of the plymouth debug log. like it tee'd
<jdstrand> slangasek: I have the debug log, shall I paste or attach to bug?
<slangasek> jdstrand: attach to bug plz
<jdstrand> slangasek: fwiw, plymouth-x11 is already installed
<slangasek> jdstrand: oh, well, hum
<slangasek> jdstrand: do you have /usr on a separate partition?
<jdstrand> slangasek: nope. / and /home
<slangasek> do you still have the FRAMEBUFFER=y line in /etc/initramfs-tools ?
<jdstrand> $ cat /etc/initramfs-tools/conf.d/plymouth
<jdstrand> FRAMEBUFFER=y
<slangasek> yeah; so plymouth is in the initramfs, and we don't ever copy x11.so over
<slangasek> 'cause if you've got an X server in your initramfs, yer doin it rong
<jdstrand> slangasek: log added to bug
<slangasek> ta
<slangasek> mdeslaur: what's your radeon chip?
<slangasek> I'm inclined to believe this is chip-specific, given that we've got a number of positive radeon tests from beta1
<mdeslaur> slangasek: same, but 16mb
<mdeslaur> slangasek: it used to work :(
<jdstrand> yeah, it was workign when manoj gave it back to me, so that was packages from a couple weeks ago and a -17 with backported drm that he added (but mdeslaur demonstrated it is not kernel specific)
<Sarvatt> actually, the drm renderer for plymouth wont work with a 8bpp framebuffer anyway will it?
<Sarvatt> radeon uses a lower color one for cards with <=16MB ram
<slangasek> jdstrand, mdeslaur: [./plugin.c]                                  query_device:Visual is FB_VISUAL_PSEUDOCOLOR; not using graphics
<slangasek> kernel done you wrong
<mdeslaur> slangasek: what's the difference between the drm.so renderer and the frame-buffer.so renderer?
<Sarvatt> the framebuffer uses up a big chunk of the video ram always and its alot bigger if its the normal 24bpp mode, the alternative is not having enough video ram to do just about anything on the desktop if you want a pretty splash just for the few seconds during boot
<slangasek> mdeslaur: one uses libdrm, the other uses /dev/fb0
<mdeslaur> slangasek: so how come it's failing with drm.so, shouldn't that work?
<slangasek> mdeslaur: the drm renderer is only used when you have more than one video output
<slangasek> mdeslaur: plug in an external monitor and see if it works? :)
<mdeslaur> ah, ok
<Sarvatt> ^on nouveau and ati, intel doesnt have that limitation
<slangasek> right
<mdeslaur> hmm...I wonder what changed
<Sarvatt> i think it was the -16 kernel that brought in the change to where drmfb's for low memory radeon GPU's use a lower color mode
<Sarvatt> can't you bump the video ram in your bios?
<Sarvatt> (or is it not integrated) sorry don't know which gpu you have
<mdeslaur> radeon 7500
<mdeslaur> okay, if it's because of low video memory, I guess we'll live with it
<Sarvatt> whats the pci id?
<mdeslaur> Sarvatt: 1002:4c57
<mdeslaur> jdstrand: what's your pci id?
<Sarvatt> ah not an IGP then :(
<mdeslaur> nope
<mdeslaur> ah, jdstrand's has the same pci id, but he has 32mb
<Sarvatt>         /* select 8 bpp console on RN50 or 16MB cards */
<Sarvatt>         if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (32*1024*1024))
<Sarvatt>                 bpp_sel = 8;
<Sarvatt> is it me or is that comment wrong and its using 8bpp for 32mb too? :D
<Sarvatt> ah yep http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=47381156a8f0d793bacfa346cc4cc515399525f7
<mdeslaur> yeah, the comment is wrong :)
<mdeslaur> so <=32 Mb
<mdeslaur> Thanks Sarvatt for the info, I've updated the bug
<mdeslaur> so, it's not really an issue
<slangasek> mdeslaur: it's not a release-critical issue, but this is clearly a suboptimal outcome
<mdeslaur> yes
<jdstrand> slangasek: yes, it is, especially since I still remember when it was working :)
<mdeslaur> jdstrand: memories fade :)
<jdstrand> slangasek: is there a workaround? do we expect it to get fixed?
<slangasek> honestly, I'm not sure why Keybuk implemented the VGA16fb support as a separate renderer, instead of adding generic support to the fb renderer for downstepping the bit depth
<jdstrand> well, radeon 7500 users (of which there are many), will have a nice usplash in all previous releases and then drop to text
<slangasek> jdstrand: not likely to get fixed for release
<jdstrand> :\
<slangasek> unless you persuade the kernel team that this change was wrong?
<jdstrand> I have no background or authority to say it is wrong
<mdeslaur> and sacrifice desktop memory?
<jdstrand> I can only say the outcome is poor
<slangasek> you could install fglrx, then you'd have the VGA fb :-P
<jdstrand> mdeslaur: this is what fixed our bug?
<slangasek> (I don't recommend this, that looks even worse than the text right now :)
<mdeslaur> slangasek: nice try, but fglrx doesn't support radeon 7500 any more :)
<mdeslaur> jdstrand: it probably helped, yes
<slangasek> heh
<jdstrand> slangasek: well, taking the fact that I bought a 7500 to avoid the proprietary driver in the first place, I don't think fglrx supports this card anyway
<slangasek> ok, you could boot with a vga= option
<mdeslaur> oh!
<slangasek> but that implies using a 32bpp fb, so I don't know how that interacts with your desktop problem
<slangasek> (OTOH, if you pick a lower res fb, it's less of an issue than when it's at native res?)
<mdeslaur> jdstrand: I know a work-around: doesn't your wife have a birthday coming up? :)
<mcurrington> Who maintains the package irssi? In apt-cache show it tells me "Ubuntu Core Developers"
<jdstrand> heh, sure she does, but not her business partner ;)
<mdeslaur> jdstrand: let me know if you try with vga=
<jdstrand> I'm trying to conjure up the magic for 1400x1050... it's been awhile
<slangasek> alternative to vga= if you're using grub2 is to try gfx_payload=keep
<slangasek> + setting a res in the grub config
<jdstrand> btw, I'm fine with a workaround...
<jdstrand> slangasek: gfx_payload-- is that kernel command line or grub's config?
<jdstrand> nm, found it
<cjwatson> if jdstrand is using a KMS graphics driver, then gfxpayload=keep will break virtual consoles, I believe
<slangasek> ah
<slangasek> nevermind then :)
<slangasek> jdstrand: in that case, it's s/linux/linux16/ s/initrd/initrd16/ and add the vga= option; I have no idea about the maintainability of that
<cjwatson> you'd probably have to edit /etc/grub.d/10_linux to avoid screwing yourself over on every update-grub
<cjwatson> slangasek: FWIW I talked with pkern, I'm going to go with libparted0debian1 as you suggested.  I think I'll wait until ries comes back though
<cjwatson> now that I have the odbcinst1debian1 precedent
<jdstrand> linux16?
 * jdstrand googles
 * jdstrand gets it now
<jdstrand> slangasek: booting without splash is nearly acceptable due to the fast boot
<jdstrand> slangasek: seems some console output is still leaking through though...
<jdstrand> (ie with just quiet)
<jdstrand> bunch of 'Broken pipe' messages
<slangasek> yes, with 'quiet' plymouth shows you console output
<slangasek> (whatever console output there is)
<highvoltage> anyone know perhaps (or have an idea) when we'll have daily builds again?
<chrisccoulson> does anybody know what happened to this: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/1596874 ?
<kees> chrisccoulson: whoa.  I would ping lamont.
<jpds> chrisccoulson: The machine died?
<jpds> Actually, the upload log is interesting.
<lex79> slangasek: in gdm.upstart there's "exec gdm-binary $CONFIG_FILE" and in kdm.upstart only "exec kdm", that change should be merged into kdm.upstart ?
<slangasek> lex79: not unless you know of something that sets that variable for kdm
<lex79> ok
<wgrant> chrisccoulson: That's some DB glitch -- it looks like something went strange just after the upgrade finished. Hit Retry.
<wgrant> That's no code bug.
<chrisccoulson> wgrant - ok, thanks. i'll retry that now
<lex79> slangasek: I merged your changes to kubuntu-members, thanks
<slangasek> lex79: thank you!
 * lamont grumbles at whoever gave back schroot/armel
<slangasek> lamont: which time?
<slangasek> 13:24 < doko__> hmm, who did give back schroot on armel? did give it back just 1h ago ...
<lamont> well, it's knocking over the pegatrons
<lamont> so I killed it with prejudice
<lamont> speaking of which, could you (I'm EOD and busy ish) block glib2.0/sparc in PaS for me?
<lamont> tired of stabbing sparc
<lamont> and yeah, glib2.0 got both of them again
<lamont> so nm... I'll deal with it when I get back to the computer in a couple hours/.
<slangasek> hum, added to PaS, but why's it killing sparc?
<lamont> dunno - there's a bug against glib2.0 for it
<ScottK> That would be me retrying glib2.0 so I can get kdebindings to build.  I guess  we'll need some arch specific magic to get around that one.
<lamont> on the bright side, we now have the log we can paste into the bug, on both sparc
<lamont> buildds
<ScottK> Is there any hope that sparc will actually work this release?
<slangasek> if it's crashed 2 buildds, that counts as 'confirmed', right
<lamont> big hint for would-be-helpful people who can give-back packages: if it looks like the build tree got nuked out from under the build?  there's a reason
<lamont> slangasek: both sparc buildds, every upload since the last one that worked
<ScottK> lamont: Is it time to think about sparc joining hppa?
 * lamont continues playing dice with launchpad trying to put the pegatrons on manual so he can unleash schroot on a bbg3 instead
<lamont> I choose not to join that discussion
<doko__> lamont: ok can do that
<lamont> doko__: do what?
<doko__> trying to put the pegatrons on manual (gourd is the only new one?)
<lamont> buttercup, gourd, and cushaw are bbg3
<lamont> my issue is that 90% of the time, +edit gives me a timeout
<lamont> in about 3 minutes, I'm gonna use a rock
<lamont> there. jackfruit finally manual
<doko__> ahh ...
<lamont> ok.  now giving back schroot again
<lamont> doko__: fwiw, when it looks like the build tree got ripped out from under the build, the most likely explanation is that I logged into the buildd and did exactly that, to kill the build hard before it did worse things
<lamont> as in, please check before giving those back
<doko__> lamont: hmm, I did check that the build log was from February and started ...
<lamont> doko__: interesting
<doko__> maybe just coincidence working at the same time
<lamont> what happens in these cases is this:  build starts, kills the machine, and launchpad says "hrm... buildd went away, lets try it on another one"
<lamont> lather, rinse, repeat
<lamont> the build log, of course, disappears in that
<lamont> when we add in that the pegatrons (and bbg3) boards are not remote rebootable, having a build go through and knock them all over is really sucky
<lamont> doko__: I'll be afk for about an hour and then checking on buttercup.  then I'll make a decision about whether or not to throw the other pegatrons back into the pool
#ubuntu-devel 2010-04-03
<Laney> can I just upload a new version of a package that is in unapproved?
 * Laney tries it
<slangasek> kirkland: "if ! pidof /usr/sbin/libvirtd >/dev/null; then" - you're in the pre-start script for the service that launches libvirtd; why is this not a no-op?
<pac1> I have a daily lucid iso that will not boot properly on my hardware.  How can i collect information for submitting a bug on a live cd?
<lamont> buildd   28521 98.2  0.7   9040  3472 ?        R    00:46 116:34      |                                           \_ dot /build/buildd/schroot-1.4.0/debian/build/doc/schroot/html/dir_17e0cfd21565d25c859a9e2623b17004_dep.dot -Tpng -o /build/buildd/schroot-1.4.0/debian/build/doc/schroot/html/dir_17e0cfd21565d25c859a9e2623b17004_dep.png -Tcmapx -o /build/buildd/schroot-1.4.0/debian/build/doc/schroot/html/dir_17e0cfd21565d25c859a9e2623b17004_dep.map
<lamont>  <-- doko: schroot vs armel
<ScottK> lamont: JFTR, the second sparc buildd wasn't my fault, the retry was either automatic or someone else did it.
<lamont> yeah - if it times out it goes "oh, want me to see if it'll kill another one? ok.:
<lamont> oh look.  glib2.90
<lamont> 2.0 even
<lamont> just like now - freshly restarted, and sejong is the lucky winner
 * lamont waits for the unpack to finish so he can shoot it in the head
<lamont> my way's not very sportsman like
<doko__> lamont: schroot wins, uploading without --enable-doxygen for arm
<doko__> s/schroot/armel/
<lamont> doko__: let me know when it's published and I'll go kill the build'
<doko__> lamont: now waiting for approval (ScottK?)
 * lamont is +1, ScottK 
<ScottK> What for?
<lamont> schroot
 * ScottK looks
<lamont> FTBFS on armel, fixed
<ScottK> lamont and doko__: accepted.
<lamont> oh most cool.  the previous version actually "just died" rather than taking out buttercup
 * lamont hugs bbg3
<ScottK> Speaking of which, glib is waiting first in line to wipe out your sparc buildds if you restart them.
<lamont> ScottK: not any more... it failed to build
<ScottK> On, sure enough
<ScottK> On/Oh
<lamont> with strange configure errors that look like some buildd admin nuked the build tree
<ScottK> I probably shouldn't retry it then.
<lamont> just one of the many services we provide
<ScottK> ;-)
<lamont> ScottK: I'd have to hurt you if you did
<ScottK> Yeah, no problem.  I got the word now.
<lamont> that does tend to be a spectacularly obvious failure mode
<wgrant> lamont: Well, if you haven't seen it before it looks like a 'wtf happened here, that looks spurious. *retry*.'
<lamont> wgrant: true
<lamont> should be part of our standard buildd-admin briefing
<wgrant> lamont: Note that non-buildd-admins can retry.
<wgrant> (anyone with upload rights)
<lamont> oh, and a "no really, make this build never try again, regardless of what the ppa owner says" button for buildd-admins would be nice
<wgrant> lamont: "UPDATE build SET buildstate=5 WHERE id=%s" isn't good enough for you? Picky. :P
<lamont> wgrant: that is insufficent in some cases, depending on the build state
<lamont> leaves dangling cruft to make bigjools cry later
<wgrant> Yeah, you'd probably have to play with the Job state as well.
<wgrant> But that will all be changing in a few weeks.
<lamont> \o/
<lamont> at least I hope
<wgrant> There we be ONE BUILD STATE FIELD! And no extra records hanging around to delete.
<wgrant> And it might even make it easier to implement the mythical 'Abort build' button.
<lamont> oh major WIN
<lamont> heh
 * ScottK has had some very similar looking armel failures work on retry.
<lamont> we have that, it just requires shell access to the buildd
<wgrant> lamont: In what fraction of cancel-requiring failures do non-virt builders respond?
<wgrant> If a virt builder doesn't respond to an abort request, I plan to just hit the reset trigger.
<wgrant> But we can't quite do that for non-virt builders.
<sistpoty> just out of interest, what kernel/distro is running on the sparc buildds? (if it's later than 7.10, then I'll have a strong reason to not upgrade revu to that version *g*)
<lamont> hardy is the dominant platform
<lamont> ppc is karmic
<lamont> armel is split between *cough* jaunty and lucid
<lamont> wgrant: not sure
<lamont> sistpoty: across the variety of platforms, it's hardy unless specified above
 * ScottK wonders what the heck doko__ is doing with all the Dapper toolchain builds.
<lamont> dapper is love, no?
<sistpoty> lamont: ah, thanks, I guess I'm lucky with revu running gutsy then :=
<sistpoty> :)
<wgrant> Isn't Gutsy out of support?
<lamont> armel  	6  	 3 jobs (50 seconds) <-- lying
<doko__> tired of openjdk security backports for every release ...
<lamont> wgrant: way big time
<ScottK> wgrant: Yes, but it the last one that works on sparc.
<lamont> doko__: that's 2 ofus
<wgrant> lamont: Estimation is completely screwed at the moment.
<sistpoty> oh, wait, it's hardy on revu even
<wgrant> It's about to become even more completely screwed.
<lamont> sistpoty: much better
<wgrant> lamont: Only by a year.
<doko__> lamont: ofus?
<lamont> I hear there's an LTS coming soon
<lamont> doko__: of us
<ScottK> Gutsy is the last Sparc installer that worked though.
<lamont> space bar fail
<doko__> no ufos ...
<lamont> ScottK: ssssssssssssssssssssssshhh
<lamont> doko__: clearly, you need to drink more... will find ufos then
<doko__> but upstart did build again in lucid
<ScottK> lamont: Just tell NCommander no cookies unless he fixes it for Lucid.
<ScottK> doko__: So it may actually work, just no new installs.
<lamont> dear sparc.  good luck on catching up
<lamont> ScottK: heh
<wgrant> How sick is PowerPC these days?
<ScottK> Runs but not extremely stable.
<ScottK> We even get Live CD images.
<lamont> wgrant: other than the porter machine, it seems happy...  I'm inclined to point at the machine, rather than the architecture/distro
<wgrant> Ah.
 * ScottK got samba4 to build today.
<wgrant> Which snapshot?
<ScottK> Had to downgrade ldb and upgrade samba4
<ScottK> The September on from Unstable
<wgrant> Ah.
<ScottK> Thus âldbâ 1:0.9.10~git20091212+really0.9.6~git20090912-0ubuntu1
 * lamont decides that it's bedtime
<NCommander> lamont: sparc is dead as far as I am concerned for this cycle :-/
<doko_> losa ...
<LLStarks> hi. what bug tag do i use for a beta 2 exemption?
<zubin71> hello, i had an idea id like to propose on behalf of ubuntu for gsoc; as the idea is one of my own im looking around for someone who could mentor me. :) But before that id like to discuss the idea. Could someone spare a little time? It`d be great if you could.
<jpds> zubin71: I'd try #ubuntu-gsoc.
<zubin71> jpds: i did ; and i mailed to the list to, as they had just suggested. I was wondering if someone might be interested(and having some spare time) to listen to my idea.
<zubin71> has anyone here worked on any project related to iptables?
<chrisccoulson> slangasek - i uploaded firefox last night. would you mind approving it if you get the chance so it builds over the weekend?
<lifeless> jpds: I'm about 50% through a smart HTTP server for lmirror
<lifeless> jpds: I'll have it wrapped tomorrow - this gets rid of the per-file round trip overhead.
<lifeless> gnight everyone
<mpt> kwwii, hi, what happened to that Ubuntu logo icon fix?
<mpt> vish, do you know if a new Ubuntu logo icon was uploaded?
<jzacsh> hello, I'm trying to play around with android development on ubuntu with eclipse (never really used eclipse before)- tried following instructions, and some trouble shooting, no luck. I keep getting dependency errors: http://paste.ubuntu.com/408702/
#ubuntu-devel 2010-04-04
<superm1> um, did vnc4-common just disappear from universe?
<superm1> rmadison appears to think so. http://paste.ubuntu.com/408810/ but the publishing history doesn't agree with that: https://edge.launchpad.net/ubuntu/+source/vnc4/+publishinghistory
<Daviey> superm1: rmadison certainly suggests that, but it's certainly in the the archive pool under the universe pocket still.
<superm1> Daviey, i think this is part of the LucidPlatformSupportableBinaries possibly
<superm1> it looks like it was on slangasek's original list
<crimsun> E: Package vnc4-common has no installation candidate
<Daviey> that is odd, because apt-get source vnc4-common certainly pulls in 4.1.1+xorg1.0.2-0ubuntu7
<Daviey> (vnc4)
<slangasek> the removals were binary-only
<slangasek> feel free to fix the build failure
<Daviey> slangasek: Sorry, which build failure?  I see a dep wait on armel
<wgrant> https://edge.launchpad.net/ubuntu/lucid/i386/vnc4-common is the equivalent binary publication page -- just like the source one, it is always right and should have a deletion comment.
<slangasek> Daviey: the build failure at the root of the spec - should be trivial to reproduce by grabbing the source and trying to build it
<Daviey> slangasek: yes, sorry - just read the spec
<superm1> woo, the debian vnc4 package builds.  i'll request a sync for it
<superm1> can an archive admin release vnc4server from NEW so all the rdepends can get back to building?
<ScottK> \
<ScottK> superm1: Done.
<wgrant> It has rdepends?
<micahg> any archive admins around?
<superm1> wgrant, mythbuntu-common needs it, and tons of stuff needs mythbuntu-common to build
<superm1> thanks ScottK
<ScottK> No problem.
<wgrant> Ah.
<ScottK> I understand a bit better why you were excited when it went missing.
<superm1> yeah :)
<superm1> kinda sorta breaks live disks
<slangasek> lool: do you know why there's no build record for valgrind on armel?
<micahg> slangasek: can you push a Thunderbird and Firefox through unapproved?
<slangasek> micahg: looking
 * kees hugs chrisccoulson micahg and mdeslaur
<slangasek> ccheney: do you know why OOo b-d on ant1.7 on ia64 (which doesn't exist) instead of ant (which does and appears to be installable)?
<micahg> thanks slangasek
<slangasek> sure thing
<SandGorgon> hi guys, this idea ( http://brainstorm.ubuntu.com/idea/24276/ ) just hit the front page of Hacker News - if somebody can get a moderator to look at it, please do
<LaserJock> SandGorgon: you probably want to talk to Brainstorm admins about that
<crypt-0> Are there plans to re-enable SMART probing in 9.10? If so when?
<River_Song> popey> Spoilers! -_-
<bdrung> persia: hi, i want to become member of u-u-s again (then i can unsubscribe u-u-s again)
<Annaa> http://tinypic.zapto.org/2kn4m8.png?t=1270382061 do my breasts look to big?
 * _romeo_ says happy easter to all
<TrueTom> does anyone know if acpid is still used for events like notebook lid opening/closing?
<TrueTom> does anyone know if acpid is still used for events like notebook lid opening/closing?
<jpds> !weekend
<ubottu> It's a weekend. Often on weekends the paid developers and a lot of the community may not be around to answer your question. Please be patient, wait longer than you normally would or try again during the working week.
<TrueTom> fair enough :)
<jdong> lazy question, does Lucid upgrade existing GRUB legacy systems to GRUB2 or no?
<micahg> jdong: I seem to have a mix and match...grub is legacy, grub-common is grub 2
<jdong> fun
<jdong> so it still doesn't attempt to rewrite the bootloader, like in 9.10
<micahg> jdong: I get an option to use grub 2 chainloader in grub 1, but that might be because of something I did in 9.10
<owen1> there is a serious bug with many asus and dell laptops but it was not assigned to any developer. what can I do to get the attention of canonical? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/512192
<ubottu> Ubuntu bug 512192 in linux "Can't configure Elan tech touchpad on Dell Inspiron 11z, Asus K7I0C and maybe also Dell Mini 10 (not V), ASUS k40in, Asus U81A and ASUS UL80-VT." [Undecided,Confirmed]
<owen1> this thouchpad is too sensitive which forces me to use external keyboard.
<micahg> owen1: you can try #ubuntu-kernel tomorrow
<owen1> micahg: thank you. what do u mean by tomorrow? i am in pacific time.
<micahg> owen1: Monday
<micahg> owen1: you can try today, but there's no guarantee anyone will be around
<owen1> ok. i will.
<micahg> directhex: any idea how I can test gluezilla being ported to 1.9.2?
<micahg> *xulrunner 1.9.2
<directhex> micahg, good question. i think gluezilla is used by the system.windows.forms web browser control, so try any old "hello world" web browser example code
<micahg> directhex: unfortunately, I'm not familiar with mono
<micahg> directhex: do we have a mono IDE in Ubuntu?
<ScottK> micahg: monodevelop?
<micahg> ScottK: looks, right, thanks
<directhex> monodevelop, but it's for gtk# work mostly
<micahg> directhex: I can't make an easy Hello World browser test in it quickly?
<xnox> it's general purpose though =) you can write C, C++ and JS in it =)
<xnox> It's like Anjuta done write similar to XCode imho
<xnox> s / write / right
<directhex> try http://www.java2s.com/Tutorial/CSharp/0460__GUI-Windows-Forms/BrowserwithUrlentrybox.htm
<directhex> messy segfault on lucid, for me
<micahg> directhex: forgive my ignorance, but what do I do with the code?
<directhex> micahg, gmcs -pkg:dotnet foo.cs
<micahg> directhex: wfm :)
<directhex> odd
<directhex> micahg, running foo.exe ?
<micahg> directhex: I'm using my modified gluezilla
<directhex> ah. awesome
<directhex> can you fling the patch at debian plz?
<micahg> oops
<micahg> just core dumped
<micahg> i'ts using the wrong xul...I'll have to look into iit further, thanks
<micahg> directhex: just enabled 1.9.2 vs 1.9.1 and built with 1.9.2, obviously not enough...I'll dig a little further
<directhex> thanks micahg
<directhex> micahg, it's not an a1 priority, as none of the default apps use it... but user apps may well do
<micahg> directhex: are you the debian maintainer?
<directhex> micahg, more or less
<micahg> directhex: there's a problem that clean deletes Makefile.in in tests/browser which makes rebuilding a pain, I was going to file a bug later this week
<lifeless> kees: is squid/squid3 meant to get security fixes ?
<lifeless> kees: nevermind, clearly in universe.
<cjohnston> superm1: ping
<superm1> cjohnston, what's up?
<micahg> sk that it be set as wishlist
<micahg> oops
<cjohnston> superm1: mind a PM?
<superm1> cjohnston, sure?
<crypt-0> where are all of the scripts located that preform the auto mounting / password prompt with full disk encryption?
<lifeless> cryptsetup
<lifeless> crypttab
<crypt-0> lifeless, if i wanted to expand upon a script how would i do so eg a script that is run *before* that one
<crypt-0> lifeless, crypttab is one line.
<crypt-0> 0_o wrong dir dorry
#ubuntu-devel 2011-03-28
<twb> dch -i works fine for non-native packages, but for a (private) native package I'm maintaining, it is changing "2011031701" to "2011031701ubuntu1".
<twb> Is there a way to make it update it to, say, "2011031702" or "2011032801" ?
<ScottK> twb: dch -d will give you the Debian standard behavior which will, I think, do what you want.
<twb> ScottK: can I put that in .devscripts somehow?
<ScottK> No idea.
<StevenK> alias dch='dch -d'
<twb> StevenK: but that assumes I run dch directly, and from a shell.
<StevenK> Just offering a suggestion
<twb> Nod, OK
<ScottK> twb: Just do dch -d instad of dch -i whereever you're doing it.
<twb> Hm, I can't see a dch -d in the manpage...
<twb> Is that a post-lucid feature?
<twb> Hm, -d, --fromdirname -- Add a new changelog entry with version taken from the directory name
<twb> --fromdirname won't work for me, because it'll always just be "foo" not "foo-1.0"
<twb> I can just use -v, I just would've preferred to have something more magical
<StevenK> I thought there was an environment variable to control it ...
<twb> StevenK: DEBCHANGE_RELEASE_HEURISTIC=changelog ?
<twb> StevenK: I have that, IIRC it makes Debian dch act list Ubuntu dch
<StevenK> twb: I'm not certain, it's a vague thought and I'm trying not to context switch
<twb> Sorry
<hyperair> sb levelclear -level clientcrap,crap,joins,parts,quits,nicks,clientnotice
<hyperair> whoops, forgot the / >_>
<StevenK> RAOF: Can haz MPRIS? :-)
<dholbach> good morning
<cdbs> good morning dholbach !
<dholbach> hey cdbs
<pitti> Good morning
<didrocks> good morning
<pitti> cjwatson: should biosdevname be in main/installed by default? you integrated it in the installer, is it only needed to write the static udev rules? or at runtime as well?
<cjwatson> pitti: yes, it should be added, I'll figure out where it belongs and sort out the seeds
<pitti> thanks
<hrw> morning
<pitti> tseliot: for the nvidia-* bits we currently have add_modules=['glx'], remove_modules=['dri', 'GLcore']; I suppose we still need to keep the remove_modules, but do we still need to manually add glx?
<doko_> pitti: intended?
<doko_>  o ttf-sil-gentium-basic: ttf-sil-gentium-basic
<doko_>    [Reverse-Depends: libreoffice]
<pitti> doko_: no, only transitional; still working on fixing c-m
 * Daviey shakes his fist at james_w for skewing the sponsorship stats... :)
<pitti> ugh, WTH?
<tseliot> pitti: I think we can safely comment out both add_modules and remove_modules in Jockey
<pitti> tseliot: if dri and GLCore are loaded in xorg.conf that won't break the driver any more?
<pitti> tseliot: (not even for 96?)
<tseliot> pitti: we only need the defaultdepth option and of course  the option to set the driver to nvidia
<tseliot> pitti: let me check what we do for 96
<pitti> tseliot: I thought dropping the driver option was the main point of bug 522061
<ubottu> Launchpad bug 522061 in jockey (Ubuntu Natty) "Nvidia proprietary drivers fallback test failed" [High,In progress] https://launchpad.net/bugs/522061
<pitti> tseliot: as we now have 105_nvidia_fglrx_autodetect.patch
<tseliot> pitti: right, the only thing I'm not sure (I should re-read the patch) is whether autoloading works also when a xorg.conf is available
<pitti> tseliot: yes, was confirmed in https://bugs.launchpad.net/ubuntu/+source/jockey/+bug/522061/comments/18
<ubottu> Ubuntu bug 522061 in jockey (Ubuntu Natty) "Nvidia proprietary drivers fallback test failed" [High,In progress]
<tseliot> pitti: err, doesn't that say that nouveau is used instead of nvidia when the driver is commented out?
<pitti> tseliot: ah, right
<tseliot> pitti: oh, and we also need the nologo option
<pitti> tseliot: I only have intel here, so I can't fully test any of this :/
<pitti> tseliot: I'll keep the remove_modules (just to be sure), the AddARGBGLXVisuals quirk for 96, and NoLogo
<tseliot> pitti: I can do it here, as I'll have to land a few fixes to nvidia anyway
<tseliot> pitti: yes, keeping remove_modules definitely won't hurt
<pitti> tseliot: ok, so I'll do the necessary changes in trunk first (support not writing Driver, that will cause a few disruptions), then update nvidia.py as I think it should be, and then ask you to test the current ubuntu bzr head?
<tseliot> pitti: sounds good
<pitti> tseliot: this will take me a couple of hours (I'll test it as far as I can in "dry mode" here)
<pitti> tseliot: cheers
<tseliot> pitti: no hurry, I'm working on other urgent stuff
<tkamppeter> It is about bug 335662, don't we have a notification area any more? At least for some users HPLIP complains that there is no notification area for hp-systray.
<ubottu> Launchpad bug 335662 in HPLIP "[jaunty] hplip status service cannot find system tray" [Undecided,Confirmed] https://launchpad.net/bugs/335662
<ohsix> would be cool if ctrl+k or ctrl+e, or both; would jump to the search box in software center, where does one request such a thing?
<pitti> tkamppeter: right, it's gone in general; we only have a backward compatible systray for java apps and skype
<pitti> tkamppeter: however, there is a whitelist; so if you think it's important, you can file a bug against unity and ask for whitelisting it
<tkamppeter> pitti, whitelisting hp-systray or the notification area?
<pitti> tkamppeter: hp-systray for the notification area
<seb128> they will probably say no
<seb128> but you can still try ;-)
<tkamppeter> seb128, why?
<seb128> because things are supposed to be ported to indicator for 3 cycles
<seb128> so they are giving increasing reasons to port those not ported now
<seb128> they also think that it's harder to give something and drop it than to not give it
<seb128> so they said they would not whitelist things that can be patched
<tkamppeter> seb128, hplip-gui is made by HP and they are trying to cover a wide range of distros, probably therefore they do not switch their stuff.
<seb128> well it's open source so we could distro patch it to use an indicator?
<tkamppeter> seb128, pitti, is it a big change to patch a notification area app to indicator?
<seb128> usually not
<seb128> tkamppeter, https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators
<pitti> tkamppeter: technically the change is trivial; it's a political/design issue
<pitti> we now have consistent indicators in the default install, i. e. the entire top panel is a signle big menu
<pitti> such whitelists break this behaviour
<tkamppeter> pitti, seb128, the app in question is hp-systray (part of hplip-gui) which is written in Python and uses the Qt widget library. The app shows as an HP logo and right-clicking it shows a regular menu. Left-clicking it does nothing.
<seb128> should be trivial to port to an indicator then
<tkamppeter> pitti, seb128, it is also a D-Bus-based user daemon for handling fax queues.
<tkamppeter> pitti, seb128, are there somewhere instructions or samples for that (above-mentioned site only handles GTK).
<pitti> chrisccoulson: your nss uploads doesn't have bug references, is it ok to keep until after beta? or does it help with RC bugs?
<chrisccoulson> pitti - oh, i forgot to add a bug reference
<chrisccoulson> pitti - it's a security fix that's currently being deployed on other releases
<pitti> chrisccoulson: oh, for the comodo stuff?
<pitti> chrisccoulson: it looks pinpointed enough anyway
<chrisccoulson> pitti - yeah, that's the one. the nss change is just to block those certs
<pitti> chrisccoulson: ok, thanks; accepting now, please close the bug manually
<chrisccoulson> thanks
<tkamppeter> riddell, hi
<Riddell> hi tkamppeter
<seb128> tkamppeter, check with agateau or Riddell I guess
<Riddell> tkamppeter: I think the only Qt implementation is KStatusNotifierItem which is a KDE class, so it would need changing from a QApplication to a KApplication
<seb128> Riddell, there is no way for qt application to use the appindicator without using kde?
<Riddell> seb128: no, it would need QSytemTrayIcon ported to the status notifier spec
<seb128> Riddell, ok
<NCommander>  /lastlog NComm
<NCommander> bah
<seb128> tkamppeter, <Riddell> tkamppeter: I think the only Qt implementation is KStatusNotifierItem which is a KDE class, so it would need changing from a QApplication to a KApplication
<seb128> ups
<seb128> tkamppeter, https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/497877
<ubottu> Ubuntu bug 497877 in hplip (Ubuntu) "Support Application Indicators" [Wishlist,Incomplete]
<seb128> you had a patch there for hplip for a while
<mvo> ev: on the system that you tested apt-clone on and that failed to upgrade, do you still have the state file? I would like to add it to the regression tess
<ev> mvo: yup, one moment
<mvo> thnx!
<ev> mvo: http://people.canonical.com/~evand/tmp/apt-clone-state-ubuntu.tar.gz
<mvo> ev: thanks!
<ev> sure thing
<hrw> pitti: hi, have a minute for a talk about pkg-create-dbgsym and cross builds?
<pitti> hrw: what's up?
<hrw> pitti: when pkg-create-dbgsym is installed cross build of ncurses is impossible to finish as it tries to generate lib32ncurses* packages (cross build on amd64 to armel target) which are not generated
<hrw> pitti: when I uninstall it then build finishes fine
<hrw> pitti: does it goes though debian/control and just tries to generate package for each entry?
<pitti> hrw: yes, it does (just checking the code); it just ought to use @{$dh{DOPACKAGES}}, as all the other debhelper scripts, I guess
<pitti> hrw: it needs to do a bit more though, i. e.  filter out the arch: all ones
<hrw> pitti: http://pastebin.com/S3C4d8Es is output
<seb128> tkamppeter, pitti: ok, open a bug about hplip whitelisting, they will likely do it
<hrw> pitti: in debian/rules creation of 32/64bit packages are handled by separate variables rather then control file
<pitti> hrw: hm, why is DEB_BUILD_ARCH==amd64 there? shouldn't that be armel?
<hrw> pitti: build_arch is amd64, host_arch is armel
<pitti> ah, that way around
<pitti> so it should probably compare the Architecture: field to DEB_HOST_ARCH then, not DEB_BUILD_ARCH
<pitti> I thought these were exactly the other way around
<hrw> pitti: pkg-create-dbgsym is called after dh_strip but does not check it's arguments?
<pitti> hrw: pkg-create-dbgsym wraps dh_strip
<pitti> hrw: it does respect -p, -N, -s, etc.
<pitti> but it defaults to all non arch: all packages from debian/control if no package is given
<hrw> pitti: 10th line of pastebin calls dh_strip with -X entries
<pitti> (minus architecture: <nonmatching>
<hrw> "dh_strip -s -Xlibncurses5-dbg -Xlibncursesw5-dbg -Xlibncursesw5 --dbg-package=libncurses5-dbg"
<pitti> hrw: that's wrong, though
<pitti> that should be -N
<pitti> -X blacklists file paths from stripping, not packages
<hrw> let me check with -N then
<hrw> pitti: http://pastebin.com/3atS38Hj shows same with -N instead of -X
<pitti> hrw: I guess it'll still fail, as it doesn't -N the lib32 binaries; it's a separate bug, though
<pitti> yes, as expected
<pitti> hrw: what does debian/control say for lib32blah? Shouldn't that have Architecture: amd64?
<hrw> Architecture: amd64 ppc64
<pitti> hrw: ok, so the bug here is that pkg-create-dbgsym checks build arch, not host arch
<hrw> thx
 * pitti runs tests
<hrw> pitti: BUILDARCH=`dpkg-architecture -qDEB_HOST_ARCH` == success here
<pitti> hrw: ah, thanks! I was about to toss you a .deb for checking, but that's the gist of the change indeed
<hrw> pitti: once you told build/host stuff I started checking files
<hrw> ncurses pacakges created
<hrw> now reverted -X -> -N changes and rebuilding packages
<pitti> hrw: http://bazaar.launchpad.net/~ubuntu-core-dev/pkg-create-dbgsym/ubuntu/revision/194
<ubottu> Ubuntu bug 194 in Launchpad itself "After clicking on a bug, I have to click on "more information" in order to see the bug comments" [Medium,Fix released]
<pitti> hrw: no, -N is correct
<pitti> hrw: -X is not the correct option for ignoring packages
<hrw> pitti: sure, but this is a bug which I will report separatelly
<pitti> tests pass
<pitti> hrw: ok, will upload, thanks for pointing out!
<hrw> pitti: you welcome. thanks for fixing
<hrw> pitti: can you look at bug 711523 and tell me what do you think about patch?
<ubottu> Launchpad bug 711523 in armel-cross-toolchain-base (Ubuntu) "dbgsym packages generated during build, but not uploaded" [Undecided,In progress] https://launchpad.net/bugs/711523
<hrw> pitti: I can explain why patch calls pkg_create_dbgsym on its own
<pitti> hrw: pkg_create_dbgsym gets called by the wrapped dh_strip, so packages which don't use debhelper need to call it manually
<pitti> doko_: FYI, pkg_create_dbgsym is not called by pkgbinarymangler, just from dh_strip
<hrw> doko_: can you merge it now when it got explanation from pitti?
<hrw> pitti: and thanks for this explanation - I did not know that before
<pitti> hrw: hrw but why do you call $(STRIP) twice?
<pitti> hrw: and note that this patch is missing a pkg-create-dbgsym build dependency
<hrw> pitti: I copied stripping rules from other part of rules
<hrw> pitti: binutils iirc already depends on it
<pitti> ah, forget about the b-d, it's || true
<hrw> pitti: this patch adds 6th call to it
<pitti> hrw: it's installed in the buildd chroots already
<pitti> doko_: ok, that's more like it: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<pitti> doko_: pinyin-database already demoted
<pitti> bryceh said that he'll add xserver-xorg-video-qxl
<pitti>  to x-x-video-all, so that'll get sorted out as well
<doko_> pitti: so you did approve a FFe for dbus-c++?
<pitti> doko_: the changelog is just bug fixes, there's no real new features there
<doko_> ok
<doko_> TheMuso: ^^^
<pitti> hrw: how urgent is the p-c-d fix? do you need it in beta-1?
<hrw> pitti: not urgent
<pitti> hrw: ok, keeping in the queue then
<hrw> pitti: would be nice to have it in natty but no rush to have it asap
<pitti> hrw: yes, will go in after beta-1, i. e. on Thursday
<hrw> pitti: in archive cross packages are not affected (as I maintain all of them and do nearly daily builds of those)
<mvo> ev: \o/ I can reproduce the bug
<ev> yay
<hrw> pitti: http://paste.ubuntu.com/586457/ would be ok debdiff for ncurses?
<psusi> pitti: I was wondering if you had seen my patches to upower, g-p-m, and indicator-session ( merge request and posoted to devkit-devel ) and had any opinion on them?
<pitti> hrw: looks fine; please forward to Debian, to avoid a permanent delta
<pitti> hrw: I wonder if we really need to upload this -- does it work with -X as well?
<pitti> hrw: it should work as long as package libfoox also has any file containing "libfoox", e. g. usually in /usr/share/doc/
<psusi> doh... emacs crashed...
<hrw> pitti: it works with -X too
<pitti> psusi: hughsie said he'd look at them, so I didn't want to get in his way
<hrw> pitti: it is rather kind of wishlist bug rather I think
<pitti> hrw: yeah; I think you should send it to a Debian bug, and then declare it done
<psusi> pitti: ok...
<hrw> thanks pitti for help
<hrw> bug reported to Debian/ncurses as minor + patch
<doko_> hrw: now merged all change to -4.5, -4.6 and binutils
<pitti> hrw: splendid, thanks
<hrw> doko_: thanks a lot
<hrw> doko_: can you merge changes to gcc-4.4 too?
<hrw> debbug 619939
<hrw> pitti:  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619939 was what I reported
<ubottu> Debian bug 619939 in ncurses "ncurses: Fix dh_strip usage" [Minor,Open]
<Daviey> pitti, Hey... would you be able to re-look at bug 651875, from an SRU ack perspective?
<ubottu> Launchpad bug 651875 in bind9 (Ubuntu Lucid) "Bind 9.7.0-P1 validation errors" [Medium,Confirmed] https://launchpad.net/bugs/651875
<MacSlow> popey, ping
<popey> MacSlow: pong
<MacSlow> Do you have a method of consistently triggering LP: #742091 you reported last thursday? Could you share that with me (or add to the bug). I have a fix and would like to put that to the test. Thanks in advance!
<popey> well, i have updated since then, and it's been even less reliable
<popey> i can crash it doing fairly basic stuff like moving windows
<popey> but I am at work now, and pc is at home, i can try when i get home tonight
<MacSlow> popey, we also have more fixes coming up :)
<popey> \o/
<popey> good to hear
<MacSlow> popey, if you could add it to the bug as addional comment... that would already help
<tkamppeter> seb128, thank you. Unfortunately, all patches presented to me in that bug report were immediate crashers.
<popey> ok, will do
<MacSlow> popey, thanks!
<seb128> tkamppeter, can you open a bug against libunity asking for hplip to be whitelisted?
<tkamppeter> I will do so, with reference to bug 497877, telling that several efforts were made to adapt hp-systray but no solution found.
<ubottu> Launchpad bug 497877 in hplip (Ubuntu) "Support Application Indicators" [Wishlist,Incomplete] https://launchpad.net/bugs/497877
<pitti> Daviey: see comment 7 -- if we can reasonably QA this (test suite or manual testing), I'm fine with that; by and large needs an upload and a test plan now
<doko_> hrw: done
<hrw> thanks again
<hrw> doko_: did you had a time to look at patch in bug 676454 - removal of u-a from cross builds of gcc
<ubottu> Launchpad bug 676454 in gcc-defaults-armel-cross (Ubuntu) "switch to gcc-4.5 and symlinks for default versions" [Undecided,In progress] https://launchpad.net/bugs/676454
<doko_> hrw: not yet, please ping me tomorrow
<hrw> doko_: ok
<ogra_> is there a reason why wpasupplicant is only in the high level seeds but not in something like ubuntu-standard ?
<tkamppeter> seb128, I have reported the whitelisting request for hp-systray as bug 744308.
<ubottu> Launchpad bug 744308 in libunity (Ubuntu) "Whitelist HPLIP's hp-systray for Unity's application indicators" [Undecided,New] https://launchpad.net/bugs/744308
<seb128> tkamppeter, tahnks
<directhex> pitti, do you know if you'll get a chance this week to look at the webkit annotations issue shana brought up?
<shana> oh, I found more
<pitti> directhex: I hope so; I have a built upstream checkout now, that just didn't build the gir at all, so I need some prep for this
<shana> pitti: there's no type annotation on signal parameters. the c:type entry is missing
<Daviey> pitti, We don't have a decent test suite.  The best we can do is manual testing..  I was 'ok' with trying to cherry pick, but as upstream don't have an open VCS this is near impossible.  Debian maintainer (lamont), and security seem to prefer adopting a new upstream version (which we are supporting in Natty).
<pitti> shana: oh, intersting
<shana> and I didn't open the bug, darn it
<shana> pitti: there is in the 1.2.5 version, but not in the 1.3
<Daviey> pitti, it's currently in the unapproved queue.. I am happy to test it on my production dns servers, but i am quite close to the issue.  So will look to try and get more manual testing once t hists proposed, by hitting the server mailing list.
<pitti> Daviey: ah, good
<shana> unless annotations changed significantly between the two versions, I'm guessing it's a side effect of the lack of ownership perhaps?
<shana> totally guessing ere
<shana> *here
<Daviey> pitti, if you are satisfied, can you add an ack please? :)
<pitti> shana: "ownership" in the sense of "nobody at webkit cares about it"?
<shana> pitti: was thinking more of the missing "transfer-ownership" thing :)
<shana> or whatever the annotation is called
<shana> :)
<pitti> shana: ah; but trunk and package are built with the same g-i version, so that wouldn't make a difference
<shana> the schema version in the gir files is different
<shana> 1.2.5 is marked "1.1", 1.3 is marked "1.2"
<shana> I have no clue if there's a difference
<pitti> Daviey: followed up
<shana> just throwing ideas, frankly, I stopped when I noticed the c:type missing and haven't investigated further
<Daviey> pitti, thanks!
<Daviey> pitti, So.. really wanted to get this new upstream version  in -updates by thursday.  Even with a call for testing, do you think this is unlikely?
<pitti> Daviey: you mean -proposed?
<Daviey> pitti, -updates!  We are going to have many unhappy people if it doesn't... It's sort of time senstive...  The rational in the url in the bug description explain why.
<pitti> Daviey: no way
<pitti> Daviey: even for a small focussed patch it needs to mature 7 days
<pitti> Daviey: for a large new upstream update I expect something like two or three weeks
<Daviey> Yup, i agree... but ideas for a resolution?
<Daviey> pitti, note, there has already been a call for testing from a PPA... but not had feedback.
<pitti> Daviey: as I said on the bug: upload a small backported patch, we'll get that into -updates next Monday, and then we can do the full release
<pitti> Daviey: lucid sustained without the fix for a year now, why is it suddenly so urgent?
<Daviey> pitti, March 31st, the internet changes...
<Daviey> url on the way
<Daviey> http://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record
<pitti> Daviey: then I'd say minimal patch and quick verification
<pitti> and we'll cut the usual 7 day period, as in this case the impact if we don't do it is higher
<YokoZar> Can a quilt patch Author field contain more than one person?
<YokoZar> (what uses the data?)
<Daviey> pitti, ack..
<Daviey> mdeslaur, around?
<Daviey> and lamont ?
<mdeslaur> Daviey: yep
<lamont> sorta
<cjwatson> YokoZar: http://dep.debian.net/deps/dep3/ "This field can be used multiple times if several people authored the patch."
<cjwatson> so Author: Some Person\nAuthor: Other Person, etc.
<YokoZar> cjwatson: thanks, exactly what I was looking for.
<YokoZar> I didn't find that page cause I kept searching for "quilt" and it's not listed there :/
<doko> pitti, TheMuso: I think I'll just merge dbus-c++, upload and then start the test rebuilds
<pitti> doko: ah, Debian still doesn't have symbols files?
<tgardner> if you'd like 802.11n high-speed wireless support re-enabled in your modern Intel wifi adapter, then please review the patch at https://bugs.launchpad.net/ubuntu/natty/+source/module-init-tools/+bug/630748/comments/64
<ubottu> Ubuntu bug 630748 in module-init-tools (Ubuntu Natty) "iwlagn degrades quickly during normal wifi session" [High,In progress]
<doko> pitti: no
 * JackyAlcine will be right back.
<cjwatson> YokoZar: right, it's not quilt-specific
<YokoZar> cjwatson: Yeah, but I didn't think to do a more generic search ;)
<u-foka> Hy! Should that overlay scrollbar stuff work in an "Ubuntu Classic" session with compiz?
<doko> ev: is python-mock b-d only?
<ev> doko: build-dep for ubiquity? Yes.
<doko> ok, promoting. should use dh_python2 for packaging at some point
<doko> pitti: dbus-c++ waiting for approval
<pitti> doko: accepted (still universe)
<doko> hmm, I think, then I'll have to wait with the promotion?
<pitti> doko: fine for me to promote it right now, more consistent archive
<doko> ok, done
<pitti> doko: (note I reopened the bug as the package upload didn't do the promotion)
<pitti> doko: let's hope that won't confuse the current upload :)
<slangasek> chrisccoulson: how well do you understand nss's build system?
<chrisccoulson> slangasek, not very well, it's fairly hideous ;)
<chrisccoulson> i take it you want to convert it to multiarch?
<cjwatson> watch out for its perversion of "build" and "host" (IIRC)
<slangasek> chrisccoulson: precisely :)  I have everything except finding where in the system it decides on the /usr/lib/nss path
<cjwatson> in fact and possibly "target" too
<slangasek> cjwatson: I'm hoping to just pass a path in via make or whatnot, and ignore its worldview entirely :)
<tgardner> slangasek, you seem kind of busy. is there someone else that you'd suggest to have a look at my module-init-tools patch at https://bugs.launchpad.net/ubuntu/natty/+source/module-init-tools/+bug/630748/comments/64 ?
<ubottu> Ubuntu bug 630748 in module-init-tools (Ubuntu Natty) "iwlagn degrades quickly during normal wifi session" [High,In progress]
<cjwatson> didrocks: what's happening with compiz/unity/nux/etc. for beta-1?
<didrocks> cjwatson: nothing planned for now, the release we did last Thursday still stand
<slangasek> tgardner: hi there - sorry, I hadn't had time to pull the tarball you pointed me to on chinstrap, but a patch in LP works fine :) couple questions I have:
<cjwatson> tgardner: needs Pre-Depends: dpkg (>= 1.15.7.2)
<tgardner> cjwatson, so thats required for natty?
<tgardner> I read about it in the man page
<slangasek> tgardner: 1) what's the expected behavior here if a user tries to boot an older kernel where iwl3945 is not split? (is this such a thing?  I don't remember 3945 ever being in iwlagn, but that's what the changelog suggests)
<tgardner> slangasek, an older kernel is likely to re-exhibit the original bug.
<cjwatson> tgardner: yes, because otherwise direct upgrades from 10.04 LTS to 12.04 LTS may fail
<slangasek> tgardner: 2) not so much a question... if you use dpkg-maintscript-helper, you're supposed to call it in all of the preinst, postinst, and postrm
<tgardner> slangasek, I was a bit confused by that, hence me bugging you for a review. I'll add those other calls.
<slangasek> tgardner: yes, it is confusing - the reason for having it in all of preinst, postinst, and postrm is to completely handle certain upgrade rollback scenarios (i.e., if you only call it in prerm, dpkg leaves bits around on the filesystem that are only needed for rollback and which you want to have cleaned up)
<tgardner> slangasek, OK. Is an older kernel a realistic scenario?
<slangasek> tgardner: it's something that might come up when a user is trying to debug / recover an upgrade; I guess there's not really much we can do there after the fact unless you want to SRU the iwlagn module to have a built-in default of 11n_disable for iwl3945 chips only?
<slangasek> but whether or not it's worth doing an SRU for the old kernels, it makes me wonder if this same default should be changed for the iwl3945 module /now/
<cjwatson> it's in debhelper as of 8.1.0, FWIW, so if you're already relying on that or don't mind doing so, you can just stick 'rm_conffile /etc/modprobe.d/intel-5300-iwlagn-disable11n.conf 3.12-1ubuntu4' in debian/module-init-tools.maintscript and not worry about the details.  (Not that I'm suggesting you necessarily need to do that here, it's just for information since maybe not many people know about that yet)
<tgardner> slangasek, there isn't an easy way to disable 802.11n for just 3945 in older kernels.
<slangasek> yep, understood
<tgardner> ok, I'll respin and annoy you guys later today.
<slangasek> I'll be here :)
<pitti> Riddell: recent kdebase-workspace introduced a dep to nodm, which is in universe? is that intended (-> MIR)?
<Riddell> pitti: Recommends: kdm (>= ${source:Version}) | nodm    nodm is for kubuntu-mobile which is built from universe
<pitti> Riddell: ah, so perhaps that's only temporary because of i386/amd64 desync
<Riddell> if it remains a problem I can just remove the recommends for both there
<ScottK> Alternate depends in Universe should be fine.
<pitti> SpamapS: woudl you have some time this week for an SRU training session? there's enough fodder in the queues now
<SpamapS> pitti: definitely! Wed or Thu would work
<pitti> SpamapS: nice
<directhex> bah
<pitti> dpm: you still have a WI "Talk to Mozilla people about using user provided translations from Launchpad"; I'm curious, did you already talk to them? what did they say? would be great to have a more direct translation flow to them
<dpm> pitti, hm, no, unfortunately I didn't get to talk to them yet. I started on this a while ago by writing the e-mail and getting it past through a couple of people, and I needed to add their feedback. I just left it at "oh, I'll do this later", but now that chrisccoulson has started moving the FF translations topic forward I need to look at it again. Let me come back to you tomorrow.
<pitti> dpm: ah, thanks
<pitti> dpm: so I keep this open; no worries, just cleaning up WIs
<dpm> no worries, thanks for the heads up
<highvoltage> 7/win 21
<nigelb> highvoltage: fail? try 42 ;)
<ari-tczew> james_w: I guess you're not looking for sponsorship? http://reports.qa.ubuntu.com/reports/sponsoring/index.html
<micahg> ari-tczew: did you see there's a comment in the merge proposal?
<ari-tczew> micahg: do you mean field Description of the Change ?
<micahg> ari-tczew: yes
<ari-tczew> micahg: ok what;s the conclusion?
<micahg> ari-tczew: they need to be analyzed if they're necessary merges, did you read the description?
<ari-tczew> micahg: yes but I don't need to be a mastermind to understand everything
<cody-somerville> ari-tczew, Are you saying you don't understand the merge proposal descriptions or that you do?
<cody-somerville> ari-tczew, (or are you saying something completely different there?)
<ari-tczew> cody-somerville: your first suggestion
<cody-somerville> ari-tczew, Are you familiar with the UDD (Ubuntu Distributed Development) work? Basically, the idea is to manage packages in bzr branches. It looks like James has a script that detects when the packages actually in the archive become out of sync with the bzr branches. The script move the old branch out of the way, pushed a new branch that *is* in sync, and created a merge proposal for the old branch to be merged into the new t
<cody-somerville> o make sure no changes that hadn't been uploaded get lost.
<cody-somerville> *moved
<ari-tczew> cody-somerville: ok, what we have to do with these branches? sponsor it?
<cody-somerville> ari-tczew, Not necessarily. What needs to happen is for interested individuals to go through those MPs, analyze the diff, and merge + sponsor in any changes to the new branch if appropriate.
<ari-tczew> cody-somerville: so it means a lot of work to do, Total requests: 102
<bdrung_> popey: funny bug report :)
<cody-somerville> ari-tczew, I imagine a lot of them can just be rejected if there is no diff.
<cody-somerville> ari-tczew, I'd ask james_w for more details though before going through and closing them based on that criteria.
<ari-tczew> cody-somerville: ok :)
<Cheery> hi, did ubuntu switch window system already?
<Cheery> or was the whole thing just a really nasty rumor?
<m4n1sh> Cheery: Wayland?
<Cheery> m4n1sh: yes
<m4n1sh> will take time
<m4n1sh> probably 3-4 releases for sure
<broder> Cheery: as sabdfl said in his blog post, wayland is almost certainly at least 2 years off
<m4n1sh> Cheery: it wasnt a rumour. Check Mark's blog
<Cheery> you probably know there's very good reason to get further with it.
<ogasawara> cjwatson: just fyi, we've uploaded a linux-backports-modules-2.6.38 for Natty (it's still in the new queue).  it can wait until after beta to move out of new, but apw mentioned we should also ping you so that it gets added to some uploaders list?
<Cheery> heh. I put nvidia + wayland into google and there is a forum fost at nvidia forums first..
<Cheery> then there's bunch of 'news' after quoting the "no plans to support"
<psusi> I still don't understand wayland.. the last I read about it, it sounded like it was just for switching between multiple X servers...
<broder> wayland replaces the x server and protocol, and (at a high level that is clearly pro-wayland) gets rid of all the legacy code and functionality that the x server and protocols have to support but nobody cares about
<micahg> er, rather that casual desktop users don't care about
<broder> like i said, clearly pro-wayland :)
<Cheery> I think I'll look into that a bit.. searching wayland API now.
<Cheery> egl + gles2 since libGL has been mutilated with GLX
<psusi> broder: it doesn't replace it though, it just exists outside it.. you still need an X server to have the functioning desktop we have now... all qt and gtk apps require X
<broder> psusi: only because the toolkits haven't been ported to the wayland backend
<broder> which will happen
<broder> just as they've been ported for carbon/cocoa/win32 backends
<psusi> broder: as far as I can see, there isn't a "wayland backend"; it's just a DRI backend
<Cheery> if there were nvidia driver for wayland without EGL/GLES2, I think I'd be already using wayland
<Cheery> and I'm writing software too :)
<psusi> and if you build gtk to use a dri backend, then you can run just a single app... there's no windowing and soforth
<broder> psusi: i only have a very high-level understanding of wayland, but i find it hard to believe that that's the end of the story
<Cheery> psusi: that's one of the things I wonder too
<Cheery> haven't really seen "wayland documentation" which actually tells what it does and what it doesn't
<Cheery> my opinion to this is that input + visuals should be dealt separately as possible.
<Cheery> I'd allow mouse + keyboard multiplexing only, as long as there's no further multiplexers.
<Cheery> the whole thing should have higher granularity than X, anyway.
<psusi> I mean, the x protocol may not be pretty, but it sounds like wayland does almost nothing and expects the toolkits to reinvent most of what X handles
<Cheery> psusi: which may be the whole point in it.
<Cheery> except that you shouldn't end up to toolkits
<Cheery> that toolkit will become just an another X
<psusi> exactly... so if the toolkits just end up becoming another X, why bother?
<Cheery> maybe.. because you're not interested about doing a toolkit but something slicker.
<Cheery> psusi: say one defines a clear API, like opengl4 has, to access window manager which provides bunch of basic elements that you can't implement otherwise, then toolkits take on from that.
<Cheery> ..if we'll ever need toolkits again.
<Cheery> the window manager API at this point would only handle things that require interaction with windows.
<Cheery> and that's about it.
<Cheery> psusi: the benefit in that is you could create a desktop app with lot less effort than now. It'd make SDL look like bloat
<Cheery> but.. I'm getting to sleep now
<tgardner> slangasek, another version of the module-init-tools patch. https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/630748/comments/65 - Please add comments to the bug as I'm outta here for the day.
<ubottu> Ubuntu bug 630748 in module-init-tools (Ubuntu Natty) "iwlagn degrades quickly during normal wifi session" [High,In progress]
<lifeless> kees: ping
<barry> slangasek: ping
<slangasek> barry: hey there
<barry> hi slangasek.  so, i think multiarch breaks from-source builds of python
<slangasek> barry: if you mean unpatched upstream source, I'm afraid that's true; we've patched the packages in natty to address this, I don't know doko's thoughts on upstream fixing
<barry> slangasek: python itself builds, but a handful of modules break
<barry> slangasek: okay, i guess it's time to bring it up on the relevant mailing lists ;)
<slangasek> yes, was reported in LP as bug #738213
<ubottu> Launchpad bug 738213 in python2.7 (Ubuntu Natty) "Python build from source lack some modules due to non-standard libraries placement" [Critical,Fix released] https://launchpad.net/bugs/738213
<barry> slangasek: cool, thanks for the reference
<cjwatson> ogasawara: right, thanks - I'll try to remember to sync up the ACLs
<RAOF> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: beta freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: RAOF
<kees> lifeless: I'm vacationing until Wed, but send me an email if it's low-urgency. for high-urgency, check with the other security folks. :)
<lifeless> kees: ah
<lifeless> kees: it was about the cve page on lp
<lifeless> kees: I think its rather specific to you :P - do you need the inline-edit widgets for the listed bugtasks
<lifeless> kees: e.g. on https://launchpad.net/bugs/cve/2009-0834/+index
<ubottu> Ubuntu bug 2009 in mpd (Ubuntu) "Need some modification" [Wishlist,Invalid]
<lifeless> kees: (mailing this now)
<kees> lifeless: cool
<lifeless> kees: but I'm hoping your answer is 'no, I don't'
<kees> lifeless: hah. OOPS-1913Q1097 on that url. :P
<lifeless> kees: yes, thats why I want to remove the edit widgets
<lifeless> and just make it a task listing like e.g. a milestone page
<kees> heh
<kees> that's fine; it's a summary page as far as I'm concerned.
<lifeless> great, thanks
#ubuntu-devel 2011-03-29
<slangasek> YokoZar: any luck with ia32-libs multiarching?
<directhex> wow, that sounds nice & easy
<slangasek> hmm?
<RAOF> directhex: Shouldn't be *that* hard, right?  âJustâ pull in /usr/lib/i386-whatever-triplet/ :)
<YokoZar> slangasek: I took a look at it and it looks a bit difficult.  But it needs to be done, possibly before release even.  Mind if I pass this off to you?
<YokoZar> slangasek: Although if it's as simple as "also look in (32-bit-triplet) and copy all libs there to /usr/lib32" then maybe I'm mistaken...
<YokoZar> slangasek: hopefully there aren't any non-relative-path surprises and such in there
<Laney> stgraber: I just noticed that the DMB isn't an administrator of ~edubuntu-dev
<RAOF> Laney: Is it possible to get the DMB to vote on my application via email or something?  Staying up/waking up to attend a meeting that doesn't happen or doesn't get 'round to me is getting kinda old :)
<psusi> anyone have any idea why on earth reinstalling nautilus would reset apps/metacity/general/button_layout back to the old menu:minimize,maximize,close setting?
<slangasek> YokoZar: it really is as simple as "also look in {/usr,}/lib/i386-linux-gnu/ and copy all libs there to /usr/lib32"
<Laney> RAOF: Yeah, I feel for you, and was thinkign about that earlier. I wonder if we could instead 'invite' applicants to a particular meeting so that they can actually know when they will be interviewed...
<slangasek> YokoZar: but if you want me to look at it I can
<ion> ia32-libs âmultiarchingâ doesnât mean âdestroying foreverâ? :-P
<Laney> RAOF: If you mail the DMB list then we'll work something out though (and it will let me raise this issue)
<slangasek> ion: not in one cycle it doesn't
<slangasek> ion: not given how long ia32-libs has been allowed to fester and continue accumulating libs
<ion> aye
<slangasek> $ dpkg -L ia32-libs|grep -c 'lib32/[^/]\+\.so'
<slangasek> 743
<slangasek> :P
<Chipzz> slangasek: wtf? :p
<Chipzz> does that include the symlinks too?
<slangasek> YokoZar: if you do want me to look at it, please say so explicitly :)
<slangasek> Chipzz: it includes whatever that regexp matches, I didn't filter too hard
<Chipzz> slangasek: ah, so prolly /3 then :)
<slangasek> yeah, dpkg -L doesn't distinguish between files and links
<Chipzz> ~250 libs, still pretty bad :/
<broder> an upstart task triggers stopped/stopping events when the exec/script block exits, right?
<slangasek> dpkg -c ~archive/pool/universe/i/ia32-libs/ia32-libs_20090808ubuntu9_amd64.deb |grep -c '^-.*lib32/[^/]\+\.so'
<slangasek> 248
<slangasek> broder: yes
<broder> hmm...i think i need to get better logs to figure out what's going on, then
<slangasek> broder: actually, no, sorry
<slangasek> broder: I confused myself - a task is "started" when the job finishes
<slangasek> and not before
<broder> so a task goes to the "starting" state, then it runs and stays in "starting", then goes to "started" when it finishes running?
<slangasek> broder: yes
<slangasek> er... maybe
<slangasek> ok, I don't know ;)
<broder> haha, ok :)
<slangasek> if I look at jobs that are tasks that definitely ran at boot time, they're in state 'stop/waiting'
<broder> i'll harrass SpamapS and the other people working on the upstart cookbook to figure out and clarify
<broder> right, that's what i was looking at
<slangasek> and those jobs should, barring bugs, emit stopping/stopped events at the end
<broder> as a guess, maybe tasks skip the running, pre-stop, stopping, killed, and post-stop states and go straight from spawned to waiting?
<slangasek> could be, but I think that would be inconsistent with the use of 'post-stop' scripts in several of the jobs
<broder> ok, you've officially got me digging through source code now, so report back on what i find :)
<broder> ugh. i might not have acquired enough of the upstart zen to know what's going on here
<broder> ah - but the logs might clarify what's going on
<broder> or maybe not, because all of the tasks in the normal boot happen before syslog is up
<broder> but certainly tasks transition through the running -> stopping -> killed -> post-stop -> waiting series of states
<YokoZar> slangasek: how's your bandwidth?  Can you upload the 800+ meg source package?
<slangasek> if I have to
<slangasek> I'd rather just send you a patch ;)
<YokoZar> slangasek: That works best for me :)
<slangasek> a patch does?
<YokoZar> yeah
<slangasek> ok
<YokoZar> Then I'll add the libraries I need and make a huge upload overnight
<psusi> it seems to me like prefixing patches with a number is a carryover from dpatch... or should 3.0 (quilt) patches also be numbered?
<broder> psusi: i tend to prefer them because it makes the order obvious just from "ls" instead of having to look at the series file. but there's no technical requirement. though obviously if you're patching somebody else's package you should follow existing style
<psusi> broder, does order really matter?
<broder> psusi: sometimes. usually it's something like ubuntu is changing something that debian already changed
<psusi> I mean yea, sometimes it does, but when you're just doing an ls to see what's there, do you normally care about the order?
<broder> it's no less valid of an order than the mostly arbitrary order imposed by the names of the patches
<RAOF> Bah.  Stupid interaction of 3.0(quilt) and vcs!
<RoAkSoAx> win 24
<RAOF> ETOOMANYIRCCHANNELS
<ion> lose 25
<RAOF> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: beta freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<ScottK> RAOF: Is there any other kind of 3.0(quilt)/VCS interaction defined?
<twb> Who has point for LibreOffice packaging: Debian or Ubuntu?  That is, who syncs from whom?
<jmg> hi all
<jmg> any reason i wouldnt be able to use fglrx on casper with persistent changes
<jmg> i really desperately need it or the radeondump tool which doesnt appear to be included anywhere in the earchive
<slangasek> YokoZar: bug #744767
<ubottu> Launchpad bug 744767 in ia32-libs (Ubuntu) "ia32-libs needs changes to cope with library packages installing to multiarch paths" [Undecided,New] https://launchpad.net/bugs/744767
<broder> slangasek: man, that multiarch command sequence from your blog is *awesome*
<slangasek> disclaimer: running it on your desktop eats your desktop.  Enabling multiarch at all on your desktop eats update-manager and anything else that uses python-apt
<broder> haha. cest la vie
<slangasek> although for the former issue, I have all the needed bits in ppa now
<infinity> Isn't the death of python-apt pretty much the result of nearly any and all toolchain fiddling in the history of... Ever?
<infinity> (Well, packaging toolchain... And occasionally C++... And... Yeah, I'll stick with "all")
<slangasek> module gtk+2.0, which the buildds won't give me for another 2 hours or so
<slangasek> s/module/modulo/
<slangasek> infinity: heh
<broder> slangasek: if you need help, i'm hoping to be able to take friday off of work to go to jono's global jam
<slangasek> broder: we're at kind of a curious point where there's not much more to usefully do until dpkg 1.16.0 hits unstable
<broder> sure, just figured i'd throw it out there
<StevenK> infinity: Your bitterness is showing
<StevenK> Er, more showing
<slangasek> nothing else can (or should) go into natty now during the freeze; I'm done putzing around in my ppa now that I have everything there needed to install flashplugin; and nothing happens in Debian with it until the bootstrap kicks off
<slangasek> so because I'm out of major things to do for multiarch, that's the time I'll blog instead ;)
<infinity> StevenK: Rumours of my bitterness have been greatly exaggerated for comedic effect.
<StevenK> infinity: No, they haven't. :-)
<pitti> Good morning
 * slangasek waves to pitti 
<broder> hmm...what's the best way to test a priori if plymouth is going to be able to use the graphical vs. text theme? look for /dev/dri?
 * infinity pokes pitti with a stick.
<cdbs> dholbach: Good morning
<dholbach> good morning
<dholbach> hey cdbs
<infinity> dholbach: Hai.
<dholbach> hey infinity
<dholbach> infinity, MAN - long time no see
 * dholbach hugs infinity
 * infinity hugs dholbach.
<infinity> I've decided to come back to annoy you.
<dholbach> hahaha, awesome :)
<soren> infinity: Dude!
<infinity> soren: *wave*
<infinity> sabdfl: I've lost track, are you in a disconnect storm, or actually joining the channel? :P
<infinity> sabdfl: If the latter, "hi".
<pitti> hey infinity, how are you?
<sabdfl> infinity: adventures in multi-device connectivity here :-)
<sabdfl> how are you, long time no speak
<infinity> pitti: Alive and well.  And I think this is more than I've typed in #ubuntu-devel in two years.
<pitti> lol, yes
<infinity> sabdfl: See above? :)
<sabdfl> timezones still seem unchanged ;-)
<soren> I'm sure we can pull up some stats on that.
<sabdfl> hey soren
<soren> sabdfl: o/
<soren> sabdfl: I though you were in a very different timezone these days
<didrocks> good morning
<soren> thought, even.
<soren> Specifically, one that does not warrant being awake right now :)
<infinity> sabdfl: And yeah, I'm still timezone challenged.  I don't imagine this is something that will ever change.
 * mvo waves to infinity
<infinity> mvo!
<infinity> Okay, now I'm getting all sentimental.
<YokoZar> slangasek: universe libs only in ia32-libs yes?
<slangasek> YokoZar: hmm?
<YokoZar> slangasek: eg can I add gstreamer0.10-plugins-ugly or just gstreamer0.10-plugins-good
<slangasek> oh, do you mean *main* only rather than universe? :)
<slangasek> there are both main and universe libs in ia32-libs
<YokoZar> err no I mean "not multiverse"
<slangasek> neither of those are in multiverse
<slangasek> ia32-libs is in universe, so you can't add anything from multiverse to it, yes
<slangasek> not that I think you should really add anything more to it at all, but hey
<YokoZar> but ugly plugins are in universe you say
<slangasek> yes, the good/bad/ugly split of the packages has to do with code quality and support, not freeness
<YokoZar> ok that makes me feel better
<dholbach> RAOF, happy patch pilot day
<pitti> ogra_: did you want to keep rhythmbox on the armel ubuntu-netbook images? If so, can you please seed it appropriately?
<pitti> ogra_: if not, I'll add it to supported (it currently wants to go to universe, but we want to keep it in main until the next LTS)
<sabdfl> soren: no, i'm trying to narrow my timezones! where did you think i was?
<soren> sabdfl: I heard a rumour about US East coast. New York or something.
<sabdfl> ah, yes, i have bought a place there, it's about as far from GMT as I'd like to live
<sabdfl> going to take a while to get it fixed up though
<sabdfl> i'm concentrating on Isle of Man and Cape Town at the moment
<sabdfl> and my little tropical love affair
<soren> sabdfl: Sounds lovely!
<tkamppeter> slangasek, hi
<YokoZar> Why are there binaries for libx264-98 still in archive when source package x264 provides libx264-106 instead now?
<mok0> I have written a system for disk quotas that makes use of libnotify. When your disk quotas are exceeded, you get a pop-up warning and is prompted to clean up your disk usage. I am looking for other ubuntu-devs that might help take it a step further for inclusion in Ubuntus server infrastructure	
<pitti> YokoZar: see http://people.canonical.com/~ubuntu-archive/nbs.html
<pitti> YokoZar: the old packages still have rdepends, they need some transition uploads
<YokoZar> pitti: in this case, all on ppc...
<RAOF> Man, libx264.  Because ABIs are hard! :)
<ohsix> yes
<ohsix> ffmpeg too D:
<mvo> dpm: is bug #744831 something that should be on langpack-o-matic or is it in the right place?
<ubottu> Launchpad bug 744831 in language-pack-as (Ubuntu) "file overwrite error" [Undecided,New] https://launchpad.net/bugs/744831
<ohsix> RAOF: both are windows centric and assume you do a source checkout and use it as is in your software
<janimo> does it make sense to have upstream bugs open in LP  (Also affects project ) if the Ubuntu packages have been fixed for all series involved?
<janimo> for instance linaro/ubuntu gcc has fixes not yet upstream, so we have a gcc bugtask open on some bugs
<janimo> ex: https://bugs.launchpad.net/gcc/+bug/398403
<ubottu> Ubuntu bug 398403 in gcc "[PR40735] gcc-4.4 fails to build upstart 0.6 on armel due to an internal compiler error" [Unknown,Confirmed]
<janimo> doko, ^ ?
<doko> hmm, linaro uses a project linaro-tracking ... (or something like this)
<doko> lool: ^^^
<cjwatson> infinity: hi!  awesome.
<dpm> mvo, yeah, I think langpack-o-matic would be the right place for bug 744831, pitti, what do you think?
<ubottu> Launchpad bug 744831 in language-pack-as (Ubuntu Natty) "file overwrite error on upgrade from maverick -> natty" [Undecided,New] https://launchpad.net/bugs/744831
<ogra_> ogra@panda:~$ archdetect
<ogra_> armel/unknown
 * ogra_ scratches head
<ogra_> i thought we had panda support in archdetect
<pitti> dpm, mvo: erk, because packagekit moved; yeah, need some extra replaces, I think
<pitti> mvo: how much does this break update-manager? (didn't it use to ignore file overwrites, or retry a few times?)
<pitti> asking because rebuilding all -base packs will take a looong time
<pitti> bug updated
<ogra_> bah, cpuinfo strings changed
<mvo> pitti: its only a issue for people upgrading manually so not beta1 critical
<pitti> mvo: ok, thanks; milestoned to b2 now
<mvo> thanks
<ricotz> hello, is there something wrong with apt or ubuntu repo? it seems apt doesnt recognize if the package lists have really changed and downloads all lists everytime.
<lool> janimo: Sorry, not sure what you're trying to solve
<janimo> lool, to reduce the number of bugs listed as needing attention in ubuntu, while triaging
<lool> doko: I think linaro-tracking is a bit of a hack to track which upstream commits fix the bug; it's more of a trick
<lool> janimo: If the bug is fixed in the Ubuntu package you certainly should close the Ubuntu task
<janimo> even if our packages are fixed, if there's an also affects project with upstream bugtracker open ticket, we get that bug listed
<tkamppeter> pitti, can you upload CUPS from BZR, to get the fix/workaround for bug 710881 into the beta? Thanks.
<ubottu> Launchpad bug 710881 in libpng (Ubuntu) "cups: Test Page /usr/lib/cups/filter/bannertops failed, test page and banner pages do not get printed" [Medium,Confirmed] https://launchpad.net/bugs/710881
<lool> janimo: That sounds like a bug in the script?
<pitti> tkamppeter: doesn't sound critical for the beta release (not important enough to delay it, anyway)
<pitti> tkamppeter: I'll upload it after b1
<janimo> lool, LP ui, not sure what script is involved
<lool> janimo: Can you give me a sample URL?
<janimo> LP for instance this appears in the list of bugs of armel-porters https://bugs.launchpad.net/gcc/+bug/398403
<ubottu> Ubuntu bug 398403 in gcc "[PR40735] gcc-4.4 fails to build upstart 0.6 on armel due to an internal compiler error" [Unknown,Confirmed]
<pitti> ricotz: hm, confirmed here
<janimo> even if it is only a Gcc 4.3 upstream task involved
<ricotz> pitti, ok ;), so it is an apt or archive problem
<lool> janimo: But where did you get this bug from?
<lool> janimo: it seems to me you're searching all bugs in launchpad tagged armel instead of just the Ubuntu ones?
<htorque> pitti, ricotz, maybe bug 677733?
<ubottu> Launchpad bug 677733 in apt (Ubuntu) "Download of the same lists" [Undecided,New] https://launchpad.net/bugs/677733
<lool> janimo: Technically, this bug is still open upstream
<janimo> lool, I think I went to armel ubuntu porters and listed bugs associated to them
<janimo> indeed it is still open upstream
<janimo> I find upstream/debian bugtasks useful until we do not have a fix ourselves as somethign to track and pick a fix from
<janimo> when we have it fixed I see no point in keeping that open, especially since upstream/debian do not use LP for bugtracking
<janimo> it is noise
<pitti> ogra_: libuqpanel0 unity-2d-default-settings binaries (from unity-2d) want to go into universe; don't you need the settings one in a seed somewhere?
<ogra_> pitti, our settings are in unity-2d itself, both are transitional packages ...
<lool> janimo: So perhaps you want to write some launchpadlib script which queries bugs for ~ubuntu-armel and excludes the ones where there are only tasks open on projects which don't use Launchpad for tracking bugs?
<lool> janimo: In the worst case, you could have a project blacklist if that's not exposed by the API
<pitti> unity-2d-default-settings |        0.4 | natty/universe | source
<pitti> unity-2d-default-settings | 3.8.1-0ubuntu1 |         natty | all
<pitti> oh, fun
<janimo> lool, ah certainly. I just with LP UI itself was cleaner
<ogra_> pitti, i'm not really sure what to do with them, only people using natty already or people that used the PPA earlier could have these packages
<pitti> ogra_: ^ i. e. universe has a newer version than main
<pitti> ogra_: so if at all they are ok in universe
<ogra_> why is 0.4 newer than 3.8 ?
<pitti> ogra_: but I'd like to remove the unity-2d-default-settings source package then
<pitti> ogra_: sorry, ignore me
<janimo> lool, I can only image the irrelevant bugtasks if people would be conscious enough and add a lot of affects opensuse/fedora buglinks to all issues :)
<ogra_> yes, that definitely can go
<pitti> ogra_: ok, thanks
<lool> janimo: ?
<ogra_> pitti, thanks for the heads-up :)
<lool> janimo: Keep in mind the bug tracker is just a tool, you don't need to actually log all issues against all projects in the bug tracker, you always have the option to just fix the bug and not 'track' it; that's true for upstream/downstream and across distros too  :-)
<pitti> ogra_: done; while I have you, are you the right person to ask about the linux-tools-omap4 and x-loader-omap3-overo packages on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt ?
<janimo> lool, many bugs presumable affect other distros. There's a possibility in LP to link to similar bugs in their respective trackers. If done, even if Ubuntu gets fixed, the bug remains open until all linked projects/distroes are fixed as well
<ogra_> the latter should be in universe
<pitti> ogra_: moved
<ogra_> for linux-tools, i guess you need to ask the kernel team if we need them
<ogra_> i'll happily seed them if so
<janimo> lool, I agree. That is why I think tracking has value until you actually track development elsewhere and waiting for a fix, and those need to be closed when Ubuntu package is fixed.
<lool> janimo: Sure, sometimes it's the other way around: people using LP just care about the upstream part of the bug and not the downstream ones; you're in the specific case that you only care about the Ubuntu state and you didn't particularly filter for it; the Launchpad web UI might not give you the right thing out of the box, but you can create your own custom report to work around this?
<lool> I'm pretty sure you could search Ubuntu bugs where ubuntu-armel is sub-ed though
<janimo> lool, https://bugs.launchpad.net/~ubuntu-armel this is what I looked at. It still lists issues which are either not closed upstream, or which LP cannot figure out if they are closed or not
<lool> janimo: http://goo.gl/b8Xk1
<lool> janimo: Basically you're asking for "all project Launchpad knows about"; you can filter with "just Ubuntu" or come up with something more precise (perhaps Ubuntu and some list of projects you care about), or blacklist (all Launchpad projects except the ones which don't track bugs in Launchpad); the latter isn't an option in the search, but perhaps you could ask for that to be added (it sounds a bit too specific though)
<janimo> lool, thanks. I never bookmarked/created custom reports. I guess I still expect LP to be intuitive to use by default :) . For instance ubuntu-armel should not be shown a valgrind bug which is fixed in Ubuntu
<tkamppeter> pitti, OK.
<lifeless> janimo: we're working on it :)
<janimo> lifeless, good to know :)
<lool> janimo: Well, you're the one who knows "ubuntu-armel" only cares for Ubuntu
<lool> janimo: The link I pasted doesn't list it, does it?
<janimo> lool, it does not indeed
<lool> janimo: I went to bugs.launchpad.net/ubuntu, hit Advanced search and put "ubuntu-armel" in Subscriber; that's it
<lool> Of course now you're going to tell me you miss the other projects you care about and which track bugs in Launchpad  :-)
<janimo> lool, not really. I miss an easy to use interface which does not need advanced search by default. I am sure not all the things I expect from LP UI needs reading the user's mind to be more useful
<janimo> actually the also affects project by default is what seems most redundant to me. Along with bugs appearing more than once in lists because of it. It makes sense for LP to keep track, but from a UI PoV I find that less helpful
<jibel> pitti, is there a way to stop the retracer aggregating all kind of unrelated ubiquity failures to bug 652916
<ubottu> Launchpad bug 652916 in ubiquity (Ubuntu) "ubiquity-dm crashed with ValueError in command(): invalid literal for int() with base 10: ''" [Medium,Triaged] https://launchpad.net/bugs/652916
<lool> janimo: Ok; I guess this is quite far away from gcc/gcc-linaro/Ubuntu gcc at this point and more of a discussion you should have with Launchpad folks
<janimo> right
<pitti> jibel: you mean all those debconf bugs have a different cause?
<pitti> jibel: I guess the best option would be to catch the error in ubiquity and then raise a more specific error (e. g. including the package name that is being configured, etc.)
<pitti> shana: here?
<shana> pitti: morning!
<jibel> pitti, I reviewed some a them and a common pattern is that when there's a faulty media, memory corruption, no space left, ... ubiquity triggers this error
<pitti> shana: morning, how are you?
<pitti> shana: I just finished building webkit svn trunk again (this time with introspection enabled), and had a look
<shana> pitti: a bit coffee-deprived, but otherwise good
<pitti> shana: to my surprise, glib:signal name="hovering-over-link" is actually in the .gir *twice*
<pitti> shana: once with wrong dummy argument names, the second one is the correct one
<shana> sorry about not opening the bug yet, soc has been siphoning all of my time
<shana> pitti: orly??
<shana> hmmm
<pitti> shana: but both have <type name="utf8"/> which seems fine?
<cjwatson> pitti: unfortunately the thing that notices is on the other side of a pipe from what could provide more information
<cjwatson> pitti: the error means "the debconf frontend I was talking to fell over"
<shana> pitti: <type name="utf8" is not enough, that's a generic name, it should have c:type="gchar*"
 * shana opens up gir files
<pitti> shana: why?
<pitti> cjwatson: is there any way we could extract more useful information out of this after the crash happened?
<shana> pitti: this is what the one I have on the system (webkit 1.2.5) has for that signal: https://gist.github.com/892145
<pitti> shana: (btw, only gchar* is translated to "utf8", so you can actually assume that)
<shana> of course, I can map those new type names, I guess
<pitti> shana: do you depend on always having the c:type one?
<shana> pitti: I did, since every single entry on the gir file has one
<pitti> shana: ok; I guess as a first step I'll track down why it appears twice
<shana> it's a standard on every parameter on every method, every type, everything
<cjwatson> pitti: the problem is that multiple python processes crash; we get useful tracebacks from the other one ...
<pitti> cjwatson: ah, we do? so perhaps we should just generally ignore this crash on the ubiquity side then?
<shana> pitti: take a look at the gist again, I added a comment with other entries on the gir file
<pitti> cjwatson: the ubiquity hook is in the apport source, so I could tweak stuff there
<cjwatson> pitti: maybe, DebconfCommunicator is started in a load of different place
<cjwatson> s
<shana> pitti: utf8 is mapped as gchar* in some places, gchararray in others
<cjwatson> actually, it's pretty odd that that particular one is relevant to anything
<cjwatson> pitti: I'm not absolutely certain, but on the whole I suspect ignoring that one would improve our bugs
<pitti> shana: ok, I'll have a look at the ctypes ones as well, but that sounds a little out of my current knowledge
<shana> pitti: since we map native types when invoking native methods (mono does that by default and gtk-sharp adds some extra layers), that info is important
<pitti> cjwatson: we currently only have a mechanism for saying "sorry can't report this", we can't silently analyze and discard a crash
<pitti> cjwatson: but I guess that would already be an improvement
<cjwatson> in this case, what *actually* happened was that usermod segfaulted and then a chain of dominoes fell over
<shana> pitti: if you need help, let me know what's the fastest way to generate a .gir file from the webkit sources (I have them here, but I haven't poked at the makefiles yet to know what does what)
<cjwatson> I don't agree with jibel's triaging of that as an X crash, but I also don't want to have to unpick all the duplicates
<pitti> shana: I did "./configure --enable-introspection" and then just "make"; it auto-parallelizes, so it built pretty quick; and once you have a built tree, building the updates should be fast
<shana> I think my tree is built
<shana> at least I think I left it building at one point
 * shana pokes
<cjwatson> pitti: I suppose I could try to have ubiquity itself log and discard all instances of that; it may be a bit tricky
<cjwatson> pitti: ah, here - there may be a genuine bug here in that that debconf-communicator instance isn't shut down properly
<cjwatson> normally it isn't a problem, but if something else goes wrong, it produces spurious crap like that
<cjwatson> pitti: I've fixed that in ubiquity bzr now
<ara> checkbox package has a set of questions for debconf priority medium, but I cannot force it to ask me the questions using dpkg-reconfigure -p
<ara> any ideas?
<pitti> cjwatson: cheers
<cjwatson> ara: try with DEBCONF_DEBUG=developer set in the environment and post the resulting stderr
<cjwatson> ara: I bet the questions are marked as seen
<cjwatson> (actually, ignore that last line)
 * ara tries
<infinity> ara: Why the -p?  dpkg-reconfigure defaults to low.  Not even sure what the behaviour is with -p and no priority specified.
<ara> infinity, -pmedium, that's it
<pitti> shana: ah, there are indeed two different signals; one for the WebFrame class, the other for the WebView class
<cjwatson> infinity: (syntax error)
<pitti> shana: and the webview one simply isn't annotated; I'll add that
<infinity> cjwatson: Remembered off the top of your head, or attempted for curiosity? :P
<cjwatson> guessed and checked for curiosity :-)
<shana> pitti: ah yes, you're right, now I see it
<cjwatson> I suspected it was getopt required-option, and thus that the package name would be interpreted as a priority; this turns out to be the case
<pitti> shana: so I wonder why g-i is clever enough to deduce the "utf8" from the G_TYPE_STRING, but doesn't also add the c:type
<shana> pitti: and why it could before but now it doesn't
<shana> not exactly sure what's going on there
<shana> and this webkit was built when I was on lucid, darn
<pitti> shana: but Gtk-3.0.gir doesn't have c:types for it signals eitehr
<shana> pitti: that scares me a bit more
<pitti> shana: would you mind asking about that in #introspection?
<ara> DEBCONF_DEBUG=developer sudo dpkg-reconfigure -pmedium checkbox > /tmp/stderr 2>&1
<ara> and the file is empty
<shana> jumping there now
<pitti> shana: (just saw that you joined; I'll listen and learn)
<cjwatson> ara: s/DEBCONF_DEBUG=developer sudo/sudo DEBCONF_DEBUG=developer/
<pitti> shana: that looks better :) http://paste.ubuntu.com/586811/
<shana> awesomesauce!
<shana> that looks indeed much better :)
 * pitti does the svn diff from hell
<pitti> shana: http://people.canonical.com/~pitti/tmp/WebKit-1.0.gir
<shana> ah, svn
<pitti> shana: ^ freshly built with the patch
 * shana looks
<pitti> shana: yeah, svn :/ slow as hell, no local commit and format-patch, etc.
<pitti> *ugh* *ugh* clapping stones together, grabbing club
<shana> with svn repos I work with git locally and push with git svn
<shana> otherwise I'd go nuts :P
<pitti> shana: so the "p0" stuff on hovering-over-link was not a general error, but just a missing annotation, and these are straightforward to add
<shana> nodnod
<shana> good to hear
<shana> the c:type is annoying, hopefully it's a bug and not a feature
<pitti> shana: for the c:type stuff, deferring to the g-i gurus; does that actually block you, or could you infer a gchar* from a type="utf8"?
<ara> http://pastebin.ubuntu.com/586813/
<shana> I could, but then on other types there'll be more problems
<pitti> shana: (since that's what g-i defines according to http://live.gnome.org/GObjectIntrospection/Annotations)
<cjwatson> broder: have you got anywhere with rewriting grub hwmatch in C?
<shana> like <type name="DOMCSSRule" c:type="WebKitDOMCSSRule*"/>
<shana> utf8 might be straightforward, but other types certainly aren't
<shana> I can do reverse lookups on other places where the type is defined correctly so I don't have to "guess"
<pitti> right
<pitti> shana: when you file the bug upstream, would you mind passing on http://people.canonical.com/~pitti/tmp/webkit.annotate-hovering-over-link.patch ?
<shana> but seeing as all other types have a corresponding c:type, I'd like to know what makes glib:signals so special
<shana> pitti: sure
<pitti> shana: well, for normal methods g-i reads the function prototype
<pitti> shana: for signals it needs to parse the g_signal_new() constructor
<shana> pitti: thanks for the time, most appreciated :D
<pitti> shana: i. e. it's two different code paths; that might explain why they behave differently
<shana> pitti: I see, interesting
<shana> maybe it's really a bug that slipped in
<shana> I really hope it is
<shana> otherwise my xslt is going to take twice as long to convert the .gir
<shana> and I'm worried that utf8 is represented with two different native types there
<shana> if I have to do lookups to get the types from other parts of the file, if I hit the wrong one, it might cause problems
 * shana frets
<shana> oh well
<pitti> *ugh* *ugh* clapping stones together, grabbing clubhttps://bugzilla.gnome.org/enter_bug.cgi?product=glib ("introspection" component), then it's also easier to point to on IRC
<shana> hahaha
<pitti> ouch, what happened here
<shana> svn strikes back
<pitti> would you mind filing this at https://bugzilla.gnome.org/enter_bug.cgi?product=glib ("introspection" component), then it's also easier to point to on IRC
 * shana opens bugs
<pitti> shana: can you even pass arbitrary objects through signals? Don't they need to be defined in terms of existing G_TYPE_*?
<pitti> ah, ignore me
<pitti> of course you can use G_TYPE_FROM_CLASS(...)
<shana> nod
<ara> cjwatson, http://pastebin.ubuntu.com/586813/
<pitti> but I guess at this point g-i's parser might give up
<ara> any clues?
<cjwatson> ara: well, it's simply not asking the questions
<shana> pitti: maybe, but it worked before, so at some point the parser was happy with signals
<cjwatson> I mean, it's not even trying
<pitti> shana: ah, good to know
<pitti> shana: so for now, let's just hope you won't need the really complicated signals :)
<infinity> ara: You're not asking for input, just doing gets?
<cjwatson> ara: ah - checkbox.config bug.  change 'configure' to 'configure|reconfigure' - or just remove the case entirely
<shana> pitti: there's always ways around it, I'm just hoping I don't have to hack it :)
<ara> cjwatson, cool, I will try that, thanks a lot
<cjwatson> ara: http://paste.ubuntu.com/586814/
<shana> the parameter names were the more problematic thing for me, so I'm happy :)
<infinity> ara: Ahh, yes, all the db_inputs happen in configure. :)
<pitti> shana: there are 5 more instances, I'll fix them as well; give me some minutes
<shana> pitti: c:type bug -> https://bugzilla.gnome.org/show_bug.cgi?id=646080
<ubottu> Gnome bug 646080 in introspection "c:type is missing for parameters on glib:signal entries in the gir" [Normal,Unconfirmed]
 * shana pats ubottu 
<pitti> shana: subscribed, thanks!
<pitti> shana: (still working on a more complete annotation patch)
<shana> :)
<pitti> $ grep '="p0"' WebKit-1.0.gir
<pitti> $
<pitti> shana: ^ *grin*
<shana> :D
<shana> yay!
<pitti> shana: http://people.canonical.com/~pitti/tmp/webkit.missing-signal-annotations.patch is the new, more complete patch (still pretty cheesy, it should actually be documented properly, but at least the names are now alright)
<pitti> shana: http://people.canonical.com/~pitti/tmp/WebKit-1.0.gir updated as well, in case you want to run your script against it
<pitti> shana: I'm happy to subscribe to your webkit upstream bug, let me know the URL
<pitti> and with that, late lunch o'clock
<shana> great!
<shana> was just opening the bug
<pitti> shana: ah, ok; I'll make some additional notes when attaching the patch
<mr_pouit> slangasek: (if it's not already on your todo list:) libxklavier would probably benefit a rebuild against the multiarchified glib, as its .pc currently contains "-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include" (it's @GLIB_CFLAGS@ replaced during the package build)...
<shana> pitti: https://bugs.webkit.org/show_bug.cgi?id=57328
<ubottu> bugs.webkit.org bug 57328 in WebKit Gtk "Introspection: missing signal annotations" [Normal,Unconfirmed]
<shana> pitti: i haven't attached the patch
<dpm> ev, pitti, do you think you could have a look at bug 630927? On every release it seems to get fixed but then it appears again. I've just marked a duplicate for Natty, and I could confirm it happens again myself
<ubottu> Launchpad bug 630927 in Ubuntu Translations "Notification of missing language support not shown after installation" [High,Triaged] https://launchpad.net/bugs/630927
<doko> janimo, slangasek: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110329-arm-natty.html
<shana> daaaamn, properties are missing c:type too
<shana> gnn
<tseliot> pitti: I know exactly what's going on in the last comment in LP: #522061 . Shall I commit a patch?
<tseliot> s/patch/fix/
<cjwatson> broder: actually, I might try working on it nowish ...
<hggdh> mvo: ping re. jenkins
<mvo> hggdh: does he work for us (just kidding ;)
<mvo> hggdh: on the phone, but what is the question
<ogra_> mvo, we really need to find someone to introduce you to jenkins next UDS
<hggdh> mvo: I might be able to help you on using jenkins
<mvo> hggdh: excellent
<mvo> hggdh: we should talk about it at uds, the auto-upgrade-tester could use some love
<hggdh> mvo: deal
<pitti> re
<pitti> tseliot: oh, what is it? I haven't had time to investigate the recent comment yet
<pitti> tseliot: please commit away
<tseliot> pitti: I've just added the patch to the bug report together with a brief explanation. I'll commit the small fix
<tseliot> pitti: committed
<pitti> shana: followed up with the patch and some remarks; thanks!
<shana> awesome, thanks!
<pitti> tseliot: ah, good catch; thanks!
<tseliot> pitti: np
<ev> dpm: added to my list of thinks to look at. Thanks
<shana> this day is definitely going sideways
<shana> pitti: oh, good thing you added the comment about the missing names, i just realized I pasted just half the info I wanted on the webkit bug :P
<shana> on a positive note, it seems that a bit of replacing yields a decently complete gir file
<pitti> shana: you mean crowbaring c:types into the gir for known types? :-)
<shana> known and unknown types, just guessing on some, but oh well, should work :)
<shana> fortunately, most types are also used on methods, where there's ctypes
<pitti> shana: I wonder what pygi does to figure out the types
<shana> not sure, but as soon as webkit finished building I'm going to find out
<pitti> apparently that doesn't complain
<shana> it's probably assuming the type name
<shana> not sure
<shana> I can fake types, but there's no one way to go about it
<shana> utf8 can be gchar* or gchararray, gulong and friends are the same, GObject.Object is Object. Gtk.Menu is GtkMenu, DOMNode is WebKitDOMNode*
<shana> and that's just the patterns I know
<shana> we have c glue code in some places and handle conversions on the type, so pretending one is the other is just asking for trouble, unfortunately
<stgraber> Laney: I can certainly fix that
<m4n1sh> abhinav-: ping
<abhinav-> m4n1sh, pong :)
<m4n1sh> abhinav-: can you come to #zeitgeist?
<abhinav-> ok sure
<stgraber> Laney: I invited dmb into edubuntu-dev. Will give admin rights as soon as it's approved.
<stgraber> Laney: not sure if we can approve it ourselves or if we need a TB member (owner of DMB) to do it
<stgraber> at least I haven't received a mail yet and can't find an obvious way of doing it in LP
<ScottK> I don't htink yo ucan.
<ScottK> (if if I spelled it right, you still can't)
<stgraber> cjwatson: can you do it ? (approve ubuntu dmb as a member of edubuntu-dev) ^
<pitti> cjwatson: ^ I can deal with it
<pitti> stgraber: done
<cjwatson> thanks
<stgraber> pitti: thanks
<stgraber> Laney: ok, added to edubuntu-dev and made it an admin
<tseliot> cjwatson, pitti: is it safe to upload packages in Natty now i.e. will they just queue up? Or shall I wait until beta 1 is released? Just double checking
<cjwatson> they'll queue up
<tseliot> cjwatson: ok, thanks
<Laney> stgraber: thanks
<tseliot> my memory is still good enough ;)
<pitti> mvo: langpack file overwrite fixed in langpack-o-matic; will do new -base packs for beta-2 anyway
<mvo> thanks!
<bdmurray> dpm: does bug 630927 need to be targetted to natty or anything?
<ubottu> Launchpad bug 630927 in Ubuntu Translations "Notification of missing language support not shown after installation" [High,Triaged] https://launchpad.net/bugs/630927
<dpm> hi bdmurray, yeah, I'd suggest targetting it to natty, I thought it had been fixed in the previous releases, but it seems to come back every time
<bdmurray> dpm: do you recall where it had been fixed before?
<dpm> bdmurray, I'd say both on lucid and maverick, but that's only from memory. Let me see if there was another bug report...
<dpm> bdmurray, jaunty: bug 337748. I can recall at least a more recent version, but I can't find any bug for that
<ubottu> Launchpad bug 337748 in ubiquity (Ubuntu Jaunty) "[jaunty] âIncomplete Language Supportâ message not shown anymore after installation" [High,Fix released] https://launchpad.net/bugs/337748
<dpm> bdmurray, ah, found it: Lucid - bug 527623
<ubottu> Launchpad bug 527623 in ubiquity (Ubuntu Lucid) "Notification of missing language support not shown after installation" [High,Fix released] https://launchpad.net/bugs/527623
<cjwatson> anything that old is probably a different problem
<cjwatson> language support bugs keep permuting themselves
<cjwatson> note also bug 741304 which could easily be related
<ubottu> Launchpad bug 741304 in ubiquity (Ubuntu Natty) "Language packs are not being installed for selected languages during oem-config" [High,Triaged] https://launchpad.net/bugs/741304
<shana> pitti: well phew, it's a regression
<pitti> shana: yeah, I followed #introspection
<EtienneG> guys, I was wondering: is there any way to verify the authenticity of the installer images?  There's checksum, but no GPG sig, and they're not in the Release file.
<cjwatson> EtienneG: https://bugs.launchpad.net/launchpad/+bug/431790
<ubottu> Ubuntu bug 431790 in Launchpad itself "debian-installer images aren't signed in the archive" [Low,Triaged]
<EtienneG> cjwatson, I see, thanks for the pointer!
<cjwatson> broder: how about http://paste.ubuntu.com/586919/ ?
<dbarth> jelmer: ping? do you have time for a question about git sub-modules?
<dbarth> i'm trying to import compiz-plugins-main, which is made of sub modules; if ever that can be supported with some of the tools available
<jelmer> dbarth: hi
<willy_1977> I'm after a few pointers on helping out with a gnome-utils bug and wondered where best to direct my queries i.e. where to start :p
<willy_1977> bug #743176
<ubottu> Launchpad bug 743176 in gnome-utils (Ubuntu) "Pink layer on taken screenshots (gnome-screenshot)" [Low,In progress] https://launchpad.net/bugs/743176
<dbarth> jelmer: hi
<dbarth> (sorry missed the pong)
<dbarth> jelmer: so any hope or workaround for mirroring a set of git sub-modules? i've tried with the development-subtree format
<dbarth> jelmer: but then it failed with a stack trace when i tried to bzr pull the git module
<dbarth> jelmer: i have another workaround anyway, by importing a tarball; but would be nice to know if there is a supported method to do better at this stage
<jelmer> dbarth: fastimport/fastexport should work with git submodules and will just ignore them as far as I know.
<dbarth> jelmer: ahah, ok, nice
<dbarth> jelmer: i'll follow this track
<jelmer> dbarth: bzr-git should work with submodules if you use development-subtree, but development-subtree is a development format (as the name suggests) so using it in production is generally a bad idea, and it's still unpolished.
<dbarth> jelmer: hmm, i got this error when trying https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/745070
<ubottu> Ubuntu bug 745070 in bzr (Ubuntu) "bzr crashed with AssertionError in create_from_tree(): Unknown kind 'tree-reference'" [Undecided,New]
<dbarth> jelmer: but anyway, right, it's not a production format for now, so i'll look at fastimport/export
<dbarth> thanks again
<jelmer> no problem
<GrueMaster> mvo: Ping.  Any update on bug 533031?
<ubottu> Launchpad bug 533031 in command-not-found (Ubuntu Natty) "command-not-found fails to work on ports architectures" [Low,In progress] https://launchpad.net/bugs/533031
<mvo> GrueMaster: I have not seen a update to the ticket, once I get access to a mirror I can run the extraction. probably best to nudge IS about it
<GrueMaster> sigh.  ok
<mvo> GrueMaster: sorry for that
<GrueMaster> np.
<GrueMaster> Would like to get this fixed for release though.
<GrueMaster> Looks like the last note I have is from March 17 from Colin.
<mvo> thats the last I have as ell
<highvoltage> n/win2 0
<broder> cjwatson: you don't want to initialize match inside the hwmatch_iter function, do you?
<cjwatson> oh, probably not
<cjwatson> wants to be initialised outside that
<cjwatson> fixed
<cjwatson> oh, and I should grub_file_close somewhere
<broder> also, i totally didn't know (but should have expected) that grub had a built-in regex engine. before i forgot about the rewrite, i was putting it off for a while because i expected it would require a larger chunk of time to deal with that
<broder> anyway, really sorry i didn't get to it - work sort of consumed my life for the last few months
<broder> cjwatson: i can't speak the correctness of your use of the grub libraries, but the logic looks correct to me
<cjwatson> broder: it was only added about a year ago
<cjwatson> broder: no problem, it didn't take quite as much time as I expected either ...
<cjwatson> I was expecting half a day or so's work, it was more like an hour
<cjwatson> broder: OK, I'll toss that into the Ubuntu package post-beta-1, then - thanks for the review
<broder> cjwatson: i'll try to make a point of doing some testing
<slangasek> broder: so hey, I did think of a multiarch-related task that'll need help this week
<slangasek> broder: I've fixed up the packages in main that have .la files that referenced other .la's that have moved for multiarch, but we've got a good number of them in universe that still need to be touched
<broder> slangasek: that totally sounds like something i could do
<broder> hmm...is there a known issue with ubiquity in maverick? this is the second time i've gotten a segfault in libapt-pkg.so
<ScottK> kklimonda is pretty good with that kind of thing too.
<broder> might be connected to checking the "download updates" box
<broder> slangasek: and when i find those, it's just a no-change rebuild, right?
<slangasek> broder: "find" - I have the full list, let me post it
<slangasek> broder: and you can do a no-change rebuild, or you can fix up the packaging to clean up the .la files according to Policy 10.2, depending on how much time you want to invest
<slangasek> but there are >100 affected packages, so... :)
 * micahg has libmpd already
<slangasek> broder: http://people.canonical.com/~vorlon/broken-srcs-universe.txt
<broder> slangasek: the rule of thumb for getting rid of .las is roughly that i can get rid of them as long as nothing that build-deps on the package also ships .las, right?
<slangasek> broder: yes; in practice I've found it easier to just apply the dependency_libs sed trick to all affected packages
<slangasek> (easier than tracking down revdeps and looking for .la files)
<broder> hmm, ok, i like that plan better. because actually getting rid of the .la files would require a bunch of rebuilds in the opposite direction of fixing the multiarch issue :)
<seb128> seems that clean those would be better to do at a cycle start though
<slangasek> anyway, it's great to clean up the underlying .la issue for as many of these as we can, but since each of these causes FTBFS for their own reverse-deps, it's more important that we get them rebuilt
<slangasek> seb128: are you concerned that cleaning them will break other things?
<seb128> note that the GNOME stack is mostly clean of those for a while, we start on that for a while
<slangasek> yep :)
<seb128> slangasek, no, GNOME ones are already cleaned as I said ;-)
<slangasek> heh
<seb128> we have as a policy to not ship a .la for new desktop libs for some time
<seb128> and clean-la was easy to use for cdbs sources
<slangasek> yeah, though it seems that clean-la in cdbs has never made it upstream...
<seb128> "upstream"?
<seb128> debian is upstream for cdbs or I'm missing something?
<slangasek> yes
<slangasek> and Debian doesn't have the clean-la.mk, last I looked
<seb128> oh, it's in gnome-pkg-tools
<slangasek> right - it's implemented both places :)
<slangasek> only the gnome-pkg-tools one is in Debian
<seb128> well, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586082
<ubottu> Debian bug 586082 in cdbs "clean-la.mk rules file" [Wishlist,Open]
<slangasek> yep
<slangasek> so I've been adding a hand-written rule when fixing this in cdbs-using packages, since adding build-deps to gnome-pkg-tools for everything is not appropriate :)
<slangasek> (and because these changes should be upstreamed to Debian ASAP)
<seb128> but when we had those discussions previously Keybuk argued that .la were useful and should not be cleaned
<seb128> it has been hard to get a consensus on what to do
<slangasek> oh, Keybuk's right
<slangasek> it would be good to keep the .la files around for static linking
<slangasek> but nobody has ever fixed libtool upstream to DTRT for the dynamic linking case, so we do what we can - we fix it in the packaging
<slangasek> (to avoid having to patch every single upstream source that uses libtool)
<seb128> wouldn't be easier or better to put ressources on fixing libtool? ;-)
<slangasek> have you ever looked at libtool's source?
<seb128> or upstream doesn't want it to be "fixed" for some reason
<seb128> i.e like don't agree on what fixed would be
<seb128> hum, no, and I don't think I want ;-)
<slangasek> I think upstream has looked into the abyss, and reproduced what they saw in the form of shell code; I don't know if they agree or not on what "fixed" should be, it's hard to get coherent answers out of them ;P
<seb128> ;-)
<seb128> anyway it seems that after this round of cleaning we can start the next cycle the other way around and start dropping those if we want
<slangasek> that would be good... let's do it in Debian though, I don't want a thousand deltas for libtool :)
<seb128> slangasek, indeed, and again I wonder why I'm talking there, the things I deal with are already out of those issues ;-)
 * slangasek grins
<kklimonda> slangasek: so for now rebuilding all the packages should be enough? And then we can revisit it in oneiric?
<slangasek> kklimonda: sure
<slangasek> time allowing I think cleaning .la files is also ok, but there's no requirement to
<slangasek> I think it will save a little bit of time overall in the end
<kklimonda> slangasek: ok, I'll see how much time can I put into this :)
<slangasek> kklimonda: cheers!
<slangasek> kklimonda: which end of the alphabet are you starting from? :)
<kklimonda> I'll start with g :)
<broder> kklimonda: if you give me a sec, i'm working on a graph so we can make sure we get the dependency order right
<kklimonda> broder: sure, I'm not going to start tonight anyway. It's too late for that :)
<broder> kklimonda: cool. i'm taking work off on friday to jam, so i'll catch up with you then
<slangasek> tkamppeter: hi there - did you need something from me earlier, or was it the cups upload that pitti is taking care of?
<slangasek> mr_pouit: so with libxklavier, why is it substituting variables into its .pc file from another .pc file, instead of using the Required field that's there for this purpose?
<tkamppeter> slangasek, the CUPS uplod is only a workaround, I wanted to make you aware of the real bug in libpng, it is about bug 710881.
<ubottu> Launchpad bug 710881 in libpng (Ubuntu) "cups: Test Page /usr/lib/cups/filter/bannertops failed, test page and banner pages do not get printed" [Medium,Confirmed] https://launchpad.net/bugs/710881
<slangasek> tkamppeter: ah - please note that I don't know anything about libpng, I've only touched the package for library packaging issues
<tkamppeter> slangasek, CUPS uses libpng to load PNG images, principally this works fine as long as the PNGs are RGBA,
<tkamppeter> slangasek, sorry, I looked at the last thrree changelog entries and they were all from you. I wanted to make our libpng guru aware.
<slangasek> tkamppeter: yep, I understand how you drew that conclusion :)
<tkamppeter> slangasek, the CUPS package I can prinicipally upload by myself (what I do when pitti is on vacation), but usually I let pitti upload it to keep a sync between Debian and Ubuntu (pitti is the Debian maintainer of CUPS).
<slangasek> sure
<tkamppeter> slangasek, seems that libpng is not really maintained by Ubuntu but only synced/merged from Debian.
<slangasek> yes
<slangasek> you're best off discussing this with upstream
<hv> is there a channel for unity?
<TheMuso> hv: You want #ayatana.
<hv> thanks
#ubuntu-devel 2011-03-30
<slangasek> broder: did you have a graph you want us to use for upload ordering?
<broder> slangasek: oh, sorry - got distracted. let me see if i can pull that together now
<slangasek> it's not a big deal if you don't have it, I know where the 'retry' button is :)
<broder> it's probably not worth the effort, since i'd have to go parsing binary packages and build-deps and so forth. retry button is probably easier :)
<broder> (i was originally planning to just grep apt-get dotty for the packages you list, but in hindsight not actually what you need)
<slangasek> yep :)
<psusi> must... annihilate... patches applied in bzr....
<cjwatson> psusi: any chance of recognising differences of opinion?
<cjwatson> rather than just ranting?
<psusi> cjwatson, if they have a good rationale... but it's causing me a great deal of pain
<cjwatson> yes, I have a good rationale for doing it that way in my packages.
<psusi> and besides, I thought you agreed with this one? ;)
<cjwatson> no, I disagree.
<cjwatson> it permits unified 'bzr blame' and 'bzr log', regardless of whether a change happened upstream or in the distribution
<cjwatson> (yes, parted etc. is done differently, that's 'cos I'm not sole maintainer)
<psusi> that's true... but it screws bzr merge
<cjwatson> it can be handled
<psusi> and makes bzr diff reviewing a royal PITA
<cjwatson> quilt pop -a; bzr merge --force; then quilt push and quilt refresh your way up the stack
<cjwatson> it's different, but it's straightforward once you get the hang of it
<cjwatson> you have to refresh all the patches anyway, so it's not that big an imposition
<cjwatson> all it really does is change the order of operations
<cjwatson> I concede that it is somewhat easy to get confused in the middle; in my packages I accept that trade-off for what I see as bigger benefits
<psusi> does that work?  I would think that would break quilt since the merge would want to mark quilt patches as applied that aren't
<cjwatson> psusi: you quilt pop -a if you're merging from upstream, which has no patches applied; if you're merging from some other branch with quilt patches applied, you pop down to the base at the branchpoint, basically
<cjwatson> but more generally, I do this quite a lot, I'm not making it up
<YokoZar> cjwatson: or you merge all patches upstream and sidestep the problem :)
<lifeless> YokoZar: that creates new isues
<lifeless> like high latency on fixes
<bbigras> Looks like bug 590564 and bug 479741 are duplicates. I'm not sure which one to close as there more subscriber to the newest one.
<ubottu> Launchpad bug 590564 in Caffeine "[needs-packaging] Include 'Caffeine' into the repo." [Wishlist,Confirmed] https://launchpad.net/bugs/590564
<ubottu> Launchpad bug 479741 in Ubuntu "[needs-packaging] Caffeine for Linux" [Wishlist,In progress] https://launchpad.net/bugs/479741
<micahg> bbigras: you can mark the older one a dupe of the newer one, further bug triage help can be found in #ubuntu-bugs
<bbigras> micahg: ok thanks
<micahg> YokoZar: ia32-libs broke flash
<YokoZar> micahg: it tends to do that.  Do you know the particulars as to how?
<stgraber> YokoZar: not sure how the whole nspluginwrapper stuff works but a ldd on the .so shows some missing libs: http://paste.ubuntu.com/587209/
<stgraber> that might be "normal", would have to compare with a system using the previous ia32-libs
<stgraber> http://paste.ubuntu.com/587211/
<stgraber> that's the same ldd on a weblive server that's still using the old version
<YokoZar> stgraber: which file are you ldding there?
<stgraber>  /usr/lib/flashplugin-installer/libflashplayer.so
<YokoZar> http://paste.ubuntu.com/587212/ <-- maverick
<ScottK> It would be deeply ironic if flash didn't work with multi-arch.
<YokoZar> ScottK: nah, turns out it's just libnss3-1d being only a symlink package now and the real files are back in libnss3
<ScottK> Ah.  Not nearly so fun.
<YokoZar> man I've spent all day cleaning up ia32-libs
<YokoZar> and the greater part of yesterday
<YokoZar> each time I'm ready to start another major upload I find something new broken and have to rerun the script that takes about 45 minutes
<micahg> YokoZar: I downgraded to the maverick version and that was fine
<YokoZar> micahg: figured out the problem, uploading fix
<YokoZar> which will take a long time
<micahg> YokoZar: awesome, thanks
<slangasek> micahg: ia32-libs broke flash> clearly you should enable my ppa then, it works fine with multiarch ;D
<micahg> slangasek: heh, I took the easy out and downgraded to the maverick version
<slangasek> awww
<pitti> Good morning
<ohsix> hm, ViTE is packaged but i can't see that any of the tools that generate traces are
<cdbs> gnome-cups maintainer here?
<cdbs> oops, that's not a package
<dholbach> good morning
<broder> morning, dholbach
<dholbach> hi broder
<didrocks> good morning
<hrw> morning
<abhinav-> dholbach, good morning.
<dholbach> hey abhinav-
<abhinav-> dholbach, I did the session in my college 2 days back. Used your blog posts as reference (with citation), a lot of students are now using Ubuntu :)
<dholbach> NICE
<dholbach> abhinav-, that's awesome!
<dholbach> how did it go?
<ohsix> anyone running natty & unity/compiz w/classic desktop that can install and try running visual-regexp? expect compiz to crash if doing so, and let me know if it in fact does
<abhinav-> dholbach, it was awesome, I tried to show to fix a bug as well, but internet speed wasn't good. But it was good.
<dholbach> abhinav-, so the docs were understandable enough?
<abhinav-> dholbach, yes, I they are in a very simple and plain language. quite easy to follow
<dholbach> sweet
<abhinav-> dholbach, I have something to ask, maybe email would be a better place to ask. Which email id you check more frequently ?
<dholbach> I check all of them frequently - just use dholbach at ubuntu..com
<abhinav-> ok thanks :)
<mr_pouit> slangasek: yup, I don't know why it does that =]
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: beta freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: pitti
<cjwatson> Riddell: can you look at bug 745446?
<ubottu> Launchpad bug 745446 in ubiquity (Ubuntu) "Kubuntu natty pre-beta installer crash" [Undecided,New] https://launchpad.net/bugs/745446
<pitti> dholbach: if I apply a patch in bzr, but don't upload it yet because of the freeze, should I unsubscribe ubuntu-sponsors? Or will that skew the stats?
<doko> pitti: did you merge your eglibc changes with mine before uploading to maverick-proposed?
<pitti> doko: ? I didn't upload eglibc to maverick-proposed, at least not recently?
<pitti> doko: I only see your upload in http://launchpadlibrarian.net/67426105/eglibc_2.12.1-0ubuntu10.3_source.changes
<doko> just got an email about
<doko> 672177
<pitti> doko: ah, I sponsored the sysvinit part of it
<pitti> (jhunt's patch)
<Daviey> doko, Early results of your archive rebuild are scaring me :(
<Daviey> Is this all more multipath fallout?
<Daviey> err, multiarch
<doko> Daviey: heh, you'r the tech-lead ;)
<doko> I didn't look yet at the build failures yet
<Daviey> pitti, apport on i386 looks odd... "error: /build/buildd/apport-1.20/debian/tmp/usr/share/icons/hicolor/scalable/mimetypes/text-x-apport.svg: No such file or directory"
<pitti> Daviey: argh, that again; it's a transient issue, a rebuild usually fixes it
<pitti> unfortunately I was never able to reproduce it locally :(
<Daviey> ahh
<dholbach> pitti, feel free to unsubscribe - if you're subscribed and don't forget about it ... :)
<pitti> dholbach: I assigned it to me, so I won't forget about it; I just wondered whether the stats look at the ubuntnu-sponsors subscribed bugs, or look at the actual uploads
<Daviey> doko, I'm scratching my head over some of these build failures... kubuntu-docs looks odd aswell.
<dholbach> I mean... it's reviewed, no?
<dholbach> so it can get off the list - there's nothing that needs to be done about it from a sponsors perspective
<pitti> dholbach: yes, I ported it to upstream git master, reported it upstream, and applied in our packaging bzr -- that's about as far as I can get it right now
<pitti> dholbach: ack, thanks
<dholbach> great
<doko> Daviey: now, before everybody starts scratching heads ... could you file bug reports for these which don't look multiarch related?
<Daviey> doko, TBH, i'm questioning if it's an issue with the packages or the build environment.  Going to rebuild the packages i need to be concerned about on that list locally.
<doko> I think slangasek will take care of the multiarch stuff
<Riddell> Daviey: where is this kubuntu-docs build failure?
<Daviey> Riddell, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110329-natty.html
<Cheery> I've got design in mind for a new windowing API
<Cheery> you think you'd be interested if I would write it up somewhere?
<geser> pitti: re the apport FTBFS: which filesystem did you use when trying to reproduce it? it seems to depend on the file system as I could reproduce it with pbuilder and tmpfs the last time I looked at it (pbuilder with ext4 is fine IIRC) (see also http://lists.debian.org/debian-devel/2010/12/msg00149.html). I don't know if lucas_ found out what's causing this.
<pitti> geser: ext4, yes
<tseliot> pitti: shall I push this commit for Jockey? https://pastebin.canonical.com/45432/
<pitti> tseliot: please remove the code altogether; the abi check should take care of it now
<pitti> tseliot: (and please add it to the changelog)
<pitti> tseliot: I bounced your abi problem mail to bryceh, FYI; any idea what's causing this?
<tseliot> pitti: do you mean the whole available() method or just what I commented out?
<pitti> tseliot: just the top two lines that you commented out; the second hunk just looks like whitespace change
<tseliot> pitti: right, that would be good to figure out before Natty's release
<tseliot> pitti: yes, I replaced a tab with whitespaces
<pitti> tseliot: ah, thanks; that's good
<tseliot> ok
<doko> hrm, rebuilding language packs during the test rebuild :-/
<doko> chrisccoulson: are the language pack builds urgent?
<chrisccoulson> doko - not really, but they'll be finished in about 5 minutes ;)
<geser> who wins the buildd? the language packs or the test rebuild?
<geser> the armel buildds are busy for the next 3 weeks?
<GunnarHj> Ridell: Hi Jonathan, can we talk?
<seb128> GunnarHj, you mean Riddell?
<seb128> GunnarHj, you want to use tab to complete nicknames ;-)
<GunnarHj> seb128: Indeed I do. Thanks!
<seb128> yw
<Riddell> hi GunnarHj
<GunnarHj> Riddell: Hi, so you noticed anyway. :)
<Riddell> yes, because seb128 highlighted me
<GunnarHj> Riddell: Saw you are a member of ubuntu-core-doc.
<GunnarHj> Riddell: I have written an i18n document for ubuntu-docs. Branch linked to bug 742857.
<ubottu> Launchpad bug 742857 in ubuntu-docs (Ubuntu) "i18n matters ought to be properly documented" [Undecided,In progress] https://launchpad.net/bugs/742857
<GunnarHj> Riddell: Asked a couple of questions in a comment on the merge proposal, and would appreciate if we could talk about them.
<Riddell> GunnarHj: I don't have anything to do with ubuntu docs, I'm there to help kubuntu doc writers
<GunnarHj> Riddell: Ok, I see. Any idea of who to contact?
<Riddell> GunnarHj: https://wiki.ubuntu.com/DocumentationTeam/Contact seems to be the page with that information
<GunnarHj> Riddell: Yeah, I know. The first item on that page suggests #ubuntu-doc, but that room seems to be very quiet.
<GunnarHj> Riddell: Anyway, I won't bother you more about it. Thanks for quick reply!
<seb128> GunnarHj, try pinging mdke
<GunnarHj> seb128: Already did that, actually. Think I'll wait a couple of hours and see what happens.
<GunnarHj> seb128: Thanks again for helping out!
<seb128> ok
<pitti> hey GunnarHj, how are you?
<ev> mvo: where is software center grabbing the category icons from? I thought they would be in app-install-data, but they don't appear to be.
<GunnarHj> pitti: Hello, I'm fine. Thx for the gdm approval.
<pitti> GunnarHj: thanks for working on it!
<mvo> ev: it uses the icon theme mostly, e.g. applications-versioncontrol and similar
<GunnarHj> pitti: I agree that the .xsession-errors.old test is a little hackish, but that's as far as I got on my own. Did you have anything better in mind?
<ev> mvo: ahhh, Humanity provides that
<ev> I was looking elsewhere
<ev> thanks a bunch
<mvo> ev yw
<pitti> GunnarHj: there's no real housekeeping when an user installs the first time or upgrades from an earlier release, I'm afraid
<doko> tkamppeter: please could you have a look at the ijs build failure (printing package)? https://launchpad.net/ubuntu/+archive/test-rebuild-20110329/+buildjob/2396040
<doko> pitti, seb128: two gnome build failures, one multiarch related: libgtop2 and gnome-games
<pitti> doko: say hello to Sweetshark  :)
<pitti> doko: do you have an URL to the log?
<doko> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110329-natty.html
<doko> pitti: glib-networking too
<doko> Sweetshark: does 3.3.2 build on lucid?
<GunnarHj> pitti: That's what I thought. And, after all, it's not a critical test. Sun will rise tomorrow even if it fails. :)
<pitti> doko: yep, queueing; thanks
<pitti> GunnarHj: let's hope :)
<ev> slangasek: in ubiquity we generate a sample hostname off dmi data, so Evan-MacBookPro.  This can get a bit long and apparently breaks NETBIOS. https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/735072 http://support.microsoft.com/kb/909264
<ubottu> Ubuntu bug 735072 in ubiquity (Ubuntu) "The hostname proposed by installer is too long for file sharing to work correctly." [High,Confirmed]
<ev> slangasek: what are your thoughts on us generating a stub smb.conf with the netbios name set to the hostname truncated at 15 characters
<ev> or rather, can we modify the samba package to do this
<doko> pitti: bamf looks desktopish too
<Sweetshark> doko: It does now in pbuilder it seems. pbuilder didnt like the gcj-native-helper dependency, although that was there in the last release too. So I am wondering more why it did build before.
<doko> Sweetshark: I think gcj-native-helper was not in lucid
<doko> mvo: could you look at the apturl build failure?
<mvo> doko: sure
<Sweetshark> doko: it wasnt, so i wonder why it did build with such a dep.
<tkamppeter> doko, thanks for the hint, I will check and upload a fixed package today.
<doko> Daviey, libdbd-sqlite3-perl libcompress-raw-zlib-perl bind9 look serverish ... could the server team look at the build failures?
<Cheery> http://paste.pocoo.org/show/362614 <- here's a specification draft.
<Cheery> it's that windowing library I told you about.
<Daviey> doko, bind9 we already have a fix for.
<doko> thanks
<Daviey> doko, looking into the other two now.. thanks
<geser> Sweetshark: have you check if perhaps it was provided by one package in lucid?
<wolfe> ^_^
<wolfe> can't remember, are there other channels besides #ubuntu-motu for packaging?
<geser> wolfe: #ubuntu-packaging but it's mostly pretty quiet
<wolfe> ah okay
 * wolfe loves all the dev channels anyway. One of the ubuntu was extremely helpful to talk me through step by step in patching, attributing, creating and sending a package update for a serious memory leak :)
<wolfe> *one of the ubuntu devs
<ari-tczew> wolfe: who is it?
<wolfe> I can't remember, but I do have it in my logs :)
<tkamppeter> doco, uploaded ijs_0.35-7ubuntu1, this should solve the build problem.
<wolfe> Definitely one of the great appraisals of Ubuntu, some of the devs are nice to go out of their way to help possible future contributors.
<tkamppeter> doko, uploaded ijs_0.35-7ubuntu1, this should solve the build problem.
<doko> Daviey: libuuid-perl too? this all looks like a systematic problem
<tkamppeter> doko, my upload was rejected, as ijs is new in Ubuntu in this cycle and I did not ask the technical board yet to give me the upload permission. I asked now, but it depends on how quickly they answer until I can re-upload. If it is urgent (to get it into beta1), I can send you the debdiff by e-mail.
<rickspencer3> mvo, for bug #671016, shall I just finalize the copy myself and beg the web team to put it somewhere and give me url?
<ubottu> Launchpad bug 671016 in update-manager (Ubuntu Natty) "EOL needs to be handled more elegantly" [High,In progress] https://launchpad.net/bugs/671016
<rickspencer3> will that help you finish it?
<doko> tkamppeter: I don't understand ... https://launchpad.net/ubuntu/+source/ijs
<tkamppeter> doko, what is wrong there?
<tkamppeter> doko, I do not see ijs_0.35-7ubuntu1.
<doko> tkamppeter: well, send me the debdiff, and I'll upload
<mvo> rickspencer3: I just send a mail to them, let me forward you what I wrote
<pitti> doko, tkamppeter: hang on, I can add ijs for Till
<pitti> Added:
<pitti> Archive Upload Rights for till-kamppeter: archive 'primary', source package 'ijs'
<pitti> tkamppeter: try again, please
<Daviey> doko, oh joy...  i wonder how much of perl is broken
<tkamppeter> pitti, thanks, package re-uploaded.
<tkamppeter> doko, the debdiff is in your mail now, but most probably we will not need it any more.
<tkamppeter> pitti, upload worked, is in wait-for-approval state due to beta freeze.
<pitti> cool
<BlackZ> pitti: good afternoon. Could you please have a look at bug #742598 ? thanks
<ubottu> Launchpad bug 742598 in gnome-system-tools (Ubuntu Natty) "users-admin - newly added user is disabled when using the generated password option" [High,Triaged] https://launchpad.net/bugs/742598
<pitti> hey BlackZ
<pitti> BlackZ: yes, will do in a minute, just sponsoring xdg-utils
<doko> hmm, libssh build failure is not reproducible
<mdeslaur> slangasek: do you have an autoconf example for getting the equivalent of $DEB_HOST_MULTIARCH?
<mdeslaur> slangasek: (I need it without setting --libdir)
<pitti> BlackZ: looks fine, thanks!
<BlackZ> pitti: thank you for the sponsoring! :)
<mdeslaur> slangasek: ah, never mind, found it...thanks
<seb128> can someone reject https://code.launchpad.net/~dstansby/gnome-control-center/bugfix-lp-572025/+merge/25087
<ubottu> Ubuntu bug 25087 in udev (Debian) "udev - udevd fails to timeout events if the kernel have no inotify" [Unknown,Fix released]
<pitti> I can't, it's an upstream branch
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: beta freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<SpamapS> pitti: good (morning|afternoon|evening)!
<pitti> hey SpamapS, how are you?
<pitti> SpamapS: do you feel SRUey? :-)
<SpamapS> pitti: I do, however we will need to do IRC only for the time being, as family is still asleep. :)
<pitti> ah, sure
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: beta freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: mterry
<slangasek> ev: where do you intend to put this stub smb.conf?  that will play havoc with the sama package when installed
<ev> slangasek: well, I thought through it more as I typed that.  Would it not be better to just do this in the samba package itself
<ev> if the hostname is already greater than the maximum allowed by netbios, set the netbios name to a truncated version
<doko> slangasek: I asked Daviey about the lib-*-perl failures, seems to be something systematic
<doko> librra seems to have an issue with .la files
<slangasek> ev: yes, that seems better
<ev> slangasek: okay
<doko> cjwatson: gcj-4.4 built, please accept gnat-4.4
<ev> I've updated bug 735072 accordingly
<ubottu> Launchpad bug 735072 in samba (Ubuntu) "The hostname proposed by installer is too long for file sharing to work correctly." [Undecided,New] https://launchpad.net/bugs/735072
<cjwatson> doko: done
<juliank> Where should I complain if one user files 6 duplicates, after I told him 3 times to stop?
<juliank> https://bugs.launchpad.net/~steinhauserchristian/+reportedbugs?field.omit_dupes.used=&field.searchtext=ndiswrapper-dkms
<cjwatson> juliank: #launchpad perhaps
<slangasek> doko: so we have the new 'svammel' tool for filing bug reports for build failures; by default it's set up to file bugs for armel regressions, but if it checks out I could also set it to filing bugs for the x86 build failures.  Should I?  Are there particular tags we should use for the bugs (to avoid filing duplicates)?
<doko> slangasek: well, why not. but maybe not for the ones which are already superseded, and not for emacs23 and ecj
<Ampelbein> juliank: I think the problem lies more in apport than in the user. If there is a package installation failure, a box comes up asking the user if the problem should be reported. Apport should remember when it already reported the same error for the same package instead of asking the user to file the report again.
<slangasek> doko: the tool knows when they're already superseded by checking the main archive
<slangasek> doko: so, what tags should we use to avoid duplicates? :)
<juliank> Ampelbein: If I tell the user three times to stop reporting duplicates, the user should remember to not click on the button again.
<doko> ftbfs ? I think we can't be more specific
<slangasek> doko: could just be 'ftbfs' + 'natty'
<doko> ok, better
<slangasek> cool
<slangasek> I'm currently doing a test run to prove the tool works for filing armel bugs without blowing up
<slangasek> if that checks out, I can tweak it and do the x86 ones
<Ampelbein> juliank: yes, that's the second part of the problem (user's just clicking report problem instead of thinking first)
<doko> slangasek: and not for m17-lib ijs lintian
<ScottK> slangasek: Is this the tool that was earlier reporting bugs on armel FTBFS that had already been fixed?
<juliank> Ampelbein: Locking the account for a month would help in such cases
<slangasek> doko: because those are false positives or already diagnosed?
<slangasek> ScottK: yes, but that was operator error while it was being developed
<doko> slangasek: already diagnosed, sync requested, or bugs already filed
<slangasek> doko: if you tag the bugs 'ftbfs' 'natty', no need to manually exclude them
<ScottK> slangasek: How's avogadro coming?
<ScottK> (speaking of armel FTBFS)
<doko> slangasek: can you targed these for the release and set a milestone?
<slangasek> ScottK: kunal is continuing to look at it, I believe he was going to be talking to folks on #kubuntu-devel overnight
<ScottK> Great.
<slangasek> ScottK: it's a tricky one, there's a lot of code in there that's non-optional and completely dependent on libGL; it didn't show up in an emulated i386 build test, because of course libqt4-opengl-dev on i386 *does* pull in GL instead of GLES2
<ScottK> Right.
<pitti> doko: do you know if the main packages on http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110329-natty.html are already complete?
<doko> pitti: no. i386 at m, amd64 at libx
<pitti> ah, ok
<bdmurray> pitti: wrt to bug 551809 how could we have written a pattern for it?
<ubottu> Launchpad bug 551809 in gtk+2.0 (Ubuntu Natty) "gnome-settings-daemon crashed with SIGSEGV (dup-of: 729150)" [High,Triaged] https://launchpad.net/bugs/551809
<ubottu> Launchpad bug 729150 in libappindicator (Ubuntu Maverick) "libappindication crashes in gtkstatusicon code on update" [High,Triaged] https://launchpad.net/bugs/729150
<pitti> bdmurray: we recently moved to a single global pattern list, so we can now write patterns which are independent of a particular package
<bdmurray> pitti: right but it seems to me that the Stacktrace is vague until it is retraced
<pitti> yeah, unfortunately
<pitti> so I'm afraid I have no good idea either
<bdmurray> well maybe the retracer could be improved to consolidate duplicates across packages?
<pitti> bdmurray: that's a bit blurry -- for some crashes we actually don't want to unify similar crashes on different packages
<pitti> there might be some middle ground, like unifying them if we have at least 5 levels of stack trace, and they have "enough" entropy in the names (for a to-be-defined treshold)
<bdmurray> pitti: I think it is something worth investigating as there are likely quite duplicates of this still hiding (unconsolidated) in Launchpad.
<slangasek> doko: target, milestone> I guess svammel doesn't currently implement that; do you consider that a blocker for getting the bugs filed, or can we go through and bump them up afterwards (scriptable, again)?
<pitti> I agree
<doko> slacker_nl: sure
<doko> slangasek: sure
<slangasek> ok
<pitti> doko: I have my little packaging army working on the four desktopish FTBFS now
<Sarvatt> doko: this fixes the linphone ftbs for me, if it's correct on the other hand I'm not sure.. - http://sarvatt.com/downloads/patches/mediastreamer2-v4l1-ftbs.patch
<doko> pitti: ^^^ is linphone desktopish too? ;)
<pitti> doko: kubuntuish, but yes, desktop arena
<Vi0L0> hi, anybody's using fglrx 8.840? if so - does vaapi works for you?
<didrocks> slangasek: thanks for the bamf fix! (of course, I just realized that when I bzr push the fix)
<slangasek> didrocks: no problem - I broke it, so I owed you a fix :)
<didrocks> :-)
<seb128> slangasek, do you look at libgtop as well? before I start on it ;-)
<slangasek> didrocks: I noticed only after upload that my rationale in the changelog was wrong... unity depends on it, which is far from "nothing", apparently I need to pay closer attention to my checkrdepends commandline... but I did rebuild testing of all the reverse-deps, nothing else breaks
<slangasek> seb128: I have not - that hadn't ftbfs yet by the time I went to bed :)
<seb128> slangasek, ok
<didrocks> slangasek: excellent and thanks for answering on my second remark just before I ask it :-)
<slangasek> :-)
<seb128> slangasek, urg, does it mean we will need to patch every single lib to set a --libdir=... or?
<slangasek> seb128: for actual multiarch conversions, yes.  to fix build failures, no
<cjwatson> seb128: smart helpers deal with it; http://wiki.debian.org/Multiarch/Implementation
<cjwatson> well, by which I mean dh(1) compat 9 :)
<directhex> 9!!?!
<seb128> hum ok
<cjwatson> yep, it's the one between 8 and 10
<seb128> can we make cdbs be smart? ;-)
<directhex> seb128, sounds like an oxymoron
<slangasek> seb128: how can you, cdbs has no equivalent to dh compat levels
<seb128> slangasek, I guess I should read the wiki before asking extra questions, I just assumed it could be default for any build ;-)
<seb128> but anyway libgtop which is unapproved builds fine there, I guess it's the "90_autotools.patch: - Dropped, using dh-autoreconf instead" which did it
<seb128> doko, pitti: ^
<slangasek> seb128: switching it on by default breaks your .install and .links files... has to be a controlled conversion, package-by-package :/
<seb128> hum, seems logic
<seb128> slangasek, thanks
<slangasek> ScottK: do you want to seed a spec for bug #745004?
<ubottu> Launchpad bug 745004 in update-manager (Ubuntu) "Same services restarted for pam library upgrade and libc upgrade" [Wishlist,New] https://launchpad.net/bugs/745004
<ScottK> slangasek: Want, no, but I will.
<slangasek> thanks ;)
<ScottK> slangasek: Done.
<pitti>  SpamapS: https://wiki.ubuntu.com/Bugs/HowToFilter
<slangasek> ScottK: blueprint name?
<jelmer> slangasek: hi
<jelmer> slangasek: would it be reasonable to (ab)use multi-arch to do cross compilation for Windows using mingw32 ?
<slangasek> jelmer: hey there :)
<ScottK> slangasek: https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-pam-restarts
<ScottK> Already fixed to use jcastro's just announced naming conventions.
<jcastro> sorry about that, normally I send that email along with the announcement
<slangasek> jelmer: yes and no - yes because there's certainly room in the namespace for windows, no because we don't have a win32 Debian architecture anywhere that you could actually ship such libraries as part of
<ScottK> jcastro: : No problem.  It was just ironic I read that mail 5 minutes after registering my first O bluepring.
<ScottK> pring/print
<slangasek> ScottK: looks good, thanks :)
<jcastro> ScottK: continuing the tradition of Foundations being done 5 weeks before everyone else. :)
<ScottK> slangasek: You're welcome.
<MadCow108> o_O ia32libs ubuntu11 doubled its size since ubuntu9
<ScottK> pitti: You're OK with any archive admin pressing the buttons for SpamapS or do you want to do it?
<pitti> ScottK: I'm ok with other AAs doing it, as long as they also run sru-accept.py
<ScottK> OK.
<pitti> https://wiki.ubuntu.com/StableReleaseUpdates#Reviewing%20procedure%20and%20tools explains queuediff and sru-accept.py
<ScottK> I've done the for jdong before.
<ScottK> Yep.
<ScottK> the/that
<pitti> queuediff will generate an appropriate sru-accept.py (without -b, to avoid opening the bugs)
<pitti> thanks
<jelmer> slangasek: That's good enough for what I need, I'll give it a try.
<slangasek> ScottK: is the current kdeedu ftbfs caused by avogadro?
<Riddell> slangasek: that and other bits of opengl
<ScottK> As Riddell says.
<Riddell> I have a compiled package in ~canonical-arm-dev ppa
<slangasek> ok, so I should mark bug #745846 as a duplicate of bug #707794 then
<ScottK> I'm expecting once kdeedu is done, kdeplasma-addons will be quite tractable.
<ubottu> Launchpad bug 745846 in kdeedu (Ubuntu) "kdeedu version 4:4.6.1a-0ubuntu2 failed to build on armel" [Undecided,New] https://launchpad.net/bugs/745846
<ubottu> Launchpad bug 707794 in kdeedu (Ubuntu Natty) "libqt4-opengl on armel should be compiled with OpenGL ES 2.x support" [High,Triaged] https://launchpad.net/bugs/707794
<ScottK> slangasek: Same for whatever the kdeplasma-addons bug is.
 * slangasek nods
<smoser> seb128, around ?
<seb128> smoser, hi
<smoser> regarding bug 740972
<ubottu> Launchpad bug 740972 in unity (Ubuntu) "running compiz in Xephyr kills compiz" [Low,Incomplete] https://launchpad.net/bugs/740972
<smoser> i really dont' even know the answer to "does it make the decorator crash or compiz crash?". i'm not familiar enough to know.
<smoser> i suspect its the "window decorator".. it gets replaced by metacity
<seb128> no
<smoser> but i think the easiest thing to do is for you (or someone who *would* know) to try it
<smoser> it literally takes 30 seconds to reproduce
<seb128> the decorator is what display the titlebar etc
<seb128> without it you get no bar with the close button etc
<seb128> but you can still switch between workspaces on dialogs, etc
<smoser> so this is a good example of why asking me is of no value, and reproducing it woudl be useful.
<seb128> well my comment was rather to give the reference to the other bug
 * slangasek hammers on https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue until lifeless takes note of the timeouts and fixes ;)
<seb128> I don't care enough to crash my current session
<seb128> smoser, but I will forward the comment to lamalex who set the bug as incomplete
<smoser> sure. i just get frustrated when bugs get marked as incomplete when they're easily reproducible.
<seb128> smoser, yeah, it's understandable
<smoser> seb128, i'm almost certain its the 'compiz' process that dies.
<smoser> well, not dies, but exits successfully
<smoser> (and then a 'metacity' process is spawned)
<slangasek> fta: thanks for the info on bug #745854 - should I assign this to you?
<ubottu> Launchpad bug 745854 in chromium-browser (Ubuntu) "chromium-browser version 10.0.648.204~r79063-0ubuntu1 failed to build on armel" [Undecided,New] https://launchpad.net/bugs/745854
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: beta freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<slangasek> ScottK, Riddell: bug #745892, another opengl qt revdep that didn't get caught earlier (not in main, not in kubuntu)
<ubottu> Launchpad bug 745892 in qtiplot (Ubuntu) "qtiplot version 0.9.8.2-1ubuntu4 failed to build on armel" [Medium,Triaged] https://launchpad.net/bugs/745892
<ScottK> Sigh.
<fta> slangasek, the ftbfs, sure. the other one, no. my part has been done.
<slangasek> fta: done, thanks :)
<doko> dear nfs-utils, this is *NO* configury, this just sucks
<slangasek> ScottK: ah, though janimo already filed this bug; marking as a duplicate then
<bambee> evening, are you planning to get the firefox 4 (release) into archives ?
<bambee> s/the//
<fta> slangasek, fix uploaded 30min ago, waiting for approval now
<slangasek> fta: cheers :)
<pitti> kirkland: thanks for the offer to help SpamapS with SRU buttons
<ScottK> slangasek and fta: I just accepted it.
<ScottK> (assuming "it" is Chromium
<ScottK> )
<chrisccoulson> bambee, it's already in the archive
<bambee> chrisccoulson: I just see 4.0~rc2+build3+nobinonly-0ubuntu1
<chrisccoulson> bambee, that *is* final
<bambee> ohhh
<chrisccoulson> rc2 became the final build
<chrisccoulson> it's identical ;)
<bambee> ok ;)
<fta> ScottK, thanks!
<ScottK> You're welcome.
<kirkland> pitti: sure thing
<pitti> slangasek, doko: glib-networking FTBFS uploaded, FYI
<slangasek> pitti: cheers
<pitti> SpamapS: oh, I noticed a gotcha: e. g. you responded to bug 687501 with an SRU ack, but that bug doesn't have ubuntu-sru subscribed yet, so the mail landed in a different folder (and only because I actually get bug mail for oem-priority); I might not see other bug responses from you at all
<ubottu> Launchpad bug 687501 in grub2 (Ubuntu Lucid) "when installer is multipath aware, grub fails to install" [High,In progress] https://launchpad.net/bugs/687501
<pitti> SpamapS: I'll still see them when I actually review packages in the queue, but response time will be much slower
<SpamapS> pitti: gotchya, will make sure ubuntu-sru is subscribed before acking them. :)
<cyphermox> anyone got a moment to look over https://code.launchpad.net/~mathieu-tl/ubuntu/natty/ubuntu-mono/icon-cache/+merge/55629 and sponsor it ? :)
<pitti> SpamapS: there, all SRU queues empty \o/
<pitti> ... speaking of which
<pitti> Daviey: what was the outcome for the bind SRU?
<cellardoor> I am going to build a .deb installer as part of a Computing project for Uni... I did it before a few years ago but can barely remember how to go about it, any good manuals or links?
<doko> does anybody have an idea about build failures like for srtp?
<slangasek> doko: hrrrm, I have seen that before
<slangasek> well, maybe not that exactly, I guess the ultimate failure message is generic
<slangasek> you would think a TeX formatting program would output prettier errors
<doko> the thing is that xolor.sty is present and even included
<doko> xolour,sty even
<doko> bah
<broder> TeX formatting program would output prettier errors> it's clearly been a long time since you tried to write (La)TeX, hasn't it, slangasek?
<slangasek> broder: not so long :)
<broder> i feel like i remember TeX errors ranking up there with C++/STL errors
<doko> broder: any *new* insight would be nice
#ubuntu-devel 2011-03-31
<broder> doko: looks like a doxygen issue. doxygen creates a doxygen.sty with \RequirePackage{xcolor}, but to get the \rowcolor command, you have to do \RequirePackage[table]{xcolor}
<broder> http://www.tug.org/pipermail/macostex-archives/2009-May/040402.html
<broder> doko: and the \RequirePackage directive is hard-coded into /usr/bin/doxygen
<broder> doko: debian bug 611656
<ubottu> Debian bug 611656 in doxygen ""table" option missing for latex package "xcolor" in generated doxygen.sty" [Normal,Open] http://bugs.debian.org/611656
<sladen> slangasek: ScottK: please could you accept the minimal change for 'ubuntu-mono' after cyphermox tracked it down (bug #741387)
<ubottu> Launchpad bug 741387 in ubuntu-mono (Ubuntu) "WARNING: gtk-update-icon-cache-3.0: The generated cache was invalid." [High,Fix committed] https://launchpad.net/bugs/741387
<ScottK> sladen: Not until after beta 1 is out.
<sladen> ScottK: is it actually building yet?  This introduces no new files, changes no files but allows a cache build on install to succeed
<ScottK> sladen: With very limited exceptions we don't accept seeded packages after the images are frozen so that they are current with what's in the archive when the beta is released.
<sladen> ScottK: thought the build didn't start until 02:45 ?
<ScottK> What build?
<ScottK> We have candidte ISOs almost fully tested.
<ohsix> cnd: thanks re: 742213, the instructions to do it myself are a bonus :D
<ohsix> i tried co'ing the version then generating the patch against HEAD^ but it didn't want to go
<ohsix> cnd: is there a way to keep a note of the proper way to fix it for the next release? or is the patch being present good enough, and the person looking at them in the future can figure it out from the bug number?
<sladen> ohsix: milestone it against 'later'
<ohsix> sladen: well theres a workaround for this release, it needs ui to adjust "minw", or a way to arrive at a usable number by itself for the next release
<cnd> ohsix, it's really a matter of working with the upstream projects to get things right
<cnd> that may be asking about it on xorg-devel for the synaptics driver
<cnd> or wherever the gnome mouse preferences dialog is maintained
<ohsix> ah
<cnd> we're reverting the change here merely cause we're so close to release
<cnd> that we don't have time to work things out with upstream
<ohsix> right
<cnd> but yes, something should be done with upstream
<cnd> I'm hesitant to say that the mouse preferences should have a new option
<cnd> partly because I'm not sure it would help (many people may be confused by it)
<cnd> and as a corollary, gnome doesn't like to take changes like that
<ohsix> yea i wasn't advocating it or anything, but i dunno if it can be enabled at all without a way to adjust it
<cnd> yeah
<cnd> I think maybe some common ground could be found by merely increasing the default threshold in synaptics
<ohsix> since it's very arbitrary, probably even down to the laptop model; and i know environmental changes affect it
<cnd> yeah, it's hard
<cnd> the real fix may be to report your usage to xorg-devel requesting that the patch be reverted
<cnd> because it just doesn't work uniformly for everyone
<cnd> are you comfortable trying to work with upstream, either gnome or xorg?
<cnd> I don't really want to add another issue to my plate if I can help it :)
<ohsix> not at the moment
<ohsix> i'll probably talk to whot about it sometime, he's the one that pointed out the patch & the person that works on it
<ohsix> he said i should adjust it so it works well on my touchpad but not how, there might be a quirk list or something that isn't as bad as it sounds
<cnd> ohsix, well, that's working with upstream :)
<cnd> it doesn't have to be on the xorg-devel mailing list
<cnd> he's the same person I would be talking to about the issue
<ohsix> ah
<linux-noob> what is the default FS in Natty ?? btrfs or EXt4
<RAOF> ext4
<dholbach> good morning
<pitti> Good morning
<pitti> tseliot, didrocks: should bug 685682 be closed with the new fglrx that we landed yesterday?
<ubottu> Launchpad bug 685682 in unity "[fglrx] compiz crashed with SIGSEGV in nux::IOpenGLSurface::UnlockRect()" [Critical,Triaged] https://launchpad.net/bugs/685682
<didrocks> tseliot: pitti: it seems that cnd still have that issue with the driver and workarounded compiz
<didrocks> pitti: anyway, there is still a need for a compiz upload which will come with other fixes (probably Monday)
<pitti> ah, thanks
<tseliot> pitti, didrocks: the fix should be available in the next upload of compiz (it's already available in a daily PPA)
<pitti> so I guess for now the fglrx tasks should be closed then?
<didrocks> tseliot: yeah, but as told, it's not working on cnd's machine, I asked him to check with you and jay
<tseliot> didrocks: sure, we definitely need more feedback
<didrocks> pitti: I think we can close the fglrx task and reopen if needed :)
<didrocks> yeah
<poolie> hi pitti?
<pitti> hello poolie, how are you?
<poolie> good thanks, how are you?
<poolie> iirc you're a good person to talk to about apport?
<pitti> poolie: I am I guess :)
<poolie> i was just thinking, ahead of UDS, about filing a bug or starting a spec for the issue of making it better at holding on to crash reports, if it's not able to file them right at the time they're noticed
<poolie> for instance if you have no net connection or lp is offline
<poolie> it seems like at the moment they're easily lost
<poolie> i don't think i'll get to actually work on this though
<pitti> poolie: it's mostly there already, though, with the --save option
<pitti> (for bug reports)
<pitti> for crashes it has always worked, the reports are in /var/crash/
<pitti> so I guess there's just a little UI missing here
<poolie> oh, if it fails to file they're left in /var/crash?
<pitti> poolie: yes
<pitti> for 7 days, then they get auto-cleaned
<pitti> so if you want to keep them around longer, you need to copy them somewhere else
<pitti> you can run ubuntu-bug foo.crash to report it again
<poolie> ok
<poolie> so there's no gui but perhaps anyone advanced enough to do this should be happy to run this command
<pitti> poolie: it's even mentioned in man ubuntu-bug
<pitti> (OMG documentation)
<pitti> poolie: so, there could be some UI improvements still; e. g. if the UI doesn't have network, it currently just fails with an error message; it could isntead give you a file save dialog
<pitti> poolie: btw, you can also double-click on a crash file in nautilus, that works too
<poolie> right, that sort of thing
<dholbach> Laney, thanks
<Laney> dholbach: no worries
 * Laney lights a candle for the MOTU Council
<soren> Laney: hm?
<Laney> soren: it's being decommissioned finally
<soren> Laney: How can you tell?
 * soren doesn't see any news on MOTU council in his inbox
<Laney> it's been dead for some time, we're just cleaning up the remaining Launchpad privileges
<ajmitch> killing it with fire?
<soren> Laney: Ah, ok.
 * ajmitch didn't know it still had any privileges to clean up
<Laney> one or two. :-)
<doko_> broder: thanks!
<seb128> jhunt_, hi
<jhunt_> seb128: hi
<seb128> jhunt_, is https://bugs.launchpad.net/ubuntu/natty/+source/gdm/+bug/436936/comments/20 ready for upload to natty?
<ubottu> Ubuntu bug 436936 in kdebase-workspace (Ubuntu Karmic) "gdm upstart job checks /proc/cmdline for single user mode, won't start on post-boot runlevel change" [Medium,Triaged]
<seb128> jhunt_, the comments you got seem to indicate it is?
<doko_> seb128: what did happen to python-gobject-doc? b-d of pygoocanvas?
<Riddell> jhunt_: and if so is there a patch for KDM?
<jhunt_> seb128: not yet, for 2 reasons. Firstly, not enough testing from users (IMHO) and secondly apw snuck in and changed gdm.conf under me :)
<seb128> doko_, it was merged back like 3 years ago?
<seb128> jhunt_, ok
<doko_> seb128: https://launchpadlibrarian.net/67723807/buildlog_ubuntu-natty-i386.pygoocanvas_0.14.1-1ubuntu4_MANUALDEPWAIT.txt.gz
<jhunt_> Riddell: the whole DM issue need discussion at UDS I feel. SpamapS and myself have a plan for "abstract jobs" to avoid all this configuration duplication.
<seb128> doko_, well, drop it, it's shipped with the other python-gobject binaries
<seb128> lunch, bbl
<tbf> Failed to fetch http://de.archive.ubuntu.com/ubuntu/pool/universe/libk/libkate/libkate1_0.3.7-3_amd64.deb  Hash Sum mismatch
<tbf> Failed to fetch http://de.archive.ubuntu.com/ubuntu/pool/universe/libm/libmimic/libmimic0_1.0.4-2build1_amd64.deb  Hash Sum mismatch
<tbf> Failed to fetch http://de.archive.ubuntu.com/ubuntu/pool/universe/libd/libdca/libdca0_0.0.5-3_amd64.deb  Hash Sum mismatch
<tbf> â shall i/we be worried?
<pitti> rbelem: hello, how are you?
<pitti> rbelem: should the kubuntu mobile arm images (or a subset) be published for beta-1? or does bug 712061 break them all?
<ubottu> Launchpad bug 712061 in kubuntu-mobile-default-settings (Ubuntu Natty) "kubuntu mobile images fail to load" [Medium,In progress] https://launchpad.net/bugs/712061
<janimo> lamont, slangasek some of the newly filed armel FTBFS bugs are those that time out because of insufficient resources on the build servers, and mentioned here https://bugs.launchpad.net/launchpad/+bug/705344
<ubottu> Ubuntu bug 705344 in Launchpad itself "builds which require more memory than a given buildd still try that buildd" [High,Triaged]
<Riddell> pitti: not worth publishing them, they don't do anything
<pitti> Riddell: ok, thanks
<ogra_> Riddell, that bug is pretty confusing btw
<Riddell> ogra_: how so?  it is a fairly broad bug covering several issues we've had
<rbelem> hi pitti :-)
<rbelem> hi Riddell ogra_
<ogra_> Riddell, well, the initial description clearly rules it out for armel
<ogra_> since we dont produce any live images
<ogra_> the last comment makes it so broad then that it could match everything
<rbelem> i ran a snapshot from some days before beta and it worked fine, but currently seems to be not
<Riddell> rbelem: on i386?  what plasma workspace was running?
<rbelem> Riddell, on i386
<rbelem> Riddell, i was unable to test on my beagleboard
<rbelem> no keyboard, mouse
<rbelem> there is a bug for that
<rbelem> usb otg support is missing
<ogra_> must be an old beagle then
<rbelem> yup
<ogra_> (i dont think we test on anything older than XM anymore)
<ogra_> though with the new headless images we might start that again
<rbelem> but it is omap3
<ogra_> yeah, but it has 256M
<ogra_> not suitable for running a desktop on it
<rbelem> yeah... too slow
<rbelem> Riddell, the image that i tested is from http://cdimage.ubuntu.com/kubuntu-mobile/daily-preinstalled/current/
<Riddell> rbelem: well that's ARM not i386
<rbelem> ops
<rbelem> that i test on beagle
<rbelem> brb
<Riddell> mvo: hmm, maybe we should revert the workaround for bug 656876
<ubottu> Launchpad bug 656876 in update-manager (Ubuntu) "distupgrade crashed during conf file change review" [Critical,Fix released] https://launchpad.net/bugs/656876
<mvo> Riddell: if that works fine now, I'm happy to do it
<Riddell> mvo: well we'd need to test to be sure, let's leave it disabled for beta 1 and enabled it next week and test, I've filed bug 746431
<ubottu> Launchpad bug 746431 in update-manager (Ubuntu) "Allow to view differences in conf file changes" [Undecided,New] https://launchpad.net/bugs/746431
<mvo> thanks Riddell
<seiflotfy> hey guys
<seiflotfy> any1 successfully using an external monitor with natty
<Riddell> how's this https://help.ubuntu.com/community/NattyUpgrades/Kubuntu ?
<pitti> seiflotfy: I do that all the time (laptop in dock)
<seiflotfy> pitti, its not working here
<seiflotfy> when i request to change to an external monitor
<seiflotfy> the external monitor keeps flickering
<RoAkSoAx> seiflotfy: Intel Video card?
<seiflotfy> yeah
<RoAkSoAx> seiflotfy: that's a known bug
<seiflotfy> crap
<RoAkSoAx> seiflotfy: you have two options. 1. don't disable LVDS
<RoAkSoAx> seiflotfy: or turn off LVDS with xrandr
<seiflotfy> how do i turn off lvds
<pitti> seiflotfy: ah, I have that effect as well -- I can't use gnome-display-properties ATM
<pitti> seiflotfy: xrandr --output LVDS1 --off
<pitti> seiflotfy: that's what I have in my "session setup" script
<pitti> seiflotfy: presumably like you I don't want the internal monitor to be on all the time while hte laptop is closed in the dock
<RoAkSoAx> bug #737891
<ubottu> Launchpad bug 737891 in xserver-xorg-video-intel (Ubuntu Natty) "[Arrandale] gnome-display-properties unable to correctly enable monitors connected to VGA" [High,Triaged] https://launchpad.net/bugs/737891
<pitti> hah, that's my chipset
<pitti> oh, I'm on DVI
<RoAkSoAx> pitti: I guess that's the same issue as with VGA then
<pitti> it worked fine until maverick, and broke at some point in natty :(
<RoAkSoAx> yeah
<RoAkSoAx> same happened to me
<pitti> I just tend to forget, as I have that xrandr thing
<RoAkSoAx> hehe yeah eventually I ended up using the same approach
<pitti> cjwatson: I just committed http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/natty/apport/ubuntu/revision/1763 for bug 745455; but then it came to my mind that this might actually be too much? Should we just read a subset of files as root?
<ubottu> Launchpad bug 745455 in apport (Ubuntu) "ubuntu-bug fails for ubiquity when not run as root" [Low,Fix committed] https://launchpad.net/bugs/745455
<pitti> (aside from the leftover print, just removed)
<pitti> cjwatson: or perhaps just do the root thing on the live system, but not on the installation?
<cjwatson> pitti: I vaguely remember it's just syslog that needs root
<cjwatson> let me check
<pitti> cjwatson: that bug was about casper.log
<pitti> cjwatson: (that one I could reproduce easily on the live system)
<cjwatson> ah, no, it's all installer logs
<pitti> cjwatson: I was just wondering if we coudl potentially expose passwords where we shouldn't
<cjwatson> that is a problem, but won't they be marked private?
<pitti> so instead of reading them we could also ignore htem
<pitti> cjwatson: crashes yes, but not bug reports (ubuntu-bug ubiquity)
<cjwatson> passwords shouldn't generally end up in the log (unless people are running in debug mode) - making the logs private was just an extra safety measure
<pitti> (we can tell them apart in the hook if necessary)
<cjwatson> not having the logs would make the reports useless, for the most part
<pitti> right, that's what I thought
<pitti> but I wondered if there was one file which we shouldn't attach, or perhaps pre-process
<pitti> cjwatson: e. g. for the debug log we could use "grep -v password" instead of "cat" or similar
<cjwatson> the file that might contain passwords if several other things simultaneously go wrong is also the most useful file to have
<cjwatson> and I'd be worried about preprocessing making it difficult to diagnose certain bugs
<soren> "Please enter your password, so that we can filter it out of your bug report"
<cjwatson> there's already a visible warning in debug mode saying that you shouldn't use a valuable password
<cjwatson> so to be honest I think it's OK to do as you did
<pitti> soren: I literealy meant "password", i. e. usually there's some debugging context around
<pitti> cjwatson: ok, thanks
<pitti> cjwatson: sounds fine, but better to have a second pair of eyes on it
<soren> pitti: I know, I'm just joking around :)
 * pitti just notices that his literally typo was an interesting morphing of that and "really"
<highvoltage> Edubuntu currently doesn't have an amd64+mac spin. Should it?
<cjwatson> I suspect IS would kill me for the extra gigabytes of disk on cdimage
<highvoltage> I would not like you to be killed
<highvoltage> (and to be honest I'm not /that/ fond of having another image to test)
<highvoltage> What should we do though? Tell mac users "sorry we don't support you"?
<ohsix> tell them to install ubuntu then edubuntu-desktop :D
<charlie-tca> Can they install the Ubuntu image and then upgrade?
<pitti> OOI, does the amd64+mac image also work on "normal" amd64 machines?
<ohsix> what does +mac involve, just some efi bits? couldn't there be one volume?
<pitti> i. e. could we just have that?
<charlie-tca> That is what Xubuntu tells them. Just install the mac/ppc image from Ubuntu and then install xubuntu-desktop
<highvoltage> charlie-tca: mostly. some of the biggest edubuntu features are installer related, so it might miss the point though
<ohsix> highvoltage: like the stuff that picks the different meta packages for grade levels?
<highvoltage> ohsix: yep, and the LTSP installer and LTSP live, and the Unity session stuff, and more language options
<ohsix> hmm
<ohsix> shrug
<highvoltage> I wonder if the standard amd64 iso will work with refit
<highvoltage> it would be an easy enough workaround if it does, which we could just include in the release notes
 * highvoltage should've bought his mac mini to the office today
<ohsix> is there something that precludes all volumes being +mac besides space?
<highvoltage> if space is the issue then the default edubuntu 64bit iso could just be +mac
<pitti> DVDs should certainly not have much of a problem with that
<pitti> on CD images it's got a bigger impact; e. g. the ubuntnu desktop amd64+mac has been oversized for ages
<pitti> it's not any more, but there are only very few languages on it now
<highvoltage> the edubuntu DVD is 2.5G, so a few extra 100K won't kill it :)
<pitti> highvoltage: at least the description on http://cdimage.ubuntu.com/daily-live/20110330/ makes it sounds like it should _also_ work on mac, not _only_
<cjwatson> pitti,ohsix> the normal amd64 can boot on UEFI-only machines, but not on Macs; amd64+mac is vice versa
<cjwatson> because Apple screwed up their firmware
<ohsix> weird
<highvoltage> :/
<pitti> ah, thanks; so it's not really a hybrid, it's an either-or
<cjwatson> at least many common versions of Mac firmware refuse to boot from a multi-catalog ISO9660 image
<ohsix> so i couldn't use the amd64 image on my main computer which isn't uefi but has 64bit gear in it?
<cjwatson> and multi-catalog is necessary to support UEFI
<cjwatson> ohsix: unless it's a Mac, you should be fine
<cjwatson> it's multi-catalog, so in general it should work with either BIOS and UEFI; Mac firmware is just useless
<cjwatson> s/ and / or /
<ohsix> so the +mac spin just has the one catalog with the mac files on it
<cjwatson> +mac actually means "no UEFI bits"
<cjwatson> but I thought it would be confusing to call it +noefi or something because Macs do have EFI
<ohsix> hm
<ohsix> oh right, they call efi uefi now huh
<highvoltage> if refit (http://refit.sourceforge.net/) works, would it be fine for Edubuntu to recommend it as a workaround on Mac systems? this also only seems to affect 64 bit, so we could also suggest using 32 bit on macs, right?
<cjwatson> UEFI is a newer version that has a multi-vendor standard
<cjwatson> EFI 1.x was AIUI proprietary
<ohsix> it doesn't just mean the old stuff they called uefi which was an efi firmware that did nothing but run legacy stuff with a bios stub
<cjwatson> (in the sense of being specific to a particular vendor)
<ohsix> being intel on ia64? that's the rub, it was specified
<cjwatson> highvoltage: sure, I'm pretty sure on the machines I remember, refit didn't work
<highvoltage> cjwatson: ok
<cjwatson> ohsix: some x86 machines too.  and if you read what I said carefully I didn't say it wasn't specified
<cjwatson> anyway, this is beside the point
<ohsix> well i was speaking to proprietary
<cjwatson> proprietary doesn't mean unspecified
<ohsix> the uefi stuff i'm familiar with doesn't even try to be ufi-e, it just boots the bios thing, the and the boot time setup is a native efi application that touches the config pages
<ohsix> that was to say apple didn't just come up with something else called EFI independently
<cjwatson> there are different classes specified with different levels of compatibility
<cjwatson> I didn't say they did, but they did break various bits of the spec
<cjwatson> such as it was
<ohsix> alright well don't let me distract you, i was the one that was confused
<cjwatson> I would love amd64+mac not to need to exist, but I don't know of a way to avoid it right now, short of not supporting Mac hardware which I figure wouldn't be popular
<ohsix> so suffice it to say uefi says a bit more about where a vendor should stay in the lines
<cjwatson> I'm pretty sure Apple also violate EFI 1.x, FWIW - their partitioning strategy is not as specified there
<cjwatson> (as one example)
<ohsix> right
<ohsix> afaik it's only used for dropping firmware updates and running them at boot time, and otherwise barren (the system partition)
<cjwatson> that's not the bit I'm referring to
<cjwatson> I mean legacy MBR vs. protective MBR
<ohsix> ah
<ohsix> re: refit, i wonder if some little cd image or something that ran in osx then rebooted into the install couldn't be used
<ohsix> to do firmware updates they drop the update in the system partition and bless it; then the firmware blesses the main thing when it's done, it'd be ugly but it could be done ;]
<cjwatson> feel free to try to produce something portable - it's not something I'm likely to do
<ohsix> i don't have the hw to even begin to be messing with stuff
<highvoltage> "Choose this to take full advantage of computers based on the AMD64 or EM64T architecture (e.g., Athlon64, Opteron, EM64T Xeon). If you have a non-64-bit processor made by AMD, or if you need full support for 32-bit code, use the Intel x86 images instead. This image is adjusted to work properly on Mac systems.
<highvoltage> "
<highvoltage> that sentence on http://cdimage.ubuntu.com/daily-live/20110330/ sounds a bit bogus imho, since it's irrelevant whether AMD made the CPU or not
<highvoltage> (and it's otherwise very unhuman)
<ohsix> highvoltage: "amd64" is the actual arch name
<ohsix> em64t is what intel calls it
<ohsix> and they mention the one confusing case of an amd processor that doesn't support 64bit, which is doubly confusing because its in the arch name _and_ some model names :P
<highvoltage> It would be better in my opinion to have something like "This image is similar to the 64bit installer above, but exclusively supports Intel-based Macs that aren't supported by the default the Ubuntu installer."
<ohsix> that's something other than your original comment, no?
<highvoltage> yes. my original comment was that the paragraph is bogus, and my last statement was a suggestion on how it could be improved.
<ohsix> file a bug :P
<cjwatson> (bugs welcome on https://bugs.launchpad.net/ubuntu-cdimage)
<charlie-tca> How will people know if their processor is supported by the default Ubuntu installer?
<hallyn> Daviey: well, open-vm-dkms compiles fine with the new version, but my clipboard doesn't work with it.  A new version was released two days ago :)  I'm going to try that, bc i'm a glutton for punishment.
<Daviey> hallyn, oh joy!
* pitti changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<pitti> (IOW, beta freeze lifted)
<pitti> didrocks, seb128 ^
<didrocks> nice :)
<seb128> pitti, I noticed the stack of accepted email,, thanks ;-)
<pitti> buildds are still busy with various gc* packages, though
<hallyn> hm, i'm being hit by bug 494445
<ubottu> Launchpad bug 494445 in bzr-builddeb "import-dsc looks for upstream-* tags with native package" [Critical,Fix released] https://launchpad.net/bugs/494445
<hallyn> cjwatson: did you have to work around that, or was it really fixed for you?
<hallyn> (i'm on uptodate natty)
 * hallyn goes the non-udd way for now
<steveire> pitti: ping?
<pitti> !ping
<ubottu> Here I am, brain the size of a planet and they ask me to respond to factoid requests. Call that job satisfaction? Because I don't.
<pitti> bah
<pitti> steveire: pong (but busy); please don't ping, just ask your question :)
<steveire> pitti: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/680088 Your comment there seems irrelevant to me because you talk about going from 10.10 to 11.04 and the issue was originally about 10.04 to 10.10 upgrades. You request for testing is irrelevant to the original issue, right?
<ubottu> Ubuntu bug 680088 in update-manager (Ubuntu Maverick) "Upgrade fails "Can not mark 'kubuntu-desktop' for upgrade "" [Undecided,Fix committed]
<steveire> pitti: Ah, I think Riddell clarified.
<pitti> steveire: it shouldn't be; a 10.04->10.10 upgrade will use update-manager from 10.10
<pitti> steveire: (we do that because it's easier to fix stuff in the later release)
<cjwatson> hallyn: I don't think I ever rechecked following James' fix, so I probably worked around it
<pitti> steveire: so if you want to test a 10.04->10.10 (with proposed) upgrade, that'd be much appreciated
<cjwatson> IIRC I just committed the same deltas by hand
<pitti> steveire: that's "update-manager --proposed"
<steveire> pitti: Ok, will do
<pitti> steveire: thanks!
<hallyn> cjwatson: do you recall how you worked around it?  Did you just create that tag?
<hallyn> i'm wondering if it'll break something if i tag the '-0ubuntu1' release with the 'upstream-' tag
<cjwatson> 16:44 <pitti> steveire: that's "update-manager --proposed"
<cjwatson> err
<hallyn> it certainly seems wrong
<cjwatson> 16:44 <cjwatson> IIRC I just committed the same deltas by hand
<cjwatson> I don't remember any more than that, sorry
<hallyn> oh there i see it :)
<hallyn> thanks
<cjwatson> I don't think I gave a monkey's about the upstream-* tags
<hallyn> all right, i'm just doing it without bzr for now.  thanks :)
<cjwatson> all I wanted was to get the PPA uploads represented in bzr somewhere
<cjwatson> hallyn: oh, I did it in bzr, I just didn't use bzr import-dsc to do it.  you can just successively apply diffs, add files, and commit ...
<cjwatson> (assuming you're starting from an existing branch)
<hallyn> existing branch, but huge delta.
<Daviey> mvo, does squid deb proxy work with extras.ubuntu.com?  Someone is reporting to me that it is 403'ing
<mvo> Daviey: let me double check
<mvo> Daviey: its in the default config, but maybe this user decided to use a custom one?
<mvo> Daviey: when the conffile prompt hit him? it was left-out in early versions. or is he using lucid/maverick on the server?
<Daviey> mvo, checking
<barry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: barry
 * dholbach hugs barry
<zul> ev: ping for the samba bug, couldnt ubiquity do something sensible and not allow more that 16 characters in a hostname?
<ScottK> Why is a 16 character hostname limit sensible?
<ev> zul: this is a limitation in netbios, not linux.
<ev> ScottK: indeed
<ev> I think this is best solved where the problem arises, in Samba.  I can talk to another machine with more than 16 characters in its hostname using every other network protocol I can think of.
<ev> equally, you can set the hostname outside of the installer, so even if we did this in ubiquity, the problem would remain.
<zul> ev: right its a problem with netbios...so something like print a warning or something
<ScottK> RFC 1123 says "Host software MUST handle host names of up to 63 characters and SHOULD handle host names of up to 255 characters."
<zul> ScottK:  right ill get on changing the netbios protocol
<ScottK> I understand the problem.
 * ScottK imagines a netbios equivalent for hostnames of 8.3 long/short filenames.
<ogasawara> cjwatson: hi, I just tried to upload a new linux-backports-modules-2.6.38 but it was rejected.  I assume it's due to the fact it still needs added to the proper ACL's first before I can pull the trigger.
<cjwatson> sure, I'll do that
<bdmurray> glatzor: it looks like bug 707490 might not be fixed
<ubottu> Launchpad bug 707490 in aptdaemon (Ubuntu Natty) "aptd crashed with UnicodeDecodeError in _set_status_details(): 'ascii' codec can't decode byte 0xd0 in position 0: ordinal not in range(128)" [Medium,Triaged] https://launchpad.net/bugs/707490
<cjwatson> ogasawara: try now
<Daviey> ScottK, Your quote of RFC 1123, is that in regards to zul's suggestion of ubiquity limiting the hostname to 16 chars - or a bug in the netbios protocol?
<ScottK> Yes.
<Daviey> ScottK, it was a xor question.
<ScottK> Sorry, that's how the result parsed.
<soren> Daviey: How do you pronounce "xor"?
<Daviey> soren, I'm not exclusive either way, but usually x-or
<soren> Daviey: Just wondering since you said "a xor" and not "an xor".
<soren> Daviey: Nice pun, though :)
<Daviey> soren, I'll make sure i check my grammar before making comment next time, thanks for the hint :).
 * soren has his red marker ready
<soren> Daviey: Seriously though, I was genuinely curious if there was a way to pronounce it that would make it an "a" word rather than an "an" word :)
 * soren wanders off again
<Daviey> :P
<ogasawara> cjwatson: thanks, I'm able to upload now
<cjwatson> soren: I've been known to say something like a hard "zor"
<cjwatson> I can pronounce initial-consonant "x"
<barry> soren, cjwatson i've always pronounced it ecks-or
<zul> http://dictionary.reference.com/browse/xor
<barry> of course, i realize that people pronounce __init__ as "dunder-init" instead of the way i say it: "under under init"
<dpm> hi cjwatson, could you approve my e-mail on appdeveloper week on the ubuntu-devel moderation queue? thanks!
<pitti> dpm: done
<dpm> thanks pitti :)
<broder> hmm...is grub going to change the tty setup enough that it would break the kernel's "you're using a 64-bit kernel on a 32-bit system" message?
<cjwatson> broder: it may actually bypass it altogether
<cjwatson> broder: that check seems to be on the 16-bit boot path
<Daviey> cjwatson, it's looking more like we will need the isc-dhcp patch... Would you nack the idea of me uploading it now, and submitting it upstream concurrently?
<broder> cjwatson: can grub theoretically do that detection? :)
<cjwatson> Daviey: as long as you're on the hook for dealing with any regressions ...
<cjwatson> broder: GRUB can certainly detect CPU capabilities ('cpuid -l'); what I'm not sure if it can do is detect what the kernel it's booting needs, since I'm not seeing it in the kernel header
<broder> cjwatson: for my use case, i'm ok with hard-coding "is this a 32-bit cpu"
<cjwatson> 'if cpuid -l' or 'if ! cpuid -l' as appropriate
<SpamapS> whoa.. ubuntu-docs bzr branch is a little bit ridiculous ..
<SpamapS> 376844kB   136kB/s \ Fetching revisions:Inserting stream:Estimate 56124/56188
<micahg> doko: I believe we can drop gcc-4.1, but gpc-4.1 has an rdepends of gpc, is this needed
<Daviey> cjwatson, yup.
<Daviey> SpamapS, What docs are you working on?
<broder> cjwatson: awesome, thanks
<SpamapS> Daviey: the server guide
<SpamapS> I'm guessing there are a lot of screenshots in this bzr branch
<Daviey> SpamapS, Great!
<SpamapS> Hrm.. I don't see the server guide there at all
<Ampelbein> hi. does http://paste.ubuntu.com/587929/ (from https://launchpadlibrarian.net/67807729/buildlog_ubuntu-natty-i386.checkstyle_4.4%2Bdfsg-5_FAILEDTOBUILD.txt.gz) look like it could be a serious problem on the builders/in gcj-4.4-jre-headless?
<broder> cjwatson: is there something like a panic command in grub script?
<slangasek> cjwatson: patch archaeology question; do you know why in pam, the RLIMIT_NICE defaults are being set to what they are?  They don't match the kernel, and I can't find any way that this ulimit has any effect at all on setpriority() behavior
<slangasek> cjwatson: this is debian/patches-applied/ubuntu-rlimit_nice_correction, formerly debian/patches-applied/061_pam_rlimits_nice_rtprio, added to fix bug #17348
<ubottu> Launchpad bug 17348 in pam (Ubuntu) "Please add support for RT prio & nice rlimits" [Wishlist,Fix released] https://launchpad.net/bugs/17348
<slangasek> (... in 2006)
<hallyn> skaet: Daviey: on bug 727342, testing (on the new package I've referenced there) is good.
<ubottu> Launchpad bug 727342 in open-vm-tools (Ubuntu) "FFE: open-vm-tools kernel module failed to build" [Critical,New] https://launchpad.net/bugs/727342
<skaet> hallyn,  good to know.   Thanks for flagging.
 * RoAkSoAx made it to DFW. Austin here i come
<seb128> slangasek, hi
<seb128> slangasek, you might want to review https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/libxklavier/natty-201103311620/+merge/55787 since you did the upload
<slangasek> seb128: <blink> ok
<seb128> slangasek, dunno what's going on, james_w opened a bunch of those
<seb128> slangasek, btw was the patch forwarded upstream? there is no bug reference in the upload
<slangasek> james_w: https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/libxklavier/natty-201103311620/+merge/55787 - seems to be something the importer should fix up on its own?
<slangasek> (and why am I not allowed to reject UDD merge requests?)
<slangasek> seb128: I upstreamed it to Debian as Debian bug #620110, I don't know how to find the right place to send such things to upstream directly
<ubottu> Debian bug 620110 in libxklavier "please fix libxklavier.pc to use Requires.private like God intended" [Normal,Open] http://bugs.debian.org/620110
<TheMuso> lol at the bug title.
<seb128> slangasek, https://bugs.freedesktop.org/enter_bug.cgi?product=libxklavier
<seb128> slangasek, if you have a fdo account
<slangasek> seb128: I don't think I do... :)
<seb128> slangasek, ok, well we will forward it for you when we merge on debian next cycle if they didn't do it by then ;-)
<slangasek> ok :)
<TheMuso> GrueMaster: Are patches being worked on for OMAP4 etc for alsa-lib and/or pulseaudio? Or, are there patches you can point me to? I have to upload revisions of both pulse and alsa-lib in the coming few days, so I'd like to encorporate all the fixes into one upload for each package.
<ogra_> TheMuso, we are still waiting for TI, i will ask in tomorrows call
<TheMuso> ogra_: Ok thanks.
<ogra_> slas-lib should be a trivial config file for omap4 UCM
<ogra_> *alsa-lib
<ogra_> i'm not sure how heavyweight the pulse ones are though
<doko> micahg: yes, I know. will care about it tomorrow
<TheMuso> ogra_: Ok cool.
<micahg> doko: ok, thanks, I still hope to clean up gcc-4.3 before beta 2
* slangasek changed the topic of #ubuntu-devel to: Natty Beta-1 released! | Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: barry
<barry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Natty Beta-1 released! | Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<slangasek> broder: you don't happen to understand the build system of root-system, do you?  I see you touched it in lucid...
<slangasek> it's been removed from Debian pre-squeeze though, so maybe we should just drop it
#ubuntu-devel 2011-04-01
<broder> slangasek: understand is a pretty strong word. i don't think i ever reached a point of understanding
<broder> just possibly a point of being able to apply grep and sed thoroughly enough
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Natty Beta-1 released! | Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: TheMuso
<slangasek> broder: so, I have a partial patch that gets root-system part of the way through a build w/ multiarch, but for some reason I can't discern, it fails to build the kerberos module
<Ampelbein> TheMuso: hi, could you have a look at bug 725044 and if it looks good sponsor the upload?
<ubottu> Launchpad bug 725044 in libsdl1.2 (Ubuntu Natty) "SDL rendering issue: graphic corruption while scrolling right" [Low,Triaged] https://launchpad.net/bugs/725044
<TheMuso> Ampelbein: I am actually looking at that merge proposal now. :)
<Ampelbein> TheMuso: ah, cool ;-)
<slangasek> broder: bug #745850 if you care to save it; if not I think removal is the right thing to do
<ubottu> Launchpad bug 745850 in root-system (Ubuntu) "Please remove root-system from natty" [Medium,Triaged] https://launchpad.net/bugs/745850
<broder> slangasek: i have no interest in saving it, i just didn't want to see kerberos maligned for someone else's issues
<slangasek> :-)
<GunnarHj> ScottK: ping?
<Ampelbein> hmm, when installing gcj-4.4-jre-headless (4.4.5-15ubuntu2) it segfaults on the configure stage in a clean pbuilder environment, but not on my worksystem.
<Ampelbein> it is the same error in pbuilder as appears on the official builders. https://launchpadlibrarian.net/67807729/buildlog_ubuntu-natty-i386.checkstyle_4.4%2Bdfsg-5_FAILEDTOBUILD.txt.gz
<lifeless> kees: FYI cve pages are fixed
<kees> lifeless: cool, thanks
<lifeless> properly even :) - that huge one is down to 2 seconds render time
<ScottK> GunnarHj: Pong
<GunnarHj> ScottK: Hi Scott! It's about a gdm security update in lucid and maverick leading to the backports binaries no longer being the latest versions. I wanted to ask if there is some shortcut available for dealing with the issue. What I'm about to do is making new backports branches that include the update.
<GunnarHj> ScottK: After having thought about it, I assume that this is a general problem with backports. Is it so?
<ScottK> GunnarHj: That's the right thing to do.  Normally backports have enough higher version this doesn't come up.
<micahg> this is actually good in this case
<GunnarHj> ScottK, micahg: But would it have been appropriate to set a higher version? I mean, in that case the backports users would not have been notified about the security update, right?
<ScottK> GunnarHj: Backports are unsupported, so that's not unusual.  It's like using a Universe package.
<micahg> GunnarHj: well, the version was appropriate for what was backported
<micahg> GunnarHj: in this case, the users are better off secure, than with the backport, the solution is to rebase the backport, sometimes packages are backported and not updated for security fixes which can be problematic for backports users
<GunnarHj> ScottK, micahg: Think I got it. As regards typical backports, even if they are official, they are unsupported, and users install them on their own risk with respect to possible updates afterwards.
<ScottK> Yes.
<ScottK> Generally though it's easy enough to backport an update that has the relevant security fix.
<GunnarHj> ScottK: But not quite as easy in this case... Guess I have myself to blame. ;-)
<micahg> GunnarHj: nah, gdm's just not the normal fare for backports, usually with leaf packages, you just backport the latest version assuming it'll build/run
<ScottK> Fortunately you can diff the security update from the base package and it should be ~easy to figure out how to update your backport.
<ScottK> micahg: No, we test that it builds/runs.  Not much more though.
 * micahg wonders what he said wrong
<ScottK> In fact builds/installs/runs is the exact test criteria.
<sbeattie> GunnarHj: FYI, bug 746796 is about the gdm backports issue.
<ubottu> Launchpad bug 746796 in gdm (Ubuntu) "locale switched from fr_FR.UTF-8 to fr_FR after upgrade to 2.30.5-0ubuntu4.1" [Undecided,New] https://launchpad.net/bugs/746796
<GunnarHj> ScottK: Yeah, not saying it's _that_ difficult. Btw, considering it's gdm, can you upload the new branches, or should I ask someone in ubuntu-desktop?
<sbeattie> GunnarHj: also, the patch fixed in USN-1099-1 is self-contained; I would be highly surprised if it didn't apply cleanly.
<ScottK> Please find someone else as I've got a $WORK project that's due today.
<ScottK> GunnarHj: ^^^
<GunnarHj> sbeattie: I know. Bug 746694 too. Yes, I don't anticipate any problems. Thanks!
<ubottu> Launchpad bug 746694 in gdm (Ubuntu) "GDM_LANG overrides my locales" [Undecided,New] https://launchpad.net/bugs/746694
<GunnarHj> ScottK, micahg, sbeattie: Going off keyboard. Thanks all for helping.
<sbeattie> GunnarHj: okay. I'm stepping away for a while, too. If you have any questions about the update patch, feel free to poke me about it.
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Natty Beta-1 released! | Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<TheMuso> 
<micahg> StevenK: would you be available to add some binary overrides?
<micahg> s/add/adjust/
<StevenK> micahg: It depends -- are we still frozen?
<micahg> StevenK: I don't think so
<micahg> StevenK: this is for stable releases
<StevenK> micahg: Er?
<micahg> StevenK: security update for qt4-x11
<StevenK> micahg: Okay, what do you need?
 * micahg is getting the list
<Dread> heya
<Dread> latest updates screwed up my internet on my main machine
<StevenK> micahg: It doesn't bode well that it's taken over 7 minutes to get the list.
<micahg> StevenK: sorry, the script is inherently slow
 * micahg has only needed to do this once before and forgot how slow it is
<StevenK> micahg: Oh, you want a bunch of stuff copied from security to updates?
<micahg> StevenK: no, there's a script that does that, I just need the overrides applied in -security
<micahg> StevenK: http://paste.ubuntu.com/588128/, I'm still working on hardy, thanks
<StevenK> micahg: All done.
<micahg> StevenK: thanks, I'm fighting with the script at the moment for hardy, I might just make it manually if I can't get this to spit it out
<micahg> StevenK: can you demote qt4-dev-tools and qt4-qtconfig in hardy-security?
<StevenK> micahg: And not libqt4-core? That's been in every other.
<micahg> StevenK: nope, that's in main in hardy
<didrocks> good morning
<StevenK> micahg: DOne.
<micahg> StevenK: thanks!
<StevenK> micahg: Welcome.
<DreadKnight> was there some alternative network manager for natty? called conman or something?
<DreadKnight> because latest updates broke my network manager, which makes my main machine kinda useless now
<holstein> how about wicd ?
<DreadKnight> hmm
<DreadKnight> holstein: does it have indicator support by any chance?
<RAOF> Connman is in the archives, yes.
<ohsix> what broke?
<DreadKnight> RAOF: so that's how you spell it xD geez
<holstein> DreadKnight: well, it did
<ohsix> nm has its own logging, you should probably look & report the breakage, chances are it isn't nm
<holstein> not sure about how things are now though
<holstein> i havent had a chance to look at wicd+natty
<RAOF> Last time I tried it it was not particularly functional; it'd do brain-dead things like update hostname to a string based on the connection and wouldn't update routes when a wired connection got plugged in.
<DreadKnight> fail
<holstein> :/
<ohsix> big fail
<RAOF> DreadKnight: In short, I'd suggest working out why network manager isn't working and fix it :)
<DreadKnight> I can fix other stuff, but when it comes to internet and not being able to at least have a wired connection...
<DreadKnight> might as well reinstall or look for another distro :
<holstein> theres other distros ?
<holstein> ;)
<holstein> DreadKnight: try updating a different way
<holstein> aptitude or apt
<DreadKnight> indeed....
<ohsix> DreadKnight: what do you mean by not working, is the applet there?
<DreadKnight> ohsix: it's there, but it's saying something like "device not administrated" (it's in my native language, sry for bad translation)
<pitti> Good morning
<ohsix> DreadKnight: ok, so that's working, you just need to find out why its ignoring the device
<DreadKnight> ohsix: even got my restricted driver I didn't really needed and installed it..
<holstein> DreadKnight: if you had a kernel update
<holstein> try booting into the older one
<DreadKnight> holstein: good idea; trying it
<micahg> GunnarHj: did you test build, install, run the new version?
<ohsix> hm /etc/NetworkManager/NetworkManager.conf references /etc/default/NetworkManager but it's not there
<DreadKnight> ohsix: bad prank for 1 april i guess
<ohsix> DreadKnight: i know it says that when i blacklist a device as unmanaged, but i do that in NetworkManager.conf, there are other places that can probably do it, i'd rule those out
<ohsix> like /etc/network/interfaces
<GunnarHj> micahg: I have test builds in my ppa. Haven't actually tested them.
<DreadKnight> holstein: same crap on older kernel
<ohsix> the nm logging in /var/log probably says when its ignoring a device and why, too
<micahg> GunnarHj: that's a requirement for backports
<holstein> DreadKnight: hmmm
<holstein> not sure, it is still beta
<DreadKnight> too much crap in /var/log/
<holstein> updates break sometimes :/
<GunnarHj> micahg: I know. Just felt it was a little urgent, and since it's effectively just a combination...
<DreadKnight> holstein: I know; but this breakage is ultra lame
<ohsix> DreadKnight: just how lame is it
<ohsix> and that message indicates user configuration ...
<micahg> GunnarHj: still needs testing though
<GunnarHj> micahg: Stupid arguments, btw. Will test. Logging out for now. See you.
<holstein> DreadKnight: im suspicious of the proprietary driver install you were talking about
<holstein> you might want to look at that a bit more
<DreadKnight> holstein: did that for the modem software; but was just a try out at fixing the issue
<DreadKnight> probably I don't have anything to do with modems anyway
<holstein> DreadKnight: i would probably sleep on it
<holstein> and see if an update comes along that sorts you out
<ohsix> that is, if you don't want to figure out what it is
<DreadKnight> holstein: I won't be able to update anyway, would have to get packages on another machine in the best case scenario and move them via an usb hdd... but that makes things kinda complicates as I won't know when or what...
<DreadKnight> d*
<DreadKnight> and not even if*
<holstein> i usually find that with things like that
<holstein> its my own fault
<ohsix> DreadKnight: hook it up to ethernet, dhclient eth0
<holstein> im not saying thats the case with you
<DreadKnight> ohsix: oh didn't know about that; getting another cable around :D
<micahg> this conversation should probably move to #ubuntu+1 unless it's discovered there's a bug
<ohsix> you're right, i'm over there too
<DreadKnight> dhclient eth0 gives me some "Permission denied" errors
<DreadKnight> SIOCSIFADDR: Permission denied
<DreadKnight> and twitce for FLAGS
<DreadKnight> SIOCSIFFLAGS: Permission denied that is
<DreadKnight> ohsix: poke :D
<ohsix> #ubuntu+1
<GunnarHj> micahg: Still there? They both install and run fine.
<micahg> GunnarHj: ok, I can't ACK it, as I'm not officially a backporter, but change the statuses to new, give a link to your built packages if they're not there already, and add an install/run comment to the bug
<micahg> GunnarHj: actually, you can mark "confirmed" as you said it "runs well"
<micahg> GunnarHj: BTW, what did you mean by:  Stupid arguments, btw.
<GunnarHj> micahg: Done. I was talking about my own attempt to justify that I hadn't tested.
<micahg> GunnarHj: ah :)
<micahg> broder: do you have time to review a backport?
<GunnarHj> micahg: If I understand it correctly, that's as long as you can help with it.
<micahg> GunnarHj: yep, aside from trying to ping someone to review it :)
<GunnarHj> micahg: You are too fast to me! :)
<GunnarHj> micahg: Think I'll ask Martin. People tend to be nervous about everything gdm, and he is well updated on the backported changes.
<micahg> GunnarHj: he's not a backporter AFAIK
<GunnarHj> micahg: No... I know that a backporter is supposed to confirm that it's appropriate for -backports, but since Scott did that a few weeks ago, and I haven't changed anything, it should still be appropriate for -backports...
<micahg> GunnarHj: right, but every upload requires the review again, should be a fast one if nothing changed :)
<GunnarHj> pitti: Hi martin, any chance that you can upload the gdm branches linked to bug 746694? micahg has helped me as far as he can. No backporters review yet, but nothing in the backported code has been changed, Scott is off making money, and it's a little urgent. ;-)
<ubottu> Launchpad bug 746694 in maverick-backports "GDM_LANG overrides my locales" [Undecided,Confirmed] https://launchpad.net/bugs/746694
 * micahg doesn't claim to have reviewed the actual package, just that pieces are ready for a backporter to review
<pitti> GunnarHj: will do; as this is a bug fix to an existing backport, it should be okay
<GunnarHj> pitti: Great, thanks!
<GunnarHj> micahg: ^^^
<GunnarHj> micahg: Btw, thanks for helping out with this urgent issue. As usual I learned a thing or two. ;-)
<micahg> broder: nevermind :)
<micahg> pitti: do you think bug 747025 is critical?
<ubottu> Launchpad bug 747025 in module-init-tools (Ubuntu) "Modprobe passes 11n_disable=1 option to iwl3945 which doesn't support the option" [High,Triaged] https://launchpad.net/bugs/747025
<mvo> dpm: do we have someone from the cjk community who could look at #206018 ? there is some config change in there for language-selector fontconfig magic, but I have no clue if it helps or not
<pitti> micahg: ugh, indeed; targetted to natty
<pitti> micahg: assigned to tim for checking/uploading
<micahg> pitti: cool, thanks
<dpm> morning mvo, let me ping the Chinese translation team, but I'm not sure they'll be able to do much, as I see some of them on the bug comments already
<dholbach> good morning
<mvo> dpm: well, if there is consens what to do I'm happy to do it :) but I can't judge whether or not its a improvement so I need someone with that knowledge to help
<mvo> dpm: if we shouldn't do anything about it, it would be good to close it as "opinion"
<dpm> mvo, ack. I can't find anyone around right now, but I'll try later on
<mvo> dpm: thanks a bunch, not urgent, I just don't want to let it drop on the floor without some opinion
<dpm> no worries :)
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<tkamppeter> pitti, can you upload CUPS? It has 2 fixes queued on the BZR.
<pitti> tkamppeter: sure
<doko_> janimo: do you get emails about the arm-rebuild build failures?
<janimo> doko_, I don't think I do
<janimo> doko_, I got various FTBFS emails these days but they were PPA related and not all armels
<janimo> some for Canonical-ARM ppa
<doko_> hmm, so it didn;t help to create the test rebuild https://launchpad.net/ubuntu/+archive/test-rebuild-20110329-arm
<pitti> GunnarHj: just looking at your gdm branches -- did you re-do them from scratch?
<pitti> GunnarHj: I had expected that you'd just merge lp:ubuntu/maverick-security/gdm into your original one, and then just have a changelog which says "update to latest security update (LP: #746694)
<pitti> GunnarHj: want me to reorganize the changelog accordingly?
<pitti> GunnarHj: otherwise it looks fine
<pitti> both uploaded
<GunnarHj> pitti: Doing so was my first thought, but I became in doubt. I simply used Bazaar Explorer and uncommitted my revision, pulled the news from -update and committed my revision again.
<pitti> GunnarHj: ok, all sponsored and approved
<pitti> thanks!
<cdbs> pitti: As for bug #722521 I tested the maverick fix on a newly-started EC2 instance. Since the proposed upload I have installed it on my instanced whenever I start a new one (this has happened 5-6 times). No regression. Would this be a verification of the SRU?
<ubottu> Launchpad bug 722521 in debian-archive-keyring (Ubuntu Maverick) "Lucid/Maverick package doesn't contain new Sid/Squeeze keys" [Medium,Fix committed] https://launchpad.net/bugs/722521
<pitti> cdbs: sounds good, thanks for testing!
<pitti> cdbs: can you please followup on the bug saying so?
<cdbs> pitti: okay
<cdbs> pitti: if I had known I would have done that quite a long time ago. I often keep building stuff on newly-started instances
<cdbs> pitti: But I verified only on maverick, so should I tag it verification-done?
<pitti> cdbs: I'll deal with this
<cdbs> pitti: commented, thanks!
<doko_> Daviey: could the server team have looks at the postfix and openldap build failures?
<Daviey> doko_, yes, thanks for raising them.
<Daviey> doko, hah, postfix builds fine... on checking, it seems slangasek multiarched it this morning. \o/
<mdz> didrocks, silbs' crash is https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/747205
<ubottu> Ubuntu bug 747205 in xserver-xorg-video-intel (Ubuntu) "[arrandale] GPU lockup (ESR: 0x00000001 IPEHR: 0x7a005502)" [Undecided,New]
<mdz> didrocks, I filed that by manually running apport-gpu-intel-error.py
<mdz> so it's not exactly at the point where the problem occurred, but should have all of the debug
<didrocks> mdz: thanks, I wasn't able to find a dup in launchpad, I'll ping your Xorg guys on that, still googling if something can be of help
<mdz> didrocks, the dupe check found bug 721086
<ubottu> Launchpad bug 721086 in xserver-xorg-video-intel (Ubuntu) "[arrandale] GPU lockup 9861d3ce (ESR: 0x00000001 IPEHR: 0x7a005502)" [Undecided,Expired] https://launchpad.net/bugs/721086
<cdbs> pitti: Sorry for the late response but bug #747025 has an attached debdiff by me - still it was assigned to tgardner
<ubottu> Launchpad bug 747025 in module-init-tools (Ubuntu Natty) "Modprobe passes 11n_disable=1 option to iwl3945 which doesn't support the option" [High,Triaged] https://launchpad.net/bugs/747025
<didrocks> mdz: ok, that's nice to know, bryceh already look at something similar
<didrocks> mdz: info sent FYI
<pitti> cdbs: I assigned it to him for review/upload, as he uploaded the original change
<cdbs> pitti: okay, thanks!
<tjaalton> mdz, didrocks: sent it upstream, and I'll ask ickle to have a look
<mdz> didrocks, info sent where?
<tjaalton> hmm, do we not mount debugfs by default anymore?
<pitti> tjaalton: we do, /sys/kernel/debug/
<tjaalton> pitti: ok, thanks
<tjaalton> mdz: can you get /sys/kernel/debug/dri/0/i915_error_state from the hung state and attach it to the bug?
<mdz> tjaalton, no, sorry, Jane has rebooted
<mdz> tjaalton, does the apport hook not collect that?
<didrocks> mdz: pang the xorg guys directly as it's more in their field of competence ;)
<mdz> i915_error_state: no error state collected
<mdz> didrocks, ah, ok
<tjaalton> mdz: it did for the other bug you linked to, don't know why not this time
<tjaalton> maybe it doesn't include it if it contains just that
<mdz> tjaalton, it's there: "no error state collected"
<mdz> tjaalton, that's the actual contents
<mdz> I think
<tjaalton> mdz: ok, thanks for confirming
<mdz> tjaalton, it just does this:     attach_file_if_exists(report, '/sys/kernel/debug/dri/0/i915_error_state', 'i915_error_state')
<mdz> tjaalton, i915_debugfs.c:396:		seq_printf(m, "no error state collected\n");
<tjaalton> mdz: yep, figured as much
<tjaalton> ickle said it wasn't a hung gpu, but related to the drm error, and will follow up on the upstream bug later
<doko> tkamppeter, pitti: could we re-add the dependency of ghostscript in gs-common for the release? just too many build failures left
<pitti> no problem from my side; I still see about 20 reverse build deps, do they all fail because they mean "ghostscript" when they say "gs-common"?
<doko> yes, /bin/sh: ps2pdf: not found
<tgardner> pitti, I'm coming to the conclusion that conf files are a bad idea. if you screw them up then the carnage lasts forever. wrt module-init-tools, should I perpetuate the carnage, or just delete the conf files from the package and leave it at that? this version missed B1 so it won't be on a CD.
<pitti> tgardner: I think in this case we can just have a preinst snippet which bluntly rm -f's it
<pitti> tgardner: it's only been in natty for a day or two as you say, so we don't need to be concerned about keeping user changes
<pitti> tgardner: please do check the dpkg --compare-version "$2" ..., though :)
<tgardner> pitti, why bother? there is no version where intel-3945-iwlagn-disable11n.conf is valid.
<pitti> tgardner: it might come back at some point, though
<pitti> tgardner: it doesn't cost much and is safer
<pitti> tgardner: but I guess we can drop the preinst code after beta-2 anyway?
<tgardner> pitti, yes
<tgardner> pitti, can you give this a quick look? https://bugs.launchpad.net/ubuntu/natty/+source/module-init-tools/+bug/747025/comments/5
<ubottu> Ubuntu bug 747025 in module-init-tools (Ubuntu Natty) "Modprobe passes 11n_disable=1 option to iwl3945 which doesn't support the option" [High,In progress]
<hallyn> interesting.  xdg-open does not fare well when executed 3 times in a row very fast (i.e. 'for x in 1 2 3; do xdg-open http://bugs.launchpad.net/$x; done').  Wonder if this is an actual bug in firefox
<pitti> tgardner: re (sorry, door bell)
<tgardner> pitti, np. I'm actually testing it first.
<tgardner> pitti, ok, it appears to work as expected.
<pitti> tgardner: with le -> le-nl it looks perfect
<pitti> le won't do much harm, though
<tgardner> pitti, how can the version be empty?
<pitti> tgardner: on fresh installation
<tgardner> pitti, hmm, ok
<dpm> hi cjwatson, the e-mail announcement I sent yesterday about Ubuntu AppDeveloperWeek didn't seem to make it to ubuntu-devel. Could you approve it when you've got a minute? thanks!
<pitti> dpm: ah, I only approved it to u-devel-announce@, I thought that was what you meant
<dpm> pitti, yeah, I got confused because I thought only Colin was admin on ubuntu-devel, I've just noticed that it didn't make it there - thanks for approving it on -announce, though :)
<cjwatson> dpm: done
<dpm> awesome, thanks cjwatson :)
<ScottK> mvo: Thanks for 745396.  Awesome responsiveness, much appreciated.
<ScottK> mvo: BTW, LP changes for backports-not-automatic will land next week.  So we can (if the FFe is approved) actually turn that on this cycle.
<Laney> \o/
<mvo> ScottK: nice!
<doko> pitti, seb128: what's the recipy for /bin/sed: can't read /usr/lib/libgobject-2.0.la: No such file or directory
<doko> libtool: link: `/usr/lib/libgobject-2.0.la' is not a valid libtool archive
<doko> make[2]: *** [bsepcmdevice-alsa.la] Error 1
<doko> ?
<seb128> doko, grep libgobject-2.0.la /usr/lib/*.la on the system where you build to figure what .la is buggy and get that one rebuilt
<seb128> or clean_la-ed
<pitti> because it's /usr/lib/x86_64-linux-gnu/libgobject-2.0.la now?
<doko> pitti: maybe, packages in universe are a mess now :-/
<micahg> slangasek posted a list the other day
<slangasek> yes, sources needing no-change rebuilds for .la moves: http://people.canonical.com/~vorlon/broken-srcs-universe.txt
<slangasek> (some of these may have already been rebuilt since the list was generated, I'll refresh it a bit later today)
<doko> maybe we should give these packages in the test rebuild
<penguin42> anyone fix a link typo on http://www.ubuntu.com/testing/natty/beta; the link to 'Download the Ubuntu 11.04 beta' goes to #Download%20Beta  where I think it should be #Download%20Beta%201
<broder> slangasek, kklimonda_: did either of you start on the universe rebuilds? if not i'll just start working my way down from the top
<slangasek> broder: I haven't started yet; let me regen the list right now and we can see what's been fixed already
<kklimonda_> broder: I didn't have time yet, I hope to get some work done tomorrow.
<slangasek> two fell off the list on their own, it seems
<broder> cool. i'll start working from the top, then
 * micahg was going to try to get a few on sunday at the global jam if time permits
<bdmurray> @pilot_in
<udevbot> Error: "pilot_in" is not a valid command.
<broder> bdmurray: 2 words
<bdmurray> broder: thanks
<bdmurray> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Natty Beta-1 released! | Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: bdmurray
<YokoZar> mvo: poke
<YokoZar> mvo: I put in a bzr branch of app-install-data for you that cleans up an old wine workaround, but never actually told you :p
<broder> slangasek: and you wanted me to start cleaning the .la files when i rebuild as well?
<hrw> kklimonda_: will you attend UDS-O?
<slangasek> broder: use your best judgement - the highest priority is to get them all rebuilt, but if we have time to also fix some along the way to proof them against future changes, that's better in the long run
<micahg> well, now that we have the list, we can always "fix" them later
<slangasek> yeah, though that's kinda double work
<broder> i don't think it's too much trouble to take care of them now - there are fairly standard snippets for most of the standard build systems
<kklimonda_> hrw: well, that depends. :)
<kklimonda_> (on whether I'll get a sponsorship, or not)
<slangasek> jani_: hmmm, why is removing the symbol from the .symbols file the right fix for bug #747047?  Symbols files exist to guard against accidental ABI changes that can break reverse-dependencies, is this symbol not needed here?
<ubottu> Launchpad bug 747047 in clutter-1.0 (Ubuntu) "clutter-1.0 version 1.6.10-3ubuntu1 failed to build on armel" [High,Fix released] https://launchpad.net/bugs/747047
<jani_> slangasek, from what I understood, the diff suggested by dh_shlibdeps is what is needed to fix such errors
<slangasek> jani_: it's what's needed to *avoid* the error, but it takes someone looking at why the symbol is gone away to decide if this is a "fix" :)
<jani_> slangasek, I admit I do not fully understend symbol files :)
<jani_> so such fixes based on what dh_shlibdeps say are not actually fixes?
<slangasek> jani_: so a previous version of the library in the libclutter-1.0-0 package exported a 'clutter_clone_get_paint_volume' symbol.  The package is configured with dpkg-gensymbols -c4 specifically to treat it as a fatal error when a symbol goes missing, because other packages in the archive may be relying on that symbol being available at runtime
<jani_> so the bug is why the library no longer exports that?
<slangasek> the questions then are: is the symbol's disappearance deliberate, or is it an accident?  And if it is deliberate, is it safe wrt the reverse-dependencies?
<jani_> slangasek, just checked upstream
<jani_> commit fd89dee1b01c01619110cd77968062aaf2a98b79
<jani_> Author: Neil Roberts <neil@linux.intel.com>
<jani_> Date:   Fri Mar 18 14:09:57 2011 +0000
<jani_>     clutter-clone: Make clutter_clone_get_paint_volume static
<jani_>     
<jani_>     clutter_clone_get_paint_volume was being exported from the shared
<jani_>     library because the function wasn't declared static. This function
<jani_>     shouldn't be exposed because it should be accessed through
<jani_>     clutter_actor_get_paint_volume.
<slangasek> ok
<jani_> so it is deliberate, as for reverse deps I don't know
<jani_> from the description it seems it was not part of a publicised API
<slangasek> so in fact the symbol disappeared on all architectures, and it's just the armel symbols file that didn't get updated
<slangasek> so your change is fine :)
<jani_> not sure why the armel file did not get updated as the others
<jani_> phew
<slangasek> jani_: probably because "all the others" shared a single .symbols file which is the one that got updated :)
<slangasek> and if it builds on x86, it's good to upload ;)
<broder> ok, maybe knowing the topo sort for these rebuilds would be helpful. the first two on the list depend on other rebuilds. oh well
<broder> slangasek: hmm...are libraries that link multiarch'd libs supposed to have rpaths?
<bdmurray> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Natty Beta-1 released! | Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<slangasek> broder: not *supposed* to, but that seems to be a common side-effect... will work on sorting that out in the next iteration
<broder> slangasek: i actually have two packages that both use libtool, and it's only happening on one, which seems weird
<broder> slangasek: but i won't worry about it too much
<slangasek> yes, the principal problem with rpath is that it makes directory transitions hard later; temporarily introducing them as /part/ of a transition is no big deal as long as we eventually fix it up
<hallyn> zul: is there anything you want from me for the lxc dput?  (i.e. if you don't want to 'bzr bd -S' it for some reason)  if not, i'll mark it as 'done' in my list.
<bdmurray> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Natty Beta-1 released! | Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: bdmurray
<broder> doko: did the ftbfs page for your most recent rebuild stop getting updated? the list of universe failures looks way too short
<broder> oh, i guess the package i was curious about just hasn't built yet
<slangasek> I don't know how frequent the job is that updates the page, but I think it's "not frequent"
 * micahg thought it was once an hour
<micahg> The status pages are updated hourly
<slangasek> ok
<broder> i'm starting on the lib* packages in an attempt to wriggle out of the dependency hell, which the rebuild hasn't gotten to yet
 * slangasek nods
<slangasek> I started from the tail end; currently stabbing xmlrpc-epi, which has some sick and wrong hard-coding of libexpat.la
<Keybuk> jono: jef!
<slangasek> Keybuk: is that your safe word?
<Keybuk> slangasek: "the safe word for tonight is 'Spatula'"
 * slangasek nods
<chrisccoulson> it's been quite an entertaining april 1st today ;)
<jono> Keybuk, LOL!
<chrisccoulson> hi jono!
<jono> hey chrisccoulson :-)
<jdong> sigh, I love you, eclipse
<jdong> "The word 'strex' is not correctly spelled". Quick fix #1 is to correct to "straw"
<bdmurray> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Natty Beta-1 released! | Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
#ubuntu-devel 2011-04-02
<broder> slangasek, kklimonda_, micahg: ok, i'm calling it quits for today on these rebuilds. i got libassuan2 through libfso-glib, not counting a handful of unrelated FTBFS's. good luck to you guys
<slangasek> broder: great, thanks for the help! :)
<micahg> broder: thanks, I took care of libmpd earlier in the week and will see what's left to do on sunday
<Ampelbein> hi, I have a question about packages failing to build because of multiarch. I filed bug 747889 for one such package and attached a fix, but I'm not sure if that's correct. The package uses cmake which supposedly should support multiarch. Can someone have a look at that please?
<ubottu> Launchpad bug 747889 in arpon (Ubuntu) "FTBFS with multiarch" [Undecided,New] https://launchpad.net/bugs/747889
<slangasek> Ampelbein: looking
<Ampelbein> slangasek: thank you.
<slangasek> cmake itself certainly does know about the multiarch paths now, but maybe it's not using them for something particular to how arpon is checking for pthreads
<slangasek> was this a failure found in the archive rebuild, or locally?
<Ampelbein> slangasek: in the archive rebuild
<slangasek> ok
<Ampelbein> but i can reproduce it locally, too
<slangasek> so 0 chance of out-of-date packages :)
<Ampelbein> http://paste.ubuntu.com/588452/ is the code arpon uses to find librarys
<slangasek> yah, I have it in front of me here
<slangasek> Ampelbein: so I would argue that the correct fix is to not require PTHREAD_LIB_DIR to be found, and to only error out when PTHREAD_INCLUDE_DIR or PTHREAD_LIBRARY is missing
<slangasek> Ampelbein: follow-up patch sent to the bug
<Ampelbein> slangasek: ok, I think I understand the reasoning. Your fix can be easily forwarded to upstream while the dpkg-architecture one is ubuntu/debian specific and makes backports etc. harder?
<slangasek> indeed
<Ampelbein> thank you very much for looking into it!
<slangasek> no problem :)
<dylan-m> Hey, little Unity question if anyone's about: right now that cool feature where the dash resizes to fit its contents only happens with the AltF2 and Home lenses. Is this for a particular reason?
<ScottK> dylan-m: #ayatana would be a better channel for that question.
<dylan-m> ScottK: Ah, that makes sense. Thanks :)
<Ampelbein> Do I need a FFe for a package removal from natty at this time? I guess so, just want to make sure.
<Ampelbein> bug 747988 in case anyone wonders
<ubottu> Launchpad bug 747988 in agsync (Ubuntu) "Please remove agsync from natty" [Undecided,New] https://launchpad.net/bugs/747988
<Hobbsee> Ampelbein: i doubt it, to be honest
<Hobbsee> it's not going to corrupt the archive if it's broken and doesn't build
<Ampelbein> Hobbsee: yes, I agree. I will subscribe ubuntu-archive and let them handle it ;-)
<rigved> hi everyone...i am talking about bug 458872...i want to test a fix which I have created for it. how do i do that? specifically, i want to introduce cruft into my system. how do i do that?
<ubottu> Launchpad bug 458872 in computer-janitor (Ubuntu) "Don't mark for removal manually installed packages" [Medium,Triaged] https://launchpad.net/bugs/458872
<ScottK> Ampelbein: As long as you've checked it has no rdepends (which is part of the process) then I think cruft removal is a bugfix and doesn't need an FFe.
 * ScottK waves to Hobbsee.
<Hobbsee> hey ScottK
<ScottK> KDE is getting good again, you might give it a try now ...
<Ampelbein> ScottK: yes, I did check rdepends, with 'apt-cache rdepends agsync/agsync-dev' and 'reverse-build-depends agsync/agsync-dev', so I am pretty sure it has none.
<Hobbsee> ScottK: i was thinkin the pictures of it looked pretty cool
<ScottK> Ampelbein: Good.
<rigved> i guess i'll ask in #ubuntu+1
<ScottK> Hobbsee: Pretty stable too.  The only problem I've had since upgrading my main laptop for beta testing was resolved by manually removing hal and the one universe package I had installed that needed it.
<Hobbsee> ScottK: impressive.  :)
<Hobbsee> (just as long as it's not windows)
<ScottK> Nope.
<ScottK> I won't mention slangasek arranging to have kdm restart in the middle of the upgrade.  That wasn't kdm's fault (and is fixed).
<Hobbsee> details...
<ScottK> Details in Bug #744944
<ubottu> Launchpad bug 744944 in pam (Ubuntu Natty) "kdm is restarted during the upgrade to Natty . The user is disconnected from the session" [Critical,Fix released] https://launchpad.net/bugs/744944
<broder> Ampelbein: wait..i would have sworn i built agsync earlier today..
<broder> maybe not
<broder> ah, no, i was about to, once i rebuilt its r-build-deps, which i thought i did
<broder> Ampelbein: it's failing to build because of the multiarch rearrangement, so i don't think that should contribute to any removal discussion
<broder> but the other reasons do seem rather valid :)
<Ampelbein> broder: yes, so I thought it's no use to put energy in fixing the build issue now
<slangasek> ScottK: is there any indication yet whether skipping the restart for nss modules is a problem, btw?
<ScottK> slangasek: I'm not aware of any.
<slangasek> ok
<vish> is there no compiz Ubuntu branch ?
<vish> (looks like there is only the packagers branch and there seems none for maverick)
<vish> https://code.launchpad.net/~compiz Â« doesnt have maverick
<slangasek> vish: rarely do you find separate branches for previous releases; in this case I guess lool should have created one when he SRUed for maverick, but that didn't happen
<slangasek> vish: and what do you mean, "only the packagers branch"? What would you expect to find in an Ubuntu compiz branch that would be different from a "packagers branch"?
<vish> slangasek: something like the usual : /ubuntu/<release>/<package>/
 * vish thought all packages had them..
<slangasek> ah, a UDD branch; let me see
<vish> https://code.launchpad.net/ubuntu/maverick/+source/compiz says 0 for all versions
<slangasek> no UDD branch because of this error: http://package-import.ubuntu.com/status/compiz.html#2011-03-15%2015:56:27.721896
<vish> oh!
<vish> slangasek: so if i'm doing an SRU for maverick, which should i branch?
<vish> which one*
<slangasek> vish: you'll need to do it the old fashioned way, downloading the source package from maverick-updates
<vish> k, thanks..
<lonejack> Hi, in UBUNTU future versions (that will adopt Wayland+unity), if I build a sw bu gtkmm, this sw, will continue to be compatible/compilabe  or not?
<lool> vish, slangasek: Thanks; I've created a lp:~compiz/compiz/maverick branch from 1:0.8.6-0ubuntu9 in lp:~compiz/compiz/ubuntu (after adding the missing tag) and importing my upload; I've also updated Vcs-Bzr in that branch for the next maverick upload if any
<Technicus> Hello . . . I'm not a developer, but I am experiencing challanges which the typical solutions to not resolve, the problems stem from trying to use a device that works on the Lucid kernel but not Mavrick kernel . . .
<Technicus> So I installed a realtime kernel from: [ https://launchpad.net/~abogani/+related-software ], but now Nvidia drivers do not want to cooperate . . .
<Technicus> Would it be appropriate to discuss this issue here?  If not please direct me to the proper channel.
<khrm> I am not being able to trap SIGILL in ubuntu in expect script. The same thing I am being able to do in other distros. Here is line in my expect file: trap quit {INT TERM QUIT ABRT HUP ILL }
<cjwatson> YokoZar: bug 746758 is presenting with the same symptoms as bug 745459, but the syslogs show that the most current version of ia32-libs (20090808ubuntu11) is installed.  Wasn't that supposed to fix it?
<ubottu> Launchpad bug 746758 in ubiquity (Ubuntu Natty) "11.04 64bit Beta1 CD Installer crashed [error processing flashplugin-installer]" [High,In progress] https://launchpad.net/bugs/746758
<ubottu> Launchpad bug 745459 in flashplugin-nonfree (Ubuntu) "package flashplugin-installer 10.2.153.1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Medium,Fix released] https://launchpad.net/bugs/745459
<doko_> broder, slangasek: the page is updated hourly
<YokoZar> cjwatson: you sure there's still a problem?
<YokoZar> cjwatson: ia32-libs contains the libraries now (according to ldd), and I was able to run youtube on it in vm before I uploaded.  The problem lies elsewhere...not sure exactly where though.
<cjwatson> YokoZar: well, as I say, the logs show the most current version of ia32-libs
<cjwatson> would you mind having a look at the logs and see if anything jumps out?
<YokoZar> cjwatson: what I mean is it a ldd link failure?
<cjwatson> no, it's nspluginwrapper complaining
<cjwatson> which was mentioned in some of the ia32-libs bugs that Andreas Moog closed too
<YokoZar> cjwatson: admittedly I didn't try installing flash fresh.  So if you installed with ia32libs -ubuntu9 (the one from maverick) it worked fine, 10 broke it, and 11 fixed it, but I didn't test actually installing on -10 or on -11
<YokoZar> so maybe that points to nspluginwrapper rather than ia32-libs itself, unless there's another library missing that flash doesn't need but the installer does for some reason
<vanguard> does it make any sense to package a webapp (like a content management system)?
<wolfe> vanguard: web apps are packaged
<wolfe> vanguard: i.e. squirrelmail
<ari-tczew> slangasek: could you look on ftbfs https://launchpad.net/ubuntu/+archive/test-rebuild-20110329/+buildjob/2395855 I guess it's related to multiarch
<JanC> vanguard: IMO it depends on how often it needs updating and whether it's possible to ship it in a way that by default is useful for many people
<ari-tczew> slangasek:  this one also has got problem with .la file https://launchpad.net/ubuntu/+archive/test-rebuild-20110329/+buildjob/2395860
<vanguard> I rather meant something like wordpress, that you install on a webserver manually normally
<Hobbsee> !info wordpress
<ubottu> wordpress (source: wordpress): weblog manager. In component universe, is optional. Version 3.0.1-1ubuntu1.2 (maverick), package size 2459 kB, installed size 9712 kB
<Hobbsee> vanguard: that one? ^
<YokoZar> Hobbsee: incidentally a package people often don't use in favor of installing it manually...
<Hobbsee> YokoZar: that's true, especially given you can update it from inside itself
<YokoZar> vanguard: really your question is generalizable to packages for software that wasn't written for systems with good packaging systems (generally windows).  They tend to have their own update infrastructure which is a pain to integrate into ours.
<YokoZar> I run into this problem whenever I consider packaging a Windows app via Wine, for instance.  ALL of them have to roll their own self-update tool from scratch since Microsoft doesn't provide anything like it.
<JanC> also, some CMS systems have configuration files all over the place
<JanC> or need updates for security issues every other week...  ;)
<wolfe> vanguard: squirrelmail IS the exact same in methodology
<wolfe> vanguard: normally people will download squirrelmail individually just like wordpress
<vanguard> wolfe: oh, I thought squirrelmail was something like postfix, sry
<Ampelbein> cjwatson: hmm, the only ia32-libs bug I (andreas moog) remember closing was bug 745781, what other bugs do you mean?
<ubottu> Launchpad bug 745781 in ia32-libs (Ubuntu) "natty ia32-libs is missing /usr/lib32/libnss3.so" [Undecided,Fix released] https://launchpad.net/bugs/745781
<cjwatson> 10:26 <cjwatson> YokoZar: bug 746758 is presenting with the same symptoms as bug 745459, but the syslogs show that the most current version of ia32-libs (20090808ubuntu11) is installed.  Wasn't that supposed
<ubottu> Launchpad bug 746758 in ubiquity (Ubuntu Natty) "11.04 64bit Beta1 CD Installer crashed [error processing flashplugin-installer]" [High,In progress] https://launchpad.net/bugs/746758
<ubottu> Launchpad bug 745459 in flashplugin-nonfree (Ubuntu) "package flashplugin-installer 10.2.153.1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Medium,Fix released] https://launchpad.net/bugs/745459
<cjwatson>                  to fix it?
<cjwatson> Ampelbein: ^-
<cjwatson> ah, sorry, it was Anders Kaseorg who closed that latter bug
<cjwatson> too many shared letters in your names so I confused them :)
<YokoZar> cjwatson: what do you mean by "same symptoms" though?
<Ampelbein> cjwatson: oh, ok, so it isn't my mind splitting and doing things on its own ;-)
<cjwatson> YokoZar: "nspluginwrapper: no appropriate viewer found for /usr/lib/flashplugin-installer/libflashplayer.so"
<cjwatson> and then flashplugin-installer.postinst exiting 1
<YokoZar> cjwatson: well what I fixed was the missing libraries, I don't claim to have fixed that since I never ran into it in testing.  But I didn't test a fresh install of nspluginwrapper.
<YokoZar> or rather of flashplugin-installer
<cjwatson> identical failure showing in https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/746758/comments/13
<ubottu> Ubuntu bug 746758 in ubiquity (Ubuntu Natty) "11.04 64bit Beta1 CD Installer crashed [error processing flashplugin-installer]" [High,In progress]
<YokoZar> I highly suspect though, that the error isn't in ia32-libs but rather in flashplugin-installer because ia32-libs is providing the libraries and they link fine post install
<cjwatson> OK, it seems to me that those bugs against ia32-libs were likely closed inappropriately, then
<YokoZar> cjwatson: well both components really
<cjwatson> yep.  I don't have an amd64 installation right now to test with
<Ampelbein> cjwatson: I tried installing flash in a fresh natty amd64 chroot (with 'pbuilder dist natty login') and there is no error, on my work system flash works and I can install/uninstall flashplugin-installer like I want to.
<cjwatson> maybe try with a desktop CD, since that's where I'm seeing reports?
<cjwatson> (check the "Install this third-party software" box on the second page)
<Ampelbein> will do. using kvm-qemu should make no difference?
<cjwatson> don't know, I'd be surprised if it did
<ari-tczew> slangasek: this one also has got problem with .la https://launchpad.net/ubuntu/+archive/test-rebuild-20110329/+buildjob/2394868
<ScottK> OdyX: Do we need some more pyside related syncs?
<OdyX> ScottK: pyside was apparently FTBFS'ing on armelâ¦ I had no time to investigateâ¦
<ScottK> OdyX: I saw you did another round of uploads in Debian.
<OdyX> ScottK: yes, new upstream releasesâ¦
<ScottK> Bugfix or new features?
<OdyX> bugfix
<OdyX> I suspect the armel thing won't be solved easily though.
<OdyX> It's #745852
<ScottK> It looks like it fails tests due to us switching from GL to GLES on armel too.
<OdyX> ScottK: but the new upstream releases build fine in natty PPAs (aka no armel). See https://launchpad.net/~pyside/+archive/ppa/+packages
<OdyX> (+ shiboken 1.0.1-2 for symbols mismatch on sparc/s390)
<ScottK> Looks like arch specific .install file will fix it on armel for Ubuntu.
<ScottK> dh_install: python-pyside.qtopengl missing files (usr/lib/python*/*-packages/PySide/QtOpenGL.so), aborting
<ScottK> OdyX: Why don't you request the sync's and I'll approve them.  Please ping me with bug numbers.  If it's bug fixes, we want them.
<OdyX> ScottK: lemme try to do that (I'm leaving for the week-end in ~1 hour).
<ScottK> OdyX: Thanks.
<arand> lool: Hia, seems to have a bit of an issue with the latest enabling of btrfsck, for some reason btrfsck reports "unsopported option" on my system (I use default mount options), and hence when it is enabled, boot fails, could this be something that many current btrfs users would run into?
<OdyX> ScottK: If you could do the "natty-armel" specific in a -1ubuntu0 for me, it'd just be great.
<ScottK> OdyX: I'll try to find the time for that. It's now part of Bug #707794
<ubottu> Launchpad bug 707794 in kdeedu (Ubuntu Natty) "libqt4-opengl on armel should be compiled with OpenGL ES 2.x support" [High,Triaged] https://launchpad.net/bugs/707794
<ScottK> slangasek: ^^^ one more.
<MadCow108> where do icons have to be so they are found by the unity launcher?
<sabdfl> MadCow108: usual places
<sroecker> Hi, there seems to be a problem with the new fglrx package for x64. I've filed bug #748308
<ubottu> Launchpad bug 748308 in fglrx-installer (Ubuntu) "fglrx driver doesn't work because libatiuki.so.1 is not found" [Undecided,New] https://launchpad.net/bugs/748308
<MadCow108> sabdfl; what are the usual places?  I have put it in pixmaps and icons and it is found also in the apps place but in the launcher I get a question mark
<sabdfl>  /usr/share/icons should work
<sabdfl> cjwatson: grub de-grubbed? sounds like it was a nasty one
<YokoZar> MadCow108: how are you putting icons there?
<YokoZar> MadCow108: I ask because generic newly defined icons coming from an upstream package should probably go into the hicolor theme, ie /usr/share/icons/hicolor
<MadCow108> thats where I put them
<YokoZar> Also I'm not sure when Unity does its caching/detection of new icons
<YokoZar> iirc when I update icons from a package I sometimes need to restart to see them change
<MadCow108> the launcher does not even display the name of the application, it does use .desktop files or?
<MadCow108> done that a few times already
<MadCow108> the app place seems to find the icon fine, why not the launcher?
<YokoZar> Now that I don't actually know
<charlie-tca> could the desktop file be pointing to a specific dir for the icon?
<MadCow108> no its just the application name
<charlie-tca> .desktop contain a line "Icon =" that sometimes is very specific
<MadCow108> I replaced my desktop file with the one from vlc (with changed exec) and its still a questionmark in launcher and a vlc icon in apps place, weird
<jcastro> cjwatson: I am only just now noticing the geoip bits in the alt installer, nice!
<ari-tczew> is it true that debian/changelog could not be longer than 79 characters?
<zul> it shouldnt
<slangasek> ari-tczew: ibus-client-clutter FTBFS because clutter-imcontext is on the list at http://people.canonical.com/~vorlon/broken-srcs-universe.txt needing a no-change rebuild; ibus-input-pad needs input-pad rebuilt; gtkmathview needs gdome2 rebuilt.
<slangasek> ScottK: noted, thanks
<cjwatson> sabdfl: getting wubi to keep working has been a bit hairy this cycle, yes :-/
<cjwatson> jcastro: thank ev for that :-)
<buxy> where should I reassign https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/748182 ? it's about an error in the installation process
<ubottu> Ubuntu bug 748182 in dpkg (Ubuntu) "Natty installer fails with E-Sub process /usr/bin/dpkg" [Undecided,New]
<slangasek> buxy: 'ubiquity' makes a good first approximation
<buxy> thanks
<phenom> ubottu has a bug: Type "nc -lv 5555" in #ubuntu. Returns:Launchpad bug 5555 in Launchpad itself "add branch form has confusing english" [Medium,Fix released] https://launchpad.net/bugs/5555
<ubottu> Ubuntu bug 5555 in Launchpad itself "add branch form has confusing english" [Medium,Fix released]
<ubottu> Launchpad bug 5555 in Launchpad itself "add branch form has confusing english" [Medium,Fix released] https://launchpad.net/bugs/5555
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<phenom> wow
<phenom> nc -lp 5555
<ubottu> Launchpad bug 5555 in Launchpad itself "add branch form has confusing english" [Medium,Fix released] https://launchpad.net/bugs/5555
<phenom> Hope it's programmed with some good flood protection.
<Daviey> phenom, Thanks - can you report it to, https://bugs.launchpad.net/ubuntu-bots/+filebug please?
 * phenom nod
<ari-tczew> slangasek: then ibus-client-clutter needs also rebuild?
<slangasek> it doesn't need a rebuild; it just needs clutter-imcontext rebuilt so that it's buildable
<ari-tczew> slangasek: ok, are you going to do it or shall I take it?
<slangasek> ari-tczew: please do :)
<ari-tczew> slangasek: ok! if they are in universe, will do
<slangasek> ari-tczew: yes, they're all in universe; I cleaned main of these issues last week
<ari-tczew> slangasek: I can do more uploads of them, just give me the reason for d/changelog which I should use.
<slangasek> ari-tczew: I've used 'No-change rebuild to pick up multiarch .la files'
#ubuntu-devel 2011-04-03
<lool> arand: Could you share the specific output you're getting and your fstab?
<arand> lool: I asked another one using the current version, not reproduced there I reported Bug #748340
<ubottu> Launchpad bug 748340 in btrfs-tools (Ubuntu) "btrfsck fails with "unsupported option features", must [ignore] to boot" [Undecided,New] https://launchpad.net/bugs/748340
<arand> lool: my fstab is pretty much default as far as I can tell: http://paste.debian.net/112820/
<arand> lool: I think it may come down to the fact that I have restored and moved around snapshots of my "/" (basically via the apt-btrfs-snapshot method).
<arand> lool: More info attached on the bug report, I'm getting more uncertain is we as downstream could really do anything about it.. Sorry for bugging you a lot if that turns out to be the case.
<lduros> hello
<lduros> does anybody use Evolution Mail on Natty?
<lduros> For some reason, there's no way for me to access the "Preferences" anymore
<lduros> The top menu only have "File" > "Close" tab and that's it
<Ampelbein> slangasek: hi, can you look at bug 748740, the sync is related to the .la-cleanup.
<ubottu> Launchpad bug 748740 in libvmime (Ubuntu) "Sync libvmime 0.9.0-1.2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/748740
<soreau> Does anyone happen to know the max time gnome-sound-recorder will record? Is it simply limited by hard drive space?
<soreau> using the default lossy ogg format
<holstein> AFAIK
<holstein> soreau: its hard drive space
<holstein> should be*
<holstein> no reason why not
<soreau> That would be my guess but I was looking for a more definitive answer
<holstein> well, with ardour + jack
<holstein> its hard drive space
<Chipzz> soreau: support questions go to #ubuntu
<soreau> Chipzz: Dont start with me.
<Chipzz> soreau: pardon?
<ScottK> soreau: Like it or not, Chipzz is correct.
<Chipzz> ScottK:
<Chipzz> 05:49 <soreau> I do enough support in #ubuntu to have the right to ask a question in -devel every once in awhile
<Chipzz> 05:49 <Chipzz> no you don't
<Chipzz> 05:49 <soreau> Well then, you can kiss my ass
<Chipzz> 05:49 <soreau> because you dont even know me
<Chipzz> 05:49 <Chipzz> how does you giving support in #ubuntu warrant violating the channel rules?
<Chipzz> 05:50 <soreau> I told you, dont start
<Chipzz> 05:50 <soreau> I start it and I end it
<Chipzz> 05:50 <soreau> I dont abuse privs
<Chipzz> 05:50 <soreau> And its none of your god damned business so shove off
<ScottK> Chipzz: Posting the private message into the public channel isn't so great either.
<soreau> Indeed.
<soreau> I cant believe you are that foolish
<ScottK> soreau: He is correct, however.
<soreau> ScottK: Yes I know, but I took it to pm and it aws over
<soreau> was*
<soreau> but know he opened a whole nother can of worms
<soreau> now*
<soreau> Actually, I dropped it. HE pmmed me to continue
<soreau> Chipzz: You have no irc etiquette which is prerequisites to using irc in the first place. Thus, you have no business even calling OT
<ScottK> soreau: You were OT.
<soreau> Yes but I dropped it.
<soreau> Now look where we are
<ScottK> Both of you: If you want to argue - Do it somewhere else.
<soreau> Totally way OT in a -dev channel
<Chipzz> soreau: my apologies for c/p the pm
<soreau> Too late
<soreau> Whats done is done
<soreau> I hope you learn not to do that in the future
<soreau> holstein: Thank you for your input
<holstein> sure
<soreau> Im pretty sure its governed solely by disk space
<holstein> check out #ubuntustudio
<soreau> I dont have the code in front of me so I figured Id ask where someone might
<slangasek> Ampelbein: 748740> done, thanks :)
<snow_ru> hi
<pwuertz> hi! natty is not loading the nouveau driver for my GF104.. this card should be supported, right?
<IanLiu> I've contributed code to Ubuntu, solving some bugs. How can I prove to job interviewers I contributed? Does my name appear somewhere?
<JanC> IanLiu: your name is probably in the bug reports or in the changelogs or something?
<IanLiu> JanC: Oh, yes, the bug report, indeed. But I looked at changelogs and haven't found ;-) I guess there is too many contributors to specify in changelogs
<JanC> sometimes they are mentioned, sometimes not, I guess
<JanC> but if you attached a patch that should be obvious  âº
<IanLiu> ;-)
<AnAnt> Hello, is there some sort of setting (gconf maybe) to change the default session to Classic instead of Unity ?
<holstein> hey AnAnt
<holstein> i would check the /topic here, and maybe try #ubuntu-beginners or #ubuntu+1 if you find #ubuntu too busy
<AnAnt> holstein: actually I need this for development
<AnAnt> I am working on a distro based on Ubuntu, and need to keep the default session type to be Classic instead of Unity
<holstein> AnAnt: you can try #ubuntustudio
<holstein> we are going to use gnome in 11.04
<holstein> not sure how that worked out on the back end
<AnAnt> holstein: thanks
<holstein> AnAnt: maybe #ubuntustudio-devel
<holstein> if no one pipes up here
<holstein> there*
<lool> arand: Thanks for the bug; so basically my upload made running fsck possible, and that exposed that fsck isn't passing for you
<micahg> slangasek: I'm getting some weird breakage with gnash, multiarch, and pthreads, gnash seems to be able to find other things in the multiarch path, but not libpthreads.so
<micahg> slangasek: nevermind, I think I found the problem, there's a libslist variable that hardcodes lib paths
<micahg> slangasek: I guess I'll need help or a guide for making a package with hardcoded lib paths multiarch aware in a sane way
<slangasek> micahg: remove the hardcoded lib path? :)
<micahg> slangasek: ok, what's the sane way to check for libpthreads?
<slangasek> micahg: how do you mean?  What checking is it doing now?
<slangasek> is gnash not using autoconf?  I would expect it to, being a GNU project
<micahg> slangasek: there's a hardcoded list of lib paths that's used to check for the .a or .so in
<azeem_> I thought it's a GNU project by politics more than by technical reasons
<slangasek> micahg: the right way is actually to not check for libpthread at all, but only to build and link with -pthread
<slangasek> (on some architectures, such as mips, -lpthread alone doesn't DTRT)
<micahg> slangasek: well, it's doing that already, so maybe I should just remove this check
<slangasek> micahg: looking over macros/pthreads.m4 now
<micahg> ah, that's where it is
<micahg> slangasek: ~line 163 is where the trouble is
<micahg> err, ~185
<slangasek> micahg: yeah, I think 183-210 are wrong for GNU systems; we should actually just be setting PTHREAD_LIBS=-pthread and skipping the manual lib check AFAIK
<micahg> slangasek: ok, what about for Debian
<slangasek> micahg: same thing, it's a function of it being a GNU environment
<micahg> slangasek: ok, cool, I'll make a patch and submit to them, thanks
<slangasek> thank you :)
#ubuntu-devel 2012-03-26
<balloons> anyone ever have there ppa build fail? I see the log, but I don't understand why it failed to build. https://launchpadlibrarian.net/98350420/buildlog_ubuntu-precise-i386.checkbox_0.13.5ubuntu1_FAILEDTOBUILD.txt.gz
<balloons> bah.. I see it, sorry for false alarm :-)
<imbrandon> copying checkbox/reports/xml_report.py -> build/lib.linux-i686-2.7/checkbox/reports
<imbrandon> error: package directory 'checkbox_cli' does not exist
<imbrandon> dh_auto_build: python setup.py build --force returned exit code 1
<imbrandon> make[1]: *** [override_dh_auto_build] Error 1
<balloons> yep. I missed that the first time, I just saw the error build 2.. I know how to fix. thanks imbrandon
<barry> lifeless: mailman 3 supports sqlite and postgres currently (hopefully someone will donate mysql support)
<lifeless> barry: so, just so you know, using timezones in the DB layer is pretty crackful
<barry> lifeless: also, martin von loewis is working on a python 3 port of storm.  it would be awesome to eventually land that
<barry> lifeless: i only care about utc
<lifeless> barry: so storm supports utc already
<barry> lifeless: not so much
<lifeless> barry: thats what timestamp without timezone columns are
<jamesh> lifeless: it is probably okay to use time zones in the database layer if every subscriber to every list on the system is in the same time zone
<lifeless> barry: AIUI
<barry> the problem is it chokes parsing +00:00 suffixes
<lifeless> jamesh: a pretty narrow case :)
<jamesh> yep, I'd recommend using "timestamp without time zone" columns with PostgreSQL -- a connection level time zone is not particularly useful for any task where you're doing work on behalf of multiple users with a single connection
<jamesh> so best to ignore the feature
<lifeless> its also dangerous
<lifeless> if you do any manual sql it *won't* do what you might expect
<barry> i'd be happy if it parsed the tz string and threw an exception on anything that wasn't +00:00
<lifeless> barry: if what parsed the tz string?
<barry> _parse_time() in storm/variables.py
<lifeless> jamesh: barry: -> #storm I guess
<ScottK> Don't distract barry.  He's got stuff to fix in his packages in Debian.
<barry> ScottK: ouch ;)
<ScottK> (you got the PM, I assume)
<ScottK> It will get extremely more painful to get the package renames fixed up if we don't get them into precise.
<mwhudson> jamesh: i bet you like django then
<jamesh> mwhudson: Django is awesome.
<mwhudson> jamesh: did i ever show you this bug? https://code.djangoproject.com/ticket/17062
<ubottu> Django bug 17062 in Database layer (models, ORM) "Using postgres, if you rollback the first transaction on a connection, the effect of settings.TIME_ZONE is lost" [Normal,Closed]
<mwhudson> jamesh: it's pretty awe-ful
<jamesh> mwhudson: that'll teach you for relying on connection level time zones :)
<mwhudson> jamesh: yep, or relying on people who etc
<jamesh> you seem to be getting more developer attention than my django bug (admittedly mine was closer to a new feature request than a bug)
<mwhudson> yeah, the bug was fixed quite quickly
<mwhudson> (and without me noticing, yay trac!)
 * jamesh is still waiting on https://code.djangoproject.com/ticket/16674
<ubottu> Django bug 16674 in Core (Other) "Django's WSGI Handler should report exceptions to the start_response() callback" [Normal,New]
<pitti> Good morning
<dholbach> good morning
<diwic> good morning dholbach
<dholbach> hi diwic
<diwic> question to anyone, I've heard good things about xbmc so I was considering installing it, but it seems to be not in the official repositories but in a PPA. Why?
<micahg> diwic: debian 469397
<ubottu> Error: Could not parse data returned by Debian: timed out
<pitti> Daviey: I assume I should move bug 844995 to final now? Or do you think you guys can fix kombu for b2 still?
<ubottu> Launchpad bug 844995 in python-couchdb (Ubuntu Precise) "Drop support for couchdb related packages" [Undecided,Triaged] https://launchpad.net/bugs/844995
<diwic> micahg, thanks *reading*
<pitti> infinity: do you still plan to work on bug 759545?
<ubottu> Launchpad bug 759545 in grub2 (Ubuntu Precise) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Triaged] https://launchpad.net/bugs/759545
<pitti> Daviey: do you consider bug 959683 urgent enough to keep it at b2? I think it's fine to move to final, WDYT?
<ubottu> Launchpad bug 959683 in mysql-5.5 (Ubuntu Precise) "missing mysql-testsuite metapackage" [High,Fix committed] https://launchpad.net/bugs/959683
<infinity> pitti: I've already promised Daviey I'd find a fix before final (I intend to work on it this week).
<infinity> pitti: But unless I fix it Monday, I think we're better off moving the milestone, yeah.
<ritz> weird, bzr branch of gtk+3 fails
<ritz> $ bzr clone  lp:ubuntu/oneiric/gtk+3.0
<ritz> The command 'bzr clone' has been deprecated in bzr 2.4. Please use 'bzr branch' instead.
<ritz> bzr: ERROR: Revision {james.westby@ubuntu.com-20110720104429-q7mz8vnm20mly8y4} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))".
<ritz> nm, https://bugs.launchpad.net/bzr/+bug/888841
<ubottu> Launchpad bug 848064 in Ubuntu Distributed Development "duplicate for #888841 Revision not present branching from udd-imported branches on lp" [Critical,Confirmed]
<ev> cyphermox: is there anything blocking us from setting up a server for the network manager connectivity check? We could potentially throw something on start.ubuntu.com, like the already-existent http://start.ubuntu.com/connectivity-check.html
<pitti> infinity: ack, thanks
<hrw> http://marcin.juszkiewicz.com.pl/2012/03/26/ubuntu-12-04-precise-and-cross-compilation-of-arm-kernels/ - refreshed instructions for precise. Thanks for everyone who helped to make it so easy
<zyga> hi
<zyga> on current precise I get very often double-event for every mouse button press
<zyga> I never had this before the upgrade
<zyga> running xev it seems that almost every button press is registered as two consecutive press and release events
<zyga> http://pastebin.ubuntu.com/900292/
<zyga> is there anyone that experiences similar issue?
<zyga> it's turning anything that requires double-click into a single-click operation
<jdstrand> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta 2 Freeze in Effect. Archive: pre-release freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand
<cjwatson> mvo: bug 839986 looks like http://paste.ubuntu.com/900317/, but would you prefer to also change python-apt to return None from .uri in such cases?  (That wouldn't fix the whole problem; _guess_third_party_changelogs_uri_by_source would still need a change anyway.)  I don't know what you think is most correct here
<ubottu> Launchpad bug 839986 in update-manager (Ubuntu) "update-manager crashed with StopIteration in uri()" [Medium,Confirmed] https://launchpad.net/bugs/839986
<cjwatson> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta 2 Freeze in Effect. Archive: pre-release freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand, cjwatson
<cjwatson> I should probably do some of this
<mvo> cjwatson: I think None makes sense
<cjwatson> mvo: want a python-apt task then?
<cjwatson> and I'll just apply the 'if not deb_uri:' part of that
<cjwatson> (to update-manager)
<mvo> cjwatson: a python-apt task for this would be nice, yes
<mvo> cjwatson: thanks, that sounds like a good approach
<mvo> cjwatson: I guess http://paste.ubuntu.com/900332/ is all we need in p-apt?
<rbasak> If I'm preparing an upload for a bugfix by taking someone else's patch to a debian/patches/... file and only adding a changelog entry, and the only change is the bugfix, should I be using his name or my name to sign the changelog entry?
<cjwatson> rbasak: his
<rbasak> cjwatson: ok, thanks!
<cjwatson> rbasak: it's acceptable to use yours and say "thanks, Person's Name", but using their name is more polite because it shows up in their +uploadedpackages or whatever it is in LP and is easier to find in applications for upload rights
<cjwatson> jamespage: https://bugs.launchpad.net/ubuntu/+source/athena-jot/+bug/804355 - I kind of feel uncomfortable overruling you on the bug, but it really isn't good form to change the packaging around in an Ubuntu patch, and I don't think we should be advising patch submitters to do it
<ubottu> Launchpad bug 804355 in athena-jot (Ubuntu) "jot random number generator broken in batch jobs" [Undecided,New]
<cjwatson> if the package is laid out in 1.0 style such that patches are applied directly, it's OK for Ubuntu modifications to follow that
<cjwatson> and much easier to merge later
<jamespage> cjwatson, looking (can't remember the bug)
<jamespage> cjwatson, ack - thats a fair point - please continue to feel free to overrule me when I'm going off on one....
<cjwatson> jamespage: perhaps you could sort out the bug and do something that seems sensible, when you get a minute?  I also don't want to confuse the reporter overly
<jamespage> cjwatson, leave it with me - he actually did alot more that I expect him todo
 * cjwatson nods
<cjwatson> thanks
<jamespage> cjwatson, np - thanks for pointing out my sometimes over zealous nature!
<stgraber> seb128: I added a comment to bug 331369 but didn't change it back to Triaged as I didn't have time to read through the whole history to see if someone decided that the current (in my view broken) behaviour is the "right" one
<ubottu> Launchpad bug 331369 in notify-osd (Ubuntu Oneiric) "regression vs. notification-daemon: positioning when multiple screens are available" [Medium,Fix released] https://launchpad.net/bugs/331369
<seb128> stgraber, talking to the wrong guy, you want to talk to MacSlow or design, I've nothing to do with notify-osd
<stgraber> seb128: ok :) just poked you as you are commented-last on the LP bug
<stgraber> MacSlow: ^
<MacSlow> stgraber, talking about 331369?!
<MacSlow> stgraber, well this decision is from Design... you have to talk to them... or you could try setting to com.canonical.notify-osd:multihead-mode "focus-follow"
<MacSlow> stgraber, which would notification bubbles appear on the monitor with the currently focused window
<stgraber> MacSlow: oh, I didn't know of multihead-mode, I guess I'll just set that then
<MacSlow> stgraber, you know how to use gsettings for that?
<stgraber> MacSlow: yep
<MacSlow> stgraber, as values for that key use either "focus-follow" or "dont-focus-follow"
<jdstrand> pitti: hi! these two merges against lp:ubuntu are in proposed now. can you set the status on them?
<jdstrand> https://code.launchpad.net/~utlemming/cloud-init/cloud-init-lp948461_sru_oneiric/+merge/98014
<jdstrand> https://code.launchpad.net/~utlemming/cloud-init/cloud-init-lp942061_sru_natty/+merge/97997
 * soren contemplates whether we're approaching a record breaking short amount of time before the release to reveal what the next release is going to be named
<soren> Hm.. "Precise" was announced 8 days before Oneiric's release. I guess there's still a bit of a way to go before we're in record breaking territory.
<soren> *shrug*
<cyphermox> ev: not much is stopping us really, and http://start.ubuntu.com/connectivity-check.html is pretty much sufficient
<ev> cyphermox: we'd have to patch n-m though, surely? As it expects either a http header or "NetworkManager is online"
<ev> or perhaps I've read the code wrong or missed an optional argument
<ev> but that's excellent news
<cyphermox> ev: that is, if you forget about the fact that enabling connectivity checking like this in ubiquity is going to be subject to FF; and adding a check is always scary to some
<cyphermox> ev: no, I thought you could specify what to check for
<ev> well, ubiquity already has a connectivity check built around this. I'm happy to move that in precise+1
<ev> I'm more concerned about bug 964508
<ubottu> Launchpad bug 964508 in whoopsie-daisy (Ubuntu) "whoopsie uploads crash reports, including core dumps, when on a 3G connection" [Medium,Confirmed] https://launchpad.net/bugs/964508
<ev> err and it doesn't directly relate to this
<ev> bug if I'm putting code in to check NM for the connection type
<ev> then we get this for free
<cyphermox> ev: don't bother, it's already supposed to be available :)
<ev> what do you mean?
<ev> oh, I see
<ev> indeed, but that's what I mean by it being only loosely related
<ev> it would be nice if whoopsie didn't throw several megs of core dump at a captive portal page
<cyphermox> well, just like any other application probably shouldn't try to load up and talk to a portal page...
<cyphermox> ev: for device type checking, getActiveDevice via DBus will give you the active device; you can then ask it its type
<ev> right, and that's what I'm doing (GetActiveDevices) - but it would still be nice to have the captive portal stuff so we don't think we're online and sending successful crashes when we are not.
<ev> err ActiveConnections
<ev> then iterating over that to find the types
<ev> and bailing out if we find any that are 3g/modem
<cyphermox> aye
<cyphermox> oh... but then don't you risk bailing out if a 3g modem is connected but not the default route?
<ev> indeed
<ev> I was just going to say :)....
<ev> suggestions welcome for how I pick the right interface to feed libcurl when there are both 3g and non-3g connections present
<cyphermox> ev: I think you don't need to pass an interface in this case, it should magically work.
<ev> ah, wonderful
<cyphermox> (because whatever you're trying to access should be behind the default gateway)
<cyphermox> so, for connectivity checking, feel free to experiment with it, I think I still have the excerpt for testing
<cyphermox> or maybe not
<cyphermox> essentially it's something like [connectivity]\nuri=http://start.ubuntu.com/connectivity-check.html\nresponse=Lorem ipsum
<ev> yay
<cyphermox> ev: from there if you look at the NM logs it will write an error in syslog if it fails, but IIRC continue silently if everything is fine
<ev> cyphermox: cool, cheers
<cyphermox> I don't see how you can connect that to just whoopsie though; seems like more of a system-wide thing
<cyphermox> .... which I'm not sure I want to see exploding in precise :)
<smw> Hey guys, can anyone answer a couple questions about version policy of packages? There is a programming language called go that is currently in RC2 and about to reach 1.0 status. Right now ubuntu has the "r60" version that is extremely old. Would ubuntu not update to 1.0 until the next release?
<smw> Would there be any way to include the RC2 and then upgrade to the 1.0?
<smw> r60 is practically a different language and will be useless when 1.0 comes out.
<smw> (I am asking if there is a way to get it into the LTS or if it would need to wait for 12.10)
<cyphermox> smw: afaik just needs somebody to do the work of updating the package
<geser> and probably a FFe too
<cyphermox> and of course have the feature freeze bug to go with the features added into your rc2 or 1.0
<cyphermox> yeah
<smw> cyphermox, what?
<geser> smw: when is 1.0 planed to get released?
<ev> cyphermox: I wont have to connect it to just whoopsie. But without it, whoopsie will interpret CONNECTED_GLOBAL to mean it can see out to the Internet, when the system might actually be behind a captive portal.
<smw> geser, they refuse to give a time. The last two weeks were officially RC1 and RC2
<smw> geser, I would say 1.0 is very soon.
<cyphermox> ev: yeah, but that's not unlike it's been for the last forever :)
<ev> :)
<cyphermox> ev: so to me it feels very late to change this kind of default
<smw> geser, you will not find that mentioned on the site, but I can show you release announcements on google groups from the google DevRel saying it is RC2 ;-)
<cyphermox> especially without knowing how it might run with people over 3g in different setups, of the russians who need to connect to a vpn to get online, or those who have a firewall blocking the start.ubuntu.com page or some other thing :)
<cjwatson> smw: it would help to get it updated in Debian, as we currently sync that package verbatim from there
<geser> smw: 12.04 is about to release end of April, so there is not much time to release it, package it and get it into the archive for 12.04 (if an exception is granted to update the package that late)
<cjwatson> it's not *essential* but it smooths the wheels a lot
<smw> cjwatson, hm...
<ev> cyphermox: sure, we can push that to +1 with the understanding that our crash reports statistics will be potentially missing data from systems behind captive portals
<cjwatson> nobody seems to have even filed a Debian bug about any newer golang releases yet
<smw> cjwatson, right now RC2 is debian's golang-weekly
<smw> cjwatson, that is because RC2 was another weekly.
<cjwatson> right, but there's a golang package which is supposed to be something you might actually use rather than a rolling snapshot
<cyphermox> ev: I feel that's safer; but I'm open to having the decision taken above my head by foundations; if you think the benefit outweights the risks and relative newness of that feature.
<smw> cjwatson, but no one would actually use r60 anymore
<cjwatson> sure, but in principle that's what the non-weekly package is for
<cjwatson> it should be upgraded if there's a newer actual release
<smw> cjwatson, one sec
<ev> cyphermox: nope - I think you're right. :)
<smw> cjwatson, http://groups.google.com/group/golang-nuts/browse_thread/thread/b3dae81308fe654d/0b3b9e48efad3d17?show_docid=0b3b9e48efad3d17
<cjwatson> um, I should clarify, I have no personal involvement with golang
<cjwatson> just giving general advice
<smw> cjwatson, they are right now in API/feature freeze for go1 .0.
<vibhav> Is there any limit to the number of FFe's that can be requested after Feature Freeze?
<smw> vibhav, FFe?
<cjwatson> I don't really need to see the release announcement :)
<cyphermox> ev: I don't have enough experience with how it might fly with some of the hairier internet connection methods; I think this particular thing would have benefited a lot from being introduced early in the release, and have a nice formal call of testing for each milestone, just in case.
<vibhav> smw: Feature Freeze Exception
<cjwatson> since I'm not the Debian maintainer here
<smw> vibhav, ah
<ev> cyphermox: understood
<cyphermox> ev: we can definitely look into that for precise+1 though :)
<ev> :)
<ev> definitely
<cjwatson> vibhav: not as such, although if you started flooding us with hundreds of them we might start taking a different attitude ...
<geser> vibhav: no limit, but I guess you will become not very liked if you flood them with requests
<smw> cjwatson, so I should submit a bug following the feature freeze exception page that says why I think golang-weekly instead of golang r60 should be included?
<smw> cjwatson, can you give any tips on what type of information I should provide/use to convince them?
<cjwatson> smw: what I suggested was filing a Debian bug asking for the new upstream release to be packaged there
<cjwatson> that is the most straightforward way to get this done
<smw> cjwatson, it is packaged, but not as "golang"
<cjwatson> as "goland"
<cjwatson> er, "golang"
<smw> cjwatson, I doubt they would do that. They have no reason not to wait.
<cjwatson> I can but offer advice
<smw> cjwatson, of course.
<cjwatson> there is also no reason not to ask :-)
<smw> cjwatson, true :-)
<cjwatson> (if nothing else, Debian has an "experimental" distribution ...)
<smw> cjwatson, but I believe the answer I am going to get is a no. I would not try and push this on debian unstable because there would be no reason. However, ubuntu is about to release an lts so it matters ;-)
<smw> cjwatson, yeah, but debian sid has no reason not to wait
<cjwatson> we can sync from experimental; that's still easier than doing it locally
<vibhav> cjwatson: But What if the exceptions are really good and not simply flood?
<smw> cjwatson, yeah, I just have no good reason to convince sid to update ;-)
<cjwatson> vibhav: you should just file them then
<cjwatson> just bear in mind that the release team is composed of humans
<vibhav> thanks cjwatson
<cjwatson> vibhav: ... how many are we talking about?  I'm a bit disconcerted by the fact that you feel you need to ask ...
<vibhav> cjwatson: I had filed a sync request eariler yesterday for syncing some package, Today I saw a list of bugs which were fixed in Debian and decided to file one more bug too, So I was a bit worried that I might annoy the release team
<cjwatson> if you're working in units of one, I don't think you will
<vibhav> ah ok
<smw> cjwatson, how can I measure the impact of a package? Like get a list of all packages which require it to build or install.
<cjwatson> smw: grep-dctrl over files in /var/lib/apt/lists/
<smw> thanks cjwatson
<cjwatson> neither golang nor golang-weekly has any reverse-dependencies in the distribution right now
<cjwatson> or reverse-build-dependencies
<smw> cjwatson, you checked?
<cjwatson> yes
<smw> thanks :-)
<smw> cjwatson, damn, even golang weekly is not up to date :-\
<pitti> jdstrand: done
<jdstrand> pitti: thanks! :)
<smw> cjwatson, when go1 is released, would they consider doing the major upgrade after the fact?
<smw> cjwatson, since it is a low impact package
<cjwatson> smw: maybe; http://wiki.ubuntu.com/StableReleaseUpdates
<smw> cjwatson, thanks
<cjwatson> the closer precise as released is to 1.0, the easier, though
<smw> cjwatson, yeah, r60 is practically another language
<smw> cjwatson, r60 was released ages ago. But once go1 comes out... it becomes useless
<smw> cjwatson, then again, it is useless now ;-)
<smw> cjwatson, yes! the debian packager for golang is an ubuntu person too! This will help :-)
<smoser> jdstrand, is bug 964008 ok? we have 3 packages on that MIR. would you like separate ones?
<ubottu> Launchpad bug 964008 in shunit2 (Ubuntu) "[MIR] distro-info, distro-info-data, and shunit2" [Undecided,New] https://launchpad.net/bugs/964008
<jdstrand> smoser: that works fine. it might be nice to be more explicit than 'All MIR requirements apply to it' for shunit
<smoser> jdstrand, i didn't really follow that.
<jdstrand> smoser: bdrung tacked on shunit in comment #2 with that comment. that's fine, but it would be better if the mir request info was explicit in the bug for shunit
<smoser> i'll update desscription. he added it to summary.
<jdstrand> smoser: well, I see that, but I mean things like Maintenance, QA, etc. it is a different package after all :)
<smoser> right. i'll update.
<cjwatson> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta 2 Freeze in Effect. Archive: pre-release freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand
<Whoopie> cjwatson: thanks a lot for uploading the sflphone package!!!
<jhojho> so will precise ship linux 3.3?
<cjwatson> Whoopie: you're welcome
<jhojho> cjwatson: btw thanks for getting openssl updated...
<jdstrand> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta 2 Freeze in Effect. Archive: pre-release freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Whoopie> cjwatson: Can I ignore this build error for sflphone? -> https://launchpadlibrarian.net/98415372/buildlog_ubuntu-precise-armel.sflphone_1.0.2-1ubuntu1_CHROOTWAIT.txt.gz
<Laney> LP ops tried to fix that, evidently without success
<cjwatson> Whoopie: not your problem, certainly, though it's somebody's problem
<cjwatson> Laney: I've re-reported it
<Whoopie> cjwatson: ok.
<Laney> righto
<dholbach> Sweetshark, adam_g, good luck later on! :)
<Sweetshark> dholbach: what exactly do I have to expect? will I be grilled with questions or will it just be a quick nod off?
<dholbach> Sweetshark, some questions will surely be asked - I don't know if anyone got just waved through
<dholbach> :)
<cjwatson> Whoopie,Laney: should be fixed now and with any luck won't recur again
<cjwatson> (this was the first recurrence, after the first *oc*currence earlier today ...)
<cjwatson> Whoopie: https://launchpad.net/ubuntu/+source/sflphone/1.0.2-1ubuntu1/+build/3319843/+files/buildlog_ubuntu-precise-armhf.sflphone_1.0.2-1ubuntu1_FAILEDTOBUILD.txt.gz is a package problem, however ...
<cjwatson> Whoopie: new failure, too, the last version built on armhf
<Daviey> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta 2 Freeze in Effect. Archive: pre-release freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Daviey
<alexbligh> If I have an old fashioned rc2.d/S99foo init script, what, if anything, stops that running before network interfaces are configured and up; i.e. is upstart interpretting the LSB stuff at the top or are they comments?
<jodh> alexbligh: If you look at upstart-events(7) and /etc/init/rc-sysinit.conf, you'll see that the SysV compat services run after all static network interfaces are "up".
 * lamont_ ponders how to get unity-greeter to actually show him his username, or a box to type same in, so that he can login to his machine as other than guest
<slangasek> using uid < 1000, eh?
<seb128> lamont_, get an uid in the normal range?
<lamont_> uid=2501
<slangasek> oh, really?
<lamont_> and it's even in /etc/passwd
<lamont_> rather than just relying on libnss-db to actually integrate
<seb128> lamont_, do you have accountsservice installed?
<lamont_> [SeatDefaults]
<lamont_> greeter-session=unity-greeter
<lamont_> user-session=ubuntu
<lamont_> #greeter-hide-users=true
<lamont_> seb128, yes
<seb128> lamont_, if you uncomment the hide users you should get a box to type your username,password
<lamont_> (I have not smacked things around since adding the # to the front of that last line of lightdm)
<lamont_> did not
<seb128> did not what?
<lamont_> I get a pretty box with "Guest Session" and  "Log in" boxes
<lamont_> no where to type a user name
<seb128> if you uncomment it you should get a box "other..."
<lamont_> let me smack X and all around one more time and see if changing it back helps.
<lamont_> seb128, forwarded you the picture of my login screen
<seb128> lamont_, can you share your /var/log/lightdm/lightdm.log?
<lamont_> minimum-uid=20000
<lamont_> I wonder if that's related.
<seb128> where do you have that?
<lamont_> guest-oaARA0@rover3:/etc/lightdm$ cat users.conf
<seb128> urg
<lamont_> that was my previous hack to get the user list to not show up on the login screen
<seb128> lol
<lamont_> since I REALLY DO NOT WANT IT THERE
<seb128> yeah, that might be it :p
<seb128> set it back to 500?
 * lamont_ gives that a stab
<seb128> though
<seb128> # NOTE: If you have AccountsService installed on your system, then LightDM will
<seb128> # use this instead and these settings will be ignored
<lamont_> seb128, no change, even with a reboot (since I killed lightdm hard enough that it didn't come back...)(
<lamont_> let me get you that log
<lamont_> seb128, chinstrap, ~lamont has lightdm.log, x-0*log
<seb128> lamont_, lightdm.log: Permission denied
<lamont_> bother
<lamont_> fixed
 * lamont_ tries show-manual-login=true, based on x-0-greeter.log
<lamont_> I wonder if that requires restarting lightdm
<seb128> lamont_, the greeter is reloaded every time so no
<lamont_> seb128, and of course, no scrollback as I bounce thru guest sessions
<seb128> lamont_, the greeter is reloaded every time you log in so no need to restart lightdm
<lamont_> that's good
<lamont_> OTOH, I do have to log out of my guest session to get back there
<lamont_> since they seem to get thrown away each time, too
<seb128> right
<seb128> mterry, there?
<lamont_> seb128, see also chinstrap:~lamont/lightdm (copy of /etc/lightdm)
 * lamont checks on what accountsservice has to say
<lamont> because that may be related
<seb128> lamont: you might want to use d-feet and look at org.freedesktop.Accounts on the system bus, but that would be for users to list
<seb128> not for the others box to show
<seb128> lamont: but you got over my lightdm knownledge, try pinging mterry or robert_ancell when he gets online
<lamont_> seb128, ok
<lamont_> though another possibility occurs to me... ubuntu-desktop decided to uninstall for a recent update, for the crying
<lamont_> brb
<lamont> nope.  still hates me
<lamont> I'm guessing that neither one of them is here atm
<smoser> cjwatson, around ? hallyn says you were looking at some crypto performance stuff recently.
<lamont> seb128: do you happen to have a commandline for d-feet?
<lamont> and somehow I fear that debugging this is going to require root and GTK
<lamont> also, d-feet segvs when run from a vt
<seb128> lamont, dbus-send but I'm not enough into dbus to know the syntax for it, I usually just use d-feet :p
<cjwatson> smoser: just bug 958430
<ubottu> Launchpad bug 958430 in openssl (Ubuntu) "[FFe] Please merge openssl 1.0.1 from Debian unstable" [High,Fix released] https://launchpad.net/bugs/958430
<smoser> i'm seeing some performance regression during https download in precise compared to lucid (bug 963420).
<ubottu> Launchpad bug 963420 in wget (Ubuntu) "https download performance significantly worse in precise than lucid" [Medium,Confirmed] https://launchpad.net/bugs/963420
<cjwatson> you probably need, like, an actual expert :)
<smoser> i'd much rather you not imply that there is an end to your expertise, cjwatson.
<cjwatson> try 'openssl speed' comparisons like those in the bug above, if you can identify the right algorithm
<lamont> smoser: I agree
<smoser> crossing my fingers, i hope that my bug is a dupe of yours.
<lamont> seb128: d-feet (run as guest) prompts me for a bus address, which is where I run into ENOCLUE
<cjwatson> nope, you already have 1.0.1
<smoser> as i had ruled out wget itself.
<cjwatson> at various points I have been a performance journeyman and a crypto apprentice, but never a crypto performance expert
<seb128> lamont, you can use the menus and connect to the system bus
<cjwatson> smoser: might be more like 940230
<cjwatson> bug 940230
<ubottu> Launchpad bug 940230 in openssl (Ubuntu) "openssl on 64bit is much slower than before" [Undecided,New] https://launchpad.net/bugs/940230
<dr3mro> unity scope cities stopped working is there a fix?
<cjwatson> I'm still sort of sceptical as it seems that some of this was deliberate; I'd like to talk with the Debian maintainer before making any precipitate changes there, but haven't got round to it yet
<lamont> seb128: User{1000,1001,2501}
<hallyn> that sounds similar :)
<seb128> lamont, yeah, I'm not sure why the greeter is not listed them then...
<lamont> hrm
<lamont> seb128: I'm tempted to remove and reinstall lightdm and unity, just to get back to the defaults and see if that makes a difference
<mterry> lamont, you had a question?
<lamont> mterry: yeah.  "why doesn't unity-greeter let me login as anyone other than guest?"
<mterry> lamont, you mean you want a login box where you can type the user?
<lamont> or even showing me the user name
<lamont> I literally have the option of logging in as guest, or on a VT
<lamont> would kind of like to have a gui again
<lamont> my preference would be to have the box to type it in
<mterry> lamont, well...  you're saying it used to show your name and now it doesn't?
<mterry> lamont, you can set "greeter-show-manual-login = True" if you want to force a manual login box where you can type your username in
<mterry> lamont, but if it used to show your username and now it doesn't, that might be a separate bug
<lamont> mterry: so before, it was showing the username and I killed that evilness by setting the minimum uid to 20000 instead of 500.  Now, after the reboot this morning (probably a week or so worth of updates, sadly), I get told that Guest is all I get
<lamont> where do I set greeter-show-manual-login=true?
<mterry> lamont, /etc/lightdm/lightdm.conf
<mterry> lamont, should be a commented out line setting it to False
<lamont> no commented lines in the file at all
<lamont> neither show-manual-login=true, nor greeter-show-manual-login=true seems to have any effect.  (when I login to the guest session, and then logout immediately - that should restart the greeter, yes?)
<mterry> lamont, add that line (with a capital True) under a [SeatDefaults] section
<mterry> lamont, oh, not a capital true.  Or maybe it doesn't matter, but other lines I have don't have the capital
<lamont> changing case did nothing
<mterry> lamont, you have it under SeatDefaults?
<mterry> lamont, oh, logging out like that will restart the greeter, but not lightdm which is giving the greeter the hints
<mterry> lamont, so try "sudo restart lightdm"
<lamont> yeah - just noticed that
<lamont> showing users now, but not the manual box
<mterry> lamont, hah, so now we're ignoring your previous setting of minimum ui?
<mterry> uid that is
<lamont> I reverted that, so we're showing users > 500 again
<lamont> but no "Other" or whatever box
<lamont> let me try lowercase
<lamont> mterry: apperantly, case matters
<vanhoof> ogra_: about?
<mterry> lamont, ok, sorry for leading you down the wrong path there with True then
<lamont> mterry: which makes this update be "greeter-show-manual-login was introduced without correctly detecting the default should be true"
<mterry> :)
<lamont> for the case where there are no users > minuid
<mterry> lamont, default is intentionally false, per design
<mterry> lamont, ah, well if no guest login is shown, we would've shown the manual login box
<lamont> mterry: correct.  and that default has only taken me a bit over an hour to track down and correct
<lamont> so now I'm just back to the small issue that something I did "back when" has effectively made it so that unity 3d works just fine, as long as I don't need a launcher. :(
<mterry> lamont, :-/
<lamont> mterry: thanks much for the help with this
<mterry> lamont, ym, sorry it caused problems
<ogra_> vanhoof, yes, for a moment
<jdstrand> SpamapS: hi! so, I install aws-status and have python-appindicator, but I don't see anything. where would I expect to see this? does it only show up if I have instances running?
<jdstrand> SpamapS: this is in unity-2d if it makes a difference (vm)
<SpamapS> jdstrand: it only shows up if you have instances running
<SpamapS> jdstrand: now that you ask.. it does seem like we could show it with 0 instances. :)
<Sweetshark> micahg: so what was your point about SONAME? I hope it wasnt 'needs a rebuild', thats so obvious I didnt bother with it at all.
<hallyn> is there a standard response when a bug is reported and the system is having badcrc messages in syslog?
<hallyn> i.e. some tool they could use to further investigate...
<hallyn> sorry, lemme move
<Whoopie> cjwatson: strange bug, "/usr/bin/ld: cannot find -lpjnath-armv7l-unknown-linux-gnueabi" and more of these.
<cjwatson> presumably substitution of the arch name somewhere
<Sweetshark> Laney: As micahg seems to be off right now, could you clarify your reservations about transitions?
<Sweetshark> (because I think you guys are mistaken there when we talk about LibreOffice)
<Whoopie> cjwatson: looking at the amd64 and i386 buildlog, you're right. It's a substitution. But the buildlog looks the same. I don't see why it fails. :-(
<Daviey> Is it possible to get upstart potential runlevel status, like chkconfig does?
<Daviey> ie, http://pastebin.com/d5L97JJM ..
<Daviey> service --status-all , is current status, not potential status.
<slangasek> Daviey: by and large no, because runlevels are just one kind of event in upstart and not necessarily the most important one
<Daviey> slangasek: thanks
#ubuntu-devel 2012-03-27
<micahg> Sweetshark: that was exactly my point
<pitti> Good morning
<ritz> heya, the oneiric branch of gtk+3 is broken
<ritz> https://bugs.launchpad.net/udd/+bug/848064/comments/8
<ubottu> Launchpad bug 848064 in Ubuntu Distributed Development "Revision not present branching from udd-imported branches on lp" [Critical,Confirmed]
 * ritz ghaa, wronmjg channel
<dholbach> good morning
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta 2 Freeze in Effect. Archive: pre-release freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach, Daviey
<Sweetshark> micahg: hah! that is so much missing the reality of libreoffice packaging. When you do that you are really not concerned about a rebuild that needs no changes to the package (and no updating the control file does not count, as for LibreOffice, control is generated). What you care for is LibreOffice breaking and requireing patching like http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commitdiff;h=7856bf2ec6e24b43eba7b361c7
<Sweetshark> (or doko uploading a multiarch libjpeg that requires patching libreoffice in the last days before natty beta freeze and then teasing me about 'using the buildds as testbuilds', when it broke because of _his_ change)
<Sweetshark> so the question is like asking for the mileage of my vehicle and wondering why I dont praticulary care if its 5 l/100km or 7 l/100km ... when my vehicle is a tank.
<doko> Sweetshark, stop whining, don't dlopen
<Sweetshark> doko: ;)
<Sweetshark> doko: wrong again btw, this wasnt dlopening btw, but a workaround for some stupid Java implementations injecting an unversioned libjpeg in the linker path.
<pitti> cjwatson: wrt bug 963460, it's fine to just throw it the locale as it is; it filters out the .UTF-8 and whatnot stuff itself
<ubottu> Launchpad bug 963460 in OEM Priority Project precise "Ubiquity calls check-language-support with "zh-hans" instead of a locale (zh_CN)" [Medium,New] https://launchpad.net/bugs/963460
<pitti> cjwatson: in the medium term it's probably easier to just use the language_support_pkgs python module instead of calling the script, but that's not urgent at all
<cjwatson> well, it would actually be awkward to put the .UTF-8 back in here, but it's easy to call it with en_GB rather than en
<pitti> ah, I see; I just thought you'd do some special pre-processing for the arguments there
<pitti> so whichever is easiest
<cjwatson> all I'm planning on doing is http://paste.ubuntu.com/901821/
<cjwatson> actually looking at this it might have . in it before preprocessing
<cjwatson> sometimes
<cjwatson> locale_to_language_pack is http://paste.ubuntu.com/901822/
<cjwatson> so yeah, I'll just feed it straight to c-l-s without any of that
<pitti> cjwatson: btw, you can probably drop taht as well; c-l-s adds langauge-pack-[gnome...]* itself
<TLE> pitti: Hallo, we haven't had the best feedback on the Natty language packs. I'm currently trying to clear up whether the bad reviews concern regressions. I'll keep you informed when I know which ones, if any, should be copied
<cjwatson> pitti: not really
<pitti> TLE: ah, thanks; note that we can also copy them individually as results come in
<cjwatson> pitti: I need that function to do set operations on the packages that are already installed, which ubiquity does need to know about
<pitti> ah
<TLE> pitti: Yes, I know, but there has actually only been tested two language packs, so I'll clear them both up right away
<dholbach> can somebody please reject https://code.launchpad.net/~kroq-gar78/ubuntu/precise/lincity-ng/fix-674519/+merge/99151 based on the last comment I added?
<pitti> dholbach: done
<dholbach> thanks pitti
<TLE> Hallo guys. After restarting my precise beta desktop today (after doing the usual upgrades) multi-monitor support broke. It was also a problem earlier in the cycle but at some point got fixed, but now it is broken again
<TLE> what happens is that the primary screen shows the background and nothing else, and on the secondary screen parts of the background flickes by at a high rate depending on where the mouse is
<TLE> do you know if this is a known problem, and if not, which component should i report this against
<TLE> I'm only asking because I think for graphcis related issues it can be a little tricky to figure out what programs are responsible for what
<dholbach> tkamppeter, do you know if https://launchpad.net/bugs/857663 only affects lucid or if it's something that should be fixed in more releases?
<ubottu> Launchpad bug 857663 in cups (Ubuntu) "cups crashes on SIGHUP if printer classes are defined" [Undecided,New]
<dholbach> hallyn, I'll mark https://code.launchpad.net/~serge-hallyn/ubuntu/precise/pulseaudio/pa-upstart/+merge/95664 as 'work in progress' to get it off the queue for precise - is that OK?
<dholbach> can somebody please set https://code.launchpad.net/~tjvries/ubuntu/natty/mawk/fix-for-955791/+merge/98069 as 'merged'?
<dholbach> it's in http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/mawk/natty-proposed/revision/11
<StevenK> dholbach: You need a member of ~ubuntu-branches.
<dholbach> :-(
<StevenK> Or you can bug an admin in -ops if it's important.
<dholbach> no, not important, but it'll stay in the sponsoring queue until it gets set as merged
<StevenK> dholbach: Member of the tech board or james_w. So cjwatson can probably do it if you ask him.
<dholbach> can we maybe extend the u-branches team? it feels weird having to bother the TB with stuff like this
<cjwatson> it's stupid that it has to be a member of ubuntu-branches at all
<cjwatson> I'd rather not work around the problem by granting more people the privilege to arbitrarily muck about with importer branches :)
<cjwatson> I've marked that mawk MP as merged
<dholbach> thanks cjwatson
<cjwatson> (https://bugs.launchpad.net/launchpad/+bug/618448)
<ubottu> Launchpad bug 618448 in Launchpad itself "ubuntu developers are not able to reject merge proposals on official packaging branches they can upload to ( IBranch.isPersonTrustedReviewer doesn't have logic for package branches )" [High,Triaged]
<cjwatson> that even points to the method that needs to be fixed, so maybe somebody with a bit of time could do that
<cjwatson> doesn't have to be a Launchpad developer
<hrw> bug 966103 goes to the sponsors queue
<ubottu> Launchpad bug 966103 in dash (Ubuntu) "FTCBFS: Cross build calls wrong-arch strip" [Undecided,New] https://launchpad.net/bugs/966103
<ev> cyphermox: any idea why is network manager using at_console to determine whether a user can do *anything* with its dbus interface? That seems a bit silly.
<ev> isn't this why we have policykit? :)
<bdrung> tumbleweed: do you have time to fix W: ubuntu-dev-tools: binary-without-manpage usr/bin/reverse-build-depends
<tkamppeter> dholbach, this is Lucid-only. The bug description tells that CUPS 1.4.4 and later is not affected.
<tumbleweed> bdrung: it's really not necessary
<bdrung> tumbleweed: a man page telling the user to use a different command would be nice
<soren> I'm having trouble working out what the difference is between stating "Breaks: b" in package a vs. "Breaks: a" in package b.
<soren> Is there even a difference?
<soren> Specifically, in OpenStack we have a number of different daemons. One of them is sort of an all-in-one daemon that includes the functionality of 4 others (listening on the same ports and everything).
<soren> I want to avoid people installing the all-in-one along with any of the others.
<soren> ...and I can't work out which way to point the Breaks: relationship.
<janimo`> seb128, do the new gtk/gnome versions which are in precise-proposed land before or after 12.04 is released?
<Daviey> soren: Don't you want Conflicts?
<seb128> janimo`, before, we use proposed a stacking area for after beta2
<seb128> janimo`, why?
<janimo`> seb128, just curious, it is the first time  I noticed uploads to proposed so long before release date
<seb128> janimo`, right, that's something we would like to standardize on
<fatal> someone please reassign LP#960497 to the kernel
<Daviey> soren: Ah no, Breaks is probably better
<dholbach> tkamppeter, is this worth to be fixed in an sru?
<cjwatson> soren: a Breaks: b means that a cannot be unpacked unless b is deconfigured.  b Breaks: a means that b cannot be unpacked unless a is deconfigured.  If you have no maintainer script ordering to consider then it doesn't much matter, but sometimes you do.
<cjwatson> soren: Do these two (sets of) packages share files?
<cjwatson> soren: Actually, never mind, that probably doesn't matter.  In your case I'd be inclined to use Conflicts in both directions.
<soren> cjwatson: No, they share no files.
<soren> cjwatson: Conflicts? Really? Why?
<soren> cjwatson: I thought this was exactly the sort of thing we added Breaks to accommodate.
<cjwatson> Not really, no.
<cjwatson> We added Breaks to avoid having to entirely remove packages during upgrades only to reunpack them again later, when simply deconfiguring them would be enough.
<cjwatson> Would you ever want to be in a state where both daemon packages were unpacked but only one of them was configured?  It doesn't sound like it.
<Daviey> Oddly, i think i'm yet to see a Breaks without a Replaces.. Anyone seen it separately ?
<StevenK> I have, yes.
<StevenK> It doesn't turn up often,
<StevenK> s/,$/./
<Daviey> StevenK: Have an example?
<soren> cjwatson: I have no desire for that scenario, but it wouldn't hurt anyting.
<cjwatson> initramfs-tools Breaks: a load of stuff with no Replaces
<Whoopie> cjwatson: I found the reason for the sflphone build failure on armel/armhf. It needs an up-to-date config.guess. If I prepare a new debdiff, would you mind sponsoring it again?
<cjwatson> soren: The difference between Breaks and Conflicts here is mainly academic, so it's probably not worth a long discussion.  At any rate I would have the relationship in both directions rather than trying to pick one.
<Whoopie> cjwatson: as suggested by tumbleweed, I test-compile it in a qemu chroot at the moment.
<cjwatson> Whoopie: sure
<StevenK> Haha, and s390-tools. I bet that impacts us somehow. :-P
<soren> cjwatson: Cool. Thanks.
<dholbach> can somebody please reject https://code.launchpad.net/~kroq-gar78/ubuntu/precise/freedict/fix-568333/+merge/98963 (explained in last comment)?
<cjwatson> dholbach: done
<dholbach> thanks cjwatson
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta 2 Freeze in Effect. Archive: pre-release freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Daviey
<tkamppeter> dholbach, it can be fixed easily, as the patch is attached, but on the other side it seems to happen only rarely, as it has no duplicates.
<dholbach> tkamppeter, ok, I'll leave the decision up to you then
<hrw> janimo`: thx for dash
<janimo`> hrw, you're welcome. Probably needs to go to Debian too at one point
<Mavrik> Hey... if there is a (imo) significant regression from 11.10 to 12.04 beta, where should I write to to get attention from the team?
<hrw> janimo`: reported there
<janimo`> hrw, nice.
<hallyn> dholbach: sure.  but this points to a bug in my sponsoring workflow :)
<cyphermox> ev: don't know. feel free to suggest an alternate configuration if it helps you
<ev> cyphermox: no worries. pitti suggested using libck-connector, which is working a treat.
<cyphermox> ok
<pitti> or just changing the NM d-bus policy to allow reading the properties for "whoopsie"?
<pitti> which seems even easier?
<cyphermox> yeah
<cyphermox> I do think it should be changed, but perhaps not now when it's been working properly. I'll mention it to dcbw once he's back from vacation though
<ev> whatever you guys think works best for ck/nm. Just provide me with a working API and I shall use it :)
<pitti> cyphermox: I think it's less risky/intrusive to just open this up to "whoopsie"; this certainly needs to be a distro patch to the policy
<cyphermox> right
<cyphermox> pitti: you mean whoopsie as a user right?
<alvin> mvo: I was directed to you from #kubuntu-devel. I'm looking for a workaround for bug 966226 I just reported.
<ubottu> Launchpad bug 966226 in update-manager (Ubuntu) "update-manager complains about a missing 'ubuntu-minimal' package, while it is installed" [Undecided,New] https://launchpad.net/bugs/966226
<mvo> alvin: I would suspect that be.archive.ubuntu.com has a incomplete precise mirror (at least that is what I read from the log in the bug)
<alvin> mvo: That might be the case. I'll switch mirrors and try again.
<mvo> alvin: note that this is not about ubuntu-minimal on your system, but about ubuntu-minimal availalble for download after the upgrade, its a precaution
<mvo> alvin: thanks
<retoaded> cjohnston, ping
<cjohnston> hey there
<cjohnston> 5 minutes?
<cjohnston> trying to finish with an issue real quick retoaded :-)
<retoaded> cjohnston, np
<barry> ScottK: https://bugs.launchpad.net/ubuntu/+source/flufl.enum/+bug/966257
<ubottu> Launchpad bug 966257 in flufl.enum (Ubuntu) "[FFe] sync to latest Debian version" [Undecided,New]
<ScottK> barry: Approved.
<barry> ScottK: thanks
<ScottK> You're welcome.  Please go fix the other ones now ...
<barry> working on it ;)
<barry> ScottK: % syncpackage -d sid flufl.enum
<barry> syncpackage: Error: Debian version 3.3.1-2 has not been picked up by LP yet. Please try again later.
<barry>  
<ScottK> It's slow.
<barry> yep, just fyi
<ScottK> OK.
<cjohnston> Mornin retoaded.
<retoaded> morning
<cjohnston> retoaded, are you familiar with what I need to setup?
<alvin> mvo: Thanks. Switching mirrors worked. ubuntu-minimal is indeed missing on the Belgian mirror. I'll update the bug report.
<mvo> alvin: thanks
<pitti> cyphermox: yes
<ogra_> vanhoof, you pinged last night ?
<vanhoof> ogra_: yeah nothing urgent, just wanted to bounce a question off of you if you have a few minutes
<ogra_> sure
<janimo`> Sweetshark, I just noticed libo ftbfs on armel, are there still (minor) differences in the packaging between armel/armhf by any chance?
<Sweetshark> janimo`: no, actually I dont think it is something 'real' at all. If you look at the buildlog it is a unittest failing very high in the build which didnt fail before. It could very well be that the builder box just had a bad day. I tried to reproduce the issue on the armel-porter box, but that one went MIA during the build (couldnt login), so I didnt look into it any further for now.
<janimo`> Sweetshark, that's what I suspect too. Given back to the builders
<Sweetshark> janimo`: so you just retry? yes, might be worth a shot.
<Sweetshark> janimo`: I just did not want to be guilty of hugging the builder (esp. in the pre-beta) without even trying on a porter to fix it.
<janimo`> Sweetshark, less time wasted this way imho, there are still plenty pandas to carry other builds
 * Sweetshark imagines an army of cute, but grim-looking pandas.
<dantti> RAOF: ping
<dholbach> congratulations adam_g
<dholbach> shouldn't you be in ~ubuntu-dev now?
<tumbleweed> dholbach: I left DMB minutes to cody-somerville, but I'll sort out the actions now
 * dholbach hugs tumbleweed
<tumbleweed> dholbach, adam_g: done
<dholbach> yoohoo
<PaoloRotolo> Hi all!
<bdrung> jdstrand: distro-info 0.7.1 is in precise now (re bug #964008)
<ubottu> Launchpad bug 964008 in shunit2 (Ubuntu) "[MIR] distro-info, distro-info-data, and shunit2" [Undecided,New] https://launchpad.net/bugs/964008
<jdstrand> bdrung: thanks
<bdrung> yw
<infinity> TheMuso: A long shot, given timezones, but are you around to update the -lowlatency kernel?
<Daviey> bdrung: woot!
<bdrung> Daviey: woot about what?
<Daviey> bdrung: distro-info
<bdrung> Daviey: wait until i will rewrite it in C. ;)
<Daviey> bdrung: Everyone really wants to see it in golang.
<bdrung> Daviey: let's check if it passes the initial test
<smoser> anyone see this: *** VTE ***: Failed to load terminal capabilities from '/etc/termcap'
<bdrung> Daviey: it has a fast startup time
<Daviey> smoser: close and re-open gnome-terminal
<Daviey> smoser: If it still does it, reboot, then phone customer support back.
<smoser> bah.
<smoser> yeah.
<smoser> i see bug 961977
<ubottu> Launchpad bug 961977 in Unity Distro Priority "Launcher shows arrows for applications on all workspaces" [High,Fix committed] https://launchpad.net/bugs/961977
<smoser> er...
<smoser> bug 961997
<ubottu> Launchpad bug 961997 in vte3 (Ubuntu) "*** VTE ***: Failed to load terminal capabilities from '/etc/termcap'" [Undecided,Confirmed] https://launchpad.net/bugs/961997
<Laney> comment #5 is right
<Laney> you need to quit all of your terminals
<broder> mdz got it slightly backwards - the bug is that the old libvte already loaded into the gnome-terminal process is looking for a file that's no longer part of the new libvte and is therefore gone
<broder> (the new libvte embeds the content into the libvte binary)
<mdz> broder, aha
<broder> and as of a few (ubuntu) releases ago, gnome-terminal is a single process for all of your terminals, so you're stuck with it until you kill off all of your terminals (this killing the gnome-term process)
<smoser> Daviey, regarding speed... http://paste.ubuntu.com/902787/
<smoser> ubuntu-distro-info --supported is roughly 6 times as slow to run as '/bin/true'
<smoser> that includes 1 fork to 'date', which accounts for 30%-ish of its time
<smoser> so there is only so much that can be shaved off.
<nemo> https://bugs.launchpad.net/ubuntu/+source/rdesktop/+bug/226885  <- this says fix released (after many years)
<ubottu> Launchpad bug 226885 in rdesktop (Ubuntu) "rdesktop not compiled with smartcard support" [Undecided,Confirmed]
<nemo> is there any way to get that fix into ubuntu?
<nemo> I guess I could just install the debian .deb and cross my fingers...
<bdrung> Daviey: bug #966570
<ubottu> Launchpad bug 966570 in gccgo-4.7 (Ubuntu) "/usr/bin/ld: cannot find -lgcc_s" [Undecided,New] https://launchpad.net/bugs/966570
<Daviey> wow.  just. wow.
<bdrung> Daviey: that's not enough. there is gccgo-4.6 too
<bdrung> Daviey: this fails too: bug #966578
<ubottu> Launchpad bug 966578 in gcc-4.6 (Ubuntu) "hello-world.go:3:11: error: import file âfmtâ not found" [Undecided,New] https://launchpad.net/bugs/966578
<meerkats> where do I find a unity channel?
<Daviey> bdrung: is it fmt or fml ?
<bdrung> Daviey: fmt
<soren> Say I'm using debconf to configure a package. Using puppet, I preseed debconf with the appropriate answers prior to installing the package. This all works well. However, say I wanted to change something later on. How would I do this noninteractively? Luckily the package has no questions of critical debconf priority, so re-preseeding followed by "dpkg-reconfigure -pcritical" would probably do the trick, but I have to wonder how I'd manage if there we
<soren> When does a question get marked as seen? When it's shown interactively or would it be considered seen even if the package is configure with the noninteractive frontend?
<soren> If the latter, I guess dpkg-reconfiure --unseen-only almost solves it (unless I've added more questions in the mean time).
<soren> Although, in that case I guess those would have been answered (and thus seen) during a package upgrade?
<slangasek> soren: packages are not supposed to overwrite existing config files with debconf answers; when there's a disagreement between the two, the .config script should be overwriting the debconf question, and your post-preseeding would be for naught
<slangasek> as long as you're using puppet, I think you should just make the config file changes directly
<soren> slangasek: Err... What is the purpose of dpkg-reconfigure, then?
<slangasek> soren: to let users *interactively* change the values :)
<soren> pft
<soren> :)
<slangasek> I mean, if you wanted to you could write a puppet debconf frontend
<slangasek> so that dpkg-reconfigure asks puppet instead of the user
<slangasek> but jamming new answers into /var/cache/debconf is not *supposed* to propagate them to the config files
<soren> This makes me sad. I've spent quite a bit of time moving all this logic into debconf so that regardless of config mgmt system, the results would be the same.
<slangasek> cf. "Debconf Is Not A Registryâ¢"
<soren> ..but if that means that I can't make changes post install... That sucks.
<slangasek> you just have to approach debconf from a different angle.  A config-system-specific debconf frontend or backend would do the job.
<soren> How would another backend help?
<slangasek> because the backend could ignore what was written to it ;)
<soren> Oh. By backend you're not referring to db driver.
<slangasek> yes I am
<soren> Right.
<soren> Hm.
<slangasek> your backend would cheerfully accept answers from the user, then discard any that disagree with puppet's policy
<slangasek> and when re-queried with db_get, it would give the answer it wants the system to have
 * soren ponders
<slangasek> (N.B., this sort of thing is exactly why the DbDriver interface exists, and yet I think only two or three people have ever written drivers... so there may be a reason, I haven't looked at the code myself :)
<soren> Good grief, I'm going to have to write perl.
<kirkland> ScottK: any idea what's the replacement for dkim-filter in Ubuntu 12.04?
<kirkland> ScottK: opendkim maybe?
<soren> slangasek: I guess adding a new db with my answers in it, setting it to read-only and putting it at the top of a Stack...
<soren> slangasek: Answers would pass through to the underlying (non-read-only) db, but when read back out, my static answers take precedence.
<soren> Or so the hypothesis goes.
<slangasek> soren: my arms-length understanding of this side of debconf thinks this sounds reasonable
<bdrung> Unity is broken in my precise system. When i login, there is no sidebar and no menu bar.
<soren> slangasek: Are you familiar with $DEBCONF_DB_OVERRIDE?
<slangasek> soren: nope
<soren> slangasek: Ok.
<soren> slangasek: SEems to be what I need.
<soren> slangasek: ...but if you knew it, but didn't suggest it, that would be useful information.
<soren> slangasek: (It's mentioned in man debconf(7))
<slangasek> yeah, seems to be the right tool
<slangasek> I knew there were facilities for this, but it's been a while since I read that manpage and have never actually done it in practice ;0
<slangasek> ;)
<soren> It does feel like somewhat unchartered territory.
<soren> Not entirely HBD, but close.
<soren> slangasek: Thanks a lot for your insight!
<slangasek> sure thing
<slangasek> soren: I look forward to seeing the results blogged/packaged, I imagine there are a few other people who would like better puppet+debconf integration ;)
<soren> slangasek: I certainly hope this will serve as an example others will follow. Debconf seems somewhat overlooked and I think it'll serve well as a lowest common denominator, drastically reducing the divergence between the result of an OpenStack (in my case) deployment done with Puppet vs Chef vs The-Next-Big-Thing-In-Cfg-Mgmt.
<soren> It, of course, rests on the assumption that the invariant is the underlying operating system.
<soren> Others might have defined Puppet (or Chef or whatever) as the invariant. That's just not my style :)
<slangasek> Daviey: still patch piloting?
<Daviey> slangasek: no :/
<Daviey> @patch out
<udevbot> Error: "patch" is not a valid command.
<Daviey> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta 2 Freeze in Effect. Archive: pre-release freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Daviey> thanks
<slangasek> ah, darn ;)  ok, thanks anyway :)
#ubuntu-devel 2012-03-28
<cyphermox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta 2 Freeze in Effect. Archive: pre-release freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox
<balloons> is there any about who would be willing to sponsor an upload?
<RAOF> balloons: cyphermox has just signed in as patch pilot :)
<cyphermox> yo!
<balloons> ahh.awesome
<cyphermox> balloons: shoot :)
<balloons> so I'm new to this, but I need something uploaded to precise-release so it can be reviewed
<balloons> bzr branch lp:~nskaggs/checkbox/checkbox-app-testing-qt
<cnd> kees, I see you're a MIR approver, could you take a look at bug 949575?
<ubottu> Launchpad bug 949575 in gtest (Ubuntu) "[MIR] gtest" [Undecided,New] https://launchpad.net/bugs/949575
<slangasek> cyphermox: checkbox-app-testing is a new package; I've agreed to do the archive review
<cyphermox> slangasek: ok
<kees> cnd: sure, done. someone else need to actually promote it, though.
<cnd> kees, yeah
<cnd> thanks for approving :)
<balloons> cyphermox, let me know if you need anything else
<cyphermox> balloons: I wish the extended description was longer, anything we can add now? :)
<kees> np :)
<balloons> sure.. umm, what else would you like.. a bigger description of the package?
<cyphermox> yeah, just more meat around it, it's not a big deal just would be nicer
<cyphermox> balloons: also, debian/pycompat isn't required afaik, it can just be dropped
<balloons> ok, I'll drop it and extend the descrip a bit
<balloons> one sec
<cyphermox> balloons: afaik it otherwise looks fine. since the package is probably not in debian you could also get away without the "ubuntuX" suffix for the version number, I think. not that it makes a real difference
<balloons> cyphermox, pushed the changes
<cyphermox> cool. I'll pull in a second, I'm running it through sbuild just now
<balloons> thanks
<cyphermox> balloons: thanks for the changes
<balloons> cyphermox, np
<cyphermox> balloons: slangasek: seems to me like much of the qt stuff should be in /usr/lib, not /usr/share
<cyphermox> (at least)
<balloons> cyphermox, I'm happy to make any changes needed :-) It's modeled after the checkbox package as an fyi.. so likely checkbox places them in the same location
<cyphermox> yeah, that's what bothers me, I have reviewed the last few checkbox uploads and didn't clue in :)
<balloons> ahh.. so they are the same then?
<balloons> i was going to say i did mod some stuff so it's possible I changed it
<cyphermox> nah, it's the same
<balloons> kk.. I would offer to leave it the same.. but your argument is sound :-)
<cyphermox> I think it needs to be fixed in both, it should be simple and pretty safe to change in checkbox-app-testing-qt now
<balloons> ok.. sounds fine
<balloons> let's have at it
<balloons> so basically I need to move qt stuff to /usr/lib
<cyphermox> yeah, but that's going to break a few things
<cyphermox> I'm looking through it now, some of it needs to stay in /usr/share
<cyphermox> you'll want to at least adjust the default value of CHECKBOX_APP_TESTING_{SHARE,FRONTEND}
<balloons> kk
<cyphermox> balloons: I think I got it, shuffled files around a bit; hopefully it will solve this and still work :)
<balloons> :-) the important part, yes :-)
<cyphermox> the important part?
<cyphermox> changes are actually pretty simple, I guess
<balloons> ok.. do you have a patch or just want to descibre?
<mhall119> w 26
<mhall119> bah
<balloons> cyphermox, ?
<cyphermox> balloons: ah, sorry
<cyphermox> I'll have a patch soon, it mostly works
<balloons> no worries :-)
<balloons> kk.. just wondering what was up :-)
<cyphermox> having an issue with dealing with upgrades, at least
<cyphermox> I'm finishing up testing this then I think I'll leave it to you to figure out (or we should ask cr3 tomorrow or something)
<balloons> ahh.. I'll have to check it tonight unless he's around
<balloons> I don't want to shorten slangasek's timeframe anymore than I have to :-)
<cyphermox> balloons: lp:~mathieu-tl/checkbox/app-testing-move-to-usr-lib
<cyphermox> I think it pretty much fixes everything
<cyphermox> maybe just review the changes and if you think it's reasonable we'll upload that?
<ScottK> kirkland: Yes.  opendkim.
<ScottK> kirkland: opendkim is a fork of dkim-milter done by the same author when he changed employers.  dkim-milter is dead.
<balloons> ok.. I'll merge and review now
<cyphermox> balloons: please test it too, make sure it behaves as you expect, the general UI look might have changed since now it would actually use the UI you ship instead of what comes from checkbox-qt
<balloons> cyphermox, yes.. that's fine
<balloons> they are the same :-)
<cyphermox> ok
<cyphermox> is it likely to ever be different? if not maybe it's not worth including
<balloons> umm.. yea.. it depends on how checkbox-qt works out
<balloons> ideally i wouldn't ship it
<balloons> let's see how she runs
<cyphermox> balloons: if you're looking for what to add to changelog for my changes, check the commit message. it's there but you'll want to adjust it for debian/changelog
<balloons> ok, thanks
<balloons> building.. building
<cyphermox> ohhh
<cyphermox> balloons: please drop the files in patches/, they clash with your package version and aren't needed since this is a new package.
<balloons> yes.. I was going to ask
<balloons> I just noticed them before asking you to take a look if they were needed or not
<balloons> thanks
<cyphermox> that's why upgrades of the package will fail until you reach a version of about 0.10 or so :)
<balloons> lol
<balloons> this is still new for me
<balloons> so.. feel free to point out the obvious :-)
<cyphermox> just make sure after that things still behave correctly, in case some changes are missing from the .ini file shipped
<balloons> ok.. so explain the patches a bit more to me
<balloons> if I kill the folder it will be as a new package
<balloons> but i have to adjust my build too or it will fail right?
<cyphermox> balloons: just empty the folder is fine.
<cyphermox> IIRC that directory is supposed to contain "patches" or scripts that will act on the .ini files shipping by checkbox to change settings, for things like blacklists and such
<balloons> cyphermox, right.. but now the build is failing because it's looking for then
<balloons> so I'm confused
<cyphermox> balloons: then edit setup.py to avoid installing these files
<balloons> rofl
<cyphermox> another easy way could have been to make the initial version a 0.10.something
<balloons> ahh.. i was looking in all the wrong places
<RAOF> Hm.  I wonder how easy it is to exploit a root-permissioned libsane-using daemon.
<RAOF> You could probably do something interesting with a specially programmed USB device, I guessâ¦
<cyphermox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta 2 Freeze in Effect. Archive: pre-release freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> Good morning
<RAOF> pitti: Aloha.
<kirkland> ScottK: thanks
<ajmitch> morning pitti
<pitti> slangasek: I'll reject your language-selector upload and reupload with a couple of additional fixes, if that's alright with you? I want to add the LP# task to your conffile fix, too
<pitti> or alternatively close it manually after the freeze
<pitti> jibel: FYI, filed bug 966845 for the last lucid-precise-universe upgrade failure
<ubottu> Launchpad bug 966845 in update-manager (Ubuntu Precise) "lucid->precise upgrade wants to remove ubuntu-desktop" [High,In progress] https://launchpad.net/bugs/966845
<pitti> jibel: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-main/lastFailedBuild/ARCH=i386,LTS=lts,PROFILE=main-all,label=upgrade-test/console crashes on a missind dir or file, could you please have a look?
<pitti> slangasek: nevermind, I'll close the bug manually
<didrocks> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta 2 Freeze in Effect. Archive: pre-release freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks
<didrocks> pitti: do you think: should I sponsor in -proposed, don't do anything for packages in main until beta freeze is lifted? (or just upload in main and the release team won't approve it until the freeze is lifted)
<pitti> didrocks: the latter usually
<pitti> didrocks: there's plenty of stuff in unapproved which is for after beta-2
<didrocks> ok, wasn't sure for main components though ;)
<didrocks> thanks pitti!
<pitti> it's fine as a general fire&forget approach
<pitti> didrocks: de rien, enjoy the flight :)
<didrocks> thanks ;)
<dholbach> good morning
<didrocks> hey dholbach ;)
<dholbach> hey didrocks
<jibel> pitti, guten Morgen. thanks for reporting the failure.
<pitti> jibel: TheMuso and I discussed it, should be fixed tomorrow
<jibel> pitti, the error for lucid main is really weird. I'll have a look.
<pitti> jibel: merci
<Mirv> does anyone happen to know a bug number (or even the component that should be fixed) for "terminal quickly shown on the screen when logging out or shutting down, before splash screen shows"?
<Mirv> it's a small detail but quite visible, and at least I'm having it on all my 3 intel graphics laptops and radeon graphics desktop
<cjwatson> dholbach: I rejected your auto-complete-el sync, since didrocks beat you to it.
<dholbach_> cjwatson, ah ok :)
<didrocks> anyone can reject this branch https://code.launchpad.net/~happyhouse19/ubuntu/oneiric/spyder/fix-for-890243/+merge/99579? (wrong target, sponsored the fix fixed to precise)
<pitti> didrocks: done
<didrocks> pitti: thanks :)
<seb128> (will they ever fix launchpad to let any dev do that?)
<didrocks> dholbach: still on sponsoring mood? I spent more than 2 hours here to build inkscape ;)
<dholbach> didrocks, really? it just took me a few minutes
<didrocks> dholbach: I hope you removed the bug # from debian/changelog? (they are just copy and paste and was already mergedpar ot the merge ;)
<dholbach> I'll stop now - sorry :)
<didrocks> dholbach: no no, I'm at the end of my shift
 * dholbach hugs didrocks
<didrocks> dholbach: at least, confirming it looks good to me :)
 * didrocks hugs dholbach
<didrocks> dholbach: I beat you at the syncing race! 1-1 I guess : p
<dholbach> haha
<cjwatson> roaksoax: are you still intending to fix bug 840406?  It's milestoned for beta-2 at the moment
<ubottu> Launchpad bug 840406 in powernap (Ubuntu Precise) "powerwaked crashed with ImportError in /usr/lib/python2.7/dist-packages/powerwake/monitors/ARPMonitor.py: No module named scapy.all" [High,Triaged] https://launchpad.net/bugs/840406
<rbasak> jodh: is there any reason why "initctl emit rabbitmq-server-running" would hang, or is this an upstart bug? I'm on arm.
<didrocks> jodh: on https://code.launchpad.net/~jamesodhunt/ubuntu/precise/upstart/big-upstart-events-man-page-updates/+merge/99687, you still have debian/conf/flush-early-job-log.conf listed in an older changelog (1.5-0ubuntu1) which is not in 1.5-0ubuntu1 distro version
<jodh> rbasak: sounds like you've got a job that has "start on rabbitmq-server-running" and *that* is hanging.
<didrocks> jodh: so if you want to add it to 1.5-0ubuntu2 (which seems to be the case), can you list it at the right place?
<jodh> rbasak: check out http://upstart.ubuntu.com/cookbook/#establish-blocking-job
<jodh> didrocks: will look at that now...
<didrocks> jodh: thanks, ping me once done, I'll sponsor them :)
<didrocks> hen*
<didrocks> then*
<jodh> didrocks: thank you
<didrocks> grrr ECANTTYPE
 * smb would love to find again the documentation explaining the preferred version format for SRU packages. There seems to be cases where <ver>ubuntu1 becomes <ver>ubuntu1.1. But I thought to remember some variant making use of the release name.
<cjwatson> smb: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<smb> cjwatson, Yeah, that was the one. Thanks.
<cjwatson> linked to from https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
 * smb bookmarks this time
<jodh> didrocks: that changelog entry does belong in 1.5-0ubuntu1 (I added it in revno 1382). It somehow got dropped when the branch was tagged and uploaded, so what's in the MP is actually correct.
<didrocks> jodh: hum, I apt-get source upstart here
<didrocks> look at the changelog in 1.5-0ubuntu1
<didrocks> and it's not here
<jodh> didrocks: yes, the distro changelog is wrong - it doesn't reflect the bzr history.
<didrocks> jodh: well, the change in debian/conf/flush-early-job-log.conf is not in the distro either
<didrocks> so the change is not referenced, nor present in the current 1.5-0ubuntu1 in precise
<jodh> didrocks: hmm, that's not supposed to happen :)
<didrocks> jodh: not sure how, but I checked twice ;)
<didrocks> jodh: not a biggie, you can add it to 1.5-0ubuntu2, just reference in debian/changelog from there
<jodh> didrocks: thanks - and good catch!
<didrocks> jodh: just ping me once you've done the change :)
<didrocks> yw
<rbasak> jodh: there is a job that starts on rabbitmq-server-running, but find_blocked_job.sh does not report anything, and I don't see any child processes of "initctl emit rabbitmq-server-running"
<jodh> didrocks: I've re-pushed that branch now.
<didrocks> jodh: thanks! looking
<jodh> rbasak: what state is that job in? Can you pb the job?
<vibhavp> Can anybody tell me how do I apply this patch : http://git.gnome.org/browse/evolution-exchange/commit/?id=a78cf5169ed46f5d53412290dbb3fe862f201500
<rbasak> jodh: http://paste.ubuntu.com/903663/
<jodh> rbasak: I think you'll find the pre-start is the problem - "initctl emit" is going to block until that completes.
<vibhavp> patch always returns invalid patch format
<jodh> rbasak: try putting the pre-start block into a shell script run with "/bin/sh -e" and see what happens.
<Daviey> jodh: I wonder if the pre-start is happening too quickly, directly as the event is emitted.. but before rabbit is /really/ ready?
<rbasak> jodh: I'll do that, thanks. How does upstart run the jobs normally? Pipe them into a shell or something? SHouldn't I be seeing a shell process somewhere that is running the pre-start?
<vibhavp> Or is there any way to download the patch?
<jodh> rbasak: the other possibility is that "initctl emit" is blocking because the 'start on' condition for that job isn't fully satisfied.
<Daviey> vibhavp: click 'patch' on that very page.
<jodh> rbasak: again, try "sudo initctl emit net-device-up" (or filesystem) and see what happens
<vibhavp> Daviey: Should that patch work?
<Daviey> vibhavp: No idea.
<vibhavp> Seems that I will have to commit them manually :(
<jodh> rbasak: it uses a number of different techniques (3) to run jobs. If you're not seeing any shells though, it must be the 'start on' that's the problem.
<rbasak> jodh, Daviey: looks like running both "sudo initctl emit net-device-up" and "sudo initctl emit filesystem" seems to fix it. I need both though. The order doesn't matter (I tried both orders concurrently on two different boards). But now the "emit filesystem" call is hung.
<jodh> rbasak: that'll be because other jobs have 'start on's including filesystem. So it's looking like net-device-up is the issue.
 * rbasak is definitely confused now
<rbasak> maas-txlongpoll has "start on filesystem and net-device-up and rabbitmq-server-running". If net-device-up hasn't happened (it should have!), then why does "initctl emit rabbitmq-server-running" hang? Surely the job's start conditions haven't been met?
<cjwatson> Emitting an event blocks until anything that starts on that event has completed.
<cjwatson> That includes things that won't start until some other event has been emitted, due to 'and'.
<cjwatson> There's 'initctl emit --no-wait', although I don't know whether that's appropriate here.
<jodh> rbasak: from initctl(8): "For the emit command, finishing means that all of the jobs affected by the event are running (or have finished for tasks) or have been fully stopped."
<cjwatson> In fact, I found that realising that emission blocked this way was the key to understanding Upstart's entire model, and especially the problems with mixing 'and' and 'or'.
<didrocks> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta 2 Freeze in Effect. Archive: pre-release freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<jodh> rbasak/cjwatson: I'll make this point clearer in the Upstart Cookbook...
<rbasak> cjwatson, jodh: OK, my misunderstanding, thanks. I need to study the docs more.
<jodh> rbasak: I've added a warning to the Cookbook with links to the appropriate sections here: http://upstart.ubuntu.com/cookbook/#initctl-emit
<rbasak> So how should I debug this problem? I'm now lost again. The original issue was that "initctl emit rabbitmq-server-running" hangs. I know it's freed by "initctl emit filesystem" AND "initctl emit net-device-up", but the "initctl emit filesystem" then hangs. What does this mean and where should I look?
<jodh> rbasak: the point is, you shouldn't need to emit these events yourself: 'filesystem' is emitted by mountall and net-device-up is emitted by either /etc/init/network-interface.conf or ifupdown all as documented in upstart-events(7).
<jodh> rbasak: I'd look at your network config.
<Daviey> rbasak: did you check if running the pre-start blocked, in shell by hand?
<rbasak> jodh: the postinst isn't emitting the events - it's just calling "/bin/sh /usr/sbin/invoke-rc.d rabbitmq-server restart"
<rbasak> jodh: I've not messed with my network config. It's a fresh netinst.
<rbasak> Aha
<rbasak> rabbitmq-server isn't an upstart job, but /etc/init.d/rabbitmq-server calls "initctl emit rabbitmq-server-running"
<rbasak> Is this allowed?
<rbasak> Or should this be --nowait?
<cjwatson> Remember that net-device-up is not a state.
<cjwatson> It is an event.  Once it has been emitted and completely processed at boot time, it goes away.
<cjwatson> I would say that it is unwise to emit events at all at restart (i.e. other than at boot) that are likely to block on events that only arrive at boot time.
<cjwatson> Even with --no-wait, you're asking Upstart to keep track of an event that will never complete.
<Daviey> cjwatson: The issue is that one job is dependant on another job running.. I think we thought events was the way to do this?
<cjwatson> Dependencies aren't a concept Upstart has.  I recommend thinking only in terms of events.
<cjwatson> The key thing to realise here is that net-device-up is not a state.
<Daviey> The old way i used to see was a crappy sleep loop that progressed to the job when it's requirement was satisfied.. that is really ugly.
<rbasak> What about when we want to start a job from a postinst? In this case, waiting for net-device-up doesn't make sense.
<rbasak> But from the next reboot, we want that.
<cjwatson> No, it doesn't.  You probably need to redesign.
<cjwatson> This whole arrangement is prone to hangs.
<Daviey> cjwatson: Okay.. Other jobs do seem to emit events to use as dependencies.. not saying this is right... but how do we solve this issue?
<cjwatson> Some of them may be wrong, and some of them may know what they're doing!
<cjwatson> But you're not talking about a job anyway, you're talking about an init script.
<cjwatson> What are you trying to achieve by this rabbitmq-server-running event?
<cjwatson> And why isn't rabbitmq-server a native Upstart job if you need to have things depend on it starting at boot?
<Daviey> cjwatson: check that something which depends on rabbit has a valid user, and if not, create one.  Yes, it's a hack.
<Daviey> cjwatson: The issue is that running rabbitmq in d-i is harder.. which means that logic from postinst was moved to an upstart job.
<rbasak> Whoa
<cjwatson> I can't see how you get from the premise to the conclusion there, given that d-i doesn't use Upstart
<rbasak> You're running rabbitmq in d-i?
<Daviey> rbasak: no.
<cjwatson> This user creation: does it need to happen more than once per boot?  Does it need to happen only once ever?
<Daviey> cjwatson: No, the issue is that running rabbit in d-i seemed to uncover many more issues within the rabbitmq package.
<Daviey> So, making the app that talks to rabbit, would traditionally have the logic in the app's postinst.
<cjwatson> Well obviously you shouldn't start daemons during installation, but there's no need to solve that with arcane arrangements of events.
<Daviey> cjwatson: I get that.. but what do you suggest?
<cjwatson> I'm trying to understand your problem before making any concrete suggestions, hence my two questions above
<Daviey> cjwatson: Okay, it should be a once only action.
<Daviey> So it really has no place being in an upstart job.
<cjwatson> But it's a once-only action that requires rabbitmq to be running?
<Daviey> However, because doing that logic in d-i wasn't viable.. it was the best of two bad situations, that seemed to work.
<Daviey> cjwatson: yep
<cjwatson> Where is the code for this action?
<Daviey> one moment
<infinity> I'm confused.
<ogra_> we know
<rbasak> I think I might actually understand it now!
<cjwatson> infinity: I think I'm reasonably close to being able to make a non-broken recommendation
<infinity> There are lots of postinst actions that require daemons to be running (ie: anything that populates *sql databases).  How is this new ground?
<Daviey> infinity: because postgres for example, can runin d-i
<cjwatson> They probably don't work during OS installation.
<Daviey> rabbit seems to not like that situation
<ogra_> how about fixing that ?
<Daviey> http://pb.daviey.com/rhGN/
<infinity> Does this relate to the outstanding rabbit bug that it uses su to start and creates a PAM session?
<cjwatson> Daviey: That would be rather astonishing given that d-i tries extremely hard to suppress any daemon startup.
<Daviey> infinity: potentially.. one of those issues was resolved.. but there is still another su that didn't seem to have been addressed
<Daviey> Howeever, with that su removed in a testing environment, it still didn't unblock rabbitmq starting in d-i
<Daviey> cjwatson: Yep.. and hard to try astonishingly hard to circumvent that :/
<Daviey> cjwatson: Yes.. ignoring policy.d.
<Daviey> I'm not going to pretend this is graceful handling.
<cjwatson> Why does this need net-device-up
<cjwatson> ?
<Daviey> I'm not sure why that was added..
<infinity> Cargo-culted from another job, I'd guess.
<Daviey> Ah, the actual daemon it's running needs to be network addressable
<jodh> if it is somehow needed, it should probably be 'static-network-up' anyway
<infinity> Daviey: Really?  rabbitmqctl can't operate on, say, a UNIX socket?
<jodh> net-device-up is prolly wrong then as that'll match 'lo'
<Daviey> infinity: no, you aren't looking at the job, are you?
<Daviey> jodh: Yeah, it would seem it needs IFACE handling
<jodh> static-network-up bypassed that though
<infinity> Daviey: I'm not?
<cjwatson> Perhaps the simplest answer is that you should only emit rabbitmq-server-running during boot.
<jodh> I smell a UDS session coming out of all this.
<cjwatson> i.e. test RUNLEVEL
<Daviey> cjwatson: So if i apt-get install package.. the emit wouldn't happen.. i'd need to reboot?
<cjwatson> txlongpoll's postinst could always do this rabbitmqctl thing if and only if rabbitmq is running.
<Daviey> infinity: The daemon which is being discussed needs rabbit and also needs to be network addressable... External web browsers don't work well with unix sockets :)
<infinity> Daviey: The job doesn't make that particularly clear, so your previous comment was unhelpful.
<Daviey> cjwatson: Hmm, okay.. that makes sense.. Have the logic in postinst for the package install situation, and in upstart if it's d-i, so satisfied on first boot.
<cjwatson> Or you could patch the daemon itself to attempt it at startup.
<ogra_> ++
<Daviey> cjwatson: That sounds like a rabbithole.. It means priv drop logic would have to be added aswell, i imagine
<Daviey> To start as root.
<cjwatson> Oh?  The Upstart job you pointed to seems to start it as root already.
<infinity> ^
<Daviey> daemon starts, cannot authenticate, so creates a user, then authenticates.. feels more ugly
<Daviey> cjwatson: Yes it does at the moment.. but i'm sure by release it will have to be done by a system user.
<cjwatson> Well, up to you, either works
<bdrung> micahg: around?
<rbasak> Daviey: shall I leave this with you, then?
<Daviey> rbasak: Unless you want it? :)
<bdrung> micahg: i have a fix prepared for vlc that i like get tested by you
<Daviey> rbasak: I need to put a peg on my noise if i'm going to touch this.
<Daviey> cjwatson: thanks.
<rbasak> Daviey: :)
<Daviey> Hmm.. If a job is conditional on two events, and the events happen at massively different times.. is this an issue?
<Daviey> ie, custom event AND a networking one?
<infinity> No.
<infinity> Once an event is emitted, it doesn't un-emit.
<infinity> (It can re-emit, mind you)
<cjwatson> Depends how massively different we're talking about, though.  Boot vs. later package installation is not a good sign.
<Daviey> no, i mean.. is the blocking of an event's return an issue
<cjwatson> Not normally for brief periods during boot.
<Daviey> ok, thanks
<cjwatson> Unless you deadlock.
<rbasak> Daviey: I'm not sure I understand upstart well enough yet. This is a complex issue. Happy to learn it but I may not get to a good solution quickly.
<Daviey> Well yes, that seems viable in other situations.. thankfully i think a deadlock isn't possible in this crappy situation
<rbasak> Daviey: I'd start by having a separate script that does the setup. Then it's just a question of where that script gets called from.
<Daviey> yeah, groovy!
<Daviey> infinity: If you want to work on rabbit using start-stop-daemon in place of su.. there is a lovely entry point. :)
<infinity> rbasak: Perhaps with a semaphore (/var/lib/txlongpoll/user_created or such), so you don't retry every damned start. ;)
<Daviey> $ pastebinit /usr/sbin/rabbitmq-server
<Daviey> http://pb.daviey.com/fFSI/
<Daviey> infinity: ^^ yes, a sbin script..
<infinity> Daviey: Love the ghetto input validation...
<cjwatson> Your problem is not that shell is revolting.  Your problem is that su has an appalling interface.
<cjwatson> You wouldn't need that if you were using a more sensible tool.
<Daviey> cjwatson: yep.. not our code!
<Daviey> cjwatson: I started writing a start-stop-script drop in, but it started to become traumatic..
<cjwatson> It ought to mostly consist of deleting code.
<Daviey> it needs to accept start / stop init.d style.. but also arbitrary input aswell.
<Daviey> The whole thing is crappy.
<cjwatson> Er you could just make the current script better without trying to add lots to it
<infinity> So, basically, it needs to be a sysv init script.
<Daviey> infinity: right!
<infinity> Turns out there are still lots of examples of sysv init scripts using start-stop-daemon in /etc/init.d ;)
<Daviey> which is why having what is near enough, but not compliant init script in sbin is awesome.
<infinity> For now, anyway.
<Daviey> But then, it's also a sunny day.
<Daviey> infinity: that isn't the issue..
<infinity> I'm not actually sure what the issue is.
<infinity> You just need to replace su with s-s-d and pass $@ wholesale.
<cjwatson> start-stop-daemon --start --pidfile /dev/null --startas "/usr/lib/rabbitmq/bin/${SCRIPT}" --chuid rabbitmq -- "$@"
<cjwatson> Or some such.
<infinity> Like so.
<cjwatson> And delete all the quoting nonsense.
<Daviey> cjwatson: right.. and $@ contains start, stop, or other things we don't know
<infinity> Daviey: So?
<Daviey> so $something needs to be --$start to rperesent --start
<cjwatson> How's that a problem?  The script you gave us just passes all that stuff through.
<infinity> Daviey: Passing $@ is exactly what it does now.
<Daviey> cjwatson: it's not conditional on matching for start/stop commands, to pass outside of $@
<cjwatson> Nor is the script you gave us.
<infinity> elif [ `id -u` = `id -u rabbitmq` ] ; then
<infinity>     /usr/lib/rabbitmq/bin/${SCRIPT} "$@"
<infinity> else
<Daviey> I'm not saying it's a big deal, i'm sayin that i'm reluctant to change it at this stage in the cycle.
<infinity> All the script does is call rabbitmq $@
<cjwatson> I'm saying that this is unilaterally better and easily testable.
<Daviey> cjwatson: ${CMDLINE} is handled within the line... but it needs extracting to be part of start-stop-daemon --start, right
<cjwatson> No
<infinity> Daviey: No.
<infinity> Daviey: --start isn't what you think it is.
<cjwatson> CMDLINE is deviant garbage that should be discarded.
<infinity> Daviey: It just means "run this command".
<Daviey> Hmm.. are you both sure?
<cjwatson> Yes, quite sure.
<infinity> Daviey: Very.
<Daviey> ok
<cjwatson> CMDLINE is an abomination that messes around quoting "$@" in order to cope with the abysmal su interface.
<cjwatson> The correct answer is to not use su, after which you don't need any of this stuff.
<infinity> (--start means special things when combined with, say --make-pidfile, but since rabbit handles its own start/stop, you're only using s-s-d as a better su)
<cjwatson> Right.
<cjwatson> There are other ways; you could use a tiny perl wrapper, for instance.
<cjwatson> But s-s-d does the job as long as it doesn't need to run within the installere.
<cjwatson> *installer
<Daviey> but i'll potentially be calling rabbit with stop on the cmdline..  but --start in start-stop-daemon ?
<cjwatson> That doesn't matter.
<infinity> Daviey: Yes.
<infinity> Daviey: --start means "run this".
<Daviey> ok
<infinity> Daviey: And what you want it to run is "rabbitmq stop".
<infinity> Which is all good.
<Daviey> ok, thanks
<cjwatson> This is in some sense abusing start-stop-daemon to do something that isn't starting or stopping a daemon.  But it works.
<infinity> Daviey: --stop doesn't run commands at all, it looks for pidfiles and kills with fire.
<Daviey> it's not as complex as i thought it was.
<infinity> Daviey: And since rabbit has its own stopping, no need to ask s-s-d to do that.
<bdrung> micahg: i don't need your help. i reconstructed your setup and tested the fix here. i am going to upload 2.0.1-3 to debian
<bdrung> tumbleweed: time to do another u-d-t upload?
<tumbleweed> bdrung: seems like a good idea. I'll have a look through open bugs
<bdrung> tumbleweed: should we split bug #964731?
<ubottu> Launchpad bug 964731 in ubuntu-dev-tools (Ubuntu) "pull-debian-source wildcard support" [Medium,Triaged] https://launchpad.net/bugs/964731
<tumbleweed> bdrung: just looking at it now. It casuses DDE to throw an exception, returning invalid json. I'm about to commit something returning a saner error message
<dupondje> Fetched 1003 MB in 6s (3684 kB/s)
<dupondje> Thats fast ... :)
<jokerdino> I don't want to swear, really.
<highvoltage> No one's forcing you to.
<jokerdino> :)
<dupondje> Fetched 1003 MB in 6s (3684 kB/s). Got this when do-release-upgrade, file a bug on apt ?
<vibhavp> 1GB in 6 seconds!?
<dupondje> its wrong indeed :)
<vibhavp> Then you should file a bug
<dupondje> guess it takes the download time from the last file download
<vibhavp> must be
<roaksoax> cjwatson i did a new upload couple days ago that was waiting for approval
<cjwatson> roaksoax: Oh, so you did.  That's on the server images and AFAICR nobody flagged it as needing a respin - can we push that bug to final?
<astraljava> cjwatson: Sorry to bug you on this small detail, but we're a little stumped on the matter. The issue concerns branding of Studio, and can be seen in this screenshot: http://astraljava.kapsi.fi/us_precise_dash-and-xubuntu-logo.png
<astraljava> There's a dash between the words, and we'd like to get rid of it. But I can't find it as a string in any obvious package sources.
<cjwatson> could you file a bug about it for me?
<astraljava> cjwatson: Sure, I can. Thanks!
<cjwatson> it comes from cdimage, I need to consider the consequences of changing it
<astraljava> cjwatson: Alright, no problem. If it can be done, great, if not, not a big deal.
<astraljava> cjwatson: What should I file it on?
<cjwatson> astraljava: the ubuntu-cdimage project
<astraljava> cjwatson: Excellent. Thanks so much! And really, if it proves to be difficult, don't worry about it. I didn't know it's got such direct consequences.
<roaksoax> cjwatson sure!
<astraljava> cjwatson: I filed bug 967140, but I'd like to stress it's not _that_ big a deal, if it proves to be difficult.
<ubottu> Launchpad bug 967140 in Ubuntu CD Images "Ubuntu Studio branding problem; name spelled with a dash" [Undecided,New] https://launchpad.net/bugs/967140
<slangasek> pitti: oh, didn't realize there was a bug opened for the language-selector conffile issue, sorry
<pitti> slangasek: no problem, I just closed it manually
<Riddell> ev: presumably ubiquity isn't expected to work at 640x480 resolution?
<stgraber> Riddell: correct, IIRC the minimal resolution is 1024x600, might work on 800x600 (I think VMWare uses that)
<stgraber> well, it should "work", just won't fit on the screen
<Riddell> there was a fix recently for 800x600 in gtk frontend
<Riddell> I have a bug in arm which means I get 640x480 so kubuntu works fine but ubuntu desktop doesn't, but I'll not report another bug
<Riddell> or as you say works but won't show on screen
<micahg> bdrung: re vlc> great, thanks
<micahg> /back
<bdrung> micahg: you're welcome. you're ls output helped to understand the issue
<bdmurray> pitti: there is an issue with apport and kerneloops bug reports not getting the sourcepackage hook for linux run at all
<pitti> bdmurray: hm, any details about this?
<pitti> an apport linux bug seems to work fine here
<bdmurray> pitti: kerneloops ones
<bdmurray> bug 963142 is an example
<ubottu> Launchpad bug 963142 in iscsitarget (Ubuntu) "kernel BUG at /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/iscsi.c:392!" [Undecided,New] https://launchpad.net/bugs/963142
<bdmurray> it seems that add_hooks_info isn't geting run and I looked around but didn't see why
<Sweetshark> tumbleweed: I heard in a recent #ubuntu-meeting you want more reviewers for libreoffice packaging. Heres your chance to get started: find the libreoffice-3.5.1-1ubuntu2 upload on chinstrap.
<Sweetshark> tumbleweed: pitti sure will help you out.
<tumbleweed> Sweetshark: what's chinstrap, and also I'm not a core-dev
<Sweetshark> tumbleweed: oh, I can post on people.canonical.com if you prefer.
<bdrung> tumbleweed: you don't have to be core-dev to review a package ;)
<tumbleweed> of course not, but it might be wasted time
<tumbleweed> Sweetshark: sure, you wanted more review, if nobody else is going to do it, I'm happy to look at it, as long as I don't kill myself in the process :P
<tumbleweed> so yes, stick it somewhere I can see it
<Sweetshark> http://people.canonical.com/~bjoern/libreoffice_3.5.1-1ubuntu2/
<tumbleweed> I'll be home in an hour or two and have a look...
<micahg> Sweetshark: FYI, apparently, ubuntu-desktop and kubuntu-desktop can upload as well FWIW
<Riddell> micahg: pardon?
<micahg> Riddell: for libreoffice :)
<Riddell> oh you mean kubuntu-dev I think
<micahg> yes, kubuntu-dev
<Sweetshark> micahg, tumbleweed: well, please coordinate with pitti, who is quite eager to get this is in for bug 916291.
<ubottu> Launchpad bug 916291 in libreoffice (Ubuntu Precise) "failed to upgrade from Oneiric to Precise: ERROR: Cannot determine language! - exit status 134" [Critical,Fix committed] https://launchpad.net/bugs/916291
<micahg> Sweetshark: I don't have time to look at it ATM, was just referring you to other people who might be able to help
<hallyn> so, when i do 'pull-lp-source lxc natty-proposed' (where lxc does not exist in natty-proposed), i end up with a crash report and apport popup.
<ahasenack> is there a way to conditionally build-depends on a package depending on the ubuntu release it is being built on?
<ahasenack> for example, python-fixtures is not available in lucid, but it is in precise
<slangasek> ahasenack: by maintaining VCS branches for the different releases
<slangasek> otherwise no
<slangasek> well, to be fair, you could also do something like this
<micahg> ahasenack: there's a way to do it in packaging, but it needs to be generated before the upload happens (not automatic) with a control.in and a rule to regenerate, openjdk works like this
<slangasek> Build-Depends: python-dev, python-dev (<< 2.7) | python-fixtures
<slangasek> supposing that python-fixtures is new and only relevant for python 2.7 or so
<ahasenack> slangasek: yeah, I thought about a dummy |
<ahasenack> slangasek: but I think the ppa builders don't honor |
<micahg> ahasenack: they do as long as it's not a versioned dependency
<slangasek> they "honor" them, but the semantics are somewhat opaque
<slangasek> actually, I think python-fixtures | python-dev (<< 2.7) is the better way around
<slangasek> because if the first alternative is unavailable, LP will try the next one
<micahg> bug 594916
<ubottu> Launchpad bug 594916 in launchpad-buildd "buildd does not install alternate dependency for versioned ORed build-dependencies" [Low,Triaged] https://launchpad.net/bugs/594916
<slangasek> (and find it already satisfied)
<ahasenack> when I tried it downloaded more than it should
<ahasenack> I had this once:
<ahasenack> python-dev (>= 2.6.6-3~) | python-central | python-support
<ahasenack> it downloaded natty/main python-dev all 2.7.1-0ubuntu5
<ahasenack> and then  python-central all 0.6.15ubuntu5
<ahasenack> so that falls into that bug? Let me check
<ahasenack> my case looks diferent, the first package was found and downloaded
<ahasenack> but it continued and downloaded the second one
<ahasenack> slangasek: I will try your idea, thanks
<slangasek> chrisccoulson: hi, have you gotten other reports of bug #967469?  I haven't heard anyone making noise about it, so I'm wondering if it's just me
<ubottu> Launchpad bug 967469 in firefox (Ubuntu) "firefox+unity-2d: runaway CPU usage when hud-service is running" [Critical,New] https://launchpad.net/bugs/967469
<chrisccoulson> slangasek, bug 801699
<ubottu> Launchpad bug 801699 in DBus Menu "DBus menu is very slow when using large menu" [Medium,Triaged] https://launchpad.net/bugs/801699
<marsfligth> Why don't offer the choice to use Unity/Gnome 3 or a full futured desktop environment that respect the usage, behavior, system requirements, stability, debugged and fully compatible desktop environment in use since 20 years? Why impose only the new one that in more its totally different than previoous?
<slangasek> chrisccoulson: does that really explain it entirely, though?  Note that I'm not trying to *interact* with any menus here, so shouldn't it eventually settle down?
<chrisccoulson> slangasek, yeah, it's the same issue. hud-service mines the menus in firefox, which causes high CPU usage
<seb128> slangasek, does it do it all the time? do you have lot of bookmarks or nested ones?
<seb128> chrisccoulson, the description seems not similar though, it suggests it happens sometimes, not always there
<seb128> we got bugs like bug #965493
<ubottu> Launchpad bug 965493 in unity (Ubuntu) "cpu race between nautilus, hud- and unity-service" [High,Triaged] https://launchpad.net/bugs/965493
<slangasek> seb128: how many is "a lot"?  I count 15 bookmarks with one submenu, not counting ones that were autocreated for me by one generation of ff or another
<seb128> chrisccoulson, ^ I think it's not the bug you listed
<slangasek> chrisccoulson: ok, so, shouldn't hud-service mine firefox /less/?
<chrisccoulson> slangasek, can you get a backtrace then?
<seb128> slangasek, can you try pinging desrt on #gnome-desktop to see if he wants to help you debugging it?
<slangasek> I mean, what's causing it to poll it *constantly*?
<seb128> ups
<seb128> #ubuntu-desktop
<slangasek> chrisccoulson: of FF?  I imagine I could
<chrisccoulson> slangasek, it doesn't it polls when the window comes in to focus, which is triggering a lot of CPU for some people
<seb128> chrisccoulson, slangasek: please move on #ubuntu-desktop
<seb128> desrt is maintaining hud-service and could be useful to include in that discussion
<YokoZar> Can I ask why p11-kit is in universe when gnutls26 seems to depend on it?
<YokoZar> and by "depend" I mean "throw warnings every time it's used when it's missing"
<slangasek> YokoZar: it shouldn't depend on it at all. What warning are you getting?
<YokoZar> slangasek: https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/957931
<ubottu> Launchpad bug 957931 in gnutls26 (Ubuntu) "Missing p11-kit dependency?" [Undecided,Confirmed]
<YokoZar> on further testing installing p11-kit doesn't actually fix this...but the warnings appear to be spurious and are generated whether or not p11-kit is installed
<slangasek> YokoZar: they're not spurious; /etc/pkcs11/modules/gnome-keyring-module exists and refers to gnome-keyring-pkcs11.so, but this is a multiarch install on amd64 and the i386 version of the module is not installed
<slangasek> the p11-kit message refers to *lib*p11-kit
<YokoZar> slangasek: I have that installed too (for both arches)
<slangasek> you definitely do not have gnome-keyring-pkcs11.so installed for both arches
<YokoZar> slangasek: ahh it's in the gnome-keyring package
<slangasek> yep
<YokoZar> ...which isn't a multiarch package
<YokoZar> So there doesn't seem to be any solution here
<slangasek> nothing that should be done this cycle, no
<YokoZar> i'll retarget it to gnome-keyring and tag multiarch
<slangasek> already done
<YokoZar> hah, thanks
<YokoZar> man wine really is the major test case for all things multiarch
#ubuntu-devel 2012-03-29
<jhojho> 940230
<jhojho> bug 940230
<ubottu> Launchpad bug 940230 in openssl (Ubuntu) "openssl on 64bit is much slower than before" [Undecided,New] https://launchpad.net/bugs/940230
<kees> micahg: so, this has regressed a while back, and I think you sent me to https://bugzilla.mozilla.org/show_bug.cgi?id=716110 but I can't make sense of it.
<ubottu> Mozilla bug 716110 in Startup and Profile System "split -new-instance flag out of existing -no-remote flag" [Normal,Resolved: fixed]
<kees> basically, this doesn't work:
<kees> /usr/lib/firefox/firefox -P Browsing -remote 'openURL(http://feedproxy.google.com/~r/MFLF/~3/WM7yqk8qY-U/)'
<kees> Error: No running window found
<kees> I've tried combinations of -new-tab and -new-window but they yell about there already being a copy of firefox running. :P
<micahg> kees: first instance without -no-remote and subsequent with IIRC
<kees> micahg: I run all my firefox process with: /usr/lib/firefox/firefox -ProfileManager
<kees> so the "Browsing" instance is already running
<micahg> kees: right, well, starting with Firefox 13 you can just pass -new-instace
<micahg> oh, wait, I see the question now
<kees> OOOOH the problem is with the initial, not the latter!
<kees> yes! starting the initial with -new-instance fixes it! yay!
 * kees hugs micahg
<kees> now I just have to figure out how I tricked unity into launching my special firefox command instead of the real thing
<kees> no idea :P
<pitti> Good morning
<pitti> Sweetshark: LibO uploaded now
<pitti> infinity, cjwatson, RAOF, SpamapS: FYI, http://people.canonical.com/~ubuntu-archive/pending-sru.html is now showing non-DONE builds
<pitti> for SRUs that's helpful to block -updates, and for precise-proposed it tells us when we can copy stuff over
<RAOF> Nifty.
<pitti> together with the new sru-release --release (or -r) switch, we now should have the basic tools to use precise as a staging area
<pitti> we are still missing an installability check for -proposed, though
<pitti> http://people.canonical.com/~ubuntu-archive/testing/precise-proposed_probs.html would be good to have, and I suppose not even particularly hard to set up
<pitti> in fact, that looks pretty trivial
 * pitti gives it a shot
<pitti> and add the missing lucid..oneiric-proposed as well (we only have it for dapper and hardy)
<cjwatson> pitti: to use it properly we'll need to be able to ask questions like "does moving this set of packages from -proposed to release make release less installable?", rather than just knowing whether -proposed is installable
<cjwatson> not saying all these aren't improvements, but we did lay out a plan
<cjwatson> of sorts
<pitti> right, I wasn't saying it was perfect already
<cjwatson> I have an LP branch for enabling -proposed outside freeze periods, which is just waiting for me to squeeze it in under the LoC requirements of the new LP maintenance policy before I submit an MP
<pitti> cjwatson: I saw, thanks so much for this
<broder> cjwatson: does your patch just enable proposed or other non-release pockets as well?
<pitti> there http://people.canonical.com/~ubuntu-archive/testing/precise-proposed_probs.html
<pitti> once LibO i386 finishes building on i386, it should have some stuff until the other arches catch up; I'll double-check it then
<cjwatson> broder: just proposed
<broder> aww :)
<cjwatson> broder: hopefully makes it a bit easier to add other pockets in future though
<tumbleweed> pitti: what is libreofficeu-core in the libreoffice upload you sponsored for Sweetshark? http://launchpadlibrarian.net/98802969/libreoffice_1%3A3.5.1-1ubuntu1_1%3A3.5.1-1ubuntu2.diff.gz
<tumbleweed> err not that
<tumbleweed> oh, no the url is right
<micahg> no, that is right :)
<pitti> tumbleweed: I suppose it's a typo
<pitti> Sweetshark: ^
<tumbleweed> he appears to be offline, I poked him an hour or two ago
<pitti> yes, still a bit early for him
<pitti> tumbleweed: let's say it's a (rather expensive) test case for http://people.canonical.com/~ubuntu-archive/testing/precise-proposed_probs.html :)
<pitti> tumbleweed: curious though, the package was already tested in a PPA, including a full upgrade test; I guess it slipped in when building the suorce for precise :(
<Daviey> pitti: Hey!  Can i talk to you about https://launchpad.net/ubuntu/+source/nova/2011.3+git20111117-0ubuntu1 ?
<pitti> Daviey: ah yes, indeed; it seems that hasn't been tested much yet
<Daviey> pitti: A few of the issues are not realistically going to get verified in Ubuntu, such as a Xen bug.  However, as previously discussed - we are putting more confidence into the upstream stable tree process (we are reviewers of it.)
<Daviey> pitti: It has.. Trellis Has been using it..
<Daviey> (and others obv.)
<smb> Daviey, a Xen bug? Where? :)
<Daviey> pitti: It's also been through our internal CI
<Daviey> smb: A bug with nova usng Xen.
<pitti> Daviey: AFAIR the proposal for the standing SRU exception was that the -proposed version has to be run through a large test suite and QA process which ensures that there are no regressions
<pitti> Daviey: not necessarily to validate each individual bug, as that's rather impractical for so many
<smb> Daviey, If you care to pass me the bug number, I may have a look too if needed. I just have missed it up to now
<pitti> so if there was something like a QA process, it either wasn't posted to one of the bugs, or it slipped our attention
<Daviey> pitti: The process is that we QA each commit upstream as it hits, and do so for milestones.
<Daviey> Hmm, but the results don't seem to be posted public.
 * Daviey investigates 
<pitti> Daviey: and that still doesn't guarantee us that the bits in -proposed will actually work
<pitti> we need to run integration/system test against the bits that are in -proposed, not against what landed in upstream trunk a long time ago
<pitti> s/not/not just/
<Daviey> pitti: True, but this is a large part of the reason we are involved in the upstream stable tree, to try to mitigate this.
<pitti> and also consider differnent kinds of existing setups and configs
<pitti> Daviey: so I think it's been in -updates long enough, and there are enough v-dones to justify moving to -updates if you feel comfortable with it
<pitti> Daviey: but I don't think it was a good example of how things should go; it took too long, and there was not enough feedback about the global (not per-bug) regression testing with this
<pitti> Daviey: shoudl go for the SRU exception, I mean
<Daviey> pitti: Yeah, I agree with that.  We need to come up with a better process to do distro validation.
<Daviey> pitti: I'm just crosschecking a few more things.
<pitti> Daviey: ok, thanks; let me know when I should move to -updates
<Daviey> pitti: It looks like it will superseed a security upload currently in -updates.. So it's a no-go
<Daviey> dammit.
<Daviey> ie, doesn't have the security fix.
<micahg> wow, that was over 2 months ago
<Daviey> micahg: 14 weeks is certainly more than 2 months :)
<micahg> Daviey: was referring to the fact it was superseded by a security upload ~2 months ago
<Daviey> micahg: Yeah, the SRU upload has been pending for 14 weeks.
<micahg> Daviey: it was out of date when it was uploaded (6.3 actually had a fix not included, so it never could've gone to -updates anyway)
<Daviey> micahg: Yep, just covered this :)
<tumbleweed> pitti: :)
<henrix> pitti: hi. it looks like some kernel packages landed on the wrong component
<henrix> pitti: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/965346/comments/2
<ubottu> Launchpad bug 965346 in Kernel SRU Workflow "linux: 2.6.38-14.58 -proposed tracker" [Undecided,In progress]
<pitti> henrix: thanks, will fix
<henrix> pitti: great, thanks
<pitti> weird, I moved the whole thing to main
<pitti> oh, that's from -meta
<pitti> henrix: it's in universe in -security and -updates as well, though
<pitti> but the -14 binaries are in main indeed
<henrix> pitti: strange...
<pitti> henrix: I guess that was before we had these nice new checks
<pitti> henrix: I'll fix it
<henrix> pitti: yeah, that would be great.
<henrix> pitti: please let me know once that's sorted out
<pitti> henrix: done; I'll re-close the bug
<henrix> pitti: cool
<pitti> ev: FYI, dealing with the problem_types thingy now (to avoid duplicate work)
<ev> pitti: cheers!
<pitti> ev: I subbed you to the bug, so that you can follow the progress
<ev> thanks muchly
<vibhavp> What is best language to learn to start with Ubuntu development?
<pitti> vibhavp: depends on the area you want to work on really, but all in all the two most common languages are C and Python
<davmor2> pitti: I added the gvfs info you asked for to bug #952933 anything else likely to help?
<ubottu> Launchpad bug 952933 in gvfs (Ubuntu) "sansa fuse not showing up as a media-player in precise ie not triggering open in Rhythmbox dialog" [Medium,Incomplete] https://launchpad.net/bugs/952933
<pitti> davmor2: hm, this also looks correct
<pitti> davmor2: do you see it in RB as a media player?
<pitti> I tested that with my phone and my wife's Sony Walkman, and it seems to generally work okay
<pitti> davmor2: do you also get this in a guest account? we had some problems with disabled plugins in RB
<davmor2> pitti: yeap I see it and it has a a music player icon,  it just doesn't open in RB or trigger the normal open in dialog like it does in natty/oneiric
<davmor2> I should say it doesn't auto open RB
<pitti> davmor2: ah, thanks
<pitti> davmor2: ok, I can check that part
<pitti> davmor2: so I retitle to "media players do not trigger Open With Rhythmbox dialo"?
<pitti> davmor2: done, thanks!
<davmor2> pitti: yeap you can do, I merely assumed it was opening the nautilus window as it wasn't triggering the fact it was a media player
<seb128> pitti, the default on media player connect is "ask what to do"
<seb128> i.e it should display a dialog
<seb128> that doesn't work?
<jelmer> FreezeExceptionProcess documents that I should explicitly document that I'm uploading a new bugfix-only upstream release during FF
<jelmer> Is there are recommended way of handling this when syncing, or should I do a merge in that case?
<cjwatson> jelmer: don't avoid syncs just for the sake of extra changeloggery
<cjwatson> syncs are good if possible
<cjwatson> you can tell us on #ubuntu-release or something
<cjwatson> or we can just look :)
<jelmer> cjwatson: will do - thanks!
<pitti> seb128: apparently it doesn't
<seb128> pitti, I've the issue with my ipod, looking at it
<pitti> my mobile phone asks me what to do with the photos
<pitti> but nothing for the music
<seb128> pitti, it seems to not detect it as a music player
<seb128> pitti, i.e nautilus doesn't have the banner either
<seb128> where a sd card with photos work
<seb128> it displays a banner in nautilus "do you want to open with shotwell"
<speakman> The flashplayer-installer update earlier today has ruined any flash content! Anyone else noticed?
<pitti> ah, http://people.canonical.com/~ubuntu-archive/testing/precise-proposed_probs.html seems to work fine
<davmor2> seb128: ref: music player. it isn't working here for me it just opens a nautilus window
<fraviofii> hello, I would like to ask some advice regarding ubuntu-core
<fraviofii> I'm trying to install opencv package in ubuntu-core distribution for arm
<fraviofii> I'm using chroot, and the apt-get install is not finding the package. I changed source.list file from /etc/apt
<geser> which error do you get?
<fraviofii> package not found
<geser> which command do you use? (which package exactly do you try to install?)
<fraviofii> first I use apt-get update
<fraviofii> and then, apt-get python-opencv
<fraviofii> sorry
<fraviofii> one minute
<fraviofii> in fact, I used "apt-get install opencv"
<fraviofii> probably that's the reason
<geser> opencv is the source package name, python-opencv is one of the binary packages build from that source package
<fraviofii> yes ... that's the problem ... i'm installing right now the python-opencv package, which is istalling the dependencies
<bjf> pilot in
<bjf> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta 2 Freeze in Effect. Archive: pre-release freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bjf
<ogra_> wow, so if i (by accident or whatever) uninstall unity-greeter i'm completely left with a crashing Xserver in a loop, there is no fallback built into lightdm (not even an ugly one) ?
<pitti> I think lightdm should not just recommend: a greeter, but depend on it
<ogra_> well, that would have left me in a similar situation, though with a console login by default at least
<ogra_> i think it should just have some unthemed fallback thing builtin or so
<pitti> bdmurray: it seems your http://reports.qa.ubuntu.com/reports/bug-fixing/precise-fixes-report.html files don't count upload to precise-proposed, nor their copies to precise
<pitti> seb128, didrocks ^
<seb128> pitti, thanks
<pitti> bdmurray: as we are going to use precise-proposed more and more for staging uploads, woudl it be possible to fix thaht?
<seb128> ogra pitti, xfailsafe should kick in
<didrocks> pitti takes the bug # countest quite seriously :)
<seb128> ogra_, pitti: check with bryceh maybe
<pitti> well, I also find it quite helpful for duplicates
<bdmurray> pitti: I'll look into it
<didrocks> indeed :)
<pitti> when I see a bug report and I remember "I fixed tihs already", etc.
<pitti> but yes, the competition is certainly the most interesting one, as well as judging applicants for upload privs
<pitti> bdmurray: cheers
<ogra_> seb128, thats another prob, failsafe doesnt get me back to lightdm at all, not even if i installed a greeter during having the failsafe stuff on the screen
<pitti> bdmurray: e. g. https://launchpad.net/ubuntu/+source/gtk+2.0/2.24.10-0ubuntu6 does not appear at all
<seb128> ogra_, not failsafe mode, xfailsafe or whatever the x debugging mode is called
<seb128> ogra_, the thing which should kick in when you get a broken xorg config
<ogra_> seb128, well, i get a dialog telling me stuff about my xserver and dropping me into a selection menu to reconfigure etc
<ogra_> funnily completely without mouse nor is any kbd management possible
<seb128> ogra_, you said " i'm completely left with a crashing Xserver in a loop
<seb128> ogra_, so which one it is?
<seb128> does it loop segfault or does it display a dialog?
<ogra_> i get that dialog, then X crashes trying to start lightdm, crashes because it finds no greeter and gets me back to the dialog
<ogra_> i can exit the failsafe thing qith esc, but not select anything
<seb128> ogra_, the dialog should let you fix your lightdm config
<seb128> you have several bugs there...
<seb128> handling broken configs and install is an hard job ;-)
<ogra_> once i exit i'm left with a black screen and blinking cursor in the top left corner and the system seems to not take any kbd input
<ogra_> (i can ping it, its not crashed, but something blocks the kbd so i cant switch to a tty)
<ogra_> seb128, yeah, and i think its a corner case (i tried lxde on my netbook ... since g-s-d is so annoyingly crashy i removed it which pulled our unity-greeter and left me in that state)
<ogra_> s/our/out/
<seb128> ogra_, can you give me the bug number for your g-s-d issues so we can try to get them resolved?
<ogra_> so how would i reconfigure lightdm from console ? dpkg-reconfigure doesnt seem to do anything
<ogra_> seb128, its logged in the tracker (also reported by pgraner), thats a plain segfault iirc
<seb128> ogra_, is that the wacom tablet one?
<ogra_> nope
<ogra_> arm
<seb128> ogra_, reconfigure what?
<ogra_> lightdm
<seb128> ogra_, what option?
<ogra_> the greeter
<seb128> ogra_, I don't think there is a dpkg interface to reconfigure anything
<seb128> just edit /etc/lightdm/lightdm.conf
<ogra_> /etc/lightdm.conf points to unity-greeter even though thats not installed
<seb128> ogra_, well install a greeter, the gtk one for example
<seb128> ogra_, the postinst will update the config for you
<ogra_> err /etc/lightdm/lightdm,.conf indeed
<ogra_> i have the gtk greeter installed now
<ogra_> since a while already, no change
<ogra_> feels like the failsafe mode still gets in the way
 * ogra_ reboots 
<ogra_> hmm,. even reboot gets me back into failsafe
<ogra_> and the second window doesnt takle any input
 * ogra_ reinstalls the gtk greeter
<ogra_> hmm, had to actually edit lightdm.conf but now it works
<ogra_> seb128, just fyi, i think my g-s-d bug is bug 956824
<ubottu> Launchpad bug 956824 in gnome-settings-daemon (Ubuntu) "[power]: gnome-settings-daemon crashed with SIGSEGV in gnome_rr_screen_get_dpms_mode()" [Medium,Triaged] https://launchpad.net/bugs/956824
<seb128> ogra_, ok, thanks
<seb128> ogra_, do you get that bug often? when doing what?
<ogra_> every login
<ogra_> it respawns immediately
<seb128> ogra_, upstream says it happens if the call to gnome_rr_screen_new() fails, I wonder if that's a race or something
<ogra_> smells very much like one
<seb128> ogra_, I will include the upstream patch in my next upload, let me know how it goes
<ogra_> i have all themes etc nothing looks weird
<ogra_> so it must respawn in the bg
<ogra_> will test, thanks "
<ogra_> !
<seb128> ogra_, yw
<seb128> ogra_, on the lightdm greeter topic robert_ancell didn't want to build builtin fallback greeter, his idea was rather to send you to xfailsafe and that xfailsafe would have an option to restore a stock config and would reinstall the greeter if it's uninstalled
<ogra_> hmm, it didnt give me any greeter rleated options
<ogra_> probably that feature isnt done yet ?
<ogra_> in any case i didnt have any kbd/mouse in failsafe after the first window so it wouldnt have helped
* pitti changed the topic of #ubuntu-devel to: Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bjf
<marsfligth> Just for your information http://www.zdnet.com/blog/open-source/linus-torvalds-would-like-to-see-a-gnome-fork/9347
<cjwatson> Please can we not have a big advocacy war here?
<apw> cjwatson, have we added anything to prevent VT handoff with encryption do you know?
<cjwatson> apw: not explicitly, but seeing as grub can't read from encrypted devices yet it's quite possible that it takes you down different code paths
<cjwatson> for example you may not have a font configured
<cjwatson> oh, and indeed that causes us not to load gfxterm
<cjwatson> so yeah, you probably won't get vt handoff with an encrypted /
<cjwatson> but it's an nth-order consequence
<apw> cjwatson, ahh ... well we do still tell the kernel we are doing it, even when we are not, which might not be good
<cjwatson> so vt handoff will make the kernel upset if it gets entered in text mode?
<apw> cjwatson, i'd not really expect it to no, and it seems to work ok for intel at least, but there are some complaints around ... though you are handing off in normal vt mode so they should be in a better place to cope
<apw> cjwatson, will investigate further there are too many holes in my data
<cjwatson> ok, well feel free to assign me a bug on that, shouldn't be desperately hard to fix up
<cjwatson> if it's just a matter of ditching vt.handoff in that case
<smoser> cjwatson, ping.
* ChanServ changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bjf
<Awsoonn> d
<bjf> @pilot out
* udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<SpamapS> W: Failed to fetch bzip2:/var/lib/apt/lists/partial/us-east-1.ec2.archive.ubuntu.com_ubuntu_dists_precise_main_source_Sources  Hash Sum mismatch
<SpamapS> ugh
<SpamapS> we really need to fix apt so mirrors can't get in this state
#ubuntu-devel 2012-03-30
<zruty> How to file a bug without knowing the package causing the issue?
<micahg> zruty: is there a window?
<zruty> no
<micahg> zruty: ask in #ubuntu-bugs to get some help
<zruty> No process (that I know of), no window, no nothing. Just something that does not work (which does work in Win)
<zruty> Okay
<pitti> Good morning
<pitti> dupondje: good morning
<pitti> dupondje: any luck getting the cryptsetup split into Debian?
<dholbach> good morning
<maximilius> Hello & sorry for this. I know DEVEL is not for user support questions. but i really need somebody with a clue to help me troubleshoot this problem.
<maximilius> In a Gnome-Terminal i SSH to a remote host and use irssi there. As soon as i launch Rhythmbox, Liferea or if i browse a modern website with Firefox or Chromium i get a slideshow in "irssi" when switching channels e.g. or when typing.
<maximilius> the hardware is an AMD64 3200 with 2GB RAM and a GeForce 8400 GS so this box should be able to handle the load, right?
<maximilius> Ubuntu 10.04 11.10 and 12.04 show all this same problem
<maximilius> please, how can i get to the source of the problem?
<janimo`> @pilot in
* udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: janimo`
<jamespage> anyone know if the LP buildd's support inotify?
<pitti> jamespage: I don't see why they wouldn't, but I'm not 100% sure
<pitti> jamespage: you mean for test suites, etc}
<pitti> jamespage: glib uses inotify, and its tests succeed on the builders
<jamespage> pitti, https://launchpadlibrarian.net/98985481/buildlog_ubuntu-precise-i386.nodejs_0.6.12~dfsg1-1ubuntu1~precise1~ppa1_FAILEDTOBUILD.txt.gz
<jamespage> its in a PPA builder - not sure whether that makes a difference
<jamespage> the test that fails passes in my local sbuild - the feature depends on inotify and the test fails with ENOSYS which would indicate it does not
<pitti> jamespage: ah, it's possible that glib falls back to something else if inotify isn't available
<jamespage> pitti, I can allow this test to optionally FAIL so I can work around it but would like to know for sure
<cjwatson> jamespage: I don't know specifically about inotify, but they do run hardy-era kernels
<cjwatson> so it's not usually a surprise to find the odd missing feature
<janimo`> dholbach, hi, how can a merge request be taken off the sponsors list? I see no equivalent of the unsubscribe button that bugs have
<dholbach> janimo`, you can mark the status of the whole merge proposal as 'work in progress' or 'rejected'
<janimo`> dholbach, ok. I only see work in progress as an option. The linked bug has been marked won't fix, but that was not very obvious in the review page until I looked for it explicitly
<dholbach> janimo`, in that case please ask in the channel for somebody (TB + other ~ubuntu-branches people) to mark it as rejected
<janimo`> dholbach, what about deleting the proposal is that not something usually done?
<dholbach> I usually try to keep it around, so the contributor can maybe click on "resubmit"
<dholbach> I don't know
<dholbach> anyone else ^?
<janimo`> dholbach, I find some merges get into the sponsoringl ist when they would better be left as discussion among the various people involved in the package/bug
<micahg> I would think to only delete if there's something destructive
<dholbach> janimo`, I agree
<janimo`> as they are clearly not beginners asking for a non-controversial change
<janimo`> dholbach, the reason I tiptoe around most of the time in the sponsoring qa list is many issues seem specific bugfixes better left to the submitter and the de facto maintainer to sort out
<dholbach> janimo`, in that cases it might make sense to get in touch with the maintainers and discuss it with them
<janimo`> dholbach, well they are subscribed to the specific bugs and attachments  I'd hope
<dholbach> you know how sometimes things get lost in big mailboxes
<janimo`> does anything with a debdiff attached automatically make it to the list ?
<dholbach> I usually ping them or join their IRC channel
<dholbach> yes, there's a bot running which adds debdiff bugs to the sponsoring queue
<janimo`> cyphermox, I unsubscribed sponsors from 915095 as that is something you've touched before
<cjwatson> janimo`: in general one does not delete things from LP
<cjwatson> "one does not simply WALK into Mordor"
<janimo`> cjohnston, yeah. I wish the button was not that prominent on the side then, it is unclear it is not a good thing to do, solely from the UI
<janimo`> cjohnston, sorry for pinging you twice, one of them by accident
<pitti> jibel: hm, the lucid-precise-universe upgrade test didn't run today?
<pitti> jibel: the at-spi fix is in, so I'm hoping it can resolve the upgrade path better now
<pitti> jibel: not a biggie, I can wait until Monday; by then we'll hopefully also have LibO built
<jibel> pitti, there was a maintenance in the lab yesterday evening and the slave didn't restart. I'll start the job.
<pitti> jibel: ah, thanks
<jibel> slave = "jenkins slave" to avoid any confusion
<jamespage> larsduesing, want me to take a run at fixing those upstart issues? I have already refactored in the process tracking stuff locally
<cjwatson> jelmer: I've done bug 968273 for you, but please note that syncs are now self-service when you have upload permissions to the package in question, which you do: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-January/000923.html
<ubottu> Launchpad bug 968273 in tevent (Ubuntu) "Sync tevent 0.9.15-1 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/968273
<janimo`> @pilot out
* udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<hrw> are there chances to get http://paste.ubuntu.com/907017/ intergrated into precise? This is fix for debian bug #659588 (which is also present in Ubuntu)
<ubottu> Debian bug 659588 in libglib2.0-0 "libglib2.0-0: fails to install with foreign Multi-Arch" [Normal,Fixed] http://bugs.debian.org/659588
<pitti> hrw: yes, absolutely; now that 2.30-2 has hit unstable, it'd be good to merge again anyway
<hrw> pitti: so request sync rather then submit patch?
<pitti> hrw: I believe we need to merge, we still have some transient delta
<hrw> right
<pitti> hrw: is there an ubunty counterpart for this bug? if so, pleaes feel free to assign to me
<hrw> pitti: Bug #950967
<ubottu> Launchpad bug 950967 in glib2.0 (Ubuntu) "glib2.0:armel uninstallable on systems that don't support executing armel code" [Low,Triaged] https://launchpad.net/bugs/950967
<pitti> hrw: thanks, grabbing
<hrw> pitti: thx
<hrw> pitti: it will unblock lot of packages for cross builds ;)
<dupondje> pitti: as told, there will be first a new release in debian with only bugfixes, next upload will be the split
<dupondje> but the maintainer is quite buzzy atm, so need to spank him :)
<dupondje> slangasek: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/874774 could you simulate this? Tried here, but it always mounts the swap just fine :(
<ubottu> Launchpad bug 874774 in cryptsetup (Ubuntu Precise) "could not mount /dev/mapper/cryptswap1" [High,Triaged]
<mdeslaur> slangasek: think you could milestone a few of the broken openssl bugs? the 1.0.1 upload is breaking a lot of stuff...
<jayson_> Hello!  I just wrote a patch for annotate-output to add some features.  Ubuntu's is forked from upstream so sending it there isn't helpful.  It's not a bugfix so opening one wouldn't be right.  Where /should/ I submit it?
<dupondje> jayson_: you can open bugreports for new features also :) its not for bugs only.
<cjwatson> mdeslaur: I'd welcome suggestions on a fix, since the Debian maintainer doesn't seem to have any immediate bright ideas
<cjwatson> admittedly -tls1 does seem to solve all the ones I've seen so I suppose maybe a change of defaults or something ...
<jayson_> OK, cool.  Will do.  Thanks!
<cjwatson> jayson_: I don't see any Ubuntu-specific changes to annotate-output at the moment, though
<mdeslaur> cjwatson: hrm, upstream bug says to disable tls1.2 in the client for now
<cjwatson> jayson_: so not sure what you mean by us being forked.  The package as a whole has Ubuntu-specific changes, but that script doesn't
<mdeslaur> cjwatson: if there's no better solution before we release, maybe we should do that and fix with a SRU later on once they figure something out
<cjwatson> mdeslaur: do you have a reference to the upstream bug, please?
<mdeslaur> cjwatson: http://rt.openssl.org/Ticket/Display.html?id=2771&user=guest&pass=guest
<cjwatson> thanks
<cjwatson> I've milestoned it
<cjwatson> (bug 956371)
<ubottu> Launchpad bug 956371 in elementary Icons "wired network panel icon is not symbolic" [Undecided,Confirmed] https://launchpad.net/bugs/956371
<cjwatson> it was already rls-p-tracking but I guess we have to tick all the boxes
<cjwatson> err, sorry, bug 965371
<ubottu> Launchpad bug 965371 in openssl (Ubuntu Precise) "HTTPS requests fail on some sites on Ubuntu 12.04" [High,Confirmed] https://launchpad.net/bugs/965371
<jayson_> cjwatson: compare /usr/bin/annotate-output vs http://jeroen.a-eskwadraat.nl/sw/annotate/annotate - the former has options for format strings and --help, the latter does not
<mdeslaur> cjwatson: thanks
<cjwatson> jayson_: in practice the current upstream for that script is Debian, wherever they originally got it from, and Debian's and Ubuntu's version of that script are identical.
<cjwatson> jayson_: what you're seeing is the changes that Debian made since the initial import.
<jayson_> Oh, I thought it was originally pulled by Ubuntu, not Debian.  Checked again, you're right!  I'll send the patch to Debian.  Thanks!
<Whoopie> seb128: Hi, regarding bug 965279, I'm not sure if the battery status icon should be hidden in all sessions. To my understanding, gnome-shell doesn't use indicator-power, so it needs g-s-d's battery icon.
<ubottu> Launchpad bug 965279 in gnome-settings-daemon (Ubuntu) "duplicated battery icon in gnome-classic (notification area)" [Low,Fix committed] https://launchpad.net/bugs/965279
<seb128> Whoopie, gnome-shell has its own shell indicator
<seb128> gnome-classic as the indicator
<seb128> unity has the indicators
<seb128> other desktop don't use gsd
<Whoopie> seb128: ok, thanks for the explanation.
<smb> cjwatson, Doing some slightly more special iso testing I found some unexpected things happening in the lands of fakeraid and the installer. Somehow I thought that all fakeraid was handled by dmraid (and bug reports seemed to say it works). However we failed to put the right dm module into the udebs without noticing.
<smb> The d-i file has dm-raid4-5, unfortunately the modules name is dm-raid45. This probably goes on for a while now. It is probably just hidden by the fact that md(adm) now understands some other meta-data formats, one of them being the Intel Matrix Storage Manager format (which is probably the most widely spread)
<smb> Does not seem to completely work on the box I tested as I only get it up read-only and did not yet succeed in making it rw. The question is whether fixing the modules name for udeb (while correct) could have some unexpected results for the installation process. So maybe it would be better delayed till after release to be targetted to a point update...
<smb> Daviey, Maybe of interest to you ^ though for server I believe people usually avoid fakeraid usage and go mdraid directly (or hw raid)
<cyphermox> janimo`: the patch was incorrect for a variety of reasons though I'm happy to see the process for sponsoring and patching a package was dead on. I updated 915095 accordingly; m-b-p-i tends to be a little special anyway
<cjwatson> smb: please go ahead and put the correct module into the udeb
<cjwatson> before release
<Daviey> smb: Oo, i didn't know md now supported other formats
<smb> cjwatson, Ok, will do then
<Daviey> smb: I'd rather fakeraid support was removed.. but can't see that happening :)
<smb> Daviey, Me neither
<janimo`> cyphermox, ok
<cyphermox> janimo`: thanks for looking at it :)
<janimo`> cyphermox, piloted by it ;)
<cyphermox> ah, right
<cyphermox> vibhavp: if you want to help writing patches for the 17 or so bugs in m-b-p-i, that would be very cool; then I'll poke upstream to get the patches committed and cut a new snapshot.
<vibhavp> cyphermox: sure!
<cyphermox> vibhavp: bug 912728 looks very straightforward, needs full triaging and the patch is provided
<ubottu> Launchpad bug 912728 in mobile-broadband-provider-info (Ubuntu) "Change of Provider name from celtel to Airtel" [Undecided,New] https://launchpad.net/bugs/912728
<vibhavp> I need to make debdiffs for them?
<cyphermox> well, it's not quite a patch it seems, but fixing that up should be simple enough :)
<cyphermox> debdiff, or fix the patch directly as a patch and send it to the upstream bug tracker (GNOME, in the NetworkManager project)
<cyphermox> I prefer option 2, since we usually just sync the package from Debian directly
<vibhavp> Ill report a bug in the GNOME BTS, right?
<cyphermox> yes
<vibhavp> alrighty
<cyphermox> bonus points if you fix the "patch" included in the LP bug report to make it a real patch to add to the upstream bug :)
<vibhavp> Ah, I understood
<vibhavp> He copied the entire file
<cyphermox> yeah
<vibhavp> thats easy
<vibhavp> The component will be general, right?
<cyphermox> yes
<vibhavp> And the version is "0.9.x"
<vibhavp> Done, attaching patch
<vibhavp> cyphermox: Done
<vibhavp> https://bugzilla.gnome.org/attachment.cgi
<vibhavp> oops :)
<vibhavp> cyphermox: https://bugzilla.gnome.org/show_bug.cgi?id=673180
<ubottu> Gnome bug 673180 in general "Change of Provider name from celtel to Airtel" [Normal,Unconfirmed]
<cyphermox> ok
<cyphermox> have you also linked the bug report in launchpad? you should be able to add that link via "Also affects project"
<vibhavp> done
<cyphermox> thanks
<vibhavp> next!
<cyphermox> vibhavp: yeah, let's just move to pm so as not to disrupt here :)
<vibhavp> sure
<pitti> doko: hm, should gccgo-4.7 really produce the gcc-4.7-base, fortran, and other packages as well?
<doko> pitti: ugh, does it?
<pitti> doko: spotted in https://launchpad.net/ubuntu/precise/+queue?queue_state=0
<pitti> doko: and from apt-cache showsrc gccgo-4.7 | grep ^Binary
<doko> pitti: no, will fix it
<pitti> doko: thanks
<pitti> doko: probably needs another gcc-4.7 upload then, so that the binaries of that have a higher version?
<doko> pitti: there is no gcc-4.7 in precise
<pitti> doko: oh right; apt-cache showsrc gcc-4.7 actually shows gccgo-4.7, sorry
<pitti> doko: so these will/shoudl just become NBS, I figure
<doko> yes
<pitti> doko: the libraries are a bit more tricky then
<pitti> e. g. lib32stdc++6 is currently built by gccgo-4.7
<pitti> but ought to be from gcc-4.6
<arges> Hello. Trying to apply an upstream patch for 'nss-pam-ldapd', I see that this package is primarily imported from debian and in fact i don't see a debian/patch directory. not sure how to approach a fix for this bug... do i need to submit something to debian first? or  should I create the patch directory in ubuntu?
<doko> pitti: wait, is this already in the archive?
<SpamapS> @pilot in
* udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: SpamapS
<pitti> doko: NEW only has the armhf binaries, I didn't check the others
<apw> cjwatson, am i right in saying that if you add a machine to the blacklist then linux_gfx_payload=text _and_ we stop supplying handoff ?
<pitti> doko: ah, i386/amd64 FTBFSed
<pitti> doko: so let me quickly reject the armhf binaries before someone accepts them, ok?
<slangasek> mdeslaur: what's "a few"?  The only one on my radar is the TLSv1 autodetection problem; if there are other bugs, could you point them out / set the bug importance?
<doko> pitti: yes please
<pitti> doko: hang on, it's probably less bad than I thought -- Binary: shows them all, but it seems they are not actually built
<pitti> doko: https://launchpad.net/ubuntu/+source/gccgo-4.7/4.7.0-0ubuntu1/+build/3368176
<slangasek> dupondje: no, I haven't ever been able to reproduce that bug yet
<pitti> doko: it still has gobjc and fortran, shoudl it?
<doko> pitti: no
<pitti> doko: ok, rejected
<pitti> doko: thanks for looking into it
<mdeslaur> slangasek: I duped  one, the others that I thought were dupes look unrelated once I looked at them carefully.
<cjwatson> apw: sorry, head in something else right now, is that what the code implies?
<apw> cjwatson, s'ok we'll work it out
<cjwatson> apw: AFAICS it doesn't delete vt.handoff=7 from the kernel command line in that case, merely doesn't load video modules in GRUB
<cjwatson> that was what I interpreted you as arguing should change in our conversation yesterday
<apw> cjwatson, that might be counter to what i was expecting ... yeah interestingly this is a second case where handoff is an issue, due to bad drivers; though the jury is out as the testing is not yet done correctly
<cjwatson> it's basically the same as yesterday's case
<cjwatson> as far as any fix is concerned anyway
<apw> cjwatson, concur, any fix would be the same.  either i need to check if you did leave me in graphics mode and ignore handoff if you did not, or grub needs to tell us what it did do
<apw> though why its an issue today and not all last cycle i am most confused by
<Daviey> didrocks: hola, sphinx/1.1.3+dfsg-2ubuntu1 seemed to lack dh python2 transition, or still depend on python-support.
<Daviey> didrocks: it's depwait.
<didrocks> Daviey: hey, weird, I built it here IIRC
<didrocks> Daviey: I'll have a look if you wish (probably Monday though)
<cjwatson> didrocks: your build chroot probably has universe enabled
<didrocks> cjwatson: yeah, should be why I didn't spot that
<didrocks> anyway, I'll fix it if that can wait on Monday, still some stuff to end before the week-end
<Daviey> didrocks: someone might beat you to it :)
<slangasek> apw, cjwatson: is there a bug number for that discussion, by chance?  it probably has bearing on half a dozen plymouth bugs, so I'd like to know what's going on :)
<didrocks> Daviey: TBH, I won't be upset by that :)
<cjwatson> slangasek: I asked apw to file one but haven't checke
<cjwatson> d
<apw> slangasek, the disucssion was in the context of an ongoing bug with not seeing the encrypted password prompt for an lvm encrypted root setup, in the first instance
<apw> slangasek, LP#942846
<mpt> ev, bug 794757
<apw> slangasek, the new one is not yet a bug as far as i know, its with hwe
<ubottu> Launchpad bug 794757 in update-notifier (Ubuntu) "Mysterious "System program problem detected" prompt" [Medium,Triaged] https://launchpad.net/bugs/794757
<ev> mpt: cheers
<slangasek> apw: right, is that the "it shows up if you double-tap esc" bug that I kicked your way this week?
<slangasek> (bug #966403)
<ubottu> Launchpad bug 966403 in linux (Ubuntu) "Lubuntu Install (entire disk with encryption) doesn't prompt for disk password." [High,Confirmed] https://launchpad.net/bugs/966403
<slangasek> or a different one?
<apw> slangasek, that would be the same symptoms by the sounds of it.  what graphics do they have ?
<slangasek> apw: nouveau
<slangasek> but that's booting *with* splash
<apw> slangasek, ok so that sounds like what rtg found when he was trying to reproduce it
<slangasek> + vt.handoff
<slangasek> so my analysis was that this was a behavior change in the nouveau driver since last cycle, because I don't think anything else pertinent has changed that would cause tihs
<slangasek> this
<apw> slangasek, yeah, i wish i had somethign which reproduced it so i could reproduce it
<apw> erm, or something ... all the boxes i have tested just work
<slangasek> including nouveau ones?
<apw> i have no nvidia kit here, i am waiting on my radeon to install now
<slangasek> ok
<apw> to try and reproduce this same issue
<slangasek> note that radeon and intel by default use the drm interface directly, nouveau is set to use /dev/fb due to historical hangs with multimonitor
<slangasek> so to entirely reproduce this you'd have to bodge the driver somehow
<apw> slangasek, i wonder if we could switch it over to drm as an experiment
<slangasek> there's a plymouth option (Ubuntu specific) to force it
<slangasek> so we could ask people to test with that
<apw> slangasek, what is that so i can get rtg to test with it also
<slangasek> apw: sorry, OTP now - it's obvious from the plymouth source package patches, otherwise I can look it up for you in a second
<apw> slangasek, no problem will look
<apw> slangasek, plymouth:force-drm
<apw> slangasek, ok that didn't help rtg though he was able to use ESC ESC to fix thigns
<apw> slangasek, what does plynouth do on esc ... switches back to normal text mode right and back to splash again
<slangasek> apw: correct
<apw> dammit now the cd writer thing just explodes
<jodh> slangasek: https://bugs.launchpad.net/plymouth/+bug/553745/comments/183
<ubottu> Launchpad bug 553745 in plymouth (Ubuntu Maverick) "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events()" [High,Triaged]
<cjwatson> coo
 * apw is pleased to find brasero still works ... oneone know what the 'CD Writer' thing is called which pops up by default so ic an file a bug ?
<bkerensa> audiojack stopped working since B2
<bkerensa> :(
<hallyn> @pilot in
* udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: SpamapS, hallyn
<bkerensa> diwic:  ping
<slangasek> jodh: huzzah! \o/
<stgraber> jodh: yay! (apparently slangasek and I just saw the same bugmail ;))
<jodh> slangasek/stgraber: progress at last!
 * jodh heads off to sniff out a cold beer...
<slangasek> jodh: though I wish you hadn't merged those bugs, I'm now drowning in bug mail ;)
<micahg> cjwatson: if I get board over? the weekend, mind if I upload aptitude
<micahg> s/board/bored/
<cjwatson> micahg: too late
<cjwatson>   Uploading aptitude_0.6.6-1ubuntu1_source.changes: done.
<micahg> cjwatson: ooh, good to hear :)
 * micahg was seeing the natives getting restless
<cjwatson> not that it entirely fixes the multiarch bugs, so I haven't closed the one that's on rls-p-tracking
<cjwatson> but at least they won't be getting restless at me :P
<slangasek> cjwatson: does it fix it well enough that we should un-track the bug now?
<cjwatson> I don't know, I'm not enough of an aptitude user to be qualified to say
<cjwatson> (IOW I find its interface incomprehensible anyway and have a hard time saying when it's less incomprehensible)
<cjwatson> I've commented on the bug, and given its activity level I expect we'll hear from affected users soon enough
<astraljava> Oohh... aptitude having multiarch support?
<astraljava> Schweet!
<cjwatson> ish, see what I just said
<astraljava> Well yeah, but something is better than nothing. :)
<raffa50> hello
<raffa50> how can i insert a new mime type?
<hallyn> ppetraki: cjwatson: lp:~psusi/ubuntu/precise/multipath-tools/fix-dmraid  splits multipath-tools-boot into kpartx-boot for dmraid.  WOuld that require seed changes to not break installs?
<hallyn> (since you were just dealing with that...)
<raffa50> example: i made an application  (that you can install whit a .deb) that makes a .slyproj file, but the user should open it whit double click
<raffa50> (whit double click on .slyproj my application should open)
<raffa50> sorry for my bad english i'm italian and i'm making ad IDE
<hallyn> raffa50: check the comment at top of /etc/mime.types - i think it's relevant
<raffa50> where?
<hallyn> (in other words, see the mime-support package, and email that list if you want something added)
<hallyn> on your system...
<raffa50> ah root dir
<hallyn> head -40 /etc/mime.types
<hallyn> i'm surprised, i'd have expected an /etc/mime.types.d that gets included from ~/.mimetypes at least
<raffa50> .deb can't add my mime type to the user?
<hallyn> if the user already exists, yes
<raffa50> i made an ide
<raffa50> that creates a file
<raffa50> whit extension .slyproj
<raffa50> ok?
<hallyn> yes
<raffa50> i want that the user can open it
<hallyn> yes
<raffa50> whit double clik
<hallyn> yes
<raffa50> it is possible?
<hallyn> as the comment says, you can add the entry to ~/.mime.types
<hallyn> all i'm saying is that if you then create a new user after installing tha tpackage, that user won't get that .mime.types automatically
<hallyn> i wonder if there is another, file-manager-specific, way
<raffa50> not me
<raffa50> an user that download
<hallyn> raffa50: might ask in #ubuntu-desktop
<raffa50> myu program
<cjwatson> hallyn: it doesn't need seed changes if there's a dependency.  I haven't checked whether that's so
<raffa50> no way!
<hallyn> it adds a dep from multipath-tools-boot to the new kpartx-boot, yes
<hallyn> thx
<jodh> slangasek: yes, sorry. In fact bug 553745 now seems totally unviewable :(
<ubottu> Launchpad bug 553745 in plymouth (Ubuntu Maverick) "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events()" [High,Triaged] https://launchpad.net/bugs/553745
<slangasek> jodh: yes, that's also part of why I didn't bother merging the bugs ;)  Good thing you now have all the info you need in order to fix it ;)
<smoser> pitti, wonder how valid you think this bug is
<smoser> bug 969462
<ubottu> Launchpad bug 969462 in postgresql-9.1 (Ubuntu) "fails to start after install if invalid locale is set" [Undecided,New] https://launchpad.net/bugs/969462
<cnd> bdmurray, is it possible to do a search of unmilestoned bugs?
<bdmurray> cnd: could you elaborate a bit?
<cnd> bdmurray, I can search for all bugs for utouch-grail
<cnd> or bugs against specific milestones
<cnd> but how do I search for bugs that haven't been milestones
<hallyn> @pilot out
* udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: SpamapS
<bdmurray> cnd: I think you'd have to iterate through all bugs and make sure they don't have a milestone
<cnd> ugh
<cnd> bdmurray, ok, thanks :)
<bkerensa> pitti: Do you by chance know of any updates that got pushed today that could have caused headphones not be sensed or broken alsa?
<bkerensa> pitti: I just see you have done some work with those packages and my audio is gone and debugging is not doing a thing for me.
<broder> any AAs around willing to accept the mosh backports from binNEW?
<hallyn> cyphermox: around?
<cyphermox> yes
<hallyn> cyphermox: great! :)  I was wondering, on libnl-3-dev vs libnl-dev,
<cyphermox> libnl-3-dev is libnl 3.2.3; libnl-dev should be libnl 1.something
<hallyn> cyphermox: why /usr/include/libnl/netlink instaed of /usr/include/netlink? is that so both pkgs can be installed?
<hallyn> cyphermox: new libvirt just #includes <netlink/msg.h>, so won't build with just libnl-3-dev...
<cyphermox> not really, I think upstream just changed it
<hallyn> that's not very nice :)
<cyphermox> hallyn: should still build, I think libnl-3-dev is supposed to give you the right includedir
<hallyn> didn't on my test rig
<hallyn> i had to symlink the dir
<cyphermox> shouldn't be required, see /usr/lib/pkgconfig/libnl-3.0.pc
<cyphermox> I think there may be an issue with cflag paths
<cyphermox> actually, come to think of it, I believe I may have an email about this kind of issue from the debian maintainer, let me check
<dylan-m> Hey, can anyone give me a hint for when Precise's new desktop background is going to appear?
<cyphermox> nevermind, it was for ipvsadm
<hallyn> cyphermox: ok, so it *should* "just work"
<cyphermox> hallyn: should, but it's not unheard of that projects don't use pkgconfig files :)
<hallyn> i would think libvirt does.  it ships its own anyway :)  not that i have any idea how to use those
<cyphermox> hallyn: is this failing with what's currently in the archive or are you working on another branch?
<hallyn> upstream git definately.  I don't *think* I had a problem with what's in the archive, and at any rate the buildd built one fine last night
<cyphermox> hallyn: do you have a branch I could play with, or at least logs from the failure? I'm pretty sure you'd see the issue from the log
<cyphermox> (and then looking at Makefile to see what the value for LIBNL_CFLAGS is, if any)
<hallyn> cyphermox: I'm afraid not right now.  It's on a box that's shut down atm.  Can I ping you monday after i push it somewhere?
<cyphermox> hallyn: certainly. Or I'll mess around with it during the weekend
<cyphermox> if it's from git, I'm pretty sure you'll get the same behavior just building directly from the git tree
<hallyn> cyphermox: no, they're on libnl1 still, so we have to convert to libnl-3 with some patches from our tree
<Darxus> Does precise really not have the Gtk3 perl module, or am I just not finding it?
<cyphermox> hallyn: ah, I see
<cyphermox> so the libnl-3 patch probably doesn't correctly apply for that new version
<hallyn> yeah, that could be.  so it's my fault :)
<hallyn> cyphermox: ok, thanks.  That just may give me all the guidance I need :)
<hallyn> have a good weekend
<cyphermox> hallyn: np. feel free to ping anytime, I'll be home and not far from a computer anyway.
<SpamapS> @pilot out
* udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
#ubuntu-devel 2012-03-31
<adam_g> is there some way to work around the maintainer-script-needs-depends-on-adduser lintian error, if the packages its pointing at all depend on a common package, which has adduser as a Depends?
<adam_g> or should adduser be moved to each package in question instead of defining globally, to shut lintian up?
<slangasek> adam_g: there's a way to shut lintian up, but I would argue it's simpler to just comply
<cjwatson> adam_g: I would in general argue that direct use should imply direct dependency
<psusi> is there something more that bug #941874 needs to make sure it's on the radar as a critical regression that needs fixed before precise is finalized?  like a milestone target?
<ubottu> Launchpad bug 941874 in multipath-tools (Ubuntu) "(fakeraid) root device not activated during boot" [Critical,In progress] https://launchpad.net/bugs/941874
<infinity> psusi: Sure, I'll milestone it. :P
<infinity> psusi: You could just fix it instead! ;)
<psusi> I have, just waiting for a sponsor to merge
<infinity> Ah, so I see.
<infinity> I'll have a look at it in a bit, then.
<infinity> psusi: Are you around for a bit tonight, in case I have questions?
<psusi> infinity, sure
<infinity> psusi: Alright.  I'll poke it later tonight.  If you decide to go have a life instead, I'll either sponsor or leave feedback on the bug, as appropriate.
<psusi> hehe... never can tell with a new baby
<infinity> ;)
<infinity> Congrats.
<psusi> ty
<bitplane-> Hi, I was bored and decided to try fixing one of the bugs on the tracker. I decided on a seemingly simple one, the text size in notify bubbles being wrong
<bitplane-> I have a stupid question though... there's debug statements in the code, how would I normally activate them? do I have to go and tell g++ to compile with DEBUG defined, or is there a better way?
<infinity> bitplane-: If you're talking about the code having something like DEBUG("foo") in it, find the declaration of DEBUG and see what it does.
<infinity> bitplane-: Odds are that it keys off a magic environment variable being set, or the program being run with --debug.
<pkh> i'm running a machine on 12.04 and the last few kernel updates have failed to find my network driver. i'm wondering what I should do wrt to reporting that.
<pkh> #ubuntu-kernel
<broder> slangasek: can you or possibly somebody else from foundations look into/fix bug #941867? i would but i'm not going to have time in the next few weeks (starting a new job on monday)
<ubottu> Launchpad bug 941867 in insserv (Ubuntu) "after upgrade to 1.14.0-2.1ubuntu0.1 0 dpkg --configure ror" [Undecided,Confirmed] https://launchpad.net/bugs/941867
<PaoloRotolo> Hi al!
<PaoloRotolo> all*
<georgelappies> hi all, I am using 12.04 I am getting random crashes to a terminal like screen were I have to hard reboot the laptop. this never happened in any of the prior ubuntu releases. Is there a known issue at the moment?
<kklimonda> georgelappies: hard to say, I'm not seeing this problem
<kklimonda> georgelappies: if X is crashing it should ask you to upload the report to LP
<georgelappies> kklimonda: it does look like X, i tried ATI proprietary drivers as well but the crash still happens...
<georgelappies> kklimonda: where could the log files be that would indicate the source of this bug? can I somehow enable logging?>
<kklimonda> georgelappies: if it crashed you should get a log in /var/crash
<georgelappies> kklimonda: if it is not in /var/crash does it mean that maybe the kernel crashed and not X?
<kklimonda> georgelappies: ah yes, that's also possible (I think I misread your question)
<georgelappies> kklimonda: is their log files the kernel writes to on a crash?
<kklimonda> georgelappies: I'd try to ask people on #ubuntu-x in that case during week, they have more experience debugging such issues
<kklimonda> georgelappies: you can check /var/log/syslog and /var/log/syslog.1
<kklimonda> if computer hasn't completely locked up there is a chance that something ended up there
<georgelappies> kklimonda: thanks, will do ;)
<slangasek> broder: yeah... sorry, I had foreseen that as a possible issue when reviewing your patch but had assumed nobody would have a *partially* fixed system in this way
<Spartan29> hallo!
<Spartan29>  I've a trouble. I can't share files from linux to windows, files are in a folder of an NTFS partition mounted on boot time. What i see is that i can't change folder and than in it contained files. Can someone help me?
<juliohm> Someone could reproduce the bug? https://bugs.launchpad.net/ubuntu/+source/procps/+bug/965341
<ubottu> Launchpad bug 965341 in procps (Ubuntu) "watch command line utility crashes with segfault when processing binary output" [Undecided,New]
<juliohm> How are launchpad bugs triggered? There are days since i reported the bug and stills undecided state.
<penguin42> juliohm: It relies on someone triaging it - there are lots of bugs, so it's a matter of time available and luck, it depends on the package as well and if someone tries it
<astraljava> juliohm: They are not automagically handled, except for some simple cases. They need to be triaged in order to progress. More info on #ubuntu-bugs channel.
<juliohm> Understand, just wondering because that was my first report to launchpad. I was thinking the community was more active in the sense that the bug is easily reproducible. In other track systems i've reporting bugs, the state is decided pretty fast.
<penguin42> juliohm: Until someone looks at it, they don't realise it's so easy to reproduce!
<juliohm> penguin42, oh, i was thinking people is notified in their mail box with some kind of summary of what the bug is about. :-)
<juliohm> Anyways, thank you for take the look. ;-)
<penguin42> juliohm: Some people will be, but they just get zillions of notifications; so they pick off stuff which is affecting lots of people or causing major panics and occasionally get around to looking at the rest
<juliohm> I can imagine a lot of notifications, one more reason why i have to make a post about how to contribute in launchpad. Do you have some nice blog post about contributing with Ubuntu on Launchpad?
<penguin42> juliohm: possibly https://help.ubuntu.com/community/ReportingBugs   although it doesn't say much about what happens next
<juliohm> penguin42, that one i already know
<juliohm> But i'm talking about the launchpad features, the daily activities of a Ubuntu-bug-reporter
<penguin42> juliohm: there is a #launchpad that may help somewhat - but that's the mehcanics of the system more, #ubuntu-bugs is perhaps a better place to ask about that, and see the info on bugsquad and bugcontrol
<penguin42> any libc standards lawyers about - juliohm's bug seems to be isprint segfaulting when passed invalid input - I just don't know whether it's correct for it to do that
<juliohm> ok, thanks penguin42 , i'll ask in the appropriate channel. ;-)
<juliohm> penguin42, the bug with watch is not just a print in the binary file, because watch is interactive, it should hang until a Ctrl+c
<penguin42> the manpage for isprint and friends says 'These functions check whether c, which must have the value of an unsigned char or EOF, ....' - is it reasonable for it to seg if the value isn't an unsigned char or EOF?
<juliohm> for me, segfault is always a bug
<penguin42> juliohm: The question is whether the bug is in watch or the C library
<juliohm> independently of the program.
<juliohm> oh
<juliohm> I don't know.
<cjwatson> the behaviour of isprint is undefined if it is passed something other than a value representable as an unsigned char or EOF; undefined behaviour includes the potential to segfault
<cjwatson> (C99 7.4 para 1)
#ubuntu-devel 2012-04-01
<Yick> Is there anyone here works in the IT department ?
<cjwatson> however it is not entirely clear to me from the comments in that bug that the segfault is in fact within isprint
<penguin42> cjwatson: Cool, so I think that bug 965341 is that it should be using iswprint
<ubottu> Launchpad bug 965341 in procps (Ubuntu) "watch command line utility crashes with segfault when processing binary output" [Medium,Triaged] https://launchpad.net/bugs/965341
<penguin42> cjwatson: comment #3 from me ?
<cjwatson> I don't see how isprint could be getting inlined into main
<cjwatson> that comment shows the segfault in main, afaics
<penguin42> yeh that's what the backtrace is showing - I'd thought the isprint and friends were macros or the like
<juliohm> i'm also curious how penguin42 inferred about isprint() from the actual bug.
<cjwatson> they might be implemented as macros, true
<juliohm> oh, strace :-)
<cjwatson> juliohm: he correlated gdb's output against the source code
<juliohm> oh, not strace, gdb output, nice.
<cjwatson> yeah, isprint is a macro that expands to an array lookup
<cjwatson> if the value is out of bounds then it might well segfault
<penguin42> cjwatson: Yeh, see ctype.h - it's a macro to __isprint that ends up indexing __ctype_b_loc that's 384 bytes long ish
<Yick> Is there anyone here works in the IT department ?
<Yick> Is there anyone here works in the IT department ?
<cjwatson> not necessarily iswprint, it might also be correct to simply check that c is representable as unsigned char before passing it to isprint
<cjwatson> Yick: please don't repeat without adding further context.  Why do you want such a person?
<cjwatson> (whose IT department?)
<Yick> any IT department. Want to know anyone has connection to Microsoft.
<penguin42> cjwatson: However I'm a bit uncomfortable saying it just needs a change from isprint to iswprint since I don't understand the wide character stuff it's wrangling with; it does have a && c<128 *after* the !isprint(c) - but I think it needs a little more understanding
 * penguin42 checks the date - oh yeh
<cjwatson> penguin42: judging from the c<128 check, it isn't really interested in wide characters; I would say just  !isprint(c) && c<128  =>  c<128 && !isprint(c)
 * juliohm is curious about the details of following the execution of the watch command in gdb for backtracing the bug and fix it
<cjwatson> juliohm: it prints a line number when the program crashes, so it's pretty easy to look up from there (in this case)
<cjwatson> for the rest, man gdb :-)
<penguin42> cjwatson: Yeh, the code seems to be trying to detect wide characters and set a 'carry' variable to indicate it should fetch the next byte - and I think that's probably still OK
<penguin42> juliohm: I installed the procps debug sym package, I then ran gdb `which watch` and then ran it in gdb with your args
<juliohm> cjwatson, so, you have to download the source code first, right?
<cjwatson> juliohm: yes, of course
<penguin42> juliohm: Then I grabbed the source (using apt-get source procps) and looked for line 541
<cjwatson> debugging programs without source code is no fun
<juliohm> hmm, very interesting.
<juliohm> let me try now, because maybe i can help in the future
<juliohm> penguin42, what do you mean by procps debug sym package? is just the procps package?
<penguin42> juliohm: Then I looked at that line and thought there's nothing that should seg fault, printed c, noticed it was HUGE, and wondered about isprint since I'd implement it using an array
<cjwatson> hmm, mind you, isprint on a wint_t is a kind of dodgy thing to do
<penguin42> juliohm: https://wiki.ubuntu.com/DebuggingProgramCrash
 * juliohm is reading the link...
<penguin42> cjwatson: Well, it does take an int (to allow EOF)
<cjwatson> penguin42: sure, but technically, nothing in the standard requires int == wint_t
<penguin42> nod
<cjwatson> penguin42: I think your first instinct was correct and it should be iswprint
<cjwatson> assuming that tests out
<penguin42> cjwatson: What worries me is that at that point it would have the first half of a wide character and then passing that to iswprint also makes no sense
<cjwatson> penguin42: how so?  my_getwc appears to read a whole wide character
<cjwatson> or WEOF
<cjwatson> penguin42: in any case, I think the important thing is that iswprint does *not* have a range of values specified as undefined behaviour
<cjwatson> oh no that's not true
<cjwatson> "For all functions described in this subclause that accept an argument of type wint_t, the
<cjwatson> value shall be representable as a wchar_t or shall equal the value of the macro WEOF. If
<cjwatson> this argument has any other value, the behavior is undefined.
<cjwatson> "
<cjwatson> still, my_getwc always returns something that meets that description, I think
<cjwatson> given that it always returns either rval (which is a wchar_t and gets implicitly converted) or WEOF
<penguin42> cjwatson: I'd be more comfortable if I understood what the heck that loop was actually trying to do
<cjwatson> I haven't bothered to work it out but I'm confident in my statement that iswprint should never segfault in this case from dataflow analysis alone :)
<cjwatson> it's some tedious display mangling, doesn't seem terribly interesting to work out the exact details
<penguin42> yeh, I'm just not sure it does what the oriignal code was supposed to
<cjwatson> well, the while condition basically asks for a non-printing character under 128 that isn't newline, tab, or (sometimes) esc; so promoting to iswprint for type compatibility doesn't seem to break anything there
<penguin42> and my_getwc blows my mind - I can't see how it's while loop ever executes more than once given that it always returns in one of two ways
<cjwatson> everything that manipulates c is typesafe
<penguin42> oh, the if isn't indented - ok, I see how my_getwc works
<cjwatson> penguin42: it just has rotten indentation
<cjwatson> yeah, the last return is conditional on 'byte == MAX_ENC_BYTES'
<cjwatson> but again, I think you just need to verify that it always returns a promoted wchar_t or WEOF
<cjwatson> which is pretty clear
<cjwatson> it's fairly grotty code but just stick to analysing the bits you need and it's ok
<penguin42> yeh, and so my_getwc either a valid WC, a WEOF on an EOF< or WEOF on a bad char, then I think I agree iswprint should work
<cjwatson> the one thing I'd note is the FORCE_8BIT bit at the top of the file, which may or may not be obsolete now
<cjwatson> although leaving it there wouldn't actually hurt anything
<penguin42> yeuch
<juliohm> penguin42, thank you very much for the link, it's really helpful. ;-)
<juliohm> I'll try the process when i have time.
<penguin42> cjwatson: The code there comes from one of the debian patches
<penguin42> cjwatson: watch_unicode.patch
<cjwatson> yep
<cjwatson> is that a big deal?
<penguin42> I was just wondering if it was a debian patch or an ubuntu patch, but I think it's a debian one
<cjwatson> looks like it
<penguin42> nod
<penguin42> cjwatson: Is the right thing there to add another patch to the end of the set or to fix that patch?
<cjwatson> judgement call in general - in this case I'd probably fix that patch
<penguin42> ode for a 1 character tweek
<cjwatson> though I wouldn't reject a branch that added another one, I guess
<cjwatson> but yeah, seems overkill
<penguin42> actually it needs one of the other patches tweeking as well because that is diff'd against it
<cjwatson> quilt push; quilt refresh your way up the stack
<cjwatson> but basically trivial
<penguin42> I could look at that tomorrow, but it's rather late now, and I can't actually remember any of teh quilt foo
<cjwatson> if you've tested a patch and confirmed it works, feel free to just attach it to the bug and I can take care of the packaging
<cjwatson> but you might want the learning experience and if so I don't want to deprive you either :)
<penguin42> I'll look tomorrow, or should I say at 1:37 am later today
<penguin42> right, bed!
<YokoZar> https://launchpad.net/ubuntu/precise/+queue  :D
<infinity> YokoZar: Yeah, I'm trying to decide if that was a joke. :P
<infinity> YokoZar: Do I review it or reject it?
<YokoZar> infinity: Review it of course, it fulfills its stated purpose ;)
<infinity> Oh dear...
<infinity> Oh, derp.  April 1.
 * micahg is curious if a second person signed off on it
<jhojho> cjwatson: see that you have been updating openssl. could you add the elliptic curve compile flag for 64bit for the next round? thx.
<cjwatson> jhojho: no, I haven't got round to talking with the Debian maintainer about it yet
<Whoopie> cjwatson: Hi, could you perhaps sponsor another package?  -> mail-notification, bug 881039
<ubottu> Launchpad bug 881039 in mail-notification (Ubuntu) "mail-notification-evolution only contains files in /usr/share/doc" [Undecided,Confirmed] https://launchpad.net/bugs/881039
<cjwatson> Whoopie: not right now, need to go out
<Whoopie> cjwatson: ok
<Whoopie> have fun
<cjwatson> I can look later if nobody beats me to it
<Daviey> Whoopie: you might find that some sponsors are unwilling to upload, without a Firstname Lastname in debian/changelog.
<Whoopie> Daviey: might be. Even though I see a lot of packages with the same "issue".
<infinity> Whoopie: It's not terribly common for people to upload with a real name.
<infinity> Whoopie: But if the code's good, I don't care deeply either.
<nigelb> ZarroBoogs: awww <3
<PaoloRotolo> Hi all!
<hallyn> tjaalton: hey, i thought i'd seen a push of xserver-xorg-video-qxl go by, but I don't see it in the archive?
<hallyn> (maybe I mis-read a subject and it was another xserver-xorg...)
<tjaalton> hallyn: you think we can just sync it? I mean it probably needs an FFe bug just to be on the safe side :)
<hallyn> tjaalton: I don't know, since Munzir hasn't responded I guess I will try installing kubuntu in a guest tomorrow and see if I can (a) reproduce the bug and (b) see it fixed with the new version.
<hallyn> tjaalton: if it doesn't explicitly fix a bug, then you might be right we should file ffe.
<hallyn> guess it coudln't hurt to file ffe anyway, and then comment there if it fixes a bug
<hallyn> (really, spice should be seen as a tech preview right now)
<tjaalton> hallyn: I don't see any bugs open against -qxl, so this was something reported on irc?
<hallyn> tjaalton: bug 913314
<ubottu> Launchpad bug 913314 in xserver-xorg-video-qxl (Ubuntu) "Corrupted display with Spice" [High,Fix released] https://launchpad.net/bugs/913314
<hallyn> after confirmation of the fix of original bug, he lists a few other things still going wrong.
<tjaalton> ah, ok
 * penguin42 looks up
<JamesJRH> Is it possible for me to obtain a correct source of TAI from my system if I keep it in sync?
<JamesJRH> Implementing TAI on top of UTC relies on UTC being correctly implemented. But Ubuntu seems to ignore leap seconds in it's implementation of UTC.
<mamemame187> hello
#ubuntu-devel 2013-03-25
<ninjaaron> Is Mir going to use libxkbcommon for handling input stuff?
<ninjaaron> keyboard input, I should say.
<xnox> ninjaaron: try #ubuntu-mir channel.
<ninjaaron> xnox: thanks. will do.
<pitti_> Good morning
<dholbach> good morning
<fishor> hallo all, is it good time to discuss replacement for gnome-media packet? I talked about it with mitya57 and he suggested to do it today with more devs
<dholbach> doko_, do you have an idea what http://paste.ubuntu.com/5645704/ might be about? (or anyone else really?)
<pitti> @pilot in
<dholbach> ah ok, it's http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703872
 * dholbach hugs pitti
<ubottu> Debian bug 703872 in python2.7 "python-reportbug:NameError: global name 'Chrome' is not defined" [Normal,Open]
<ev> mpt: what's something you want in the error tracker that I and bdmurray wont have time for? :) I'm willing to sponsor someone for Summer of Code: https://wiki.ubuntu.com/GoogleSoC2013/Ideas
<mpt> ev, collecting the kinds of errors you've been meaning to collect since 12.04 but haven't had time for: hangs, debconf prompts, Ubuntu installation failures
<mpt> ev, implementing the "Send a report automatically if a problem prevents login"
<mpt> Implementing "Show Previous Reports"
<mpt> Implementing "What's unusual about this error"
<mpt> ev, and on the site, filtering by package set (-proposed, Ubuntu Server, Kubuntu, etc)
<ev> mpt: cheers!
<ev> mpt: https://wiki.ubuntu.com/ErrorTracker/SummerOfCode2013
<cjwatson> mpt: -proposed isn't a package set, FWIW
<cjwatson> It should be orthogonal to things like Ubuntu Server, since it would be useful to be able to search for errors in server-related packages that are still only in -proposed
<pitti> doko: do you want to look at https://code.launchpad.net/~mitya57/ubuntu/raring/python3-defaults/3.3.0-3ubuntu1/+merge/154723 yourself, or want me to review/upload?
<pitti> doko: same question for https://code.launchpad.net/~mitya57/ubuntu/raring/python-defaults/2.7.3-10ubuntu6/+merge/152592
<pitti> cjwatson, infinity, lan3y: can you please hint udev to propagate to raring, to unbreak everyone's ACLs? it's stuck because of chromium armhf again
<pitti> seb128: ^ FYI
<jamespage> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage
<cjwatson> pitti: that's odd - since chromium was already broken, why did the new udev make it worse?
<cjwatson> or did somebody fix chromium/armhf?
<pitti> cjwatson: I wouldn't know -- perhaps it stumbles again over the libudev0 removal?
<cjwatson> oh, yeah, that could be
<pitti> no, there hasn't been a chromium upload
<pitti> at least update_output complains about libudev0
<pitti> it certainly doesn't make it worse, though; it just remains NBS
<cjwatson> hinted
<mpt> cjwatson, true, true. But better to be able to filter by either and not both, than by none. :-)
<pitti> cjwatson: cheers
<cjwatson> mpt: oh, certainly.  I just find getting terminology straight from the start can be helpful later
<cjwatson> or at least categories :)
<jibel> doko, could you look at bug 1159636
<ubottu> bug 1159636 in python2.7 (Ubuntu) "python2.7 failed to import webbrowser: NameError in register_X_browsers(): global name 'Chrome' is not defined - Regression in 2.7.4~rc1-2ubuntu1" [High,Confirmed] https://launchpad.net/bugs/1159636
<seb128> pitti, the new udev fixes my intel card
<seb128> thanks
<pitti> seb128: thanks for testing; cjwatson hinted it, so it should go into raring RSN
<seb128> great
<jamespage> jibel, I just hit that as well
<pitti> sorry, I thought I unbroke that for the weekend
<pitti> I wasn't aware it would be stuck in -proposed
<pitti> popey: ^ that will also fix your bug
<seb128> pitti, no worry, we don't pull systemd-services in by default yet so I doubt many people got bitten (out of desktop ppa users)
<popey> i do not have systemd-services installed pitti
<pitti> popey: ok, something else then
<popey> pitti: should I file a new bug on this?
<pitti> popey: I guess so
<pitti> popey: did you verify it's the new kernel?
<pitti> popey: you can boot the previous one in grub
<popey> yes, i was missing linux-image*extra
<pitti> aah
<pitti> missing metapackages?
<popey> no, overzealous cleanup on my part i think
<pitti> popey: ah, not a bug then :)
<popey> indeed
<popey> i have two machines with the python problem though
<popey> bug 1159636 covers it I think
<ubottu> bug 1159636 in python2.7 (Ubuntu) "python2.7 failed to import webbrowser: NameError in register_X_browsers(): global name 'Chrome' is not defined - Regression in 2.7.4~rc1-2ubuntu1" [High,Confirmed] https://launchpad.net/bugs/1159636
<fishor> hallo all, is it good time to discuss replacement for gnome-media packet? I talked about it with mitya57 and he suggested to do it today with more devs
<rahulprasad> How do I contribute to manual pages ?
<fishor> short description of problem i mean. gnome-media package is dead. gst-mixer and gstreamer-profiles are deprecated/not used.  Gnome-sound-recorder is not working.
<seb128> fishor, right, we dropped gnome-media from the CD/default installation in raring
<seb128> fishor, it's unmaintained upstream and we didn't want to port it to gstreamer1.0
<fishor> seb128, i extracted gnome-sound-recorder and ported it to gstreamer1.0
<seb128> fishor, oh, nice, does it work with your version?
<fishor> upstream refused to accept patches, thay said it must die, it is too old and some
<fishor> yep
<fishor> some one started to write recorder from scratch in vala... but stopped it one year ago
<seb128> fishor, open a bug on launchpad with the patch and the reference to the upstream bug
<seb128> we can get the patch in the package
<seb128> that would still be an improvement on the current situation
<fishor> seb128, there is no more upstream bugs... i strted to work on it in my repo
<fishor> the patch will make no sense
<seb128> fishor, "<fishor> upstream refused to accept patches" ... was that a private conversation?
<seb128> fishor, ok, I don't follow you
<seb128> you have a patch that port it to gst1.0 and make it work or not?
<fishor> this conversation of on the list
<seb128> what do you suggest there?
<fishor> seb128,  https://gitorious.org/gsr/gnome-recorder
<fishor> here is my repo
<cjwatson> rahulprasad: that depends which manual pages; they're usually distributed/maintained along with other projects
<fishor> seb128, i kept sending patches.. but after porting it to gst-1.0 all other parts from gnome-media made no sense any more.. i mean it conficted with gst-1.0
<fishor> so i removed it.
<fishor> since there is nothing more in gnome-media except recorder, it makes no sense to call it gnome-media. Upstream requested at the beginning that i create clean git source without usless parts but with old logs of recorder
<fishor> i created it, but then it was declared as usless work since some body works on new recorder
<fishor> it talked with this person, he is willing to cooperate but has no time to continue his project
<fishor> the problem i had with his project is that it is in vala. I needed add new futers
<fishor> new options to recorder and to gstreamer, but it made me even more work with vala.. so i continued to work on C version of recorder
<fishor> seb128, that is my story :)
<seb128> fishor, ok, so what do you want to ask/suggest at this point? that somebody package your "forked" gnome-sound-recorder as a new source and drop gnome-media from the archive?
<fishor> seb128, yep, if you wont working recorder in raring ;)
<seb128> fishor, I would rather just apply that big patch over gnome-media
<seb128> fishor, it's a bit late to start adding new sources in the archive etc
<fishor> seb128, i'm not sure if it will apply...  i removed unneeded part from git history too
<fishor> but you can try
<seb128> fishor, well, nothing to do with git, diff -Nru old new
<seb128> that gives you a big diff that should work
<tvoss> seb128, ping
<seb128> fishor, can you open a bug on launchpad ask for your source to be packaged?
<seb128> tvoss, hey
<tvoss> seb128, I think we should reschedule the settings meeting as mpt won't be able to make it
<seb128> tvoss, did you plan to discuss UI design?
<seb128> tvoss, and will we ever find a slot where the 9 people are all available?
<seb128> tvoss, imho there is enough technical details to discuss that we can keep busy for an hour without talking pixels
<tvoss> seb128, it's less talking pixels it's more to make sure that we have collected all the relevant use-cases
<seb128> tvoss, well, lars and aruiz talk to him like daily
<seb128> I would trust them to have a good overview of the plans he has
<tvoss> seb128, okay, just want to avoid duplicating conversation
<seb128> ok, I feel like we will be able to make good use of the hour, don't worry
<seb128> there is quite a lot to discuss on the topic and we have quite some people on the call
<jamespage> pitti, are you working from the sponsors review queue as well?  just noticed your feedback on bug 1141942
<ubottu> bug 1141942 in Ubuntu "[needs-packaging] New package sphinx-voxforge-en" [Wishlist,Triaged] https://launchpad.net/bugs/1141942
<pitti> jamespage: yes, I'm currently piloting
<pitti> urgh, I did @pilot in this morning, where did the topic go
<pitti> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage, pitti
<jamespage> pitti, ditto - are you focussing on anything specifically or just working down the list
<pitti> jamespage: I don't have any particular order really
<pitti> but I guess we should coordinate now :)
<pitti> jamespage: I just uplaoded the two jackd SRUs
<jamespage> pitti, ack
<jamespage> I'm looking at the virtualbox precise SRU right now
<pitti> jamespage: "Fails to parse /etc/default/locale" also already uplaoded
<pitti> jamespage: I ignore the security updates, as I can't/don't know how to process them
<pitti> I wonder if they should really be on that page
<jamespage> pitti, yeah - so do I - it does contribute to general noise in an annoying way for sponsors
<pitti> jamespage: I'll stop now anyway, I already spent my whole morning on the queue
<jamespage> pitti, ack
<pitti> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage
<tkamppeter> OdyX, hi
<fishor> seb128, here it is : https://bugs.launchpad.net/ubuntu/+source/gnome-media/+bug/1159744
<ubottu> Launchpad bug 1159744 in gnome-media (Ubuntu) "replacment for gnome-media" [Undecided,New]
<seb128> fishor, thanks
<seb128> lunch
<seb128> be back in ~1h
<jamespage> doko, bringing you attention to https://code.launchpad.net/~mitya57/ubuntu/raring/python3-defaults/3.3.0-3ubuntu1/+merge/154723
<jamespage> doko, just in case you are working on such an update for raring.
<mitya57> pitti: hey, last time we agreed with jamespage and xnox that all linux headers in Ubuntu are automatically installed together with the kernel
<xnox> mitya57: which bug is it again?
<mitya57> also, when "linux-headers" package is installed it doesn't mean that the headers corresponding to the user's actual kernel flavour are installed (take 12.04
<mitya57> *12.04.2's backported kernel as an example)
<mitya57> xnox: the same package, pitti marked my branch as "Needs fixing"
<mitya57> the same = blktap-dkms
<mitya57> jamespage: btw, thanks for uploading virtualbox ;)
<jamespage> mitya57, np - 3.5 dkms breaks 12.04.2 are a personal hate of mine (I had to fix openvswitch and iscsitarget)
<jamespage> mitya57, did you see my comment on the bug?  really need to be tested with 3.2 kernel as well
<jamespage> as fix will land on systems with both types of kernel
<mitya57> jamespage: so number of broken packages is >= 4? not cool
<mitya57> no, I didn't see that
<jamespage> mitya57, the fix looks like it will support 3.2 - the code updates have conditions for >=3.5
<mitya57> jamespage: I believe I tested it on my sid machine which has 3.2 :)
<jamespage> mitya57, great - well it should be picked up during verfication anyway
<jamespage> I added it to the regression potential section
<ev> pitti: remind me, do you use -proposed on the Launchpad retracers? I'm seeing a problem where doing so prevents crashes from retracing when any of the dependencies come from a version earlier than whats in proposed
<ev> as apport doesn't consider proposed special and sets RetraceOutdatedPackages in that case
<ev> we could just drop the -proposed sources, but then that means we can't retrace crashes where -proposed is actually involved
<ev> hm
<jamespage> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * dholbach hugs jamespage
<jdstrand> jamespage, pitti: we believe that security updates should be on that page-- we sponsor things too and we look at that page when piloting
<jdstrand> we also have people tend to those when not piloting
<mitya57> mvo / dpm: we have been discussing bug 1159689 today in ubuntu-l10n-ru@, can you please comment on it?
<ubottu> bug 1159689 in Package Descriptions for Ubuntu "Many description, translated into russian on Launchpad, are still in english in Software Center " [Undecided,New] https://launchpad.net/bugs/1159689
<xnox> mitya57: interesting, I last generated app-install-data, but I didn't do any fetching of additional translations from launchpad. My understanding was that those translations should land in the package itself.
<mitya57> xnox: app-install-data is used only for "short" descriptions, AFAIK, "extended" descriptions should be taken from ddtp-ubuntu
<xnox> ah.... I see.
<stgraber> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber
<stgraber> (missed my shift on Friday)
<ogra_> same here ... i'll do mine towards the weekend
<DigvijayUbuntu> hello!
<DigvijayUbuntu> any ubuntu developer here?
<DigvijayUbuntu> helllo?
<ion> Just ask the question.
<ogra_> no, we calld that channel #ubuntu-devel just for fun ... we're a secret microsoft conspiracy
 * ogra_ is joking indeed ...
<ogra_> !ask
<ubottu> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<DigvijayUbuntu> ok =) I am not exactly usre, of what happen here. This irc is used fore conversation between developers? Am i Correct?
<ogra_> yes
<ogra_> for developing  the ubuntu distro (not for development on ubuntu (see channel topic))
<DigvijayUbuntu> Yes yes exactly. Now i wanted to know what would be a good way to contribute to the ubuntu distro? I read something about getting a mentor or so
<cjwatson> https://wiki.ubuntu.com/ContributeToUbuntu
<DigvijayUbuntu> Well i was on that page only. Thanks for the effort though. It says under Writing Code, Contact : Read the UbuntuDevelopment wiki page
<DigvijayUbuntu> Join the ubuntu-devel mailing list
<DigvijayUbuntu> Join the #ubuntu-devel IRC Channel on irc.freenode.net
<mpt> ev, how's the ramp-up weighting going?
<ev> still stuck in the queue
<ev> mpt: (https://portal.admin.canonical.com/ruins?team=losa - RT 60205)
<janimo> DigvijayUbuntu, that page also describes ways you can contribute. You can pick one that suits you and when you have specific questions you can use the maliing list and IRC
<cjwatson> DigvijayUbuntu: we don't typically assign people a mentor or anything - usually what happens is that sponsors review your work after you've submitted it, and if necessary advise on ways you can improve it
<DigvijayUbuntu> so I work on Ubuntu, something which would be useful or making ubuntu better. Then I submit it to a sponsor?
<cjwatson> https://wiki.ubuntu.com/SponsorshipProcess
<DigvijayUbuntu> ok thanks cjwatson =)
<jodh> xnox/stgraber: could you take a look at my packaging changes in lp:~jamesodhunt/ubuntu/raring/upstart/1.8
<stgraber> jodh: finishing a couple of reviews and some work on ssh-agent. Will take a look after that.
<jodh> thanks.
<jodh> stgraber: I'm wondering if http://paste.ubuntu.com/5646542/ would improve it further.
<dobey> who broke python?
<mitya57> dobey: ?
<dobey> mitya57: on fully updated raring run: python -c "import webbrowser"
<dobey> NameError: global name 'Chrome' is not defined
<cjwatson> dobey: bug 1159636
<ubottu> bug 1159636 in python2.7 (Ubuntu) "python2.7 failed to import webbrowser: NameError in register_X_browsers(): global name 'Chrome' is not defined - Regression in 2.7.4~rc1-2ubuntu1" [Critical,Confirmed] https://launchpad.net/bugs/1159636
<dobey> ah, thanks cjwatson
<dobey> davmor2: ^^
<mgz> ha!
<davmor2> dobey: ta
<mgz> ha, need to dupe bug 1159737 against that
<ubottu> bug 1159737 in python2.7 (Ubuntu) " Importing `webbrowser` module gives NameError in Python 2.7.4rc1 " [Undecided,Confirmed] https://launchpad.net/bugs/1159737
<ScottK> dobey: Who always breaks python?
<mgz> more to the point, how does the test suite not passing not prevent it getting in the archive...
<dobey> mgz: dep8 tests, or build time tests?
<mgz> dobey: python itself has a test that checks that "import webbrowser" works (only that though, their coverage isn't fantastic)
<davmor2> mgz: I wouldn't mind but import webbrowser fails :)
<mitya57> doko has already uploaded a fix to -proposed
<mgz> not landing things that break the packages own test suites seemed like a pretty important part of the stability work
<dobey> mgz: but is that test being run (and causing the build to fail) during the package build? or is it only being run during the dep8 tests?
<mitya57> dobey: it's not run during build, and there are no dep-8 tests :(
 * mitya57 runs away
<dobey> :-/
<bdmurray> stgraber: were you looking at a casper upload? there is a patch in bug 1159464
<ubottu> bug 1159464 in casper (Ubuntu) "make persistent storage pathnames fully configurable" [Undecided,New] https://launchpad.net/bugs/1159464
<stgraber> bdmurray: that sounds like a new feature to me
<stgraber> cjwatson: hey, so I've been working on a ssh-agent user job, which I finally got to work reliably now. I'm just wondering in what source to put it in. The equivalent Xsession script is in x11-common but I think it'd make more sense for the job to go in openssh-client. Do you agree?
<cjwatson> stgraber: Maybe.  Does it need any interaction with x11-common (disabling the Xsession script if user jobs are active, or something)?  Will installing the user job be harmful if Upstart doesn't have user job support?
<stgraber> cjwatson: the job is a user-session only job and will only start as part of an upstart-driven xsession. The job itself doesn't depend on xsession but if /etc/X11/Xsession.options exists, it'll check for the use-ssh-agent flag in there
<stgraber> cjwatson: http://paste.ubuntu.com/5646619/
<stgraber> I don't think it'd be completely wrong to have it ship in x11-common, but I think it'd look a bit weird to have an ssh-agent upstart job installed on a system that doesn't have ssh-agent itself.
<stgraber> whereas the reverse wouldn't be as weird looking as having the job on a system that doesn't use upstart user sessions, would just mean an extra unused file under /usr so not really user visible
<cjwatson> stgraber: OK.  Can I have a bug on Debian openssh-client and I'll stick it in there?
<cjwatson> I was planning on an upload soonish anyway.
<stgraber> cjwatson: sure. So should I just wait for the next sync from Debian to get it in raring?
<cjwatson> If you don't mind that
<stgraber> nope, that's fine. Do you think you'll have this done before FinalBetaFreeze? (we have a FFe for those few remaining upstart integration bits and I try to have all of those done before we start getting into the last freezes)
<cjwatson> Yep
<ev> bdmurray (and pitti in case you're curious): https://bugs.launchpad.net/daisy/+bug/1159849
<ubottu> Launchpad bug 1159849 in Daisy "We shouldn't ever mark retraces as failed." [Undecided,New]
<ev> infinity: do you know what happened with the plans to keep dbgsym packages in the librarian forever?
<bdmurray> ev: thanks
<ev> bdmurray: if you have thoughts on that one, do share :). I'm on my 3432094832097th cup of coffee today and battling lcy02 to the death, so I do not doubt that I might be talking rubbish.
<jodh> ev: have you just overflowed?
<ev> jodh: ew, hopefully not!
<ev> ;)
<seb128> hum,
<seb128>   File "/usr/lib/python2.7/webbrowser.py", line 489, in register_X_browsers
<seb128>     register(browser, None, Chrome(browser))
 * seb128 looks at doko
<mgz> seb128: bug 1159636
<ubottu> bug 1159636 in python2.7 (Ubuntu) "python2.7 failed to import webbrowser: NameError in register_X_browsers(): global name 'Chrome' is not defined - Regression in 2.7.4~rc1-2ubuntu1" [Critical,Confirmed] https://launchpad.net/bugs/1159636
<seb128> mgz, thanks
<seb128> is anyone working on an upload for the fix?
<mgz> it's in -proposed apparently
<seb128> ok, good
<seb128> mgz, thanks
<cjwatson> seb128: yeah, it's waiting for the armhf build to finish
<seb128> cjwatson, I applied the diff to the .py directly and confirmed it works ;-)
<philwyett> Hi all. Is there an issue with the precise upload queue? We have nvidia-cuda-toolkit and and viennacl built in the queue and showing on proposed report, but no binaries showing on LP for both. I am waiting for mesa 9.03.
<cjwatson> uploads to stable releases require manual review by the SRU team which can take a while
<philwyett> Ah, OK.
<cjwatson> um, except I guess that isn't what you're talking about
 * cjwatson looks
<philwyett> :-)
<cjwatson> ah, changed package names I guess?
<cjwatson> any new package name causes the binaries to land in the NEW queue awaiting archive admin review
<philwyett> So we are waiting on that then.
<cjwatson> which in this case would be because the binaries hadn't previously managed to build in precise at all
<philwyett> Does this process normally take long?
<cjwatson> I'm looking at it now
<ScottK> It's mostly waiting for someone with time to review.
<mlankhorst> ugh why is mesa-lts-quantal in new then?
<cjwatson> though you'll have to wait until the binaries squidge down over my not-so-broadband
<philwyett> Thats great.
<cjwatson> mlankhorst: now that's probably just an LP ancestry bug
<stgraber> cjwatson: debian bug 703906
<ubottu> Debian bug 703906 in src:openssh "Add upstart user session job" [Normal,Open] http://bugs.debian.org/703906
<DigvijayUbuntu> Hey! I want to know where I can find the Ubuntu source code documentation
<mlankhorst> cjwatson: anything I can do against it?
<DigvijayUbuntu> Hello busy developers. It would be great help
<cjwatson> mlankhorst: no, I'll take care of it
<cjwatson> DigvijayUbuntu: there is no single place, since Ubuntu is an aggregation of many projects
<cjwatson> DigvijayUbuntu: with this kind of question it generally helps to have some idea which project you're looking at
<cjwatson> stgraber: thanks
<DigvijayUbuntu> cjwatson O I see. I see.
<DigvijayUbuntu> cjwatson Well i dont have a very good idea as of now. Is there any place that needs improving? I'll try to work there
<dobey> DigvijayUbuntu: what do you mean by "source code documentation" exactly?
<tkamppeter> OdyX, around?
<DigvijayUbuntu> dobey Well like how the operating system is built up. What goes where. Like a stack.
<DigvijayUbuntu> Well i was actually looking for this piece of information, so some source code documentation would be the place to look
<DigvijayUbuntu> but there isnt any
<OdyX> tkamppeter: half
<dobey> DigvijayUbuntu: an overview of the stack is quite different from "source code documentation" :)
<DigvijayUbuntu> i know i know, but that would b e a good place to look for it
<dobey> not really
<dobey> looking at the linux kernel source code won't tell you anything about the userspace programs that run on top of it
<DigvijayUbuntu> well ,ok. But the question remains unanswered
<DigvijayUbuntu> so is ther a place like that?
<dobey> probably not
<DigvijayUbuntu> well it qould be quite useful
<DigvijayUbuntu> would*
<DigvijayUbuntu> this information that is
<dobey> i don't think it would be terribly useful; though it wouldn't be hard for someone to create a simple image with a basic overview of that information
<philwyett> DigvijayUbuntu, Maybe the LFS (Linux From Scratch) project may offer some help here and give you that kind of documentation.
<dobey> without specific software names involved, the graph(?) will basically be the same for any monolithic kernel based OS
<dobey> and for versions of linux, it will only vary in minor ways across different distributions
<DigvijayUbuntu> yes dobey
<DigvijayUbuntu> i agree
<dobey> oh, there is something
<dobey> http://developer.ubuntu.com/resources/platform/documentation/platform-diagram/
<DigvijayUbuntu> well, that does seem like it. But if i were to search for these in the source code
<DigvijayUbuntu> how is it organized?
<dobey> DigvijayUbuntu: what source code? ubuntu is made up of thousands of separate projects/packages, which are in various different languages. there is no single "source code" tree for ubuntu. and how they use things may vary differently across them
<ogra_> ubuntu is organized by seeds ... seeds are defining a set of binary packages ... have a look at the ubuntu-minimal, ubuntu-standard, ubuntu-desktop metapackages and tasks, these are generated from the ubuntu seeds and usually make up want a typical ubuntu install contains
<ogra_> (likewise for flavours like kubuntu. xubuntu, lubuntu etc)
<dobey> anyway i need to get lunch and deal with some life things
<DigvijayUbuntu> ok see you dobey
<DigvijayUbuntu> tthanks
<ogra_> s/want/what/
<DigvijayUbuntu> ogra_ the packages are there, but if i were to say work on a package how would i find it
<DigvijayUbuntu> as in say i want to work on what makes unity tick
<DigvijayUbuntu> work on unity*
<tvoss> seb128, ping
<ogra_> then you would take a look at  the desktop seed, though if its specifically just unity you would look at the unity metapackage and what it depends on
<seb128> tvoss, pong
<DigvijayUbuntu> ogra_ how do i improve some package which already exists
<DigvijayUbuntu> desktop seed?
<DigvijayUbuntu> how do i go there?
<DigvijayUbuntu> or get to it?
<ogra_> https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.raring
<cjwatson> It's probably more useful to get the unity source directly and start there
<cjwatson> apt-get source ANY-PACKAGE-NAME  gets you its source code
<ogra_> yeah
<DigvijayUbuntu> i see,
<DigvijayUbuntu> though this seed thing is totally a new one for me
<DigvijayUbuntu> it seems quite useful
<ogra_> we jumped from "how is ubuntu organized" to "how do i fix unity" :)
<DigvijayUbuntu> lol that was just en example
<cjwatson> I don't really think seeds are a good place for newcomers to start - they're essentially an implementation detail of how we keep track of what we want to install by default in Ubuntu
<DigvijayUbuntu> thats the first thing which came to my mind
<ogra_> the easiest to start contributing is probably to go to the bugtracker or errors.ubuntu.com and pick a bug and try to fix it
<DigvijayUbuntu> oooo
<DigvijayUbuntu> but bugs are rrors
<DigvijayUbuntu> and i want to work on performance
<DigvijayUbuntu> generally* errors
<DigvijayUbuntu> like say everytime i open ubuntu software centre, for a second it seems like it is hung
<DigvijayUbuntu> every time i boot ubuntu
<DigvijayUbuntu> the splash logo appears only in the end for half a second
<DigvijayUbuntu> stuff like this....
<DigvijayUbuntu> like say my room mate is using ubuntu, and he says this is not right
<DigvijayUbuntu> then i want to fix it
<philwyett> The splash screen thing is known. See: http://www.worldofnubcraft.com/1621/make-plymouth-start-earlier-in-the-boot-process/
<DigvijayUbuntu> well why has no one worked on it?
<philwyett> Sorry all. That is more of an #ubuntu question and answer.
<DigvijayUbuntu> any good software, has to atleast start well
<cjwatson> the problem with the splash screen thing is that moving it earlier slows down the boot process
<cjwatson> so it's an unfortunate trade-off
<DigvijayUbuntu> o i see
<DigvijayUbuntu> so i seem the way to understand more about ubuntu
<DigvijayUbuntu> is starting at the bottom
<DigvijayUbuntu> so bugs it is for now\
<DigvijayUbuntu> thanks for the info guys
<DigvijayUbuntu> see you around
<ogra_> thats a good start :)
<DigvijayUbuntu> bye!
<roaksoax> slangasek: howdy!! I was wondering if there's something else I needed to take care of for MAAS to get accepted into -proposed?
<DigvijayUbuntu> okays
<DigvijayUbuntu> lol
<DigvijayUbuntu> so i m back
<DigvijayUbuntu> just afor a seconf though
<DigvijayUbuntu> i looked at new bugs
<DigvijayUbuntu> this seems interesting enough
<DigvijayUbuntu> https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1159883
<ubottu> Launchpad bug 1159883 in shotwell (Ubuntu) "Wishlist : should be able to delete photo date and time" [Undecided,New]
<tkamppeter> OdyX, I have done a small fix on iOS client printing support in the Ubuntu CUPS package (1.6.2-1ubuntu3). Can you merge it back to Debian? I am currently not syncing as after our FF I do not want to take in the new binary package splitting.
<OdyX> tkamppeter: yeah, no problem, thanks.
<cjwatson> philwyett,mlankhorst: nvidia-cuda-toolkit/viennacl/mesa-lts-quantal accepted
<mlankhorst> yay ty
<cjwatson> (will take the usual hour or so to publish)
<OdyX> tkamppeter: ideally, you could do git commits without debian/changelog messages in master, and then create out-of-branch tags for the Ubuntu releases.
<OdyX> (aka re-creating the tree of revisions)
<OdyX> tkamppeter: but that way is good enough, I'll manage. :-)
<philwyett> cjwatson, Thanks
<OdyX> tkamppeter: pushed, thanks.
<slangasek> roaksoax: nothing else... I just need to sanity-check it, I was stymied on Friday by the lack of a diff in the queue (not your fault, but launchpad's)
<roaksoax> slangasek: ok cool :)
<infinity> ev: The plan still exists, it's just been stalled a bit.
 * infinity runs away back to being on vacation.
<ev> infinity: thanks
<hallyn_> apw: hey - i'm trying to build a sparc-cross-toolchain-base package, based on the arm and powerpc versions.  (this is to build sparc openbios for qemu to use on x86 etc)  Doing so requires sparc architectures in linux-source-3.8.0 (debian.master/rules.d/sparc.mk file etc).  I assume I'll have to just keep that in a local quilt diff, but if there's anything kernel team has sitting around that would help, please let me know :)
<hallyn_> apw: nm, i see now in the rules file some tweaking is sort of expected anyway :)
<apw> hallyn_, :)
<hallyn_> doko: I'm trying to caox a sparc-cross-toolchain-base into building.  At this point it dies because gcc-4.7 tries to apply 'gcc-as-needed', which doesn't apply 100% cleanly.  I can quilt push; quilt ref' it by hand just fine, but am not sure where in gcc's packaging to udpate it.  (might resort to unpacking the .xz and updating manually)
<hallyn_> hm, maybe just removing that patch is working (as tmp solution)
<stgraber> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<infinity> hallyn_: the *cross* packages re-patch the source packages they're building.  I assume you've noticed this, right? :)
<infinity> hallyn_: So, you can just fudge it in there.
<hallyn_> infinity: yes, and i do so with linux-source,
<hallyn_> infinity: but with gcc it keeps re-extracting it, so i can't just say "after extracting it, quilt push -f quilt ref"
<hallyn_> well lemme start over from 'init-gcc' stamp
<hallyn_> ooh, i removed the wrong path (gcc/* instead of *)
<hallyn_> maybe that'll do it
<hallyn_> remember, serge, when it looks like something magical is happening, you've got a typo
<infinity> hallyn_: Or you have genuine magic.
<infinity> hallyn_: And I'd like to know about it, so I can ride your coattails to riches and fame.
<hallyn_> if i find some, i owe it to you - will let you know
<ahasenack> hi guys, anyone here familiar with gir1.2-gudev-1.0 and libgudev-1.0-0 packaging?
<ahasenack> in raring, gir1.2-gudev-1.0 does NOT Depends on libgudev-1.0-0
<ahasenack> but it does in oneiric, precise and quantal
<ahasenack> is this an oversight? I'm currently tracking #1159997, where landscape-client doesn't work in raring unless libgudev-1.0-0 is installed
<ahasenack> but before adding that as an explicit dependency, I wanted to ask first
<ahasenack> since we already depend on  gir1.2-gudev-1.0, and that used to be enough (it pulled in libgudev-1.0-0)
<bdmurray> RAOF: are you working on a precise fix for bug 827934?
<ubottu> bug 827934 in colord (Ubuntu Precise) "colord crashed with SIGABRT in raise()" [Medium,Confirmed] https://launchpad.net/bugs/827934
<bdmurray> it seems more prevalent there with nearly 25k incidents
<nemo> Hey. I'm trying to support a user who hit an endless spinner on 12.04 installer at "preparing to install" (attempting to reinstall an old install)
<nemo> so I suggested he open a command prompt on CD and launch the installer app manually, so he could note any errors
<nemo> now. I'm pretty sure that 12.04 uses Unity so I can't just tell him to right click on the icon, choose properties and copy and paste that text
<nemo> Does anyone here offhand know what the installer script name is?  pretty sure it is python. not positive tho
<sarnold> nemo: I think you're looking for 'ubiquity'
<nemo> sarnold: that sounds about right
 * nemo tries feeding that into google
<sarnold> nemo: 12.04 LTS also had an 'alternative installer' (debian-install, iirc) that is less friendly and might work on different hardware (no gui)
<nemo> yeah. doubt gui is his problem
<nemo> I suspect it hit some error. for example. last time I used CD to do an upgrade, it blew up over a non-empty /usr/local
<nemo> but I didn't discover this until I ran from commandline
<nemo> probably could have found something in xsession-errors I suppose
<sarnold> if he's just upgrading, a do-release-upgrade might do the job better than a CD anyhow
<ScottK> More likely, the 12.04.2 media uses a newer kernel and X server to support newer hardware, so installing now presents a host of possibilities for trouble.
<ScottK> sarnold: Definitely.
<sarnold> .. and likewise, "What ScottK said" :) hehe
<nemo> sarnold: he had screwed up his existing system badly
<nemo> sarnold: so just wanted to reinstall
<sarnold> nemo: ah :)
<nemo> he's not terribly savvy and can't let me into his system (well, wouldn't really want him to anyway)
<sarnold> nemo: well, if /home is on its own filesystm it's easy enough to wipe everything else and get back to basics quickly enough. If /home wasn't on its own filesystem, it isn't as easy to make a clean break, but hopefully still possible with the installer...
<nemo> I imagine it was all one filesystem
<nemo> I doubt he cares about /home
<sarnold> yeah, me too :(
<sarnold> oh :)
<nemo> I think it was a windows/linux dual boot
<nemo> I think he just is very worried about wiping windows
<nemo> so safest option seemed to be reinstall
<nemo> hm. he thinks he is running 10.04 - not that it should matter for a reinstall
<nemo> anyway. trying to get him to figure out how to launch gnome-terminal in unity :)
<lool> wow, serious syslog spam from the accountservice SRU -- tons of "dbus[461]: last message repeated 10 times" messages
<lool> Hmm I guess dbus reloaded its config one time per locale on the system or something like that
<nemo> sarnold: didn't help anyway. ubiquity spun its wheels for 15 minutes w/o anything showing up on terminal
<nemo> he's trying again w/ tail -f .xsession-errors running on the offchance stuff ended up there :-/
<sarnold> nemo: 15 minutes?? ouch.
<nemo> I have to say. unless the install is a clean one, and ideally w/o trying to preserve any existing OS, ubuntu installer has been pretty hit or miss for me :-/
<nemo> and I like to think that after 17 years I kinda know my way around linux, yet it still manages to stump me
<nemo> certainly what it is doing is hard, but it does not make it easy to discover or debug errors
<nemo> is like "everything should just work, and if it doesn't, you're just gonna have to guess"
<sarnold> nemo: heh, I was _thrilled_ when everything Just Worked on my Pandaboard. I expected an oddball architecture to be a pain in the butt, but I got to return my usb-serial cable _unopened_. I was duly impressed with the installer that day. :)
<nemo> sarnold: well. for a *clean* install, installer has always been a marvel
<nemo> sarnold: is just if I need to upgrade, or reinstall, or preserve an existing windows install
<nemo> that I get flakiness.
<nemo> in this case, I'm wondering if the fact that he has 2HDs is somehow confusing it
<sarnold> nemo: hrm, I thought re-sizing existing windows Just Worked these days too.
<sarnold> naah, most of my installs had multiple hard drives, that just works.
<nemo> well. windows situation may well have changed. haven't tried that one in quite a while to be sure.
<nemo> pretty windows free at home these days
<ScottK> As long as it's not Windows 8, AFAIK, it shouldn't be an issue.
<nemo> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/188976 was the last one I hit, which appears to have been fixed last year
<ubottu> Launchpad bug 188976 in ubiquity (Ubuntu) "ubiquity crashed with OSError in copy_all()" [High,Fix released]
<nemo> ScottK: heh. well. windows 8 is a whole new level of evil
<nemo> ScottK: poor users, if they can even get ubuntu installed period, w/o being locked out or having to navigate arcane bios settings...
<RAOF> bdmurray: That's a difficult one; fixing it requires basically rewriting the colord-sane component.
<bdmurray> RAOF: ah, I didn't realize it was that different
<RAOF> bdmurray: Probably the most reasonable way to deal with it is to avoid hitting it by disabling sane support in the conf file. I'm not sure that's an excellent SRU, though.
<RAOF> Actually, probably the *best* way of dealing with it would be for apport to just not pop up on colord crashes. They have no user-visible effect other than the apport dialog, and colord will be automatically respawned when something tries to use it.
<bdmurray> Preventing all crashes from the package being reported seems heavy handed to me.
<RAOF> bdmurray: We could try client-side filtering of crashes? Although that would be difficult, because the reason it crashes is that it leaks fds until it's got more than 1024 open, and then dies somewhere when something tries to do something that won't work on fd > 1024.
<sarnold> like, select(2)? :)
<sarnold> ouch.
<RAOF> Indeed.
<smoser> hey all. i have a very simple little python project.  It has no 'make install' or other way of installation.
<smoser> what would be recommended way to install (with an eye towards making packaging easy)
<smoser> ie, i'll pick whatever makes stuff "just work".
#ubuntu-devel 2013-03-26
<lifeless> use setuptools, and dhpython or whatever it is will DTRT
<smoser> lifeless, thanks, thats what i was thinking.
<xnox> smoser: "Files listed in debian/pkg.pyinstall file will be installed as public modules for all requested Python versions" man dh_python2, such that you can skip setuptools ;-) if it's pure python.
<xnox> but then you will not have an egg / something to put into cheeseshop.
<ScottK> setup.py for such things are trivial.
<ScottK> robert_ancell: Is it the lightdm core or just the Unity greeter that requires the Canonical CLA for contributions?
<robert_ancell> ScottK, both
<ScottK> robert_ancell: Unfortunate.  KDE is looking for an upstream KDM replacement and except for that it was the best candidate.  I was hoping they were wrong.
<mbiebl> RAOF: looks like the systemd package in ubuntu is missing a call to dh_girepository
<mbiebl> or just use the gir dh addon
<ScottK> pitti: ^^^ was that you?
<vibhav> What does bzr branch debianlp:package pull the source from?
<vibhav> s/What does/From where does/
<RAOF> From launchpad's import of debian.
<RAOF> vibhav: ^^^
<vibhav> RAOF: I mean, from which distro series?
<RAOF> That's a fine question!
<RAOF> My guess would be sid.
<RAOF> IIRC you can make it explicit by pulling debian:testing/package or debian:unstable/package.
<RAOF> Or some syntax like that.
<vibhav> yes, you can do that
<vibhav> I wonder which is the default distroseries
<vibhav> yes, probably sid
<ScottK> It's Sid.
<vibhav> ah, thanks
<pitti> Good morning
<pitti> ScottK, mbiebl: ah right, that's missing from both our package as well as http://people.debian.org/~biebl/systemd-198/debian/rules; I'll create a patch and send it to mbiebl, thanks for pointing out
<dholbach> good morning
<mardy> oSoMoN: hi! I'm investigating how to intergate Online Accounts with the browser
<mardy> oSoMoN: do you provide an extension mechanism?
<mlankhorst> g'day
<oSoMoN> mardy: no, thereâs nothing like that atm
<vibhav> The newest version of blackbox fixes some stuff for m68k, should I mark the merge useless then?
<mardy> oSoMoN: currently, for Firefox and Chromium, we have an extension which collects all the cookies for the currently visited domain and forwards them to Online Accounts (in order not to have to re-login in there, when creting an account)
<mardy> oSoMoN: do you think that we could get a similar functionality with the Touch browser?
<oSoMoN> mardy: sounds doable, weâd have to investigate how to collect the cookies from the QML webview, you have quite some experience with that, donât you?
<mardy> oSoMoN: mmm... not sure :-) I know how to collect the javascript cookies, but we need especially the http cookies
<mardy> oSoMoN: AFAIK, the problem is not easily solvable, because of the split-process architecture in webkit2
<mardy> oSoMoN: I wonder if we can do anything better than reading the cookies directly from the file where WK2 stores them :-/
<oSoMoN> mardy: no clue eitherâ¦ sounds like a question for the webkit-qt ML
<mardy> oSoMoN: yep, I'll ask there. Thanks anyway!
<bkerensa> vibhav: is it just bug fixes or new features too?
<vibhav> bkerensa: afaik, ubuntu doesn't have m68k support
<vibhav> (strike me if I am wrong!)
<bkerensa> vibhav: hmm in that case I defer :P
<vibhav> :)
<vibhav> Ill mark it as "not needed" then
<sladen> cjohnston_: ta x2!
<xnox> infinity: are you interested in doing bug 1012081 ?
<ubottu> bug 1012081 in util-linux (Ubuntu Raring) "util-linux needs updating to 2.22+" [Undecided,Triaged] https://launchpad.net/bugs/1012081
<pitti> xnox: I have fixed bug 1159997 this morning in my git, FYI
<ubottu> bug 1159997 in Landscape Client "Landscape Client doesn't start on 13.04" [Critical,Confirmed] https://launchpad.net/bugs/1159997
<pitti> xnox: uploading now, I just fixed the other outstanding bug
<xnox> pitti: snap
<infinity> xnox: Yeah, I should do it in experimental and raring (the latter assuming someone other than me gives it an FFe)
<xnox> pitti: https://launchpad.net/ubuntu/+source/systemd/198-0ubuntu8
<pitti> xnox: sorry for the duplicate work; I should have guessed when you asked me 15 mins ago :)
<infinity> xnox: Since I'm on VAC right now, care to see if you can get an FFe from someone else on the release team and let me know? :P
<pitti> xnox: argh; rebasing my git tree then, and reuploading; poor buildds
<xnox> pitti: sorry =)
<pitti> xnox: what provides "--with gir"?
<xnox> pitti: gobject-interspection package, which is a Build-Dep already.
<pitti> ah, nice
<xnox> pitti: I tend to do a lot of `dh --list` and dpkg -S /usr/share/perl5/Debian/Debhelper/Sequ*/foo*
<tkamppeter> pitti, are you intending to upload the fixed CUPS (AppArmor) to Ubuntu or should I do so?
<pitti> tkamppeter: it doesn't seem urgent enough to warrant an upload just for that IMHO
<OdyX> tkamppeter: what is the good upstream way to report foomatic-db updates ?
<didrocks> hey infinity! we noticed that daily release doesn't have their .pot/mo imported in launchpad, it seems it's just a flag to set to a non virtualized ppa, do you mind giving us some guidance on what to ask for so that pkgbinarymangler is ran on the ubuntu-unity/daily-build?
<OdyX> tkamppeter: my use-case is that Brother MFC-9460CDN works fine with postscript driver for MFC-9450CDN Foomatic/postscript.
<infinity> didrocks: I don't think the PPA is doing anything wrong here.  I see the translations tarballs in the upload.
<infinity> didrocks: It could be that LP discards/ignores translations when doing copies, but that's wildly more complex to unwind than what you're suggesting. :/
<didrocks> infinity: hum, seb128 noticed that the .pot were not updated in launchpad? https://bugs.launchpad.net/cupstream2distro/+bug/1158775
<ubottu> Launchpad bug 1158775 in Canonical Upstream To Distro "the ppa builds don't have their translation template (.pot) sent back to launchpad, leading to outdated Ubuntu strings lists" [Undecided,New]
<infinity> cjwatson_ / wgrant: ^-- Thoughts?
<infinity> didrocks: I'm not arguing with you on whether or not they're being imported, I'm saying that they ARE being built and uploaded in the PPA.
<infinity> didrocks: PPAs don't import translations, as that would be madness, only the primary archive does.  So, if they're getting lost, it's in the copy.
<cjwatson> Are the translations in question just attached custom uploads?
<infinity> cjwatson: Yep.
<infinity> cjwatson: https://launchpadlibrarian.net/135275530/unity_6.12.0daily13.03.26-0ubuntu1_amd64.changes
<infinity> cjwatson: For example.
<cjwatson> Oh, wait.  ROSETTA_TRANSLATIONS uploads aren't marked as copyable
<cjwatson> cf. lib/lp/soyuz/scripts/custom_uploads_copier.py
<infinity> Perhaps to avoid re-importing on pocket copies?
<cjwatson> So that's probably why, but I'm not quite sure why that is ...
<cjwatson> Perhaps, not sure
<infinity> Not that reimporting tends to harm anything.
<cjwatson> That doesn't seem really right either though.  Consider even a copy from quantal-updates to raring
<infinity> Or, it shouldn't.
<cjwatson> It's more likely that it just wasn't considered, since I embraced and extended the existing custom uploads copier to do what we needed
<infinity> So that may just be a dormant misfeature that no one cared about until today.
<cjwatson> I don't feel that I know enough about Rosetta to fix it safely, though
<infinity> Ursinha might.
<infinity> I guess the only real question is "will importing the same tarball version twice break?"
<infinity> Which would be easily testable in staging or something.
<cjwatson> Yeah
<infinity> Since we know reimporting the same exact templates is a non-issue, as we do it daily.
<cjwatson> It also might involve some code refactoring
<cjwatson> I more or less shoehorned almost all the other custom upload types into the same kind of structure
<cjwatson> lp.archivepublisher.*.FooUpload
<cjwatson> But ROSETTA_TRANSLATIONS is handled in lp.soyuz.model.queue
<cjwatson> So that might need to be hoisted out and mangled into a similar form, to avoid pain
<infinity> Translations import handling is fundamentally silly anyway, as previously discussed.
<infinity> (There seems to be 0 reason that should be happening syncronously in the publisher...)
<infinity> Not that that's relevant to today's issue, but if someone's going refactoring. :P
<cjwatson> Well, sure, I filed a bug about that a while back :)
<cjwatson> bug 1064895
<ubottu> bug 1064895 in Launchpad itself "Translations processed in-band by the publisher" [Low,Triaged] https://launchpad.net/bugs/1064895
<cjwatson> So, sure, if Ursinha wants to have a go then this'd be a good thing to sort out
<infinity> cjwatson: I need to go find some bed (and get back to being on VAC), want to chase this up with wgrant/stevenk and see if there seems to be an easy way out?  And yeah, Ursinha's previous rosetta experience may prove handy here.
<cjwatson> Shuffling it out to an async job isn't really directly related; it would just be easier with the code in question pulled out of queue acceptance
<infinity> didrocks: If there's no quick way out of this, would you guys be against slamming some manual uploads directly at the archive to get your templates imported? :/
<didrocks> infinity: well, whatever is unblocking for this release. I can surely do that everytime we have a new string, which will happen for 40 components in the 100scopes projects, but after that, it should be minimal. So sounds good :)
<cjwatson> Sure - I'm guessing it might be next .au morning at this point
<seb128> infinity, I did that friday, uploading updated templates manually
<didrocks> infinity: as long as something is on track to get it working on the long term ;)
 * infinity nods.
<seb128> infinity, so we are fine for raring
<infinity> seb128: Okay, good to know.
<didrocks> seb128: well, we'll have all the new strings from 100scopes, so yeah, 40 more uploads to come (and launchpad karmaâ¦ :p)
<didrocks> but I knew I would get bored on the 1st of April :)
<seb128> lol
<infinity> Still feels like a fairly urgent bug, as "we're good for raring" often translates to "we'll forget about this for another six months and panic again", which would be suboptimal.
<seb128> didrocks, the smart scopes have strings reflecting in the ui?
<didrocks> seb128: yeah, for filters
<seb128> didrocks, well, there are the filters, but most are only a name (e.g "tomboy")
<seb128> so they don't really need translation
<didrocks> or the no result hint
<didrocks> Sorry, there are no Zotero results that match your search.
<didrocks> for instance
<seb128> k
<seb128> so yeah, we will have to upload those templates, easy to script ;-)
<didrocks> seb128: you volonteer? :)
<seb128> didrocks, can do
<didrocks> \o/
 * didrocks goes back in a 100 insanelyness ;)
<didrocks> thanks seb128, infinity, cjwatson
<seb128> thanks
<tkamppeter> OdyX, upstream bug tracker for Foomatic is http://bugs.linuxfoundation.org/, product OpenPrinting.
<ev> pitti: remind me where the LP retracers live?
<pitti> ev: on the i386/amd64 porter box, osageorange
<ev> ahh, thanks
 * ev updates https://wiki.canonical.com/UbuntuEngineering/QA/ApportRetracerMaintenance
<maxb> Canonical was really scraping the bottom of the fruit naming convention for that one, I see :-)
<infinity> There were worse.
<infinity> Most internal, and some so awful they got vetoed. :P
<ev> pitti: did you happen to see my message from yesterday? Can you confirm that once we have packages in -proposed, we can't retrace crashes from the regular release on the LP retracers.
<ev> We're trying to deploy retracers on prodstack and ran into this: https://pastebin.canonical.com/87608/
<ev> I'm thinking we should treat -proposed as special in that check
<ev> or maybe just try the retrace anyway and see what happens :)
<pitti> ev: that's right, the sandbox building logic only looks at the current package in apt right now
<pitti> ev: it would be better to check the versions in Package and Dependencies and then try to find that particular version
<ev> pitti: okay, I'll work on a branch for that today
<ev> thanks
<ev> pitti: oh also, before I subject the population of Ubuntu users to uploading core files more often, I'd appreciate your feedback on this idea: https://bugs.launchpad.net/daisy/+bug/1159849
<ubottu> Launchpad bug 1159849 in Daisy "We shouldn't ever mark retraces as failed." [Undecided,New]
<ev> whenever you have spare time, that is
<pitti> xnox: and once again empty :) https://launchpad.net/ubuntu/+source/systemd/+bugs
<pitti> ev: I opened a tab, will look ASAP
<ev> thanks
<cjwatson> plars: firewalls and cdimage code are all ready for you to have a try at the cdimage current symlink updating thing now (this time for real)
<rbasak> Feeling a bit freaked out by floating heads in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703906. When did they start to appear?
<ubottu> Debian bug 703906 in src:openssh "Add upstart user session job" [Normal,Fixed]
<cjwatson> rbasak: http://www.donarmstrong.com/posts/libravatar_for_bts/
<rbasak> Erm...thanks :)
<plars> cjwatson: cjwatson ok, send me the details if you don't mind on what I need to run. I discovered a bit more work that has to happen on this side, mostly due to the fact that we have some legacy stuff happening for precise, and changed the process a bit for raring+
<cjwatson> plars: ssh cdimage@nusakan /srv/cdimage.ubuntu.com/bin/mark-current --project=ubuntu --series=raring --publish-type=desktop --architecture=i386 20130326
<cjwatson> plars: replace as appropriate
<plars> cjwatson: and that will need to run from only that IP I gave you the other day, or it can happen from anywhere in our lab?
<cjwatson> plars: full option parser is in https://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/lib/cdimage/tree.py
<cjwatson> plars: It's currently locked to only 10.97.0.6 and 10.98.0.1, both in firewalls and in authorized_keys.  If you need to run it from somewhere else then IS need to update both of those
<cjwatson> (in fact, 'ssh cdimage@nusakan /srv/cdimage.ubuntu.com/bin/mark-current --help' should work from those IPs, if I got t right)
<cjwatson> *it
<cjwatson> plars: It'd be great if you could try it out by hand if possible, just to make sure that things are good from my side
<cjwatson> plars: Note that I need to maintain a list of which images are having their current symlink maintained this way, so it'd be good if you could drop me a note whenever you turn something on.  I'll probably notice eventually from logs though
<plars> cjwatson: I'll do that. the ssh seems to timeout at the moment, let me talk to our lab guy a moment.  we may need to use a different ip
<plars> cjwatson: ok, apparently the IPs I had were the VPN IPs, we need a different ip for the firewall. Is there a ticket still open on this, or should I just open a new ticket to get that changed?
<xnox> rbasak: bts supports "settings" and you can turn it off, if you find it creepy & disturbing =) imho it should be floating on the right.....
<rbasak> xnox: I prefer heads that are attached to bodies. Preferably when both are alive, too :-)
<xnox> rbasak: min avatar got "banned" from debian planet. But you can see it on the bts: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606825
<ubottu> Debian bug 606825 in dpkg "dpkg: Please add mingw to ostable and triplettable." [Wishlist,Open]
<cjwatson> plars: the ticket's already had problems with confusion, and is now closed - might be best if you opened a new ticket and I can ack/clarify as needed
<cjwatson> plars: make sure to ask for both the firewall and /etc/ssh/user-authorized-keys/cdimage to be changed
<plars> cjwatson: ok, I'm finding out that the other IP for the PS system needs changing too, I'll get it sorted out with retoaded and get it fixed. Thanks
<cjwatson> Makes sense
<cjwatson> cdimage will now explicitly log when current symlink updates are requested for images it didn't know were trigger-controlled, so I can probably just grep for that rather than you having to coordinate carefully with me
<cjwatson> You'll notice if it's uncoordinated because it'll just point current to the latest build any time one happens :)
<cjwatson> plars: And I see PS Jenkins is being moved to a new host so I guess that'll need to be sorted out too ...
<plars> cjwatson: yes, and I'll make sure that one is corrected as well
<cjwatson> I've optimistically marked my WI for this done, anyway; I'm fairly sure it's at worst minor debugging now
 * cjwatson wonders if he has had enough coffee to tackle rewriting publish-release
<xnox> plars: note, that jenkins is moving =) *perfect timing*
<GunnarHj> cjwatson: Hi Colin, and thanks for uploading the openssh patch at bug 952185 to Raring. Steve created a Precise task too, but I wouldn't be the right person to prepare it, since I don't know what the test case would look like. Can you ask somebody who is enough ssh proficient to do it?
<ubottu> bug 952185 in gdm (Ubuntu Precise) "~/.pam_environment not parsed by default" [Medium,In progress] https://launchpad.net/bugs/952185
<cjwatson> GunnarHj: that's probably me :)
<GunnarHj> cjwatson: Great, then you can ask yourself. :)
<GunnarHj> cjwatson: Can you put it on your todo list?
<cjwatson> Let me just do it now
<GunnarHj> cjwatson: Ok, great.
<cjwatson> GunnarHj: I think it can just be the same SRU description as lightdm and gdm, aside from trivial differences in wording - do you have any reason to think otherwise that I might have missed?
<cjwatson> GunnarHj: I've adjusted the bug description thus
<cjwatson> GunnarHj: and uploaded openssh 1:5.9p1-5ubuntu1.1 to precise-proposed, pending SRU team review
<GunnarHj> cjwatson: Sorry, away from kb for a few minutes. No, I have no reason to think that the description wouldn't fit. OTOH I can't confirm that it fits either. ;-) Thanks!
<cjwatson> heh, ok
<freeflyi1g> hi there, do we need FFe for those native package speific to Ubuntu like default-setting and theme?
<GunnarHj> I'm struggling with fonts and font configuration at bug 1153188 without knowing very much about it. It's about how you make the system actually use a desired font when rendering text in a language, in this case Urdu. Anybody out there who is able to give a helping hand?
<ubottu> bug 1153188 in fonts-nafees (Ubuntu) "Urdu with better support: Default Fonts, Kbd Layout" [Medium,In progress] https://launchpad.net/bugs/1153188
<cjwatson> freeflyi1g: If changes to them are new features, yes
<TheLordOfTime> also, crossposting is discouraged.  (was posted here and in -motu)
<freeflyi1g> cjwatson: noted, thanks
<SpamapS>  4243 clint     20   0  647m  46m  12m R 100.0  1.2  11:09.66 unity-lens-phot
<ttx> jamespage: ceilometer MP branch cut
<ttx> dunno if you track that one
<jamespage> ttx: we do
<jamespage> thanks
<ttx> jamespage: that's the last one. Cheers!
<jamespage> great!
<FourDollars> Hi, could someone review my patch of https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/1160414 ?
<ubottu> Launchpad bug 1160414 in ibus-chewing (Ubuntu) "Use shift keypress to switch to English mode." [Undecided,Confirmed]
<mitya57> FourDollars: please file a merge proposal against raring (lp:ubuntu/ibus-chewing)
<FourDollars> mitya57: There is no need to file a merge proposal against raring. Thoses patches come from raring.
<mitya57> FourDollars: then just file a MP :)
 * mitya57 can't upload, but can leave a +1
<FourDollars> mitya57: To where? lp:ubuntu/quantal/ibus-chewing and lp:ubuntu/precise/ibus-chewing ?
<FourDollars> https://code.launchpad.net/ubuntu/+source/ibus-chewing
<chilicuil> kenvandine: ping
<FourDollars> There is no lp:ubuntu/precise-proposed/ibus-chewing or lp:ubuntu/quantal-proposed/ibus-chewing on https://code.launchpad.net/ubuntu/+source/ibus-chewing .
<mitya57> FourDollars: just lp:ubuntu/precise/ibus-chewing or lp:ubuntu/quantal/ibus-chewing
<FourDollars> mitya57: OK.
<kenvandine> chilicuil, pong
<FourDollars> mitya57: https://code.launchpad.net/~fourdollars/ubuntu/precise/ibus-chewing/lp1160414/+merge/155528 and https://code.launchpad.net/~fourdollars/ubuntu/quantal/ibus-chewing/lp1160414/+merge/155527
<chilicuil> kenvandine: hey, I'm testing the gwibber package from the friends ppa before it go to raring and the gwibber interface doesn't work, is there any way I can report a bug against those packages?
<kenvandine> chilicuil, what are you seeing?
<kenvandine> chilicuil, want to join #gwibber and we can debug?
<chilicuil> kenvandine: yep
<FourDollars> mitya57: Thank you. :)
<ev> there's a new version of https://errors.ubuntu.com/ out. Let me know what you think.
<seb128> ev, http://ubuntuone.com/0McV8himWSAQ2tToHaXedH
<seb128> ev, is that the wanted start page?
<bdmurray> I had to do a shift reload
<ev> seb128: hit refresh harder :) ctrl-shift-n or what-have-you
<mitya57> ev: still only for canonical-ers? :)
<ev> mitya57: sadly, yes. Still waiting on legal for an NDA.
<ev> slangasek: ^
<seb128> ev, ok, works after a firefox restart, weird ... thanks ;-)
<ev> seb128: sure thing :)
<seb128> ev, the orange box in the top left corner is weird ;-)
<ev> seb128: send design complaints to mpt at the usual domain dot com :)
<seb128> hehe
<ev> unless they're me failing to implement things as designed
<seb128> ev, is the design document available somewhere for comparaison?
<ev> seb128: https://wiki.ubuntu.com/ErrorTracker#errors.ubuntu.com
<seb128> ev, ah, that orange box should be an ubuntu project logo according to the design ;-)
<ev> seb128: the reason for that is that we do not yet have an Ubuntu project global navigation
<ev> oh yes, and that :)
<seb128> bah, it is now
 * seb128 kicks firefox
<ev> there's work being undertaken by the web and design teams to refresh the navigation structure, and hopefully we'll get an "Ubuntu project" hierarchy out of that
<ev> but until then we don't have anything to point at
<ev> since our links off to qa.ubuntu.com all became as dead as that site itself
<jcastro_> wow, teamviewerd crashing lsb_release seems overly popular.
<ev> jcastro_: iknowright
<mitya57> ev: if you have some time, can you show me some stacktraces (I asked on #ubuntu-bugs yesterday, but nobody wanted to do that)?
<mitya57> http://paste.ubuntu.com/5649740/
<ev> mitya57: looking
<rbasak> jibel: hey, with lxc-create -t ubuntu-cloud I get "Only i386 and amd64 are supported by the ubuntu cloud template.". Easy enough to bypass, but is there something I'm missing?
<xnox> ev: wow, awesome =) how did it know that I like filesystem packages only?! =)))))) awesome.
<ev> xnox: you can thank bdmurray for that part :)
<xnox> ev: why is precise converging with quantal on error (e.g. increasing?!)
<xnox> since december there is strong correlation and tendancy for precise to be a quantal look a like.
<didrocks> stgraber: just to confirm re transition freeze/hard freee. The freeze that you propose for beta2 is just proposed -> raring, right?
<jibel> rbasak, yes, it is bug 1159818, I had to modify the template to allow armhf
<ubottu> bug 1159818 in lxc (Ubuntu) "Allow architecture armhf with template ubuntu-cloud when running on ARM" [High,Confirmed] https://launchpad.net/bugs/1159818
<rbasak> jibel: got it - thanks. I noticed that sources.list was wrong afterwards and had to fix it up manually
<ev> xnox: indeed. The data checks out as well.
<bdmurray> xnox: I wonder if it is the lsb-release bug bumping up precise
<bdmurray> or the aptdaemon one line diff bug
<jibel> rbasak, you'll also need to specify the url of the tarball, ubuntu-cloudimg-query doesn't find an AMI for arm
<bdmurray> I mean bug 1120322
<ubottu> bug 1120322 in aptdaemon (Ubuntu Precise) "update-manager crashed with UnboundLocalError in show_diff(): local variable 'line_number' referenced before assignment" [High,In progress] https://launchpad.net/bugs/1120322
<stgraber> didrocks: yes
<didrocks> stgraber: so on the 1st of April I would be able to push to proposed the 100scopes, isn't it?
<stgraber> didrocks: though I'd like to get the opinion of other release team members before deciding what to do after beta2. ScottK has a good point wrt having control on what happens between the last two images, but I was hoping for other people to express their opinion...
<stgraber> didrocks: you'll be able to upload, yes. It won't land on people's machines though as I expect unity to be part of the migration freeze
<didrocks> stgraber: ok
<jibel> rbasak, I filed bug 1160488 for the second part of the problem with update-initramfs
<ubottu> bug 1160488 in flash-kernel (Ubuntu) "flash-kernel uses mkimage but u-boot-tools is not installed" [Undecided,New] https://launchpad.net/bugs/1160488
<ogra_> jibel, thats intentional
<ogra_> the installer needs to install u-boot-tools
<ogra_> (and theoretically your u-boot shouldnt use mkimage at all, we switched to uEnv.txt and preEnv.txt quite a while ago)
<rbasak> ogra_: flash-kernel uses mkimage. It's from Debian.
<ogra_> rbasak, ?
<ogra_> if it does, thats a bug
<ogra_> none of our supported arches should use mkimage at all
<rbasak> IIRC, it's a major component of flash-kernel. Am I missing something?
<ogra_> yes, the switch to plain text configs about a year ago :)
<ogra_> for unsupported debian arches flash-kernel-installer should care to install it during installation though
<ogra_> (dont ask me if it does, i dont test unsupported arches)
<rbasak> ogra_: how does flash-kernel know whether to use mkimage or not? I don't see a flag in all.db
<ogra_> if you would have a dep you would install mkimage everywhere ... not every arm board uses u-boot
<ogra_> in ubuntu it simply doesnt unless you special cased it
<rbasak> I must be missing something. I didn't special case anything, and it does use mkimage
<ogra_> it uses /etc/default/flash-kernel and assembles the cmdline from that ... then dumps it into uEnv.txt
<ogra_> what arch ?
<rbasak> From memory, armadaxp and highbank in precise and quantal, and AIUI this bug is because omap4 is doing it.
<rbasak> (in raring)
<ogra_> i see -generic
<ogra_> which means omap3
<ogra_> which we dont even actively support
<ogra_> but yeah, that will need adjustment
<ogra_> to use uEnv.txt ... i guess it gets confused with the -generic kernel
<ogra_> i dont think we have any other arch but omap in generic currently
<NishanthMenon> uEnv.txt is now supported in u-boot upstream http://patchwork.ozlabs.org/patch/209925/
<NishanthMenon> for omap4
<ogra_> sicne a year or so
<ogra_> omap4 didnt change in ubuntu ...
<ogra_> still uses the quantal kernel
<ogra_> and will go on to do so (and vanish in 13.10)
<ogra_> but omap4 defaults to uEnv.txt since 12.10 anyway
<ogra_> (since the beginning of the 12.10 dev cycle actually)
<ogra_> rbasak, anyway, if you have an arch that doesnt support uEnv.txt, please make it use it ... if you cant you need to special case it in f-k-i and make it install mkimage
<rbasak> ogra_: has this change been documented anywhere? I wasn't aware that anything in flash-kernel had changed.
<rbasak> ogra_: and what in flash-kernel differentiates the two cases? Something in all.db?
<ogra_> there was a spec for 12.10 iirc
<ogra_> rbasak, nothing differentiates, the expectation is that by noiw all u-boot arches we support use uEnv.txt
<ogra_> thats why i say you need to special case or fix your u-boot
<rbasak> ogra_: so how is it that omap3 and highbank/armadaxp in 12.10 manage to get flash-kernel to use mkimage?
<ogra_> omap3 doesnt
<ogra_> it uses uEnv.txt
<ogra_> and i never touched either of the other two, check the code in 12.10
<rbasak> So why does bug 1160360 happen when a call to mkimage fails?
<ubottu> bug 1160360 in lxc (Ubuntu) "flash-kernel failed in an armhf lxc container on ARM: /usr/sbin/flash-kernel: 214: /usr/sbin/flash-kernel: mkimage: not found" [Undecided,New] https://launchpad.net/bugs/1160360
<ogra_> err
<ogra_> why would you call mkimage in an LXC container ?
<ogra_> you should teach f-k about LXC :)
<rbasak> Well exactly. You tell me. You're telling me that flash-kernel does not call mkimage.
<rbasak> Yet it does.
<ogra_> it does what ?
<rbasak> Call mkimage
<ogra_> fix that then :)
<ogra_> you dont want f-k to even run in LXC
<rbasak> Yeah, that's a separate thing. I don't want f-k to even be installed in LXC
<ogra_> your container creation tool should put FLASH_KERNEL_SKIP=true into /etc/environment or some such
<ogra_> or yeah, dont install it at all if your deps allow
<rbasak> But what you're telling me about uEnv.txt conflicts with both my (limited) knowledge of flash-kernel and observed behaviour, and I don't understand why.
<ogra_> i would guess it uses a debian default fallback
<ogra_> ogra@anubis:~/Devel/packages/flash-kernel-3.0~rc.4ubuntu30$ grep uEnv db/all.db
<ogra_> U-Boot-Script-Name: uEnvtxt.omap
<ogra_> U-Boot-Script-Name: uEnvtxt.omap
<ogra_> use that for whatever arch you want to switch over (and make sure u-boot understands it ... by having a new enough u-boot)
<ogra_> i assume what you see with -generic is just a debian fallback since f-k doesnt know about -generic yet
<ogra_> and for LXC simply use the global var or avoid having it installed
<rbasak> So there's magic in these filenames?
<rbasak> Where's this magic documented?
<ogra_> there is a case statement in f-k (see the code)
<rbasak> I don't see it in the README
<ogra_> as i said, there was a spec for 12.10 ... i currently cant find ... and i sent a mail to ubuntu-devel whern it was switched
<ogra_> so file a bug about the README :) i didnt add it there
<ogra_> the code is pretty obvious though
<rbasak> Indeed. Now that I know it's there.
<ogra_> sorry for the missing docs ...
<rbasak> I see an email to ubuntu-devel on May 30 but no mention of this change.
<rbasak> And I don't recall a spec or a session
<rbasak> </grumpy>
<ogra_> rbasak, if you need mkimage, make sure it is in Optional-Packages in your db entry (that hanst changes since we got the new f-k from debian)
<ogra_> or in "Required-Packages"
<rbasak> I have no idea where I need mkimage or not.
<ogra_> Machine: Highbank
<ogra_> Kernel-Flavors: highbank
<ogra_> Required-Packages: u-boot-tools
<ogra_> Kernel-Flavors: armadaxp ...
<ogra_> Required-Packages: u-boot-tools
<ogra_> both arches you seem to care about have it
<rbasak> This issue is about the cloud image, eg. as used for lxc
<ogra_> right avoid f-k altogether there
<rbasak> Where I don't need flash-kernel at all. I'll look into the dependencies and see if we can ship without it.
<ogra_> if you cant, use the /etc/environment setting
<ogra_> thats what we added it for
<cjwatson> ogra_,rbasak: I think I saw an unresolved Debian RC bug about f-k Required-Packages not working properly
<ogra_> cjwatson, well, looking at flash-kernel-installer i wouldnt see how
<cjwatson> Nor did the bug report, but still
<ogra_> it just blindly installs them with apt-install
<cjwatson> Debian #693839
<ubottu> Debian bug 693839 in flash-kernel "debian-installer: kernel install fails on armel buffalo linkstation pro, missing uboot-mkimage" [Serious,Open] http://bugs.debian.org/693839
<cjwatson> feel free to investigate that; dinnertime here :)
<cjwatson> it sounds kinda related
<ogra_> argh
<ogra_> thats definitely a totally wrong fix
<ogra_> its like adding a hard dep on lilo on all kernel packages
<ogra_> because one could use it
<ogra_> ah, phew, Martin Michlmayr seems to have stopped it
<ogra_> argh
<ogra_> so now someone tell me why my disk on precise just got filled with several 100G
<seb128> ogra_, trying to do an offline copy of the internet? ;-)
<ogra_> seb128, not funny, it ate like 150G over 20min ... and i only have FF, xchat, evo and three terminals open
<ogra_> i still see write operations in the multiload indicator going on, but cant make out where they come from
<seb128> ogra_, try to run baobab or similar to see where the space went?
<seb128> ogra_, ls -l ~/.xsession-errors?
<ogra_> iotop shows nothing
<ogra_> GEEZ !
<ogra_> 34G
<seb128> that's not 150G
<seb128> but that's a start
<ogra_> (indicator-weather:3113): LIBDBUSMENU-GLIB-CRITICAL **: dbusmenu_menuitem_build_variant: assertion `DBUSMENU_IS_MENUITEM(mi)' failed
<ogra_> (indicator-weather:3113): LIBDBUSMENU-GLIB-CRITICAL **: dbusmenu_menuitem_build_variant: assertion `DBUSMENU_IS_MENUITEM(mi)' failed
<ogra_> GRR
<ogra_> that silly thing
<seb128> indicator-weather is quite buggy, and unfortunatly quite popular as well :-(
<ogra_> might be that there are somne steam games that have been updated in the bg without me noticing
<ogra_> that might be the other 100G, i only really noticed it within the last 20min
<ogra_> since i rebooted ... after doing a dist-upgrade today
<seb128> ogra_, run baobab and see what directories are taking space
<ogra_> running ... though i fear it wont get alkong with my levels of symlinks
 * ogra_ has a 3TB disk mount symlinked inside his home
<ogra_> seb128, that xsession-errors is only a few hours old ... people on precise will all fall over if they use the weather indicator
<ogra_> we should do an emergency revert of whatever changed
<seb128> ogra_, we had a few reports about it going crazy
<ogra_> else we will have funny easter bugmails
<seb128> ogra_, I don't think it's a new issue
<seb128> you just got unlucky that you hit that race/bug today
<ogra_> getting a 36G log within a few hours after reboot ?
<seb128> ogra_, well, it hit an error loop and is flooding your log at the capacity of your machine
<ogra_> right, i got a diskspace warning popup
<seb128> ogra_, but as said, it's not a new issue afaik, it's just not frequent, you just happened to hit it
<ogra_> never had that since i installed this machine
<ogra_> ok
<seb128> it's like winning the lottery
<ogra_> i thought it came with todays upgrade
<seb128> without the money :p
<ogra_> \o/
<ogra_> :(
<ogra_> oh, wow, i have a ~/.cache/tracker/ directory that has a few G ... from 2011
<slangasek> cool, nice to know that xsession-errors handling is LFS-clean
<slangasek> no truncated error logs for you!
<ogra_> haha
<ogra_> bah, smells like the evolution default folder changed
<ogra_> i have one 2G big ~/.evolution and a ~/.local/evolution that has 18G
<ogra_> heh, and baobab realyl doesnt get along with my symlink to my 3TB disk in ~
<ogra_> it counts the filled up space to the size of my home
<ogra_> but doesnt count the free space of the disk :)
<ogra_> oh, fun ... and removing ~/.xsession-errors doesnt seem to have any effect in df
<slangasek> yes, because it's still open for writing
<ogra_> even after two syncs
<ogra_> sigh ...
<slangasek> rm'ing a file doesn't free any space on the fs while there are still fds open to it
 * ogra_ logs out
<ogra_> yeah
<ogra_> that didnt go so well
<ogra_> my desktop machine is completely dead now
<ogra_> logging out didnt get me lightdm back ...  disk LED is constantly active, console switching doesnt work
<ogra_> (active as in wildly flickering, not solid)
<ogra_> given that this is a plain 12.04 with not much extra  software and i explicitly didnt tinker with it to retain the best stability i must say i'm pretty disappointed
<ogra_> (worked rock solid until todays upgrade)
<seb128> ogra_, what's the issue for login after you freed space?
<ogra_> well, no lightdm
<seb128> sudo restart lightdm?
<ogra_> i switched to tty1 and restarted it ...
<ogra_> didnt come up, cant switch consoles anymore
<seb128> ogra_, and you did 'tinker' it by installing indicator-weather...
<seb128> ogra_, sudo stop lightdm
<seb128> sudo lightdm
<ogra_> seb128, didnt tinker "much"
<seb128> is there any error?
<seb128> or check in /var/log/lightdm
<ogra_> i did what my mom or my sister would have done with such a machine ... i dont even use apt on it but resort to UI
 * ogra_ checks if ssh still works 
<seb128> right, the ENOSPACE handling is suboptimal :-(
<seb128> and the fact that error logs can file up the disk is a known issue
<ogra_> sudo lightdm returns immediately
<ogra_> though indeed i'm in via ssh
<seb128> is there a running instance?
<ogra_> there is no way tpo get to console
<seb128> rm .xsession-errors* and reboot maybe?
<ogra_> 8217 tty7     Ss+    0:00 /usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitc
<ogra_> i removed the log before loggin out
<seb128> df is showing space?
<ogra_> but yeah, i'll trigger a reboot via ssh
<ogra_> df shoows 40G free
<seb128> k, reboot I guess...
<ogra_> running already
<ogra_> ok, it is back
<ogra_> but this is seriously an experience i wouldnt want a normal enduser to have
<ogra_> without ssh i wouldnt have been able to recover cleanly (apart from the reset button indeed)
<seb128> yeah :(
<seb128> we use to have ubuntu booting/logging in fine on full disk
<seb128> but I don't think we did check that was still working over cycles
<seb128> so I'm not sure it still does
<ogra_> well, i'm not sure why lightdm didnt come up again
<seb128> me neither
<seb128> but you had an Xorg running according to ps
<ogra_> i did a df first before restarting it
<seb128> and vt changes were not working
<seb128> seems like your kernel was in a weird state
<ogra_> hmm, might be
<ogra_> i dont run the quantal stack ... just the plain 12.04 kernel
<ogra_> but havent had probs with that before
<seb128> could be a side effect of the full disk...
<ogra_> yep
<ogra_> well, at least xsession-errors doesnt grow anymore
<seb128> not likely you will run into the indicator-weather bug anytime soon
<ogra_> well, it crashed for the first half of precise since release ....
<ogra_> now it doesnt crash anymore but eats my disk at times
 * ogra_ will just write his own weather indicator some day ... i cant do worse i guess :P
<ogra_> slangasek, sooo ... there is that other precise bug i recently ran into ... (though i guess it shows on later releases too) ... and i wonder if we have a plan for it
<ogra_> slangasek, dpkg --add-architecture armhf ... breaks apt
<slangasek> breaks it how?
<ogra_> well, the logic is flawed, it tries to get security updates from security.u.c
<ogra_> and i'm still unsure what to file it agains
<ogra_> t
<slangasek> ogra_: WFM here... you just need to mess with /etc/apt/sources.list* to tell it which architectures are available on which source
<ogra_> i did a dpkg action, but that breaks apt
<slangasek> e.g.: deb [arch=amd64,i386] http://mirrors.cat.pdx.edu/ubuntu/ raring main restricted
<slangasek> deb [arch=armhf] http://ports.ubuntu.com/ubuntu-ports/ raring main restricted
<ogra_> slangasek, heh, indeed, i could tinker with it ...
<ogra_> and i know how to do that ...
<ogra_> but the occasional user doesnt
<slangasek> the occasional user won't be installing armhf binaries on x86
<ogra_> i think we should fix that somehow
<slangasek> this is a developer feature
<slangasek> well, we can fix it for later releases by getting armhf moved onto the main mirrors :)
<ogra_> heh, yeah ... only trying that since like 4 years now
<ogra_> i think we should omit security in case of ports arches on a low level
<ogra_> if we know we are "foreign"
<ogra_> devs can still add a sources.list entry but at least it wouldnt be broken by default
<slangasek> no, we're not going to hard-code rules about architecture:mirror mappings into apt
<ogra_> (i agree its a dev feature, i just think "broken by default" isnt the right thing)
<slangasek> apt giving you warnings about package files not being downloadable isn't really "broken"
<ogra_> i dont care about apt
<ogra_> update-manager and sw-center completely stop working
<ogra_> andi get a warning indicator icon
<slangasek> ah, yes
<slangasek> so that might be something that needs to be fixed in update-manager/update-notifier
<ogra_> right
<ogra_> (we could indeed just move armhf to the main archive ... that might be a good reason finally ... all former reasons infinity, davidm or i tried to bring up weren compelling enough apparently :) )
<ogra_> *weren't
<slangasek> I don't think this reason is more compelling than others
<slangasek> I thought we already had agreement that armhf should be moved to the main mirrors
<ogra_> dont trash my hope :)
<ogra_> when did that happen ?
<slangasek> "Months ago"
<slangasek> I think it just hasn't been a priority to make the move happen
<ogra_> veerytime i asked in the past there was this "no we dont want to make mirror admins grumpy" thing
<ogra_> *everytime
<slangasek> elmo: can you refresh my memory as to whether there are any remaining blockers for moving armhf onto archive.u.c?
<doko> seb128, are any more gnome/gtk updates expected this week?
<elmo> slangasek: say what now?
<slangasek> elmo: well, last time robbiew was asking about it (because of cloud archive-y reasons), he seemed to think it was blocked by concerns from the archive admins... I redirected him to "IS" and never heard anything more :)
<robbiew> whoa
<robbiew> slangasek: pgraner took it ;)
<slangasek> hah what
<robbiew> slangasek: talk to pgraner...it was sitting with him
<ogra_> LOl
<ogra_> seems i triggered something ... sorry :)
<slangasek> robbiew: seriously?  how did "Do we have enough space on mirrors to move armhf to archive.u.c" become pgraner's problem? :)
<slangasek> pgraner: can we move armhf to the main mirrors? :)
<elmo> slangasek: the answer is the same answer it's been for the last N years.  moving armhf to archive.u.c will bloat archive.u.c; this will a) cost Canonical more money (from expanding the expensive HW used to run archive.u.c), b) cost mirrors more money, c) cause an unknown but I suspect non-trivial number of mirrors to stop mirroring Ubuntu, d) cost Canonical more money in bandwidth bills because of (c)
<elmo> slangasek: every time it's come up previously, we've run the usage numbers of arm* and it's never remotely been justifiable
<infinity> slangasek: Yeah, I don't remember anyone agreeing "months ago" that it should be moved.  We agreed to move the images, and the server team agreed to fix their broken scripts that assumed all arches live on the same mirror.  That's the last time I remember it coming up.
<infinity> It's rather unfortunate that the hackish way one does multiarch in sources.list made this a much uglier and more noticeable issue than it ever was before, but I'm not sure "weird apt config files" should force anyone's hand here. :/
<slangasek> infinity: it was "agreed" in the sense that there was nothing on the UE side that should block such a change
<slangasek> elmo: ok, I didn't understand that it still had an impact on the costs for archive.u.c
<infinity> Kay.  This must have come up again after the MaaS context?
<infinity> Cause I sure do hope "we'll move it to archive.u.c soon" wasn't used as an excuse to not fix the MaaS mirror assumption bugs.
<slangasek> infinity: I think it was in the maas context
<slangasek> my understanding was that the maas bugs were being fixed regardless
<infinity> (Which will just bite them ALL OVER AGAIN with arm64 or x32, or...)
<infinity> And, in fact, the cross-building/multi-arch developer story gets to go from "being crap on armhf" to "being crap on arm64" soo too, so the latest darling misfeature people hope to fix won't be fixed by moving armhf. ;)
<infinity> s/soo/soon/
<seb128> doko, gtk: no, gnome: some bug fixing, nothing that should impact builds if that's the question
<doko> ok, thanks
<seb128> yw ;-)
<doko> xnox, ScottK; iiuc you need at least a partial kde rebuild for the next test rebuild?
<doko> infinity, do you plan to update eglibc to the branch before the freeze?
<infinity> doko: Yeah, I'll do a pull and see if there's anything interesting.
<Reezz> Hey guys, any ideas on why I would get a SIGSEGV in the cogl lib? http://pastebin.com/7nJBUG4v
<seb128> Reezz, try asking on #gnome-hackers on irc.gnome.org rather
<Reezz> k, i'll give that a go :)
<Reezz> seb128: kind of a dead channel :/
<seb128> Reezz, welcome to IRC
<seb128> it's an async communication channel, people come and go
<seb128> you are after european hours and might in u.s midday break time
<Reezz> Well, really now? Thanks for the update
<Reezz> Urgh, douchebags
<ScottK> doko: Because?
#ubuntu-devel 2013-03-27
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso
<xnox> ScottK: doko: I don't see a reason for that, either. Mind sharing your train of thought here?
 * ScottK didn't either.
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<DigvijayUbuntu> Hello people
<DigvijayUbuntu> I needed help understanding how the ubuntu-software-center code is layout
<DigvijayUbuntu> any pointers on where i can start?
<sarnold> DigvijayUbuntu: I really love ctags, id-utils, and cscope
<DigvijayUbuntu> sarnold: i am a bit confused
<DigvijayUbuntu> so you can help me?
<sarnold> DigvijayUbuntu: I can try :) hehe
<DigvijayUbuntu> ok greate =)
<DigvijayUbuntu> wait lemme pm u
<pitti> Good morning
<tvoss> pitti, good morning :)
<vibhav> guten morgen
<tvoss> guten morgen :)
<KeithW> Hello folks. We just released mosh 1.2.4 and uploaded 1.2.4-1 to Debian. What is the appropriate way to respectfully request a sync to Ubuntu raring (universe) and a FFe to make the release?
<infinity> KeithW: Point me at a 1.2.3 -> 1.2.4 changelog?
<KeithW> infinity: http://mailman.mit.edu/pipermail/mosh-devel/2013-March/000447.html
<infinity> KeithW: Looks good to me, syncing.
<infinity> Or... I would if LP knew about the version in unstable yet. :P
<infinity> I'll sync when it does.
<infinity> KeithW: FWIW, I would have called the mm:ss disconnect display a bugfix, not a feature.  Being offline for eighty bazillion seconds has always annoyed me. :P
<KeithW> :-)
<KeithW> Thanks much!
<dholbach> good morning
<dholbach> can somebody from the desktop people reply to https://twitter.com/larsschuetze/statuses/316652779605225473 maybe? :)
<mardy> thomi: ping (need some help with autopilot)
<mardy> dholbach: hi! Do you know how to write autopilot tests?
<dholbach> mardy, I'm afraid not - I wrote an autopkgtest once though :)
<mardy> dholbach: do you know anyone who could help me, who is currently online? It's a rather newbie-like question, I presume
<dholbach> mardy, maybe just best ask the question?
<dholbach> pitti, Mirv: ^ do you know much about autopilot?
<mardy> dholbach: let's try :-)  How do I wait till an application becomes visible, after calling start_app()?
<pitti> mardy: perhaps you can pick a particular widget and use Eventually() to wait until its visible property becomes tru?
<pitti> true
 * pitti only did some baby steps with autopilot as well, I'm afraid
<Mirv> dholbach: I can run the autopilot tests of unity and tweak if something fails, but not that much. I'd take a look at unity autopilot tests for a basis.
<mardy> pitti: I'll try -- but I guess that I won't be able to get a handle to any widget, until the window is created
<Mirv> mardy: Eventually seems to be used in Unity..
<mardy> Mirv: I tried that, but on what property? "user_visible" doesn't work ("Eventually is only usable with attributes that have a wait_for function or callable objects.")
<mardy> funny thing is that none of the tests in http://bazaar.launchpad.net/~ubuntu-testcase/ubuntu-autopilot-tests/trunk/files/head:/ubuntu_autopilot_tests/ check for the window visibility
<mardy> maybe start_app() actually waits for the window visibility itself?
<dholbach> seb128, salut - do you know who could reply to https://twitter.com/larsschuetze/statuses/316652779605225473?
<seb128> dholbach, salut
<seb128> looking
<seb128> dholbach, you could reply? ;-)
<dholbach> no
<dholbach> I don't know the answer
<seb128> no reason we can't if there are applications proving good enough
<seb128> I don't see qml equivalent/replacements of our desktop core apps atm though
<seb128> but I'm pretty sure that will happen in the futur, hard to predict when and what apps though
<thomi> mardy: Hi
<dholbach> seb128, ok
<thomi> mardy: did you get your problem resolved?
<mardy> thomi: hi! Just trying to write some autopilot tests for Online Accounts, and I've a few questions :-)
<mardy> thomi: does the start_app() actually wait for the window to be visible, before returning?
<thomi> mardy: hmmm, let me check
<mardy> thomi: none of the tests in http://bazaar.launchpad.net/~ubuntu-testcase/ubuntu-autopilot-tests/trunk/files/head:/ubuntu_autopilot_tests/ is waiting for that, they all seem to assume the window is already available
<thomi> mardy: it doesn't check for window visibility inside that method, no. I belive some of the tests have their own way of checking that the application has been initialised
<thomi> which would be the correct way to do it
<thomi> since an application window can be visible, but not initialised yet
<thomi> mardy: so Ideally you'd start the app (via launch_test_application), and then read application state to ensure that it's been set up correctly
<mardy> thomi: OK, the second question is: are start_app() and launch_test_application() completely separate? or can I get an ApplicationProxyObject froma BamfApplication object?
<thomi> mardy: they are completely separate, and no, you can't. launch_app just starts the application normally, whereas launch_test_application does the "magic glue" that allows autopilot to introspect the application
<mardy> thomi: well, I guess that if I use launch_test_application() directly, the question above doesn't even apply
<mardy> thomi: OK, now it's clear. Thanks! :-)
<thomi> mardy: lots of people make that mistake, and we're making it clearer in newer versions of autopilot :)
<thomi> the launch_app methods are there if you want to test how your application interacts with opther apps.... which is really useful if you happen to be testing a desktop shell =)
<thomi> autopilot is showing it's lineage :)
<thomi> mardy: It's getting late here, so I'm going AFK. If you run in to any other problems, feel free to dop me an email: thomi.richards@canonical.com
 * thomi waves
<mardy> thomi: mmm... just got one more question :-) Are my "print" statements eaten up somehow?
<mardy> thomi: actually, it seems that launch_test_application() never returns
<mardy> thomi: nevermind, I was missing libautopilot-gtk :-)
<vrodic> why is ubuntu insiting on trying to ship outdated versions of mesa. 13.04 only has 9.0.3, but drivers in 9.2 are much better
<cjwatson> seb128: we seem to have a gnome-settings-daemon that breaks the current version of indicator-datetime, and no new indicator-datetime - do you know what's up with the latter?
<cjwatson> looks like policykit-desktop-privileges and gnome-settings-daemon aren't currently coinstallable so image builds are failing as a result
<seb128> cjwatson, yeah, cyphermox was supposed to autoland indicator-datetime to go with the other bits and didn't for some reasons :-(
<seb128> cjwatson, I'm looking at it
<cjwatson> seb128: thanks - can you let me know when it's landed so I can retry image builds, please?
<seb128> cjwatson, will do, sorry about the issue
<seb128> cjwatson, I overlooked that britney was not checking for installability to migrate stuff, when I uploaded I though it would stay in proposed until the breaks were resolved
<cjwatson> seb128: it checks for installability, but not coinstallability of arbitrary sets
<cjwatson> seb128: (which gets into the seriously NP-complete side of things, never mind being exception city :) )
<seb128> cjwatson, was there any discussion about checking for installability of ubuntu-desktop?
<pitti> isn't that pretty much what daily live fs builds do?
<seb128> or (*)ubuntu-desktop
<pitti> (installing ubuntu-desktop and telling us about failures)
<seb128> pitti, I was talking about plugging the result of that check in britney's migration
<pitti> tricky; britney would take ages with that, I guess
<cjwatson> seb128: we do check for installability of ubuntu-desktop
<seb128> pitti, we broke daily iso with an uncomplete transition
<cjwatson> seb128: we don't check for installability of the ubuntu-desktop *task* (i.e. including all Recommends)
<cjwatson> you've fallen into the crack there
<cjwatson> You can tell this because http://people.canonical.com/~ubuntu-archive/testing/raring_probs.html doesn't show ubuntu-desktop as uninstallable
<cjwatson> It might be worth generating some kind of per-task virtual packages that depend on everything in each task
<cjwatson> Though we'd have to be careful about when the task changes
<cjwatson> Or we could get proposed-migration to promote Recommends to Depends selectively or something ...
<cjwatson> All seems fairly hackish but I suppose possible
<seb128> yeah, I'm not sure what is best either...
<seb128> cjwatson, I'm going to do a manual upload for indicator-datetime, utah seems to be out of order on the daily builds
<seb128> e.g http://10.97.0.1:8080/job/ps-indicators-autopilot-release-testing/183/label=autopilot-nvidia/console
<cjwatson> seb128: got it, thanks
<mardy> pitti: any idea how I can introspect a GtkTreeView contents in autopilot? I don't see the "model" property there...
<pitti> mardy: no, I don't; unfortunately autopilot-gtk is rather limited right now
<mardy> pitti: OK, tough luck :-) I'll file a bug in the meantime, let's see how it goes...
<seb128> cjwatson, indicator-datetime uploaded/built everywhere, I guess it just need to be published and to be moved to raring proper with gnome-settings-daemon and we should be ok for the iso
<seb128> cjwatson, we will need systemd-services/systemd-shim promoted as well (MIR are approved, we just need to promote the binaries)
<cjwatson> seb128: ok, cool, I'll keep an eye on the hints
<cjwatson> and I'll go and poke those MIRs
<dholbach> pete-woods, AFAICT sphinx-voxforge-en looks good - it might be worth to put your comment (#10) from the bug report into either debian/copyright or debian/watch or maybe both to make it clear where the files are coming from and how they are constructed... also in case somebody else might want to update/fix the package and should not know how to go about it
<dholbach> pete-woods, if you reupload the source package (or somewhere else) with that fix, you should just have to update the .dsc and .debian.tar.gz file - I can then upload it for you
<pete-woods> dholbach: thanks for the review. I will put some more information in the debian/watch file - at the moment it doesn't mention the training tool I write
<cjwatson> seb128: I can't find the MIR for systemd-services - can you point me at it?
<pete-woods> *wrote
<seb128> cjwatson, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1152187
<ubottu> Launchpad bug 1152187 in systemd (Ubuntu) "[MIR] systemd" [Undecided,Fix released]
<seb128> cjwatson, comment #12 has the ack
<seb128> cjwatson, and #14 from security
<cjwatson> seb128: oh, it's closed, ok
<cjwatson> seb128: moved all those to main now
<seb128> cjwatson, thanks a lot
<cjwatson> seb128: looks like it's been promoted now
<seb128> cjwatson, good, I just got the launchpad emails that indicator-datetime and gnome-settings-daemon moved to raring
<pete-woods> dholbach: did you see my comment on the sphinxtrain package? (https://bugs.launchpad.net/ubuntu/+bug/1144015)
<ubottu> Launchpad bug 1144015 in Debian "[needs-packaging] New package sphinxtrain" [Unknown,New]
<pete-woods> it's not installable in the state in the bug tracker
<pete-woods> I can't update it myself, as you already have extra changes in there
<pete-woods> (also have learned by 0ubuntu1 lesson :) )
<vibhav> Do we need a FFE for syncing ncpfs?
<vibhav> http://packages.debian.org/changelogs/pool/main/n/ncpfs/ncpfs_2.2.6-9/changelog , if anyone wants to read the changelog
<vibhav> (the latest release fixes from critical bugs though)
<tumbleweed> vibhav: the latest release has also been synced
<tumbleweed> it's from november
<vibhav> wierd, ubuntuwire still shows it.
<vibhav> (must be update lag)
<tumbleweed> probably because it's stuck in -proposed
<vibhav> ah
 * vibhav takes a look
<vibhav> yes, it is
<vibhav> tumbleweed: thanks
<tumbleweed> vibhav: in fact, IIRC, I even commented about why it's stuck on the rcbugs page on ubuntuwire
<tumbleweed> it looked non-trivial, but we should unstick it
<vibhav> tumbleweed: yeah, I saw it
<mlankhorst> oops
<mlankhorst> can someone delete the xxv-modesetting upload I did? forgot to fixup distro
<pitti> mlankhorst: where did you upload it to?
<mlankhorst> precise-proposed
<pitti> mlankhorst: seems someone already removed it, or the upload was rejected
<pitti> https://launchpad.net/ubuntu/precise/+queue?queue_state=1
<mlankhorst> probably in new
<mlankhorst> yeah
<mlankhorst> I don't think precise had the modesetting driver :)
<cjwatson> mlankhorst: rejected from NEW
<mlankhorst> ty
<ogra_> xnox, for your switch back to metacity, dont we also need to seed it again ?
<xnox> ogra_: don't think so. compiz uses libmetacity to draw decorators. so 2/3 binary packages from src:metacity was still on the cd anyway.
<ogra_> just wanted to make sure ...
<xnox> ogra_: and today's image wasn't build yet (due to respin with g-s & stuff) so will be testing once it lands.
<ogra_> ++
<leagris> Hey, hello
<leagris> Themuso, I wanted to reach you if you have a little bit time to talk about Ubuntu low sight accessibility
<cyphermox> seb128: tests failed, the autopilot vms exploded overnight, that's why it didn't land
<seb128> cyphermox, ok, would have been nice to do a manual upload to unbreak installability of the desktop/cds
<seb128> cyphermox, but no worry, we sorted it out this morning
<cyphermox> would have been, but you asked and I was no longer around
<cyphermox> sorted it how? is there something to merge back into indicator-datetime now?
<leagris> For all, I have strong concerns if Compiz E-Zoom could dissapear in the next ubuntu releases (while dropping Xorg). EZoom is the best suited screen magnifier for my 10% signtness. Comparing to Gnome Orca magnifier or its KDE counterpart or even the closed source world. Ezoom is responsive, smooth, easy and work anywhere even with full screen applications.
<seb128> cyphermox, I did a manual upload of lp:indicator-datetime/13.04 to raring
<cyphermox> seb128: ok!
<seb128> cyphermox, so I guess yes, we will need that merged back (or overwritten, I don't care much about the changelog entry)
<dholbach> pete-woods, I'm not sure what this means......... is the bug fixed already?
<cyphermox> seb128: yeah, I'll just merge it and it's going to be fine
<seb128> cyphermox, thanks
<seb128> cyphermox, the utah guys looked at their issue this morning and retried the tests, which failed because systemd-services was not promoted yet, I retried again
<pete-woods> dholbach: sorry, I got my wires crossed and contacted the wrong person about it :$
<dholbach> pete-woods, ok... no worries :)
<cyphermox> it failed again in this case :)
<seb128> cyphermox, indeed :-(
<seb128> one day utah will work for more than 2 runs in a row
<ogra_> wishful tinking :)
<mlankhorst> slangasek: can I reassign bug 982889 to you?
<ubottu> bug 982889 in lightdm (Ubuntu) "X trying to start before plymouth has finished using the drm driver" [Critical,Confirmed] https://launchpad.net/bugs/982889
<slangasek> mlankhorst: if you wish... but I'd also be happy for you to follow through on it :)
<mlankhorst> I don't trust myself touching upstart on other computers
<slangasek> why is update-manager upgrading packages that it's not showing me in the details list?
<ScottK> It's an over achiever?
<slangasek> ... specifically, packages that I'm hacking on locally and want to hold back but have not done a dpkg hold on, expecting update-manager to let me unselect them
<xnox> slangasek: talk to mpt. It's the new design saying that "technical packages" are lumped together into "Core OS" item.
 * xnox looks for the wiki / definition page.
<slangasek> xnox: there's a "Base OS" pulldown that lets me see lots of packages... but not the ones I care about
<slangasek> libdbus - listed.  libdecoration0 - not listed
<slangasek> "Ubuntu base", it's called here
<xnox> slangasek: https://wiki.ubuntu.com/SoftwareUpdates#Expanded_presentation_of_updates
 * xnox upgrades using cmd-line only =/
 * xnox ponders if I should be using the "normal" updates method
<slangasek> xnox: yes; I assert that, even within the context of that design spec which I disagree with, the current behavior is buggy because I have no way at all to see and control the complete list of updates being installed
<blitzkrieg3> does anyone have a good way to test the timezone picker in ubiquity?
<xnox> blitzkrieg3: please explain more? to test what?
<xnox> (it has geoip detection, visuals/timezone highlights, setting correct timezone for the target user, offline geoip-less mode)
<xnox> it's actually a few things the meat of the timezone picket is libtimezonemap which is also used by gnome-control-center as the time picker.
<KeithW> I am impressed that you guys synced mosh 1.2.4 and correctly reverted the appropriate commit to fix the FTBFS on armhf with no drama!
<coderanger> Anyone know if apt (10.04+) actually still uses the MD5 and SHA1 fields in repos?
<coderanger> Guessing it is just crufty old stuff and everything hopefully uses the sha256 sums now, but I've not looked into the apt source
<sarnold> coderanger: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1098738
<ubottu> Launchpad bug 1098738 in apt (Ubuntu) "apt-get source only checks md5 hashes in Sources files" [High,In progress]
<coderanger> sarnold: I haz a sad now
<coderanger> Will include all of them then, thanky
<infinity> KeithW: Oh, I was going to make drama for you, but you weren't online. :P
<KeithW> infinity: Haha, well, impressive! We just pushed 1.2.4a to Debian to do the same thing.
<infinity> KeithW: Didn't feel like fixing the broken test code instead?  The revert was just the path of least resistance for me. :P
<KeithW> We already had our own end-to-end test of OCB with the same test vectors in src/tests, so it didn't seem worth it. The real problem was that the built-in ocb.cc test doesn't even give a bad return code on failure, so it wasn't even working for us as an automated test!
<infinity> KeithW: Hah.  Smooth.
<infinity> KeithW: Alright, I'll resync 1.2.4a-1 over my upload later, then.  After I've seen it build on all the Debian buildds.
<infinity> KeithW: (Which I should have checked before doing the sync for you before, mea culpa)
<KeithW> Ok, I think your existing 1.2.4 is fine (the only relevant changes in 1.2.4a warnings on RHEL 5 and ARM/MIPS/s390 that failed the build), but also fine if you want to sync it.
<KeithW> Er, the only changes in 1.2.4a are to fix build warnings.
<infinity> Oh, I'm sure mine's fine, I'd just sync it to get it off my plate, so it autosyncs correctly again later.
<infinity> (We don't autosync packages with Ubuntu changes, for obvious reasons)
<KeithW> Oh, ok. Sounds good.
<xnox> Mirv: when are you planning to upload qt5 again? I really want the Gtk theming fix in, but there are a few more things stagged in the bzr branch.
<ScottK> xnox: What and is it upstream?
<xnox> ScottK: don't panic. We missded -gtkstyle & libgtk2.0-dev build-dep in qt5 package vs qt4 package, hence gtk theming support didn't build and right now qt5 hello world app looks like it's from 1987
<ScottK> OK.
<ScottK> What are the few more things?
<sarnold> (can we keep that as an option? :)
<xnox> ScottK: see unreleased stanza: https://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src/view/head:/debian/changelog
<xnox> ScottK: also do you have highlight on my nick or just on "qt" ? =)
<ScottK> Just happend to notice.
<ScottK> OK.  Not too scary.
#ubuntu-devel 2013-03-28
<vsingh165> does anyone know how I can build libreoffice with unity menu integration from the git sources?  I know how to do make dev-install, etc but not sure how to get it with unity menus.
<micahg> infinity: I never saw the chromium armhf fix go in, so since we're close to beta 2, I'm going to have to upload just to drop the spurious recommends
<infinity> micahg: Can you nag Chris about it?  But yeah, go ahead and do that anyway.
<micahg> infinity: I don't see him at the moment and might not be available online before beta 2
 * infinity nods.
<infinity> I'm on VAC until next week too, but I'll see if I can catch up with him.
<infinity> It needs to be fixed before release.
<micahg> ok
<Mirv> xnox: didrocks hasn't wanted to have the GTK style support build in before the appmenu-qt5 is in, since he's seeing some graphical corruption in menus with the style support in (a graphics driver issue, but he has relatively common model nevertheless - hasn't been checked for ca. two weeks or so)
<Mirv> we didn't find other machines having the menu problem though either, or hear from the qt5-beta-proper users, but still.
<Mirv> now the appmenu FFe has however been approved, so we can proceed after required testings
<dholbach> good morning
<tvoss> seb128, ping
<seb128> tvoss, hey
<tvoss> seb128, good morning :) quick question: how can I find out if a fix to a debian package has propagated to ubuntu?
<tvoss> seb128, bug and fix in question are here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701779
<ubottu> Debian bug 701779 in lttng-tools "Fails to install due to missing library (in dependency?)" [Grave,Fixed]
<tvoss> seb128, happy to look myself if you can give me some pointers :)
<seb128> tvoss, good morning to you too, sorry was away some minutes
<tvoss> seb128, welcome back then :)
<seb128> tvoss, there is no easy "is that debian bug fixed in ubuntu" check, basically look at the debian bug and what version of the package fixed the issue and look at what is in ubuntu
<seb128> tvoss, or "pull-lp-source <source> raring" and look at the content of the package
<tvoss> seb128, ubuntu is quite outdated when compared to debian :/
<seb128> tvoss, it means nobody merged that one on debian or synced it
<tvoss> seb128, just found a ppa, hold on
<tjaalton> it could probably be synced at this point
<tjaalton> new upstream pushed to ubuntu last summer
<tjaalton> not touched since
<geser> tvoss: it got removed in the past (during precise development), see the deletion comment at https://launchpad.net/ubuntu/+source/ltt-control/+publishinghistory (expand the first entry)
<tvoss> geser, agreed for the ltt-control package, but seems like lttng-tools suffer the same issue, looking at that right now and testing the lttng ppa
<tjaalton> can't it just be synced now? new lttng-tools builds ltt-control
<geser> tjaalton: does it work now? and someone has to fix the FTBFS first
<tjaalton> ftbfs?
<geser> see https://buildd.debian.org/status/fetch.php?pkg=ltt-control&arch=i386&ver=2.1.1-1&stamp=1362096027
<tjaalton> oh, good point :)
<tjaalton> didn't know that
<geser> tvoss: lttng-tools are build from the ltt-control source package
<tvoss> geser, the ppa works, just tested on raring
<tjaalton> yeah I got those wrong, was the other way around
<mpt> slangasek, update-manager should certainly never update a package without listing it. That would be a bug, not a design flaw.
<geser> tvoss: once someone fixes Debian bug #701976 (either directly in Debian or a patched package for sponsoring) and a FF exception is granted (we are past Feature Freeze) then it could get into raring
<ubottu> Debian bug 701976 in src:ltt-control "ltt-control: FTBFS: /usr/bin/ld: tp.o: undefined reference to symbol 'rcu_dereference_sym'" [Serious,Open] http://bugs.debian.org/701976
<tvoss> geser, okay, I will look into it ... final missing piece: the lttviewer, cannot see it in the ppa
<geser> is it packaged in Debian?
<tvoss> geser, not sure, searching
<seb128> tvoss, geser: http://packages.qa.debian.org/l/lttv.html
<seb128> it's in raring as well
<tvoss> seb128, sure, cannot see it
<tvoss> ?
<geser> it got removed from the archive for the same reason as ltt-control
<seb128> tvoss, oh, sorry, misread that indded
<seb128> tvoss, https://launchpad.net/~lttng/+archive/daily has builds for quantal, not sure if they didn't enable it for raring on purpose
<mpt> ev, thanks to ant, <https://wiki.ubuntu.com/ErrorTracker#error-types> now has cell borders and should be easier to follow
<ev> yay
<mpt> (apart from Gecko's long-standing problem where cell borders sometimes disappear after scrolling)
<mpt> ev, and I guess we need to update all the "(targeted for 13.04)" cells
<ev> yes
<ev> on it
<ev> I think I'll take the reminder that apport is a thing and fix some bugs in it
<seb128> hum
<seb128> I've a package install "stalled"
<seb128> "perl -w /usr/share/debconf/frontend /var/lib/dpkg/tmp.ci/preinst install" seems blocked in a read (from strace)
 * tvoss notices that the eclipse version in the repo is quite outdated
<ogra_> there is one in the repo ?
<ogra_> i thought we dropped that
<geser> tvoss: the eclipse version in raring is the same as in Debian testing/unstable, and the version from experimental (3.8.1-1) is waiting in raring-proposed on someone to fix the build failure on armel and armhf before it can get moved to raring
<tvoss> geser, ack and thx
<tvoss> has anyone been working the lttng eclipse integration?
<shadeslayer> seb128: ping
<shadeslayer> seb128: I'm curious as to how empathy spits out the mcp-account-manager-uoa deb, since you uploaded it last, any ideas?
<shadeslayer> the control file has no entry for mcp-account-manager-uoa
<shadeslayer> my guess is debhelper.mk is doing some magic?
<shadeslayer> ahh nvm
<shadeslayer> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/empathy/raring/view/head:/debian/control doesn't list the entries for me for some reason
<mitya57> shadeslayer: lp:ubuntu/empathy is out of date
<geser> shadeslayer: see the top entry in the changelog
<geser> shadeslayer: http://package-import.ubuntu.com/status/empathy.html#2012-09-06%2020:53:54.256127
<geser> shadeslayer: use https://code.launchpad.net/~ubuntu-desktop/empathy/ubuntu instead
<maxb> Would you like me to poke at that import or is it essentially irrelevant since there's a human-maintained branch instead
<maxb> ?
<shadeslayer> ah
<shadeslayer> thanks mitya57 & geser
<maxb> UDD has never really found a workable path in the aftermath of source format 3.0
<shadeslayer> now I'm curious, should mcp-account-manager-uoa depend on empathy?
<shadeslayer> same for all of the other account-plugin-* stuff
<shadeslayer> if it's for MC any telepathy client can use it, so why a hard dependency on empathy?
<apw> infinity, we are seeing some dpkg issues, and wondering if there is an api change there ie us using it wrong or if it is generally broken
<apw> infinity, https://launchpadlibrarian.net/135490864/DpkgTerminalLog.txt
<cjwatson> apw: that sort of looks like having lost a file descriptor somewhere.  do you have a way to reproduce it?
<cjwatson> I'd suggest sticking set -x in the preinst and running with DEBCONF_DEBUG=developer if so
<cjwatson> (set -x'ing preinsts is painful if you can't inject a test .deb, unfortunately)
<apw> cjwatson, will have a go indeed
<apw> cjwatson, we are seeing a bunch of lp bugs being filed on this
<apw> jsalisbury, ^^ can we see if this is reproducible ...
<jsalisbury> apw, sure, I'll give it a shot on one of my machines
<FourDollars> Hi, could somebody help me to review https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/1160414? Is there anything I missed?
<ubottu> Launchpad bug 1160414 in ibus-chewing (Ubuntu) "Use shift keypress to switch to English mode." [Undecided,Confirmed]
<mitya57> Hi Riddell, you know that qtwebkit-sources 2.3.0 is stuck in -proposed, right?
<mitya57> if we can't fix that, maybe it'll be a good idea to force-copy it to -release
<cjwatson> doesn't look like it should be horribly difficult to fix?
<Riddell> mitya57, cjwatson: needs working out the magic to make it stop trying to compile that javascript engine on powerpc, I'll ask again about it but I'm not wanting to spend much time on powerpc issues
<cjwatson> well I can hack on it on Adam's fast powerpc system given a general pointer
<mitya57> Is it the same javascript engine that 4 previous uploads were trying to disable?
<cjwatson> I mean it only takes 20 minutes to fail on adare (which is ancient)
<mitya57> :D
<Riddell> mitya57: that's the one
<mitya57> Weird. As 2.3-0ubuntu8 doesn't have powerpc packages built, forcibly copying the new version shouldn't break anything, so I think it should be done.
<mitya57> ... while we are not frozen
<cjwatson> it might not break but I always prefer to try to fix things first
<cjwatson> (also, even if it comes to that, archive admins should never forcibly copy to raring but should use britney hints instead)
<mitya57> I meant something like that, yes.
<cjwatson> and should always use the minimum possible force so that we find out about problems they might not have thought of
<infinity> apw: I'm on vacation all week, but I'd suggest getting Colin's input on that bug.
<mitya57> FourDollars: looks OK
<FourDollars> mitya57: Thank you. I have asked bdmurray in #ubuntu-release to help me to upload the package.
<bdmurray> xnox: your openssl upload to precise was superceded by a security upload
<xnox> bdmurray: yeah, I know. You can reject both of them for now. I will reupload when I have time to rebase the patch, hopefully sometime this week.
<mdeslaur> xnox: sorry about that :(
<bdmurray> xnox: okay
<xnox> mdeslaur: 13th time lucky maybe ;-)
<mdeslaur> hehe :)
<bdmurray> xnox: ping me when you have one ready to review
<xnox> ack.
<Riddell> cjwatson: could you try this on powerpc? http://people.ubuntu.com/~jr/tmp/qtwebkit-source_2.3.0-0ubuntu2.dsc
<infinity> Riddell: Testing.
<qengho> Hi hi.  I have a problem.  In raring we want users of (chromium-browser + unity) to automatically have webaccounts-chromium-extension and unity-chromium-extension installed.  But, those packages Depend on lots of things that users of things other than unity do not need, so a Recommends in chromium-browser might pull in a lot of stuff that's unwanted.  What's the best way to get packages installed for unity + chromium-browser users, but not necessarily
<qengho>  others?
<slangasek> mpt: then we agree ;)
<mpt> yep
<xnox> qengho: there is no easy way. Are the extensions by them self small? I'd recommend to install the chromium extenstions by default with unity, but they'd do nothing unless people install chromium browser.
<xnox> E.g. treat those extenstions to be part of unity =)
<infinity> That's probably the only way to achieve what you want, yes.
<infinity> Of course, then they'd need to drop the depends on chromium.
<qengho> Right.  Move that to Enhances?
<infinity> And we'd have to make sure they get registered with chromium regardless of installation order.
<qengho> Order doesn't matter, already.
<infinity> Kay, then yeah, move the Depends to an Enhances, and then pull them into the desktop seed or something.
<infinity> It's an unfortunate bit of cruft on non-chromium desktops, but there's no good way to express the "if foo and bar are installed, I also want baz" relationship.
<infinity> Well, there are ways to *express* it (like Enhances), but there are no ways to *enforce* it.
<qengho> Maybe a mutual Suggests and Enhances could be as weighty as a Recommends.
<infinity> Something tricky like that could work, if you feel the urge to bring it up with debian-devel and policy types.  Certainly not a good quick fix. :P
<infinity> Riddell: Fairly sure my test build is already past the point of the last failure.  I'll let it carry on to completion, though.
<infinity> cjwatson: ^
<qengho> xnox, infinity, thank you for your help.
<infinity> Riddell: If it completely successfully, want me to just sign and upload it?
<infinity> s/completely/completes/
<qengho> unity+chromium-browser talk continues in #ubuntu-desktop.
<Riddell> infinity: groovy, go for it
<cking> are there any know compiz issues with today's updates?  apw's desktop is hosed
<seb128> bdmurray, hey
<seb128> bdmurray, https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1071922/comments/24
<ubottu> Launchpad bug 1071922 in OEM Priority Project precise "double tap does not open folders or files in Nautilus" [Medium,Fix committed]
<seb128> bdmurray, do you just look for any report make by users running that version?
<bdmurray> seb128: for any bug reported by apport with people using that version yes
<seb128> bdmurray, ok, makes sense, thanks
<seb128> bdmurray, if I marked the other bug as duplicate of an old bug I don't need to tag it stop-nagging, right?
<bdmurray> seb128: someday it'll check errors for crashes that first appeared with that specific version of the package too
<bdmurray> seb128: I'll double check the logic but you shouldn't need to tag it
<seb128> bdmurray, ok, thanks
<infinity> Riddell: Your qtwebkit build was happy on my machine; uploaded.
<mitya57> Riddell: you fixed it? congrats! \o/
<cjwatson> Riddell,infinity: ah, excellent
<rahulprasad> How do I create unity lens ?
<jpds> rahulprasad: https://developer.ubuntu.com/resources/technologies/lenses-and-scopes/
<rahulprasad> <jpds> Thanks
<hallyn> infinity: so i have a set of 5 source packages (mirroring the analogous powerpc ones mostly) at https://launchpad.net/~serge-hallyn/+archive/crossc/+packages which build a openbios-sparc, with which i can run qemu-system-sparc as sparcstation 10 target, and boot debian images.
<hallyn> i assume it's too late in raring cycle to try getting those in?
<infinity> hallyn: Being entirely new packages, if they're based on the same sources as the PPC ones, it's probably not a big deal to get them in.
<infinity> hallyn: But, it's much harder to justify yet another cross-compiler for an arch we don't even ship.
<hallyn> ok - i suppose they can sit in ppa for now, for anyone who really really needs it.
<hallyn> when s opens up, who do you think would be the right person to look at them for sanity check and maybe sponsor?
<infinity> hallyn: I can have a look at them.  If they're based on the arm{el,hf,64} and powerpc packages, a simple debdiff should show their relative sanity.
<hallyn> infinity: cool, thanks.  I'll leave a note to talk to you then
<infinity> hallyn: Well, per the above, I don't think it's "too late".  It's more about if we want them at all, now so much when.
<hallyn> infinity: oh.  i thought you meant we didn't want to deal with them now for that reason (i.e. priorities)
<hallyn> I suppose we could go the squeeky wheel principle and wait to see if bugs are raised about openbios-sparc not existing
<infinity> hallyn: I think the only bugs that have ever been filed have been from developers who were annoyed that it couldn't be built, not from users who needed full system sparc emulation on Ubuntu.
<infinity> hallyn: I could be wrong, though.
<hallyn> uh, beside bug 1125540 of course
<ubottu> bug 1125540 in qemu (Ubuntu) "openbios-sparc64 missing" [Low,Confirmed] https://launchpad.net/bugs/1125540
<infinity> hallyn: Also, lolwut?  Fixing https://bugs.launchpad.net/launchpad/+bug/217427 wouldn't fix the openbios-sparc bug. :P
<ubottu> Launchpad bug 217427 in Launchpad itself "Please support arbitrary arch/buildd affinity for arch:all builds" [High,Triaged]
<hallyn> infinity: i'm fine waiting to see if there is a lot of demand...
<infinity> Oh, you got there later in the bug log. :P
<hallyn> infinity: right, it wouldn't :)
<hallyn> not without a ... cash injection :)
<infinity> hallyn: I think that cash injection would have to be preceded by Oracle spinning off Sun again and letting them get back on their previous path.
<infinity> hallyn: In other words: HAHAHAHA.
<infinity> (I wouldn't say no to a Fujitsu-sponsored sparc port either, but also seems unlikely)
 * hallyn thinks back fondly on his sparcstation 1
<bdmurray> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bdmurray
<bkerensa> is there any reason ubuntu-minimal on Ubuntu Server requires bluetooth?
<bkerensa> imho cloud servers should not need bluetooth ;)
<bkerensa> cyphermox:  ^
<cyphermox> no idea
<cyphermox> sorry, I'm busy can you send me an email and I'll look it up?
<bkerensa> sure
<bdmurray> mdeslaur: can you unsubscribe security sponsors from bug 1155000?
<ubottu> bug 1155000 in almanah (Ubuntu Quantal) "[SRU] CVE-2013-1853: Almanah doesn't encrypt the database" [High,In progress] https://launchpad.net/bugs/1155000
<bdmurray> It's already in the Q queue.
<mdeslaur> bdmurray: it really should be built as a security update
<mdeslaur> bdmurray: is it already in -proposed?
<bdmurray> mdeslaur: no its in the unapproved queue for Q
<mdeslaur> bdmurray: can you reject it, and we'll do it as a security update?
<bdmurray> mdeslaur: sure will do
<mdeslaur> bdmurray: thanks
<bdmurray> mdeslaur: done
<mdeslaur> bdmurray: thanks
<xnox> stgraber: I noticed you started implementing image/snapshot generation. Should I start looking into how to adjust current phablet images to use the proposed fs layout semantics?
<stgraber> xnox: nah, for now it's just a prototype, once we know it's what we want we'll do the changes
<stgraber> xnox: just don't spend too much time writing tools to deal with the old way things were done :)
<xnox> stgraber: sure, I was just thinking to push files around on different partitions and see if android will manage to boot/start with at least read/write bindmounts.
<bdmurray> mterry: does your update-manager requires-restart branch need a FFE?
<mterry> bdmurray, needs a UIF now probably
<mterry> bdmurray, it could wait until S
<bdmurray> mterry: okay, that probably makes sense then
<bdmurray> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
#ubuntu-devel 2013-03-29
<cyphermox> bkerensa: still around?
<vibhav> Can someone change the topic to "Archive: Final Beta Freeze?"
<vibhav> s/?"/"?/
* sladen changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<neosrix> i did a make deb-pkg and the kernel image turned out to be 600 MB
<neosrix> the config file was copied from 12.10 lubuntu
<kentb> Is an ubuntu-server build for March 29th going to be posted on cdimage today?
<vibhav> How does Ubuntu mount /dev/sdb1 without root permissions?
<jpds> vibhav: polkit, I think.
<ScottK> mterry: I rejected your qtpim upload because there's no FFe.
<ScottK> Mirv: ^^^
<Mirv> thanks. qtpim is broken at least for the organizer part without a new snapshot, and the packaging should separate the QML plugins + update copyright at least.
<mterry> ScottK, it was part of the touch stack, which has a standing FFe, but sure.  There's no rush on it, I think the touch stack is mostly landing in S now anyway
<Mirv> mterry: I don't think we want any more of the git snapshot modules in archives, since they're not very supportable
<Mirv> before s, at least
<ScottK> mterry: OK.  That wasn't clear.  Mirv has some issues with the package, so please work it out with him before you upload again.
<mterry> ScottK, yah, I should have mentioned in the changelog
<Mirv> for touch image building we will need to use updated packages from PPAs
<ScottK> Mirv: The touch stuff does have a standing FFe so it's legit from a process perspective to upload it.  I'll let you two fight it out on the technical merits.
<mterry> Mirv, you mean as a project or as PS?  git snapshots happen all the time, and this package came from PS, so I figured it was fine
<Mirv> ScottK: ok
<mterry> Mirv, I didn't see any qml plugins in this package.  It looked like mostly straight qt libraries.  Maybe I missed it
<Mirv> mterry: it might need more discussion, but since the snapshot modules are nonsupported by upstream and often broken, I don't think it makes much sense to upload them to archives - qtlocation/qtsensors were exceptions since qtwebkit build-depends on those
<Mirv> mterry: /usr/lib/x86_64-linux-gnu/qt5/qml/* should be in qtdeclarative5-pluginname-plugin packages
<mterry> Mirv, sure, I understand why git snapshots are not necessarily the best thing since sliced bread.  But we had this git snapshot already
<Mirv> mterry: but since you fixed many problems with the package already, could you perhaps push your branch to https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtpim-opensource-src ?
<Mirv> the copyright file would still need fixes as well, it's out-of-date
<mterry> Mirv, yes they should.  I see that in the contacts library now
<mterry> Mirv, ah!  I wondered; that should have been documented in Vcs-Bzr
<Mirv> mterry: yes, it should have been :)
<Mirv> mterry: I've also packaged the snapshot builds of qtsystems, qtfeedback, qtconnectivity and qtwayland, and I don't think they are suitable for the archives either at this point - we haven't used them, they might be broken and the upstream future is uncertain
<mterry> Mirv, regardless, this doesn't need to hit raring
<Mirv> IMHO they're fine material for PPA and trying to figure out slowly which modules we really want to be part of the core stack
<mterry> Mirv, sure, again, I get that snapshots aren't the plan A for any package.  But since we had this package already and were using it...  it seemed to make sense to continue to use it, rather than downgrade the version for the archive
<Mirv> mterry: to be exact, there's no released version of qtpim available (Qt5 compatible one), and I'm not sure if we're yet really using it since at least the organizer part is broken
<mterry> Mirv, speaking of qt5 versions of things, what's with the telepathy-qt5 code we have in the PPAs?  It seems like we've made non-debian-patched changes to the upstream code?
<Mirv> but I might be wrong, I don't really know which of the modules are in active use
<mterry> Mirv, qtpim is a build-depend for phone-app at least.  not sure which of its modules are used by which apps
<mterry> Mirv, (regarding telepathy-qt5, upstream git seems to support both qt4 and qt5, but our code only seems to support qt5)
<mterry> Mirv, hmm, the kubuntu-packaging link above is 404?
<Mirv> mterry: I'm not familiar with the telepathy-qt5. good to know qtpim is build dependent on
<Mirv> mterry: pushed now. I hadn't pushed my packaging branch there since it was on my list of "fix it to be proper", which you now mostly did already
<mterry> Mirv, ok, will propose a branch
<Mirv> mterry: anyway this upstream thread (latter part of it) is some of the reason of my wariness of uploading non-supported snapshot modules to archives: http://comments.gmane.org/gmane.comp.lib.qt.devel/9851
<Mirv> upstream doesn't want those to be mixed with actual Qt 5
<Mirv> so I started adding also warning texts to the package descriptions of qt3d etc
<Mirv> anyhow, I should be on holiday now :)
<mterry> Mirv, https://code.launchpad.net/~mterry/kubuntu-packaging/qtpim-cleanup/+merge/156199
<mterry> Mirv, oh on holiday?  nm about the merge until later  :)
<bdmurray> ScottK: is there somebody who could look at bug 1069072?
<ubottu> bug 1069072 in ubuntu-release-upgrader (Ubuntu) "DistUpgradeViewKDE.py launches browser as root" [High,Triaged] https://launchpad.net/bugs/1069072
<ScottK> Riddell: ^^^
<ScottK> He's probably the best person.
#ubuntu-devel 2013-03-30
<vibhav> good morning
<aaron_rackspace> evening
<aaron_rackspace> hey all, i'm looking for anyone who would be interested in a c++11 project that I'm looking to package with an ubuntu distro. would require an understanding of BGP, syslog, and TCP sockets.
<aaron_rackspace> project is currently alpha
<vibhav> heh: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1161840
<ubottu> Launchpad bug 1161840 in gnome-settings-daemon (Ubuntu) "DOES NOT GO TO ELEVEN" [Undecided,New]
 * ScottK is tempted to mark that critical.
<vibhav> ScottK: :D
<vibhav> Isn't there anything like "Critical \m/"
<alkisg> Hi, can I submit portable Windows apps packaged as .debs in https://myapps.developer.ubuntu.com ? They have launchers and icons and file associations and Depends: wine and everything, and they've been widely tested in hundreds of schools...
<sladen> alkisg: "portal Windows apps" ?
<sladen> alkisg: NET/CLR applicatoins?
<alkisg> sladen: portable means that it doesn't require a setup.exe
<alkisg> So that it can be installed in /usr/share/app, and not in ~/.wine/...program files...
<alkisg> No usually they're MFC or Delphi applications
<sladen> alkisg: x86-Win32 applications, that need to be run under Wine?
<alkisg> Yes
<sladen> alkisg: if they are probably configured, you control the source code, and have a dependency on wine; desktop files and such then there shouldn't be a problem
<alkisg> OK in 3 out of 4. But in _some_ cases I don't have control over the source code.
<sladen> alkisg: more commonly though, we do include CLI-CLR (".Net") applications
<sladen> alkisg: there would be a problem distributing programs that are not allowed to be distributed
<alkisg> E.g. the ministry of education has ordered some programs, and it has exclusive rights for everything including redistribution, but it doesn't have the source code
<alkisg> (just because the people that received the app didn't care to ask about the code)
<alkisg> So my team which is part of the ministry does have redistribution rights but not the source code
<sladen> okay, so in this case you're acting on behalf of the Ministry of Education
<sladen> and you've packaged what you've got
<alkisg> Right
<sladen> ah ha.  Yes, so, upload/submit those and be ready to explain this aspect when somebody asks
<alkisg> Thanks a lot sladen, will do.
 * alkisg looks for the screenshots infrastructure...
<alkisg> sladen: ah, a last question please, am I allowed to submit greek-only apps, of course as long as they have an english description that states they're greek only? I've seen that happen with magazines in app center, so I think it's acceptable, right?
<sladen> alkisg: AFAIK, that's not a problem.  Ideally it would be good to add an English description so that it's possible for more people to tell them apart
<alkisg> Gotcha, thanks again
<sladen> alkisg: btw, if you're involved with Greek, and the Ministry of Education, I would like to talk to you at some point about the Ubuntu Font Family coverage of Greek and how suitable it is
<alkisg> sladen: sure, although I think in the ubuntu-gr team there are some members like simosx which already filed bug reports whenever there were problems with the greek glyphs of the ubuntu fonts
<alkisg> I hang around at #ltsp most of the day; feel free to ping me whenever you need me
<sladen> alkisg: yes, obviously the more /independent/ perspectives I get, the easier it is to work out what issues there might be across the board, and what issues are only the perceived in a single situation, or by only 1-2 people
<sladen> alkisg: eg. if you're having to change the default font before sending laptops out, we know there's a significant issue
<sladen> alkisg: whereas if they're being shipped out and people are /using/ them, then the potential improvements can be smaller
<alkisg> I haven't heard about any complains wrt the ubuntu font lately, or with the default ubuntu/greek fonts in general... on the other hand, the default debian/gnome installation uses cantarell which doesn't have greek glyphs at all, so there's a big problem there, but of course not related to ubuntu
 * sladen nods
<alkisg> We do have problems with the default tahoma font shipped with wine, but that needs to be solved upstream too
<sladen> is that MS Tahoma (which is not shipped by default), or is that the default subsitution for MS Tahoma (eg. Deja or something
<alkisg> It's the wine tahoma implementation
<alkisg> Someone has implemented a tahoma font especially for wine, but it lacks i18n glyphs
<alkisg> So very bad substitutions happen, so bad that the text is almost unreadable
<sladen> "wine-tahoma-fonts".  Right
<alkisg> I volunteered to include some greek glyphs from another font inside the tahoma.ttf shipped with wine, at least temporarily until someone actually implements the correct glyphs, but upstream didn't really respond to that idea
<sladen> there will be legal issues
<alkisg> Not if the other font has an open source license too
<alkisg> E.g. if we copy from liberation or deja vu, to tahoma.ttf...
<Joy3003> Hello guys, can u please redirect me to the page where GSoC ideas are being discussed??
<Joy3003> I'm new to this.
<Joy3003> Thanks in advance. :)
<alkisg> Unrelated to the fonts issues, the most important problem that we have with greek localization, is that lightdm destroys the "us,gr" layout on login, so people can't type greek unless they manually add them from the gnome keyboard applet... LP bug #1016409
<ubottu> Launchpad bug 1016409 in lightdm (Ubuntu) "Default XKBLAYOUT is not used, so new users only have "en" layout" [Undecided,New] https://launchpad.net/bugs/1016409
<alkisg> That started with 12.04 and hasn't been addressed since.
<sladen> Joy3003: one people.  it was on ubuntu-devel (mailing list) recently
<sladen> Joy3003: https://lists.ubuntu.com/archives/ubuntu-devel/2013-March/036962.html
<sladen> Joy3003: that was links to the Wiki page
<doko> xnox, trying to understand why all of /usr/share/tcltk/tcl8.5 was left in tcl8.5, and not moved into tcl8.5-lib ...
<cjwatson> doko: tcl8.5-lib is really a misnamed libtcl8.5 IMO, and as such it makes sense for it to just be the M-A: same library
<doko> cjwatson, it's not the name, just that tcl8.5 is non-functional without the library files
<cjwatson> tcl8.5-lib isn't meant to provide a functional tcl though
<doko> imo, tcl8.5 should only hold the tclsh binary
<cjwatson> It's just "thing to link against"
<doko> then tcl8.5-lib is enough for an embedded tcl interpreter
<wmp> hello, i have problem with multiarch in 13.04, when i trying to install consolekit:i386 apt-get want to remove half of my system
<wmp> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1162247 - who can look on this?
<ubottu> Launchpad bug 1162247 in apt (Ubuntu) "apt-get on raring can't install ia32-libs" [Undecided,New]
<cjwatson> wmp: consolekit isn't multiarched so it is not expected that you should be able to install consolekit:i386
<wmp> cjwatson: so why pulseaudio:i386 has in depends consolekit:i386 ?
<cjwatson> It's not expected that you should be able to install pulseaudio:i386 either.  I've posted a suggestion in the bug for getting less misleading debugging information
<wmp> cjwatson: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1162247/comments/2
<ubottu> Launchpad bug 1162247 in apt (Ubuntu) "apt-get on raring can't install ia32-libs" [Undecided,New]
<wmp> cjwatson: this isn't same?
<cjwatson> Oh, I missed that, sorry
<wmp> ;)
<cjwatson> You appear to have some kind of broken PPA active
<cjwatson> Whatever is providing libjack-jackd2-0 6:1.9.9.5-1+kxstudio1~quantal1
<cjwatson> And your problem appears to be that apt can't find a matching libjack-jackd2-0:i386 to install
<wmp> cjwatson: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1162247/comments/3 :D
<ubottu> Launchpad bug 1162247 in apt (Ubuntu) "apt-get on raring can't install ia32-libs" [Undecided,New]
<cjwatson> wmp: Irrelevant
<cjwatson> wmp: You have that version of libjack-jackd2-0 *installed*
<cjwatson> Moving sources.list.d aside, if anything, would make matters worse
<cjwatson> With multiarch you need to have exactly matching versions of any libraries that need to be installed on >1 architecture
<cjwatson> Downgrading to the version of libjack-jackd2-0 (and any related packages) in raring might help
<wmp> cjwatson: how to downgrade package?
<cjwatson> apt-get install libjack-jackd2-0/raring
<wmp> cjwatson: ooo, this work :D
<cjwatson> And does that then allow you to install ia32-libs?
<wmp> yes
<wmp> thanks ;)
<cjwatson> Excellent
#ubuntu-devel 2013-03-31
<vibhav> good motning
<vibhav> morning, even
<twpoland> hello
<ositake> hi, I just found a problem in Ubuntu 12.04 and I don't know if it can be consider as a bug
<ositake> the problems is that if you issue strace -ttt -f -p [pid from the xorg]
<ositake> (don't try
<ositake> it freezes the complete Ubuntu
<ositake> meaning, you need to hard reset to work
<ositake> but if I do the same from the any console
<ositake> like ctrl+alt+F1
<ositake> works smooth
<geofft> that's disallowed by default because of the ptrace_scope stuff, right?
<ositake> that's what I don't know
<ositake> I guess that it is kind of stupid to strace the xorg
<ositake> when you are in
<ositake> but in a way, you should be able to do it
<ositake> still I can't say
<geofft> that too, I'd call that expected behavior. :-)
<ogra_> well, if you call it like above you will output to the xterm you run in ... meaning you strace your own command as well ... sounds like a deadly loop you force there
<ositake> indeed
<geofft> I bet if you write a shell script to strace xorg with output to a file, and then kill the strace process after 30 seconds
<ogra_> try redirecting to a file instead of oututting directly
<geofft> it won't actually hang the system
<ogra_> *outputting
<ositake> good idea
<ogra_> (since you would be stracing the strace output ... )
<ositake> I know is something that a normal user would not do
<ositake> that's why I wanted to ask before submitting any bug on that topoc
<ositake> topic
<ositake> thanks for the tip, by forwarding to a file, it doesn't happen,
<geofft> I vaguely recall that tcpdump or tshark or something is clever enough to notice if you're over ssh
<geofft> and not try to dump its own output
<geofft> I wonder if it's worth doing the same thing for strace
<geofft> but I can't really figure out how.
<ositake> that could be a good idea
<infinity> It's not worth trying to save people from applying that gun to that foot, I don't think.
<infinity> "Infinite loops make computers appear frozen" isn't really a bug, unless it's a loop you reach in normal use.
<ositake> true infinity , that's why I wanted to ask before hand
<infinity> This is all reminiscint of how, every few years, someone freaks out because you can DoS a UNIX system by forkbombing.  Oooo.
<infinity> The answer, of course, being twofold: "don't do that then" and "limit processes for non-root, if you care".
<geofft> I thought that's no longer a problem with cgroups or something. :)
<BenC> infinity: Can I get some buildd love for linux-ppc?
<infinity> And in the ptrace case, we don't let regular users ptrace, and we really don't let them ptrace root-owned Xorg servers.
<infinity> BenC: Maaaaybe.
<infinity> BenC: adare and ross are manual, go nuts.
<BenC> Thanks
<geofft> I'm reminded of http://blog.michaeltang.me/yes-yes-no/
<ositake> need to leave, thanks for the clarification!
<ositake> cheers
<geofft> (and in particular how _two_ different users on a shared system I run decided it sounded like a good idea to run)
<BenC> Now I just need some distro-manager love
<infinity> BenC: Release, you mean?  I can do that. :P
<BenC> infinity: ah, the email says "distro manager approval"â¦I wasn't sure who to blame^Wask
<infinity> BenC: There really was no ABI bump for PPC in that rebase?
<infinity> That seems suspicious.
 * ScottK hands infinity a neck tie, since he's distro manager, he should dress the part.
<infinity> ScottK: Not gonna happen.
<infinity> BenC: *poke*
<ScottK> ;-)
<infinity> BenC: Are you sure the rebase to 3.8.4 didn't bump ABI?  You don't have the abi check disabled?
<BenC> infinity: I ran the build and no ABI bumps for me
<BenC> infinity: debian.ppc/rules.d/powerpc.mk:skipabi = false
#ubuntu-devel 2014-03-24
<hyperair> argh
<hyperair> is indicator-application meant to be started via dbus or upstart?
<hyperair> i see an upstart job and no dbus job, but if you start indicator-application after it's crashed out via upstart, it refuses to stay alive
<hyperair> it just says (process:1679): libindicator-WARNING **: No watchers, service timing out.
<hyperair> and then it dies and gets restarted
<hyperair> pfft
<infinity> hyperair: Maybe restart unity-panel-service?
<infinity> (shot in the dark, based on event deps)
<hyperair> infinity: this is exactly what caused the problem in the first place
<infinity> Oh. :)
<hyperair> you restart unity-panel-service, and indicator-application goes down and refuses to come back up
 * hyperair is affected by a compiz bug where it hangs when you change your screen configuration
<hyperair> plug in external monitor -> hang
<hyperair> unplug external monitor -> hang
 * hyperair has a hotkey defined in compiz that allows me to kill compiz, so it's not like compiz itself is hung, just the displaying portion of it
<hyperair> but it doesn't work if unity's running the lock screen
<hyperair> oh wait a second...
<hyperair> IT FINALLY STARTED
<hyperair> YAY
<pitti> Good morning
<RAOF> pitti: Good morning!
<pitti> hey RAOF, how are you?
<RAOF> Surprisingly well, given Zoe's sleeping patterns of late :/
<pitti> RAOF: heh, you are learning to sleep really fast?
<RAOF> :)
<RAOF> So, I've got two fun things for you! Firstly, I don't know why http://paste.ubuntu.com/7144964/ hangs in the read() of errfd.
<RAOF> Secondly, if you comment out that read (and the associated check), you find that umockdev's evemu playback doesn't round-trip.
<pitti> RAOF: the delays in the events are almost zero; could it be that the startup of evemu-record takes longer than 0.07 seconds, so it doesn't see any event any more?
<pitti> RAOF: can you try replacing teh "0." with "1.", does it work then?
<RAOF> pitti: I don't think so, because the first event matches up. I'll give that a whirl, though.
<pitti> RAOF: instead of starting to replay events immediately it probably should wait some time before it starts the playback
<pitti> RAOF: ah, nevermind, that was bogus
<pitti> RAOF: playback starts when the client program open()s the device
<pitti> RAOF: -EMONDAYMORNING
<RAOF> :)
<pitti> RAOF: do you actually expect any stderr output?
<RAOF> No.
<pitti> RAOF: I mean, SIGINT doesn't actually terminate the program, does it? that's like Ctrl+Z, or is that still Monday morning?
<UserError> Has anyone ever looked at how insane the new deps for bamfdaemon and libunity-webapps0 are?
<pitti> ah it is, that's SIGSTOP
<RAOF> SIGINT is ctrl-C; it generally does terminate the program.
<RAOF> (It terminates evemu-record)
<UserError> Pulling in hundreds of megs of packages for no reason on non-Qt platforms sounds like a wonderful idea.
<pitti> RAOF: do you have the output of evemu-record (i. e. "sout") when disabling the stderr read()?
<pitti> RAOF: i. e. in what way it doesn't match up? (other than slightly different timestamps)
<RAOF> pitti: I'll grab it again from gdb, but when I inspected it it terminated early.
<pitti> RAOF: but that's a nice test, thanks for that
<RAOF> pitti: Output is: http://paste.ubuntu.com/7145011/
<doko> lool, gstreamer ping
<RAOF> pitti: ie: we get the first 3 packets fine, and then stop for some reason.
<pitti> RAOF: ok; I have no off-hand idea about that, that needs some in-depth debugging
<infinity> UserError: Which Qt libs would those be?
<UserError> All of them (Only half kidding)
<UserError> do the chain of deps
<UserError> http://packages.ubuntu.com/en/trusty/bamfdaemon
<UserError> libunity should be a recommends to begin with, or hell even a suggests
<UserError> but the service on libunity-webapps0 should be a recommends
<UserError> having a library != wanting a service
<infinity> UserError: unity-webapps-service links with libunity, you can't just magically make a linked library not necessary by changing the packaging.
<infinity> UserError: And I'm still not seeing the Qt-related complaint...
<RAOF> pitti: (a) Do you want this formalised somewhere (github issue, merge request?) and (b) are you in the mood for debugging it? :)
<UserError> infinity because you failed to follow the dep chain
<UserError> all the way down
<pitti> infinity: would you have a minute to accept the postgresql-8.4 lucid/precise SRUs for bug 1294006, or tell me that I can/should self-review them? (bdmurray already accepted the corresponding -9.1 uploads)
<ubottu> bug 1294006 in postgresql-8.4 (Ubuntu Precise) "New upstream microreleases 9.3.4, 9.1.13, 8.4.21" [Undecided,In progress] https://launchpad.net/bugs/1294006
<UserError> i followed every fork in the road until i saw the insanity
<pitti> RAOF: (a) can't hurt, git pull request sounds nice, then I have the new test ready for examination; (b) later today, yes; not right away I'm afraid
<infinity> UserError: That's nice.  How about a hint, then.
<UserError> bamfdaemon -> libunity-webapps0 -> unity-webapps-service -> webapp-container =
<UserError>     libqt5core5a , libqt5gui5 , libqt5network5 , libqt5qml5 , libqt5quick5 , libqt5widgets5 , unity-webapps-qml.
<infinity> pitti: If they match the ones bdmurray did, just self-accept.
<UserError> and because ubuntu and debian now pull in recommends by default, just imagine
<RAOF> pitti: Ok. I'll do (a) and then EOD; (b) is therefore not important :)
<UserError> andddddd the library does indeed work without the service
<infinity> UserError: So, perhaps you could have started with "does webapp-container really need to be installed" instead of where you did? :P
<UserError> 0 for 2
<UserError> just like bamfdaemon works without the webapp stuff they added in some 13.xx version
<UserError> Are you people still depends-ing xprint6 too?
<infinity> Though, it only seems to be installed by default on ubuntu-desktop anyway.
<UserError> Right however sane package structure is the norm for a distribution with official and community spins
<infinity> Fine.  File a bug.
<UserError> It looks like it probably came in like that on some ubuntu-touch stuff because I recall it from around that time period
<infinity> Yeah, it would have come from touch/unity8 integration.  Qt is sort of here to stay for Ubuntu.
<UserError> So by default, 14.04 is using three frameworks?
<UserError> unity*
<RAOF> pitti: Enjoy your shiny new pull request!
 * RAOF EOD
<pitti> RAOF: thanks, good night!
<dholbach> good morning
<pitti> infinity: ack, done (postgresql SRU)
<Noskcaj> Does anyone want to update clutter-gst-2.0 to 2.0.10? It fixes a memory leak and adds a few new interfaces
<darkxst> Noskcaj, we are past feature freeze, and that doesn't look like a bug fix only reales
<Noskcaj> darkxst, My thoughts too. I'll see how hard it would be to cherry pick the memory leak fix
<darkxst> that said, it might be ok
<infinity> pitti: Oh, Merry Christmas, BTW.  You have an autopkgtest flood.
<lool> doko: pong
<doko> lool, solved, problem introduced by siretart
<Noskcaj> dholbach, Is there anything i should be doing to try and improve my chance of getting MOTU tomorrow morning?
<Noskcaj> Or at least xubuntu packageset, since all my uploads there have been high quality
<dholbach> Noskcaj, you could ask your sponsors to see if they update their testimonials?
<dholbach> Noskcaj, I could have a look at updating mine if you give me the link to your application again
<pitti> infinity: eglibc o'clock? :-)
<doko> pitti, is the autopkgtest for mysql-5.6 5.6.16-1~exp1: RUNNING? blocks ncurses
<seb128> crazy the number of uploads we get on freeze days :p
<doko> pitti: python-flake8 autopkgtest always fails
<pitti> doko: yep, that's a new test which is broken
<pitti> doko: mysql-5.6 is actually running, yes; but for quite a while already
<pitti> doko: eek, started two days ago; I suppose something in the test hangs and also kills the timeout timer, I kill it
<doko> zul, python-taskflow autopkg test fails
<Noskcaj> dholbach, https://wiki.ubuntu.com/Noskcaj#MOTU
<Noskcaj> Although you testimonial is pretty good, maybe mention that there's around 100 sponsorings from you
<Noskcaj> I've batch pinged a fair few other sponsors, no one replied, except logan, who said he wasn't ready to leave a testimonial
<seb128> Noskcaj, one note from me is that you should be more selective in your updates after ff, you tend to merge on Debian when there are not so many useful changes that we need/the changes don't bring any real value (that adds reviews etc load which is not spent on bugfixes)
<Noskcaj> seb128, That's actually something that's been making me think recently, just what level of fixes are worth uploads for
<doko> Noskcaj, cherrypy3 autopkg test is failing
 * Noskcaj looks
<Noskcaj> I'm going to guess it's not from my change though
<Noskcaj> um. link to tests plz
<doko> Noskcaj, you should know about http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html ...
<Noskcaj> doko, I've seen it before, just didn't know the location
<apachelogger> Sweetshark: ping, when/why/how did the libreoffice package start recommending default-jre?
<pitti> Noskcaj: what was the intention of the "make basic autopkgtest" in python-flake8?
<pitti> Noskcaj: it just calls "flake8" without any arguments, but it should ceratinly be called on some python tree?
<Noskcaj> Sounds like something i shouldn't have done, but i'm not allowed to be on the computer at the moment
<Noskcaj> same applies to the cheerypy3 test failure
<pitti> Noskcaj: I'll create some test files and run flake8 on that, and send it to Debian
<Noskcaj> ty
<Sweetshark> apachelogger: http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commitdiff;h=06cc27ab781946cf92bc45dbf48fdd2ff8a46b0f;hp=ba56ec3d266f5f232304b13a80bb19b86e02c172
<apachelogger> Sweetshark: is that absolutely necessary to be recommends? it made kubuntu amd64 go oversized quite a bit
<Laney> doko: are you planning on fixing plainbox for 3.4?
<pitti> doko: python-flake8 autopkgtest fix uploaded, and bug/patch sent to debian
<doko> Laney, ugh, wasn't aware that it is broken ...
<Laney> I don't know if the code is, but X-Python3-Version << 3.4
<Laney> zyga: ^?
<zyga> Laney: we're uploading 0.5 without that today
<zyga> Laney: which is okay on 3.4
<zyga> Laney, doko: so please hold on and approve the sync request from debian instead
<doko> zyga, debian only has beta2
<doko> zyga, do you want to have a look at the bzr test failures?
<zyga> doko: yes, we've fixed the final i18n bug on Sunday
<zyga> doko: gladly but I need to upload 0.5 first, give me one hour please
<pitti> zul: python-taskflow autopkgtest failure shows the missing new dependency on -kazoo; I filed bug 1296607
<ubottu> bug 1296607 in python-taskflow (Ubuntu) "MIR: python-kazoo; new taskflow version needs python-kazoo from universe" [Undecided,New] https://launchpad.net/bugs/1296607
<doko> Laney, https://bugs.launchpad.net/ubuntu/+bug/1282837 is this approved by you?
<ubottu> Launchpad bug 1282837 in Ubuntu Trusty "FFe: new package cloud-install" [High,Confirmed]
<Laney> doko: yes, but why has it lingered for a month?
<doko> ask ubuntu-archive?
<Laney> doesn't seem to be in their queue
<Laney> also you â ubuntu-archive :P
<doko> no, just for test rebuilds and mir
<Laney> hmm
<doko> we really need to revisit all these teams, and who is working when on things ...
<Laney> maybe I should have subscribed the sponsors
<Laney> how did you come across it?
<ogra_> xnox, it looks like your autopilot change causes some havoc ...
<ogra_> xnox, if you look at the .crash files on all these failed tests on http://ci.ubuntu.com/smokeng/trusty/touch/mako/255:20140323:20140304/7336/
<ogra_> the error is always: apparmor.click.AppArmorException: "Could not find '/usr/share/autopilot-touch/apparmor/click.rules'"
<rbasak> stokachu: ^^ who are you expecting to land bug 1282837?
<ubottu> bug 1282837 in Ubuntu Trusty "FFe: new package cloud-install" [High,Confirmed] https://launchpad.net/bugs/1282837
<zequence> any archive admins around?
<zequence> ubuntustudio-live needs approval, getting close to release time and it would be nice to have it on our ISO ASAP :)
<Laney> zequence: it is already in
<Laney> laney@iota> rmadison -S trusty ubuntustudio-live                                                                                           ~ ubuntustudio-live | 1 | trusty/universe | source, all
<zequence> Laney: Ah, great. Missed it. Thanks!
<zul> pitti:  i saw thanks
<ogra_> do we have any bootchart specialists ? i'm wondering why --crop-after is racy for me ... i sometimes get http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-255.png ... which is properly cropped after unity8 ... but http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-256.png then again doesnt crop at all
<marga> Hey all, we are seeing trusty installs failing due to python 3.4 change.
<marga> I'm about to report a bug, but wanted to know if this was a known issue already.
<seb128> doko, ^
<seb128> marga, hey, I noticed the daily iso failed on some python error as well, so I guess it's somewhat known
<marga> Yes, pkern had already pinged doko privately.  In any case, I'll just file the bug :)
<marga> seb128, known but not reported?
<seb128> marga, there is at least one reported against plainbox it seems
<marga> Yeah, I'm looking at https://bugs.launchpad.net/ubuntu/+source/plainbox/+bug/1289334, but it's older
<ubottu> Launchpad bug 1289334 in plainbox (Ubuntu) "package python3-plainbox 0.4-4 failed to install/upgrade: ErrorMessage: le sous-processus script post-installation installÃ© a retournÃ© une erreur de sortie d'Ã©tat 3" [High,Confirmed]
<marga> This one: https://bugs.launchpad.net/ubuntu/+source/plainbox/+bug/1296588
<ubottu> Launchpad bug 1296588 in plainbox (Ubuntu) "Precise -> Trusty upgrade fails: plainbox fails to configure with E: py3compile:243: Requested versions are not installed" [Critical,Triaged]
<jibel> marga, could you file a bug and we'll duplicate if it is already known.
<marga> jibel, it's this second one.
<jibel> marga, okay. zyga will upload plainbox .5 to fix this.
<marga> Ok, good
<zyga> hmm
<zyga> I'm seeing strange failures on precise that weren't there before
<doko> zyga, please can we fox this now?
<zyga> doko: trying to
<zyga> doko: but this prevents us landing stuff to trunk
<zyga> sphinx fails to build correct documentation with nothing but 'error: None' and return code1
<zyga> nothing in sphinx changelog seems to explain why
<doko> zyga: do you have a candidate package?
<zyga> doko: in debian svn, the only thing I need is the documentation update and the final tarball that cannot generate because of that sphinx failure
<zyga> ohhh, I think i found it
<doko> zyga, I don't care, I would rather upload an interim package to fix the installation failure first
<maxiaojun> any news for usb-creator?
<zyga> doko: sync 0.5b2 from unstable
<zyga> doko: I fixed the issue
<zyga> doko: give me 3 minutes and everything will be ready
<maxiaojun> xnox: ping
<zyga> doko: plainbox-0.5 upstream released, debian packaging updated, request for sync sent, looking at the ubuntu package now
<zyga> doko: so how should we release plainbox-0.5 into ubuntu now? can you somehow sponsor it to debian? or would you rather sync 0.5b2 which is in unstable already?
<doko> zyga, already synced
<zyga> doko: thanks
<zyga> doko: will you fix 0.5 once it lands, it fixes i18n bugs that we'd like to see in 14.04
<doko> zyga, sure I can do that, just put a signed dsc somewhere
<zyga> doko: I never uploaded plainbox to debian myself, I always requested sponsorship, not sure what I need to do to give you the final .dsc
<doko> zyga, who did in the past?
<zyga> doko: p1otr (Piotr OÅ¼arowski)
<zyga> doko: I sent him RFS a few minutes ago
<cjwatson> infinity: thanks for sorting out the coreutils build failure, I'd been stuck on that
<sforshee> pitti: I'm trying to work out how to trigger a bug report for a certain condition from the kernel. One possible trigger would be the appearance of a certain file in /var/log - does apport support anything like that?
<stokachu> rbasak: smoser was handling it i thought
<doko> stokachu, rbasak: cloud-installer (- to 0.1+bzr111-0ubuntu1)
<doko>     Maintainer: Ubuntu Developers
<doko>     Section: universe/admin
<doko>     0 days old
<doko>     cloud-install-landscape/amd64 unsatisfiable Depends: cloud-installer
<doko>     cloud-install-multi/amd64 unsatisfiable Depends: cloud-installer
<doko>     cloud-install-single/amd64 unsatisfiable Depends: cloud-installer
<doko>     cloud-install-landscape/arm64 unsatisfiable Depends: cloud-installer
<doko>     cloud-install-multi/arm64 unsatisfiable Depends: cloud-installer
<doko>     cloud-install-single/arm64 unsatisfiable Depends: cloud-installer
<doko>     cloud-install-landscape/ppc64el unsatisfiable Depends: cloud-installer
<doko>     cloud-install-multi/ppc64el unsatisfiable Depends: cloud-installer
<doko>     cloud-install-single/ppc64el unsatisfiable Depends: cloud-installer
<doko>     Not considered
<stokachu> doko: nice
<doko> stokachu, well, only nice if you fix it ;p
<stokachu> doko: yea i think its b/c of the architecture set in it
<pitti> sforshee: we'd need to wire that through an upstart job
<pitti> sforshee: that's fairly similar to what we are already doing with pretty much all other crashes
<pitti> sforshee: e. g. /usr/share/upstart/sessions/update-notifier-crash.conf
<pitti> sforshee: we also used to have (not sure if it still works) integration with kerneloops which calls /usr/share/apport/kernel_crashdump on an oops
<sforshee> pitti: I'm looking at kerneloops too but the spewage in dmesg would need to be changed to be more consistent
<sforshee> pitti: but the upstart job might work, I'll play with that. Thanks.
<pitti> sforshee: another option might be to send an uevent, if you can do that in that situation
<sforshee> pitti: there is a uevent, another option I'm considering :-)
<pitti> sforshee: wiring through an udev rules avoids assuming a particular init system, if you want to use this for other distros (e. g. upstreaming to linux), and in ubuntu's future
<sforshee> pitti: do you know of an example of doing it that way from a udev rule?
<pitti> sforshee: in the past we used to have that for missing firmware
<pitti> sforshee: e. g. the hplip bits listened for that, and we also plumbed it into jockey
<pitti> sforshee: but no existing example for something crash-y
<sforshee> pitti: okay, thanks. I'll look into doing it that way too.
<dholbach> seb128, not sure if I read the excuses list correctly, but python3-defaults not moving out of -proposed is because of dh-python tests failing somehow? seb128, looks like dh-python failed somehow? https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-dh-python/ARCH=amd64,label=adt/ - not sure if I read the excuses list properly
<dholbach> oops
<doko> dholbach, correct, apparently I'm still missing some tests. but maybe barry can help ;p
<dholbach> doko, great - I was just looking at why this was one failing https://launchpadlibrarian.net/170552764/buildlog_ubuntu-trusty-i386.click-reviewers-tools_0.6-0~181~ubuntu14.04.1_FAILEDTOBUILD.txt.gz - but I guess the two are related :)
<doko> dholbach, it did succeed here: https://launchpad.net/ubuntu/+source/click-reviewers-tools/0.5build1
<barry> doko: hi
<seb128> doko, dholbach: the ppa doesn't use trust-proposed so it still tries to build for the old python version
<doko> ahh, ok
<dholbach> ah, that makes sense then
<dholbach> thanks guys :)
<doko> which ppa?
<dholbach> doko, https://launchpad.net/~ubuntu-sdk-team/+archive/staging
<seb128> it probably makes sense for a ppa you recommend to users
<seb128> you don't want the to get proposed updates with it
<doko> sure
<glambert> hi, how do you generate a new random-seed file?
<cjwatson> glambert: it's done at every shutdown by /etc/init.d/urandom
<cjwatson> sudo dd if=/dev/urandom of=/var/lib/urandom/random-seed bs="$(( ($(cat /proc/sys/kernel/random/poolsize) + 7) / 8 ))" count=1
<cjwatson> should do it manually
<cjwatson> I don't see why you would need to do it manually though, given that it's only read on startup
<cjwatson> And all that's done at startup is to shove it back into /dev/urandom
<glambert> cjwatson, I'm writing a version of the virt-sysprep tool from libguestfs that I'm tweaking to suit my needs but also trying to port all of the tools they have
<glambert> generating a new random-seed file is one of the things on there
<cjwatson> Ah, makes sense
<glambert> but given that I'm going to be running my version on the guest rather than on the host
<glambert> if it's all done at startup I don't suppose I need to do anything
<cjwatson> I think you need to run it on the host - until you've seeded the RNG you don't have meaningful entropy in the guest, surely
<cjwatson> Well, it's done at startup/shutdown, but you might well end up with a weak RNG in the guest if you don't do anything
<cjwatson> It's good practice to give it some entropy from an environment that actually has some
<glambert> cjwatson, I can't run it on the host, the virtual machines are running in network storage and the virt-sysprep tool can't connect to them
<glambert> hence the reason for going it alone so to speak
<cjwatson> You might consider installing something like haveged in the guest to assist
<cjwatson> (Though IANA cryptographer)
<shadeslayer> seb128: seems that protocol handling is semi working now
<shadeslayer> for firefox
<shadeslayer> seb128: however firefox is still not reading /etc/firefox/pref/apturl.js
<shadeslayer> symlinking it to /usr/lib/firefox/browser/defaults/preferences/apturl.js makes stuff work
<seb128> shadeslayer, it's not supposed to
<shadeslayer> but as noted before, that's wrong :P
<seb128> yeah
<seb128> chrisccoulson said that firefox needs to be fixed
<shadeslayer> chrisccoulson: ^^ when you fix apturl , please poke me too, I'd like to register some extra protocols for KDE like magnet link handling and such
<seb128> shadeslayer, I don't think apturl needs fixing, it's firefox which does, nothing prevents you do add handlers to KDE meanwhile
<shadeslayer> seb128: sure, but how do I do that?
<shadeslayer> I mean, I can do them via browser/defaults/preferences
<chrisccoulson> application/x-scheme-handler, like every other handler ;)
<chrisccoulson> you don't add them in firefox
<shadeslayer> okay, ktorrent for eg doe register magnet links in application/x-scheme-handler
<seb128> shadeslayer, you add e.g "x-scheme-handler/apt" to the MimeType of the .desktop
<shadeslayer> but firefox doesn't open it
<seb128> right, firefox needs to be fixed
<seb128> the url handler code is buggy
<seb128> that's what chrisccoulson said at least
<chrisccoulson> it used to work, and then regressed over a year ago
<chrisccoulson> it's only the last few weeks that people have been mentioning it ;)
<stgraber> cjwatson: just sent an e-mail to u-d-a if you have a sec to approve
<cjwatson> stgraber: done
<stgraber> thanks
<pitti> hallyn: congratulations to your shiny new core-dev badge!
<ogra_> pitti, i know you are familiar how bootchart works, do you know whats the condition for the --crop-after arg ? i suddenly got a bootchart like http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-255.png (properly cropped) while they usually look like http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-25&.png
<ogra_> err
<ogra_> while they usually look like http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-256.png
<pitti> ogra_: it's a list of process names at whose appearance (any, not all) the boot is considered "done"
<ogra_> pitti, right, i added unity8 to that
<pitti> ogra_: e. g. the cron job does --crop-after=compiz,metacity,mutter,kwin,xfwm4,unity8
<pitti> and all CPU usage after that is attributed to user action
<ogra_> (and i'm actually creating the png locally with pybootchartgui with that arg)
<pitti> ogra_: but I'm actually not entirely sure how that works entirely, as normally cropping should happen once the CPU goes idle
<ogra_> right
<ogra_> thats what the documentation says
<pitti> oh right, the documentation even says that
<pitti> that process runs AND CPU is idle
<ogra_> and there is no CPU use ...
<pitti> as it can be idle in between (like, waiting for a driver to load or so)
<pitti> ogra_: so I do see unity8 on the second chart; was that done with the same parameters?
<ogra_> pitti, yes, its a script i run locally on a N4 with broken screen (great use for the broken phones)
<ogra_> all bootcharts in that dir are created by the same script
<pitti> heh
<ogra_> http://paste.ubuntu.com/7146809/
<ogra_> thats the script
<ogra_> hallyn, OOOH !congrats !
<highvoltage> hallyn: congrats!
<cjwatson> doko: dh-python autopkgtest still fails - maybe try http://paste.ubuntu.com/7146925/ ?
<cjwatson> doko: t204 looks a bit dodgy too
<hallyn> thanks :)
<doko> cjwatson, hmm, but it's strange that it did succeed earlier this release cycle ...
<barry> cjwatson, doko yeah, they do.  i need to finish up something in progress, and get lunch, but i can start to look afterward
<doko> thanks, afk now for some hours
<cjwatson> doko: well there was a non-trivial merge in there IIRC
<cjwatson> barry: ok, soon would be good since it's making click tests fail
<barry> cjwatson: ack
<asac> awe_: cyphermox: do you know if NM is going to ofono or
<asac> is MM still the focus for dan?
<awe_> asac, not sure...
<pitti> doko: dh-python autopkgtest fixed, FTR
<asac> awe_: got pinged by debian about updating MM package to 1.0+
<awe_> I know he was interested in our ofono support, but not sure if he has plans to merge any of it soon?
<asac> so wondered if we rather want to drop it and go ofono.. but seems not
<asac> ok so surely not yet superseded upstream. thats enough info
<cyphermox> no, it's MM
<awe_> yea, that might be too premature
<asac> cyphermox: would the 1.0 package we have in trusty be good for debian?
<cyphermox> asac: it's already in experimental
<awe_> also there's always going to a be a set of modems that MM will support better than ofono
<asac> cyphermox: i know. but people want it in sid i guess
<cyphermox> and we'll upload 1.2 to experimental or unstable soon too
<cyphermox> yes
<asac> what is holding that back?
<asac> ah good
<asac> ETA?
<cyphermox> as I recall it was breaking parts of KDE
<cyphermox> maybe this week?
<cyphermox> depends how much time I can spend on that
<asac> cyphermox: you work with mbiebl on this in debian?
<cyphermox> yeah
<asac> kk
<asac> will forwar that info to richi then
<cyphermox> I already told him
<asac> kk
<vlad_starkov> QUESTION (cross-post): Can't boot on freshly installed 12.04.4 64bit. Got multiple CPU soft lockup messages. Could someone point me how to boot in verbose/debug mode to figure out what's going on?
<barry> cjwatson, doko dh-python 1.20140128-1ubuntu8 passed dep8 and is being propomted
<cjwatson> yay, thanks
<barry> cjwatson: i can't take any credit.  looks like pitti fixed the 2.6 bits
<cjwatson> transfer as appropriate :)
<pitti> :)
<barry> :)
<pitti> that should also make python-defaults go in finally
<ScottK> barry: It fails in Debian CI too, so please fix there as well.
<barry> ScottK: ah
<pitti> barry: well, it rather just disables three explicit "2.6" checks; I'm not entirely sure how that's supposed to work in dh-python (e. g. if you have an explicit python2.6 shebang, but 2.6 isn't supported)
<pitti> but as ScottK says, it's failing in Debian as well, so I hope Piotr will fix it properly
<infinity> mwhudson: I assume you're keeping an eye on https://sourceware.org/bugzilla/show_bug.cgi?id=16629 for me so I don't have to, and you'll let me know when Will has a patch that actually works for you? :P
<ubottu> sourceware.org bug 16629 in libc "[aarch64] setcontext clobbers alternate signal stack" [Normal,New]
<cjwatson> doko: did you notice the arm64 build failure in your gluegen2 sync?
<kirkland> glambert: cjwatson: is someone in need of an RNG seed at first boot?  :-)
<kirkland> there's an app for that :-)
<kdeuser56> somehow I get the impression apport is buggy as hell:  it overwrites existing reports in /var/crash if the same binary crahes again
<kdeuser56> that way I cannot keep record of crashes happened on my system ...
<kdeuser56> pitti: any idea?
<doko> cjwatson, yes, known. regression when we switch from zero to hotspot. will need to fix this next week with an openjdk-7 update
<doko> cjwatson, can you give me a hint why python3-stdlib-extensions won't migrate?
<kdeuser56> how does the naming scheme of apport work? what means 1000.crash?
<ogra_> kdeuser56, thats the UID
<kdeuser56> ogra: always the same here ...
<ogra_> always the same user then
<kdeuser56> ogra_: okay ... but what happens if the same program crashes again?
<kdeuser56> ogra_: I suppose the file gets overwritten?
<ogra_> might be, ask the author :)
<ogra_> i would guess they are though
<kdeuser56> ogra_: it is certainly like that... now I am asking myself whether apport is that sophisticated that it automatically tries to detect if a backtrace is similar and if not ... write a new file ...
<kdeuser56> ogra_: but I can't imagine that ...
<kdeuser56> ogra_: there would be a very simple solution to that: simply add a time stamp in the filename ...
<ogra_> apport surely knows if a backtrace is identical ... well, at least the launchpad side of it does (so i guess the local one does too)
<kdeuser56> ogra_: do you have any idea how I could simulate crashes?
<ogra_> easiest is to kill a python app that creates a traceback i think
<ogra_> (also wont make the backtras so big)
<ogra_> *backtrace
<kdeuser56> ogra_: will the trace always be identical if I kill the same application?
<ogra_> if you kill it at the same point
<kdeuser56> ogra_: do you know some example python app from the repos that is not that big?
<ogra_> not of the top of my head ... juust take something installed
<dobey> i think apport auto-increments
<dobey> or maybe not
<kdeuser56> dobey: then why is there only one timestamp in one file?
<dobey> but you shouldn't be crashing the same app in 10 different ways so often anyway
<kdeuser56> dobey: that should not matter
<dobey> then file a bug against apport if it doesn't handle some case as well as it should
<kdeuser56> dobey: could the file ./usr/lib/python2.7/dist-packages/apport_python_hook.py
<kdeuser56> be responsible for writing the files?
<kdeuser56> ./usr/lib/python3/dist-packages/apport_python_hook.py is the same ...
<cjwatson> doko: it makes idle-python3.3 uninstallable, and proposed-migration doesn't know that you're intending to get rid of python3.3
<cjwatson> doko: (can't look further now)
<doko> cjwatson, well, ok to remove python3.3? will make pystache uninstallble. nothing else
<dobey> kdeuser56: i don't know what code exactly is responsible for generating the file names. it should be obvious. and you should work against a bzr branch of apport, not against the installed files
<cjwatson> doko: ask me tomorrow
<doko> ok
<kdeuser56> dobey: yeah, but this looks like it is what I am looking for:  pr_filename = '%s/%s.%i.crash' % (os.environ.get(
<kdeuser56>             'APPORT_REPORT_DIR', '/var/crash'), mangled_program, user)
<dobey> ok
<dobey> then file a bug and make a branch
<kdeuser56> dobey: okay I have the bzr branch ... it is in the file apport_python_hook.py
<kdeuser56> dobey: how can I regenerate the package and install to test my changes?
<Noskcaj> pitti, From yesterday, the flake8 autopkgtest was taken from somewhere, i forget where
<dobey> kdeuser56: many ways. i don't know how apport is built exactly though
<smoser> stupid question. is there an easy way to ask dpkg "is package foo installed with 'ii'" ?
<rbasak> smoser: I looked at dpkg-query -W --showformat. Something like dpkg-query -W --showformat '${Status}\n' foo or dpkg-query -W --showformat '${db:Status-Abbrev}\n' foo seems cleaner.
<rbasak> smoser: (but I'm not sure that's really any better)
<dakira> Hi. I found a bug in a totem plugin (subtitle downloader) and fixed it. I added a patch to the package and proposed it for merging. Whats the next step?
<dakira> https://code.launchpad.net/~mniess/ubuntu/trusty/totem/fix-lp1292262/+merge/212324
<Noskcaj> dakira, Wait
<Noskcaj> Someone will eventually upload it
<dakira> Noskcaj: you mean if it's any good ;)
<Noskcaj> I'll do a quick review, but i can't upload
<dakira> Noskcaj: okay.. but that answers my question. I don't need to subscribe anyone.
<dakira> Thanks!
<Noskcaj> Ubuntu-branches autosubscribes to it
<Noskcaj> But you need to make "trusty" the target release, and if possible, fill out the dep-3 header
<Noskcaj> Also the patch should be forwarded to debian and gnome
<dakira> Noskcaj: the bug was fixed in gnome. but only in 3.12. So I just took the fix to 3.10.
<Noskcaj> dakira, ok. Make sure you mention that in the patch dep3 header
<dakira> Noskcaj: I'm reading up on dep3 right now. That header goes at the beginning of the patch file?
<Noskcaj> yep
<Noskcaj> The header isn't really needed, but it makes your work better and others can understand the patch
<Noskcaj> Plus it's good to practise
<dakira> Noskcaj: okay. So after I pushed my changes, do I need to resubmit the merge proposal?
<Noskcaj> you shouldn't have to
 * hallyn feeling no love for whoever decided a terminal shouldn't be a default icon in unity
<dakira> Noskcaj: if the description gets longer, can I just split lines or does it all have to be in one line?
<Noskcaj> dakira, use http://paste.ubuntu.com/7148240/ as a template for that bit
<Noskcaj> and http://dep.debian.net/deps/dep3/ is the page about dep3
<Noskcaj> thanks for your work
<dakira> Noskcaj: thanks for the pointers. I pushed the changes.
<Noskcaj> :)
<Noskcaj> looks all good. It should get sponsored this week. thanks
<dakira> So how do I forward this to Debian? The Gnome folks only fixed this in 3.12
<Noskcaj> dakira, debian's in the process of packaging 3.12, i don't think you need to
<dakira> okay ;)
* infinity changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<sarnold> infinity: is the archive supposed to still be frozen after the beta 1 has been released?
<infinity> sarnold: It will be, yes.  Same as we did last cycle.
<infinity> sarnold: As my email reads, unseeded stuff will auto-accept, but we'll be reviewing seeded uploads.
<sarnold> ah and there's the explanatory mail :)
<sarnold> thanks infinity
#ubuntu-devel 2014-03-25
<latenite> Hi folks / devs, why does Ubuntu not have the "common" way of storing keymaps? like in https://gist.github.com/anonymous/9752563
<cjwatson> Because the old console-data thing was awful - it required maintaining all keymaps twice, once for the console and once for X
<cjwatson> And they inevitably got out of sync
<cjwatson> So now we autogenerate from XKB instead
<latenite> cjwatson, sounds nice. I try to come to grips with the new concept. Why?! ..because I build custom initramfs with a keymap selction menu on boot
<latenite> they used to use the old keymaps style (arch, gentoo). now I port to ubuntu
<latenite> could you explain to me how keymap selection in ubuntu works?
<latenite> I know how "loadkeys /path/to/keymap/file" works
<cjwatson> XKB* variables in /etc/default/keyboard
<latenite> how is the new way done?
<cjwatson> console-setup reads those and generates a keymap which is fed to loadkeys
<cjwatson> setupcon is the thing that does the hard work there
<latenite> what will I need to set a keymap manually? what tools and what directories?
<cjwatson> well basically you need to set the right things in /etc/default/keyboard and run setupcon
<cjwatson> it has some options if all you need to do is save the cached keymap rather than load it immediately
<latenite> cjwatson, no way in "interactively" switching the keymap?
<cjwatson> sure, you can "loadkeys LAYOUT:VARIANT"
<cjwatson> e.g. "loadkeys gb" or "loadkeys us:dvorak"
<latenite> nice.
<cjwatson> that calls ckbcomp under the hood, which is the thing that actually compiles an xkb keymap into Linux console-speak so that loadkeys can deal with it
<latenite> What tools will my "initramfs" need? only "loadkeys" as usual? Or "setupcon" as well?
<cjwatson> setupcon also uses ckbcomp; setupcon is quite a short script, you can read it
<latenite> I guess I have to strace all the tools?
<latenite> or is "ckbcomp" and "loadkeys" all I need?
<cjwatson> if you need to generate keymaps then you'll need ckbcomp and all its bits
<cjwatson> and the XKB files
<cjwatson> you might consider reading those off the target root filesystem instead though
<cjwatson> rather than bloating the initramfs with them
<latenite> /usr/share/X11/xkb/ ...any other directories I need?
<cjwatson> I can't give you a complete manifest, it's 1am and I haven't looked at this stuff in some time.
<latenite> cjwatson, naw, thats totaly cool. I can take it from here. Thank you tons for giving me some insight.
<cjwatson> might also be worth looking into console-setup-mini, though it conflicts with console-setup so you may not be able to use it directly on Ubuntu; you could have a look at its source
<cjwatson> I vaguely recall it relies on somewhat more precompilation
<cjwatson> like I say it's been a while ...
<latenite> cjwatson, do you know, by chance, any other distro that uses this new KBD concept?
<cjwatson> I haven't kept track of whether Debian uses it by default nowadays, but we borrowed it from there
<cjwatson> as in it was Debian that developed it to start with
<cjwatson> we adopted it a bit more enthusiastically and did a good deal of work on it
<cjwatson> I don't know if anyone outside the Debian ecosystem has picked it up
<latenite> I ll try to come to grips with it. Maybe arch-linux likes it :D
<cjwatson> it's apparently one of the few things not in the Gentoo portage tree
<infinity> Maybe everyone can move to console/xkb map consolidation just in time for us to do away with xkb entirely and move on to something else. ;)
<latenite> :D nice one
<latenite> cjwatson, any idea what I migth be doing wrong? https://gist.github.com/anonymous/9753468
<cjwatson> latenite: keymap names don't map exactly; there's no XKB layout "us" variant "qwerty"
<cjwatson> latenite: there's an index of sorts in /usr/share/X11/xkb/rules/xorg.lst or /usr/share/X11/xkb/rules/xorg.xml as you prefer, or you could look things up directly in /usr/share/X11/xkb/symbols/
<cjwatson> Keyboard/xmlreader in the console-setup source package parses xorg.xml and dumps out a Perl module with all the layouts and variants
<latenite> hmm, how can I set a "us qwerty" layout with loadkeys then?
<cjwatson> that's just "loadkeys us"
<cjwatson> without a variant name you get the default variant for the given layout, which is almost certainly what you mean here
<saiarcot895> Is it standard for LTS releases to be released as development releases one month prior to the official launch?
<cjwatson> yes
<cjwatson> insofar as a development series is "released"
<cjwatson> by which I mean, what we're doing at the moment (in-development, final beta shortly) is entirely standard for our LTS releases
<saiarcot895> Interesting. I thought someone made a mistake.
<saiarcot895> As in, I get a prompt to upgrade if I do do-release-upgrade -c -d
<stgraber> you are passing it -d which specifically tells it to upgrade to unreleased series
<infinity> saiarcot895: What stgraber said, "-d" means "development series".
<latenite> cjwatson, is there any way to generate a list of "LAYOUT and VARIANT" choices *without* parsing the /usr/share/X11/xkb/rules/xorg* files? I mean by parsing actual files/data not the indexes
<infinity> saiarcot895: When we're on the ball, that works to upgrade to the next devel series literally hours after we release the previous one as stable.
<cjwatson> latenite: I expect you could implement enough of an xkb parser to parse the symbols files directly but that seems like pointless self-infliction of pain
<saiarcot895> infinity: so even without the -d switch, it can prompt to upgrade to non-LTS releases?
<cjwatson> there are indexes, you might as well use them
<infinity> saiarcot895: I'm not sure what you mean.  Without -d, it will only prompt to upgrade to stable releases.
<cjwatson> saiarcot895: depends on what you're upgrading from.  normally we wouldn't switch on upgrades without -d from an LTS until the next LTS has had its .1
<infinity> saiarcot895: Whether that's normal release or LTS is defined in /etc/update-manager/release-upgrades
<saiarcot895> as in 12.10, 13.04, 13.10, etc (after release)
<latenite> cjohnston, I realy might want to do that. What is a symbol file? Could you give an example of a symbol file.
<saiarcot895> infinity: ah, ok
<cjwatson> saiarcot895: the way this is actually implemented is with the meta-release* files on /usr/share/console-setup-mini/keyboard-configuration.config
<cjwatson> latenite: just don't ask me for help, I'm not interested in that work :)
<cjwatson> latenite: /usr/share/X11/xkb/symbols/*
<latenite> sure ok.
<infinity> cjwatson: Fantastic cross-talk in your paste there. :)
<cjwatson> infinity: hm?
<infinity> 19:31 < cjwatson> saiarcot895: the way this is actually implemented is with the meta-release* files on /usr/share/console-setup-mini/keyboard-configuration.config
<infinity> Two conversations for the price of one.
<cjwatson> oops!
<cjwatson> saiarcot895: on http://changelogs.ubuntu.com/ that is
<cjwatson> that probably makes slightly more sense
<infinity> cjwatson: Perhaps someone should send you to bed.
<infinity> (or you could fix some grub bugs...)
<cjwatson> I was failing to understand the geda-gaf/armhf build failure, mostly
<cjwatson> Which builds fine on a porter box, although I did "ulimit -u 500" it just in case I hit https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724922
<ubottu> Debian bug 724922 in src:geda-gaf "geda-gaf: FTBFS: dh_auto_test fork bombs" [Critical,Open]
<infinity> cjwatson: Would be hard to hit that bug, given that the testsuite is disabled...
<infinity> Or, so bdale's changelog claims.
<cjwatson> yeah, but just in case the disabling was broken
<cjwatson> (which it doesn't seem to be)
<infinity> Oh, the lack of log for the build on LP is annoying.
<infinity> Is it actually KILLING highbank nodes? :/
<cjwatson> I assume it must be
<cjwatson> But it signally failed to kill shedir ...
<infinity> Failing to kill a Panda while killing a highbank is a whole new failure mode...
<infinity> And entirely backwards.
<ScottK> This talk of killing Pandas had me concerned until I recovered context.
<pitti> Good morning
<pitti> Noskcaj: how do you mean "taken from somewhere"? I wrote the test and sent it to Debian as a bug
<Noskcaj> pitti, i don't know. I won't up around 5 minutes before i replied, and my work on that package was months ago
<Noskcaj> zul, Mind if i proposed a fix to the kazoo build failure, or is it easier if you fix it yourself? It should just be a missing nose depend
<Noskcaj> never mind, it also requires a java depend and some extra commands
<dholbach> good morning
<doko> test rebuilds finished \o/
<pitti> doko: nice! you started them yesterday?
<pitti> arm64 still has some catching up to do
<jibel> hey, creation of Ubuntu Beta2 image failed with apparmor-easyprof : Depends: python3-apparmor but it is not installable
<jibel> could someone have a look?
<pitti> yep, it's on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<pitti> jibel: I'll promote the binary
<jibel> pitti, thanks
<zyga> good morning
 * zyga has a lot of TODOs today
<infinity> Argh.
<infinity> click is being pulled into images AGAIN.
<Unit193> https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1297034
<ubottu> Launchpad bug 1297034 in indicator-sound (Ubuntu) "Do I really need 17 click or phone related packages on a Desktop install?" [Undecided,New]
<seb128> infinity, hum, how did that happen? https://launchpadlibrarian.net/170569869/indicator-sound_12.10.2%2B14.04.20140320-0ubuntu1_12.10.2%2B14.04.20140324-0ubuntu1.diff.gz doesn't seem to have new interesting depends
<infinity> +            unity-greeter-session-broadcast,
<infinity> seb128: ^
<seb128> that doesn't make sense that this one depends on click though
<infinity> seb128: It depends on upstart-app-launch
<ogra_>  Recommends: unity-control-center | gnome-control-center | ubuntu-system-settings | pavucontrol,
<ogra_> +            unity-greeter-session-broadcast,
<ogra_> +            accountsservice,
<infinity> seb128: We either need a hard revert on indicator sound, or someone to surgically remove that one feature for now until it's done click-free.
<infinity> seb128: Or drop that Recommends to a Suggests.
<ogra_> i guess the session-broadcast thing is the issue
<seb128> ogra_, read backlog
<ogra_> oops
<didrocks> ogra_: you're lagging :)
<seb128> infinity, I pinged thostr on another channel
<infinity> seb128: Sooner rather than later, so I can spin images, ideally. :P
<didrocks> seb128: I pinged him 25 minutes ago though on something else and didn't get an answerâ¦
<seb128> infinity, I would go for a revert
<ogra_> we can just seed it directly in touch
<didrocks> +1
<ogra_> just drop the recommends
<infinity> seb128: Well, if it's a Recommends, it obviously should work without it, so just dropping to Suggests would make the world happy for now.
<seb128> ogra_, are you sure it's not going to create runtime issues on desktop?
<infinity> If it created runtime issues to not have it, it would be a Depends.
<ogra_> seb128, no idea, it is for the infographics on the phone greeter though
<infinity> Unless the people doing the packaging don't understand dependencies. :P
<ogra_> i would suspect it is a no-op on desktop
<seb128> infinity, if you want to do that sure, I've to admit I'm annoyed enough at this landing/the level of changes it has/how late that I want to drop it, but that might not be the best option :p
<seb128> ogra_, it has nothing to do with infographics
<infinity> seb128: I'll just lower it to a suggests for now to make the archive happy.
<seb128> ogra_, it's to share sound controls/play song/etc to the greeter
<ogra_> seb128, well, thats part of the usermetrics/infographics stuff
<seb128> ogra_, no it's not, we use the same mechanism on desktop to make the greeter display your bg image
<ogra_> i dont think thats an expected desktop feature
<seb128> there is no such thing than desktop != phone, convergence
<seb128> the current desktop greeter doesn't use those infos, but that's not the point
<ogra_> atm there is :)
<seb128> it could, they are stored in accountsservice, that's where unity-greeter reads the background image on desktop
<seb128> it could also read the play song and display it if we wanted
<ogra_> right, it could
<seb128> those mps have nothing to do with phone
<seb128> they just publish info in a store
<infinity> seb128: Uploaded.
<seb128> then whether the greeters use the info is orthogonal
<seb128> infinity, thanks
<seb128> infinity, can you mp that back to lp:indicator-sound? ;-)
<infinity> seb128: Nope.  I'm exercising the excellent support they have for re-integrating distro uploads. :P
<seb128> infinity, that would be me (or somebody else who care about indicator) mp your change back for you
<infinity> seb128: That's not how it's meant to work.  The system is meant to flag an archive upload and make people act on it.
<infinity> seb128: If that's not happening, it's fundamentally broken.
<seb128> infinity, it's working, happening ... it's just that if you mp yourself you are a better citizen than if you wait for one of co-worker to do the work for you ;-)
<seb128> same as using packaging vcs-es when there is one
<infinity> seb128: An MP is a waste of time.  If I can commit to that branch directly, I will.  An MP isn't much better than you just applying the debdiff as a commit yourself.
<pitti> the trunks can be pushed to directly for such cases
 * infinity checks this theory.
<pitti> in fact, there is no other way for this direction
<seb128> infinity, maybe that's ok
<seb128> I only go through CI since we have it
<pitti> infinity: I did that for autopilot several times to integrate archive uploads
<Laney> if you're in $team, which not all core-devs are
<infinity> ... why am I only getting 5k/s from code.lp.net? :(
<infinity> Laney: Which they should be...
<seb128> pitti, well, the other way is "mp the archive diff" and add that to next landing ask
<infinity> Anyhow, not feeling like criticizing process tonight.  Just want to fix the package.
<pitti> seb128: but that would entail an upload and a review again, both of which have alreayd happened?
<seb128> pitti, right, you don't really have a choice if you don't have commit access to the trunk though
<pitti> *nod*
<seb128> infinity, yeah, let's move on
<pitti> seb128: on that topic, I think I already asked, but I forgot: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<pitti> seb128: could indicator-datetime maybe stop having indicator-applet as preferred alternative?
<infinity> Already annoyed enough that I only just noticed this and I'll have to respin xubuntu and a couple of others.
<pitti> as that pulls in all the old gnome 2 stuff
<seb128> pitti, it's not the issue there I think
<pitti> seb128: I think back then I proposed "Depends: unity | indicator-applet | indicator-renderer"?
<infinity> seb128: Right, what pitti said would work.  We looked at this the other day.
<seb128> pitti, other indicators do the same things and are not listed in there
<infinity> seb128: Which other indicator does the same thing?
<seb128> infinity, indicator-session for example?
<pitti> -power has the same as recommends, hmm
<seb128> or power
<infinity> Huh.  That's... Weird.
<pitti> perhaps c-m only takes the first rdepends into account?
<seb128> or indicator-messages
<pitti> and -datetime is asciibetically first
<pitti> hm, not asciibetically, that would be indicator-appmenu
<seb128> pitti, indicator-appmenu is before
<seb128> right
<seb128> which has the same recommends
<pitti> so perhaps first out of the randomly ordered set
<seb128> well, I'm not against changing those to "unity | indicator-renderer"
<seb128> but that's weird only one indicator has the problem
<seb128> would it be because unity is not installable on some arch?
<seb128> (it used to be because it was missing/not built on some archs, but that's not the case anymore)
<pitti> seb128: last time you mentioned it was due to unity not yet being built on ppc64
<seb128> right
<seb128> that has been fixed though
<pitti> seb128: but why would that be an arch specific issue for only one indicator?
<seb128> yeah, doesn't make sense
<pitti> e. g. power and datetime are both built on all our arches
<pitti> oh no, datetime is missing on arm64
<infinity> Right, let's revisit this one after we fix up some more build failures.
<infinity> I've been expertly ignoring c-m for that for a while anyway. :P
<infinity> Oh, FFS, after that 5k/s checkout from LP, I realised the debian/control was wrong, and I checked out the raring branch of indicator-sound.  I give up.  It's almost 4am.
<infinity> seb128: Please merge my tiny debdiff. :P
<seb128> infinity, ok
<thostr_> seb128: I'll work with Ted to get https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1297034 fixed/eased up
<ubottu> Launchpad bug 1297034 in indicator-sound (Ubuntu) "Do I really need 17 click or phone related packages on a Desktop install?" [Undecided,New]
<seb128> thostr_, thanks, infinity demoted the recommends to a suggests meanwhile, which we think should be good enough to resolve the issue
<infinity> Hey, neat, the testsuite segfaults.
<seb128> but still good to check with ted once he's up
<infinity> Love this code.
<thostr_> seb128: yes, the less the better
 * infinity head->desk.
<infinity> thostr_: So, your testsuite segfaults on i386.
<infinity> https://launchpadlibrarian.net/170654716/buildlog_ubuntu-trusty-i386.indicator-sound_12.10.2%2B14.04.20140324-0ubuntu2_FAILEDTOBUILD.txt.gz
<infinity> pitti: You're the test king, the above mean much to you?
<seb128> infinity, thostr_: that update also has a regression https://bugs.launchpad.net/bugs/1297078
<ubottu> Launchpad bug 1297078 in The Sound Menu "/usr/lib/x86_64-linux-gnu/indicator-sound/indicator-sound-service:11:g_str_hash:g_hash_table_lookup_node:g_hash_table_lookup:media_player_list_greeter_iterator_real_next_value:indicator_sound_service_update_preferred_players" [High,Confirmed]
<seb128> shrug
<seb128> infinity, we should maybe have reverted :p
<Laney> no need to past tense there
<pitti> infinity: no off-hand idea I'm afraid; I've never seen these indicator tests
<thostr_> seb128: ted is on that already
<seb128> thostr_, right, but that landed just before beta freeze, are we going to get the fix in beta and are we stucked with the buggy version until after the freeze ends?*
<seb128> that's why we don't take on so much code changes late in the cycle usually :/
<infinity> seb128: Feel free to revert instead.
<seb128> I'm pondering it
<infinity> Bonus points if the revert fixes the i386 segv. :/
<infinity> Half our flavours are sort of blocked on producing click-free images until this is sorted one way or another.
<pitti> sounds like revert is in order; that won't slow down ted or thostr_ in any way
<thostr_> pitti: I'm ok in reverting for now
<Laney> Do it, I can accept/respin when that happens if infinity wants to go to bed
<ekarlso> piany reason for a pretty critical bug going 4 days without attention ?
<ekarlso> https://bugs.launchpad.net/ubuntu/+source/biosdevname/+bug/1295873
<ubottu> Launchpad bug 1295873 in biosdevname (Ubuntu) "biosdevname messes up interface names from emX to renameX" [Undecided,New]
<ekarlso> I can't configure my network reliably with that happening
<infinity> ekarlso: There are lots of bugs.  Personal attachment to one doesn't make it any more special.
<infinity> But yes, that bug should be fixed by release, IMO.
<ekarlso> well atm for me trusty is useless on 3/4 servers because it doesn't name interfaces as expected..
<ekarlso> I dunno how to work around it either as all the things I've done seems to not fix it
<pitti> infinity: sorry, we just discovered that yesterday's langpack uploads miss a lot of files; I know why, but I'll need another full rebuild
<ekarlso> guess i'll do Precise instead for now
<pitti> infinity: I can handle it, ok if I do it now and do the queue accepts, etc?
<pitti> infinity: ETA about 6 hours until everything is prepared, uploaded, built, and in the archive
<infinity> pitti: Yeah, go to town.  This current set of images is a wash anyway.
 * didrocks does the revert
<infinity> pitti: I can do respins in the morning, if people have gotten me a less crap indicator-sound by then too.
<infinity> didrocks: Thanks.
<didrocks> infinity: I have a script for it now :)
<seb128> didrocks, thanks
<infinity> didrocks: pull-lp-source $pkg $oldver && apply changelog delta && dch -i?
<cjwatson> ekarlso: biosdevname=0 should work around it
<didrocks> infinity: not far from that, but it handles multiple packages and so on
<pitti> cjwatson: I thought we don't do biosdevname yet?
<infinity> pitti: Evidently, we do.
<pitti> although I recently had a bug report that claimed that lubuntu or so installs it by default
<infinity> And it seems a bit goofy.
<cjwatson> pitti: it depends on the platform
<cjwatson> pitti: https://lists.ubuntu.com/archives/ubuntu-devel/2012-August/035670.html
<pitti> bug 1293633
<ubottu> bug 1293633 in biosdevname (Ubuntu) "alternate install sets up biosdevname by default" [Undecided,New] https://launchpad.net/bugs/1293633
<pitti> cjwatson: ah, thanks
<cjwatson> well I fought against it but the server folks made me
<pitti> so above bug is by design then
<cjwatson> I don't have time to sort it out, maybe the people who made me make this change can do so.
<infinity> cjwatson: Why did the server folks want it?
<infinity> I've never quite grasped how it was an improvement.
<cjwatson> the list post above should have references, maybe upthread
<ekarlso> well it's easier to identify nic's...
<ekarlso> if it actually works...
<didrocks> grrr, I'm stupid, I used the wrong version to revert toâ¦
<infinity> ekarlso: I'm not sure there's any scheme that makes it easier to identify 16 ports across 4 cards, but I'll take your word for it. :)
 * infinity has always been mostly happy with the 70-persistent-names thing, so I can just make it how I want it, and it literally never changes.
<infinity> Laney: Don't worry about driving my respin-fest.  pitti's langpack-respin-of-doom won't be done until I'm awake again anyway.
<Laney> Yeah, no worries
<didrocks> ok, reverted with the weirder name ever
<didrocks> (due to the typo in version when reverting the first time)
<infinity> Do I want to look?
<ekarlso> infinity: if you have 1 embedded card with 4 ports, and say 2*2*10gb cards
<ekarlso> it'll be em1-4, p0pX, p1pX depending on the order in the pci
<infinity> 12.10.2+14.04.20140324.is.12.10.2+14.04.20140324-0ubuntu1 ... rly?
<soren> infinity: It makes device naming deterministic even without 70-persistent-net-blah. This is pretty handy when you're doing unattended installations en masse.
<infinity> didrocks: You didn't need to do that, since the previous version was never accepted...
<didrocks> infinity: yeah, did forget about the queue ;)
<didrocks> ok, doing the right version now
<ekarlso> where to set biosdevname=0 btw ?
<infinity> ekarlso: kernel cmdline.
<soren> ekarlso: Kernel command line
<ekarlso> kk
<ekarlso> let me try it
<soren> infinity: If you get a hundred servers at a time with (at least) two different ethernet cards, how would you make sure to assign the correct ethX to each port without biosdevname?
<infinity> soren: Dumb luck? ;)
<soren> infinity: I've recently exhausted my supply of dumb luck.
<infinity> (honestly, I'd probably just prefer a simple d-i thing that named the first interface with a physical link "eth0", and let the rest fall out)
<soren> infinity: I'll admit that one of the interfaces can reasonably straight forward to identify, since probably only one will be able to get an address by DHCP.
<soren> infinity: ..and if you're clever you can probably figure out the rest based on that.
<soren> infinity: Like, say, knowing that the first port on a specific card is the one connected to the DHCP-enabled network, so the subsequent 3 ethX's is probably the other ports on the same card.
<soren> infinity: ..and the remaining two are the ports on the other card. Or whatever.
<soren> infinity: ...but biosdevname really makes this much more of a no-brainer.
<infinity> soren: When it works. :)
<soren> infinity: When it works.
<soren> infinity: I really wonder about the eth0->em1, eth2->em3, and eth3->em2 renaming. They're being reordered.
<soren> infinity: Well, as long as it's consistent, it's cool.
<infinity> soren: Yeah.  Looked like the sort of thing that would happen in an attempt to unwind a rename loop, and it got stuck part way through.
<infinity> soren: That's my best guess anyway.  udev used to suffer similar problems with 70-persistent if you gave it a Really Hard problem to solve (where "really hard" for udev is, like, 3 operations and short break for tea)
<soren> infinity: Yeah. I'm not particularly envious of whomever has to fix that bug. I foresee much hair pulling.
<infinity> It's basically just towers of hanoi.
<infinity> Which is proof that Kai never took a CS degree.
<infinity> Cause every useless CS student has written a hanoi solver.
<soren> My lack of CS degree probably explains my reluctance to dig into it.
<ncopa> hi
<ncopa> anyone knows what kernel ubuntu 14.04 will use? 3.13 or 3.14?
<ncopa> or is that not yet decided?
<infinity> ncopa: 3.13
<ncopa> ok. thanks
<infinity> pitti: Want to give me a poke when all your langpack stuff is done and in the release pocket?
 * infinity heads to bed for a bit.
<pitti> infinity: yep, will do
<Laney> ev: Does 'Send a report automatically if a problem prevents login' do anything inside whoopsie?
<shadeslayer> hi, I was wondering if anyone here has some experience with shipping PAM modules
<shadeslayer> more specifically, this pam module needs to be loaded/executed by lightdm
<shadeslayer> was reading this https://wiki.ubuntu.com/PAMConfigFrameworkSpec , but I can't figure out how to make lightdm load the pam module
<shadeslayer> slangasek: ^^
<pitti> l
<ritz> RAOF, hi, awaiting review of gtk2/gtk3 from  https://launchpad.net/ubuntu/precise/+queue?queue_state=1
<ev> Laney: nope, not yet
<Laney> ev: okay, I'm going to hide that in alm then
<Laney> doing some poking there
<ev> Laney: feel free to implement it :-P
<Laney> oh look, a squirrel ...
<Riddell> why does ubuntu-restricted-addons still depend on gstreamer0.10-plugins-ugly as well as gstreamer1.0-plugins-ugly ?
<shadeslayer> Riddell: sounds wrong to me :)
<shadeslayer> Riddell: or, could be that ubuntu ships with purple on the image
<zyga> doko: hey, just a heads, up, I have some ideas what's going on with bzr but I won't have time to work on that until checkbox and derivatives are all in trusty and we can be sure that the code works okay, we're still working on getting the last bits into the archive and that has priority over any work over bzr
<zyga> doko: though I *really* want to work on bzr so I will try to find some time in the evening to test my theory
<smoser> cjwatson, or xnox do you know if this was ever successfull ?
<smoser> http://comments.gmane.org/gmane.linux.ubuntu.devel.discuss/14419
<smoser> i try to
<smoser>  kexec --type multiboot-x86 --load /mnt/boot/grub/i386-pc/core.img
<smoser> and it says:
<smoser>  Cannot determine the file type of /mnt/boot/grub/i386-pc/core.img
<melodie> hi
<melodie> I would like to find someone having knowledge related to the localisation process, because I met with a strange issue, in an edition (custom) having both English and French. does someone logged in now have insights on how the locales are displayed in a given environement?
<Saviq> pitti, hey, any idea how to work around bug #1297276 ?
<ubottu> bug 1297276 in apport (Ubuntu) "apport-cli miscalculates free space and prevents from sending a report" [Undecided,New] https://launchpad.net/bugs/1297276
<seb128> melodie, hey, what do you mean? language selector has a ranking of the languages
<melodie> hi seb128
<melodie> I will describe it
<pitti> Saviq: in meeting, bbl
<melodie> seb128 http://pastebin.fr/33138
<melodie> the description of the issue
<melodie> seb128 have you seen?
<smoser> and above, 'mbchk' seems to think the provied core.img is just fine http://paste.ubuntu.com/7151224/
<seb128> melodie, yeah, we would need to get details on the environment LC_ALL/LANG/LANGUAGE from that installation
<melodie> seb128 I see
<melodie> I can restart a vm
<melodie> seb128 firing it now
<melodie> seb128 environment: http://pastebin.archlinux.fr/499255
<caribou> what's the preferred way to upgrade to trusty ?
<caribou> I used do-release-upgrade -d but now I'm not sure it was the best thing to do
<seb128> melodie, what about echo $LANG and "locale"?
<melodie> http://pastebin.archlinux.fr/499257
<melodie> this is locale
<melodie> and
<melodie> $ echo $LANG
<melodie> en_US.UTF-8
<melodie> I'll add a screenshot of what I see
<MacSlow> Saviq, bfiller: https://bugs.launchpad.net/unity8/+bug/1296777/comments/1
<ubottu> Launchpad bug 1296777 in Unity 8 "avatar displayed incorrectly in notification" [High,New]
<caribou> for some reason I  have more than 300 packages being kept
<caribou> seb128: I think that this is a follow up to the issue I had when I upgraded & opened a bug
<bfiller> MacSlow: so the same image is successfully shown in the dialer-app call log and the messaging menu
<melodie> seb128 http://meets.free.fr/images/USC-en-fr.png
<bfiller> MacSlow: maybe look there to see how they dispay it
<Saviq> bfiller, can you attach the image used to the bug maybe?
<bfiller> Saviq: sure
<bfiller> MacSlow: just take a picture with the camera of yourself. It will live in ~/Pictures dir
<Saviq> bfiller, fwiw I can't set an image in the contacts app... it's stuck in "Loading" apparently
<MacSlow> bfiller, Saviq: got to start the camera-app... will try to replicate bfiller's described way too now
<MacSlow> Saviq, regarding the shell in image 259... have you seen taps on the dash just being ignored?
<bfiller> Saviq: hmnn, which image? everthing got released yesteday but needs a new gallery-app from the store which should have been updated in the default image
<seb128> melodie, is apt-cache show gparted displaying things in english?
<melodie> I will look
<seb128> melodie, http://askubuntu.com/questions/313105/where-does-ubuntu-software-center-store-its-language-settings
<Saviq> bfiller, 258 here, was same on 256
<melodie> seb128 yes, it is in English
<bfiller> Saviq: strange, working for me on 256
<Saviq> bfiller, can you install unity8-autopilot and run:
<Saviq> python3 /usr/lib/python3/dist-packages/unity8/shell/emulators/create_interactive_notification.py --icon ~/Pictures/...
<seb128> melodie, ok, I don't know then
<Saviq> bfiller, with the file in question
<bfiller> Saviq: sure
<MacSlow> bfiller, Saviq: got a new contact-entry with my picture now...
<bfiller> Saviq: is content-hub running when you do a ps?
<bfiller> Saviq: you might have stale data in gsettings - we ran into that last week but couldn't reproduce
<Saviq> bfiller, indeed not
<Saviq> let me try and do the image selection again
<Saviq> bfiller, yeah, no content hub
<bfiller> Saviq: I'll run that test after my meeting I have now
<Saviq> bfiller, ok
<MacSlow> bfiller, Saviq: sent me a SMS... image is indeed oddly placed
<melodie> seb128 ok, I see from your link that there is a bug report here: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/434601
<ubottu> Launchpad bug 434601 in software-center (Ubuntu) "Package descriptions etc display only in the language of whoever installed the OS" [High,Confirmed]
<melodie> I will add my feedback there, thanks
<Saviq> MacSlow, I wonder if it's putting it in the secondary icon maybe?
<MacSlow> bfiller, Saviq: but it's got to be something before the notifications are involved
<MacSlow> Saviq, no... that would result in the icon be 2x2 GUs then
<MacSlow> Saviq, and it had to be placed there explicitly...
<Saviq> MacSlow, print the source
<Saviq> MacSlow, maybe it's sending it scaled / cropped already
<MacSlow> Saviq, besides... it still gets masked with the UbuntuShape... and that only is done for the main image, never for the secondard image
<MacSlow> Saviq, yup... checking that
<melodie> seb128 https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/434601/comments/29  || thanks for your help!
<ubottu> Launchpad bug 434601 in software-center (Ubuntu) "Package descriptions etc display only in the language of whoever installed the OS" [High,Confirmed]
<smoser> well, if anyone cares, for my kexec issue above
<smoser> https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1297316
<ubottu> Launchpad bug 1297316 in kexec-tools (Ubuntu) "kexec doesn't load multiboot images" [Undecided,New]
<Saviq> MacSlow, seems the image is complete indeed, and it looks (almost - stretched instead of cropped) fine in the messaging menu
<cjwatson> smoser: I'm afraid I don't recall.  Ask upstream?
<MacSlow> Saviq, yes... this is what I'm getting too http://ubuntuone.com/539eDhUVFjoGzwBEykVHlh
<pitti> Saviq: I asked a question on the bug
<smoser> cjwatson, well, i filed that bug. it doesn't seem to work.
<Saviq> MacSlow, yup, but notification is broken completely indeed
<MacSlow> Saviq, looking at the source debug-print how
<cjwatson> smoser: sorry, can't help at the moment
<MacSlow> Saviq, still I'm assuming it's happening before the image is passed to the notification... as we don't really touch it
<smoser> cjwatson, thanks. thats fine.
<MacSlow> Saviq, apart from the scaling
<MacSlow> Saviq, I'll see
<Saviq> pitti, replied
<pitti> Saviq: err, f_bavail=0 ?
<pitti> that's broken
<pitti> Saviq: not sure what host vs. device is; the error happens "device" but not on "host"?
<Saviq> pitti, nexus 4 vs. desktop
<Saviq> pitti, thought initially btrfs is a factor, but apparently it's not
<Saviq> pitti, what seems to be a factor is the big .crash file - it choked on both phone and desktop on the same file
<pitti> Saviq: but what that check does is not related to the .crash at all
<pitti> it does this:
<pitti>         st = os.statvfs(mount)
<pitti>         free_mb = st.f_bavail * st.f_frsize / 1000000
<Saviq> pitti, I understand
<pitti> where mount iterates over /, /var, /tmp
<pitti> I'm not sure how it gets to 0.057344 though
<pitti> that's nowhere close enough to 0 to be a rounding error
<pitti> and if f_bavail is zero it should be a perfect 0
<pitti> Saviq: oh, wait
<pitti> Saviq: so you did create the report on the mako, which is the "device", and collected information there
<pitti> Saviq: and then scp'ed it over and tried to send it from your workstation?
<Saviq> pitti, yes
<pitti> Saviq: then it indeed considers the free blocks on mako
<Saviq> pitti, ah
<pitti> Saviq: i. e. that check wasn't written with this r/o and "full" file system in mind
<Saviq> pitti, then it might actually have been low on space on mako
<pitti> well, "in mind", it was written well before that
<Saviq> pitti, especially when the .crash was big
<pitti> Saviq: right
<pitti> that'd fill up /var
<Saviq> pitti, so it should be enough to rewrite the .crash file a bit
<pitti> Saviq: so the 0 free blocks might actually be correct?
<Saviq> pitti, I imagine it might
<Saviq> pitti, ok, feel free to kill that bug
<pitti> Saviq: thanks for debugging
<pitti> Laney, infinity, seb128: fixed langpacks in trusty
<MacSlow> Saviq, bfiller: it gets even a bit stranger... for the same contact sending an SMS, the avatar-image slightly different (seems like a different region shown)... and not the last test I did the full image was shown
<pitti> Laney, infinity, seb128: .. are now .. :)
<MacSlow> Saviq, bfiller: btw... in between image 260 also came in OTA
<GunnarHj> cjwatson, pitti: Any chance that bug #1294858 can be fixed in 14.04? Given that some langpacks contain multiple translations, I think it would be a step in the right direction.
<ubottu> bug 1294858 in ubiquity (Ubuntu) "Installer does not install all language support packages" [Undecided,New] https://launchpad.net/bugs/1294858
<spineau> Hello, I have two patches to apply for  plainbox-provider-resource-generic and plainbox-provider-checkbox in ubuntu.
<spineau> The changes are really small as it's just a namespace change in a configuration file for both
<spineau> https://code.launchpad.net/~sylvain-pineau/ubuntu/trusty/plainbox-provider-checkbox/namespace_fix/+merge/212629
<spineau> https://code.launchpad.net/~sylvain-pineau/ubuntu/trusty/plainbox-provider-resource-generic/namespace_fix/+merge/212627
<spineau> I'd like someone to review those patches as an upcoming version of ubuntu/checkbox-ng (0.2.2-1) will require the new namespace
<spineau> they can be dropped on future syncs to Debian
<slangasek> shadeslayer: a module to be loaded by a specific application is supposed to be in /etc/pam.d/$app
<shadeslayer> slangasek: roger, so for eg. if that module should be loaded on login, that would go in lightdm-greeter?
<shadeslayer> slangasek: this particular PAM module opens the KDE wallet on login
<slangasek> shadeslayer: I don't know the structure of the PAM configs for lightdm, but I would assume that lightdm-greeter is a PAM session for the /greeter/, and lightdm is the PAM session for the user login
<shadeslayer> oh
<shadeslayer> okay
<shadeslayer> slangasek: any clue why it's looking in /lib/security instead of /lib/arch/security
<shadeslayer> Mar 25 15:57:54 kubuntu lightdm: PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory
<slangasek> shadeslayer: because it looks in both directories
<slangasek> but only spits out an error message for the last directory
<shadeslayer> ah
<shadeslayer> slangasek: it doesn't actually seem to load the module
<shadeslayer> slangasek: http://paste.kde.org/p7ph6nr76
<slangasek> shadeslayer: 'ldd -d -r /lib/arch/security/pam_kwallet.so'?
<SpamapS> question re biosdevname: is there any reason we make it hard to turn on?
<SpamapS> cjwatson: ^^ ?
<pitti> sforshee: I reviewed https://code.launchpad.net/~sforshee/apport/iwlwifi-fw-error/+merge/212680; please let me know if you have questions
<pitti> sforshee: thanks
<smoser> hey. anyone able to help. i'm having trouble declaring 'prereq' in initramfs script (also tried hook).
<smoser> i must just be doing something wrong
<smoser> infinity, hey. your change to https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1271534 is causing cloud image build failure for i386 as seen
<ubottu> Launchpad bug 1271534 in eglibc (Ubuntu) "libc6-xen:i386 installation can cause panics on boot" [High,Fix released]
<smoser> http://paste.ubuntu.com/7152440/
<smoser> it is possible that we no longer need libc6-xen
<smoser> our seed for cloud-image explicitly lists libc6-xen
<smoser> for i386
<smoser> utlemming, ^
<infinity> smoser: You don't need libc6-xen, haven't for a long time.
<smoser> i suspected that.
<smoser> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/427288 is listed as "why".
<ubottu> Launchpad bug 427288 in Pantheon "Karmic i386 EC2 kernel emulating unsupported memory accesses" [Undecided,New]
<utlemming> that seems like an easy fix
<smoser> utlemming, we want to remove that, and to remove any thing else that we might have done in the build process to address it.
<infinity> smoser: I wasn't kidding when I called it redundant in the changelog.  libc6:i386 and libc6-xen:i386 were built with identical options when we moved to i686 by default, and no one noticed.
<utlemming> smoser: do you want to make the seed change and I'll build/confirm?
<smoser> well, that would seem to indicate that they were redundent.
<infinity> smoser: FWIW, upgrades will be fine, I tested that.
<infinity> smoser: (libc6:i386 C/P/R libc6-xen, and that worked fine on the i386 Xen VM I spun up)
<smoser> you're a good man, â
<smoser> utlemming, pushed
<utlemming> smoser: danke
<infinity> smoser: Also, due to the Provides, anything that depends on libc6-xen should be fine too, so need to carry deltas from Debian or anything.
<infinity> smoser: I assume your only issue was the explicit seed breaking your image build setup.  Sorry about that, didn't think to check.
<barry> xnox: https://code.launchpad.net/~xnox/phablet-tools/py2-3/+merge/205608 :(
<slangasek> barry: ?
<barry> slangasek: that's xnox's branch for py2/py3 phablet-test-run.  still not landed afaik
<slangasek> barry: was the landing silo requested somewhere more appropriate than in the log of the MP?
<slangasek> barry: for instance, if you talk to stgraber he may be able to help you get this scheduled
<barry> slangasek: i'm not sure.  i was hoping xnox would have some status
<bdmurray> xnox: did you sort out updating command-not-found-data?
<Logan_> bdmurray: regarding Bug 1295097, shouldn't we be tracking when the fix goes into the actual app-install-data-ubuntu package?
<ubottu> bug 1295097 in unity-webapps-qml "Mistyped word 'Comonent'" [Undecided,In progress] https://launchpad.net/bugs/1295097
<bdmurray> Logan_: okay, although its unlikely the bug would be automatically closed by a reference in the changelog so someone would need to manually close it.
<Logan_> I just think that it's probably not right to say that it's invalid, as that implies that it doesn't affect that package, while it actually does
<Logan_> but I do see where you're coming from about closing the bugs
<aberrant> hi all
<aberrant> is this the right channel for .deb packaging questions?
<TheMuso> aberrant: I think #ubuntu-motu is more appropriate.
<aberrant> thanks -trying there
<infinity> happyaron: Was that indicator-china-weather upload intended for your beta images, or for post-beta?
#ubuntu-devel 2014-03-26
<psusi> cjwatson, what do you think about adding a test to partman-ext3's check.d to tell you ( roughly ) "hey dummy, you didn't set up an efi system partition and mount it in /boot/grub/efi"?
<psusi> err, partman-efi rather
<happyaron> infinity: beta image
<smoser> slangasek, https://pastebin.canonical.com/107156/
<smoser> that make any sense to you?
<smoser> or anhyone else have ideas on how /etc/mtab got foobar'd to not include /
<smoser> that is precise
<psusi> smoser, that's odd.. I don't have access to that pastebin
<smoser> bah.
<smoser> yeah, that sucks.
<smoser> here, repaste
<psusi> smoser, but as a general rule, mtab gets foobared all kinds of ways, which is why upstream removed it some time ago
<psusi> but we're still stuck on a very old util-linux
<smoser> and replaced with link to /proc/mounts ?
<psusi> yep
<smoser> http://paste.ubuntu.com/7154679/
<psusi> I've been trying to get it updated for some time... spoke with infinity last week and he said he would block out some time to do it properly instead of my kind of hackish update soon
<psusi> ( basically I gave up on trying to identify which of the 1000+ commits in the debian repo that diverge from upstream actually matter and aren't already upstreamed and just threw them all out and copied the debian/ dir into the new upstream source and changed it to 3.0 quilt format )
<psusi> which probably would have introduced a regression or two, but I thought was worth it to get a clean start on an updated upstream rather than spending days analyzing that many bloody commits to pick out the handful that actually needed ported to quilt
<slangasek> smoser: if the rootfs was already mounted rw in the initramfs; or if the rootfs isn't listed at all in /etc/fstab; maybe that would account for it?
<pitti> Good morning
<pitti> Noskcaj: oh, what were the objections against uploads for xubuntu?
<Noskcaj> ?
<Noskcaj> pitti, Do you mean in my dmb meeting?
<pitti> Noskcaj: yes
<Noskcaj> The exact same reasons as with motu. Three out of four present members said they thought my quality of work wasn't enough
<Noskcaj> I ended up with rights for 4 packages, when i'm the debian maintainer for nearly all of xubuntu's apps
<pitti> yeah, I can understand the reason for waiting with MOTU TBH, but the xubuntu apps are pretty much all the same, packaging and policy wise
<pitti> anyway, just try again in half a year or so
<Noskcaj> yep
<pitti> Noskcaj: I'm curious, how well does the sponsoring process work from your perspective? I. e. whats the usual delay?
<Noskcaj> pitti, anywhere from 12 hours (for easy syncs) to a month (merges and patches)
<Noskcaj> The sponsoring process is good for syncs, since nearly all are done in a few days, but merges average 1 week or more
<Noskcaj> Unrelated, would it be worth syncing gnome-icon-theme-extras? build fixes + icons for SSDs
<pitti> sounds harmless enough
<Noskcaj> pitti, Will you sync the new glib releases? glib2.0 is fixes to docs, tests, and translations, and -networking is just translations the depends change you made
<Noskcaj> actual, beta freeze, so ignore the above for this week
<Noskcaj> *actually
<pitti> Noskcaj: yes, we most definitively want to do that; no worries, that's what we have -proposed for :)
 * pitti will package gobject-introspection too and upload it to exp/sync to trusty
<Noskcaj> ok. I'm just looking for 3.12 stuff we want.
<pitti> ah, someone already did,  nice
<pitti> Noskcaj: so yes, will do that tomorrow, when the images are set and there is no chance that we'll need -proposed for an urgent fix for beta-2
<Noskcaj> ok, cool
<Noskcaj> glibmm can probably get one more experimental point release (doc fixes) but not all the way to 3.12
<Noskcaj> I'm just using the irc logs as a reminder to myself now
<zyga> good morning
<dholbach> good morning
<menace> Hi, there were security announces about initramfs-tools and openssh on the Ubuntu Security Announce. But i see the updated packets for precise not in precise-security, but in precise-updates. Why? I would have assumed, it comes with the Security Repository? Do i understand something the wrong way?
<pitti> menace: they should be in both repositories
<pitti> menace: confirm with apt-cache policy openssh
<pitti> menace: -updates are mirrored, so they can usually be downloaded faster than from security.u.c.
<pitti> menace: I meant apt-cache policy openssh-server
<menace> ah, okay, that could explain why it was not in my security mirror.
<menace> another question: is there any "garantued" time from security announcement til appearance in the update/security repository?
<pitti> menace: when the announcement goes out, the update is alreayd on security.u.c
<pitti> menace: it of course may take some time until it is in -updates on your mirror
<pitti> until then, you'll download from -security; from then on, you'll download from -updates
<pitti> (that's the point of having it in both)
<pitti> sforshee: can such an iwlfifi error be triggered synthetically for testing?
<pitti> sforshee: e. g. on my system the /iwlwifi/iwlmvm/fw_error_dump path doesn't exist, I only have a "iwldvm" directory (not iwlmvm)
<pitti> sforshee: I replied on the MP, better keep the discussion at one place
<smoser> slangasek, possibly root was mounted rw in initramfs, but i'm not sure why that would have occurred. /etc/fstab never channged and the initramfs successfully found the root (missing data from that paste then is /proc/cmdline).
<zyga> pitti: what decides which gettext domains are added to language packs? just being in main or is there a secondary mechanism
<Saviq> can anyone make bug# 1232146 public please?
<zyga> Saviq: I can, it seems
<zyga> Saviq: are you sure?
<Saviq> zyga, dunno, not my bug :D
<Saviq> zyga, I can't see it
<Laney> I did it
<pitti> zyga: being in main, plus the ones whose source packages declare X-Ubuntu-Use-Langpack: yes
<Saviq> Laney, thanks
<zyga> oohhh
<zyga> pitti: ah, I misread you, ok
<zyga> pitti: so all I need is to wait for the next langpack rebuild, I was looking at plainbox packages and they lost their translations as compared to debian
<pitti> zyga: i.e. "plus" == "or", not "and"
<zyga> pitti: right
<zyga> pitti: thanks
<pitti> zyga: did plainbox recently move to main?
<pitti> zyga: yesterday's langpack build (with data from March 20) does not  have any trace of "plainbox"
<zyga> pitti: not recently, but only recently it gained i18n (after 0.5~b2 was synced to main by doko a few days ago)
<pitti> zyga: no templates available: https://translations.launchpad.net/ubuntu/trusty/+source/plainbox
<zyga> hmm
<zyga> how can I debug that?
<pitti> zyga: there are some at https://translations.launchpad.net/ubuntu/trusty/+source/plainbox/+imports
<zyga> oh
<zyga> so I need to manage that now?
<pitti> at this point I don't know any more what needs to happen; dpm ^
<pitti> zyga: that's an one-time thing AFAIK
<zyga> pitti: I don't seem to have the rights to approve those
<pitti> neither have I
<zyga> pitti: thanks for helping, I'll try to understand how this works
<pitti> zyga: dpm should know how to proceed from that
<dpm> pitti, zyga, let me see if I can have a look before my next call in a few mins
<zyga> dpm: thanks
<dpm> zyga, ok, I've approved the po/plainbox.pot template. It's a bit of a pain that it's a manual approval for each new template, but it should be done now. I guess the other 2 .pot files are a product of the build and can be ignored?
<dpm> https://translations.launchpad.net/ubuntu/trusty/+source/plainbox/+imports?field.filter_status=all&field.filter_extension=pot
<zyga> yes
<zyga> all the debian ones are dupes
<zyga> (I wonder if we should strip those during the build now)
<zyga> dpm: could you also approve 'stubbox.pot', the one in  plainbox/impl/providers/stubbox/po/stubbox.pot
<zyga> dpm: it is a part of the same package
<doko> will make a component-mismatch day today ...
<zbenjamin> cjohnston: ping, can you help me with some ideas about a sdk-launcher, that allows me to run and monitor a application in a special way?
<zbenjamin> cjohnston: sorry wrong nick
<zbenjamin> cjwatson: ping, can you help me with some ideas about a sdk-launcher, that allows me to run and monitor a application in a special way?
<zbenjamin> cjwatson: i wrote down what i need, its point 4 in this document: https://docs.google.com/a/canonical.com/document/d/1hCWBkCu81lEQMqhQ0TnxMvBmGrvsHnpBeWJmeXGDC8I/edit
<dholbach> jodh, is anything else required on https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1256949?
<ubottu> Launchpad bug 1256949 in linux (Ubuntu) "Dell Latitude E5420 doesn't boot if killswitch is turned to "radio off"" [Undecided,Expired]
<jodh> dholbach: that's probably a question for the kernel team - maybe they need to blacklist the default driver for that users wifi card?
<dholbach> jodh, it's just that the bug tasks both went to "expired"
<dholbach> so I'm not quite sure what's still missing on there
<jodh> dholbach: I too was slightly confused - the user found the solution to be a bad driver issue and already has a fix for it. It's not an upstart issue, hence my thought on the kernel team blacklisting.
<dholbach> ok
<dpm> zyga, done
<dpm> https://translations.launchpad.net/ubuntu/trusty/+source/plainbox/+imports?field.filter_status=all&field.filter_extension=pot
<zyga> dpm: thanks
<zyga> dpm: do the two 'aubuntnu archive auto sync' templates also need to be imported?
<dpm> zyga, yes. I approved the oldest ones and the newest will be imported subsequently. And from now on, no more manual approvals will be required, unless you change the name of the template or something like that
<zyga> ok, that should be it then, thanks :)
<cjwatson> zbenjamin: I would have thought that that should be done by extensions to upstart-app-launch (-> tedg)
<zbenjamin> cjwatson: yeah basically i need something like upstart-app-launch <appid> <pkgdir> that does the same as launching a click package just from the given directory
<zbenjamin> cjwatson: i can myself register listener for app-start stop signals
<cjwatson> Seems like something UAL could probably support without too much trouble, but you should talk with Ted about it
<zbenjamin> cjwatson: ok thx
<seb128> zyga, hey, could you have a look to https://bugs.launchpad.net/ubuntu/+source/checkbox-ng/+bug/1297118 ? e.u.c suggest that started recently, it looks like it might be your plainbox sync
<ubottu> Launchpad bug 1297118 in checkbox-ng (Ubuntu) "checkbox crashed with TypeError in emit_signal(): Don't know which D-Bus type to use to encode type "NoneType"" [High,New]
<zyga> seb128: looking
<zyga> seb128: I beliveve this will be fixed by checkbox-ng sync (there's a bug about that)
<zyga> seb128: checkbox-ng and plainbox are closely tied and after the latter was synced into ubuntu we were doing our best to sync the former as well
<zyga> seb128: note, there are also two merge requests to ubuntu branches to correct (one liners) some data sets to get the whole pack to work
<zyga> seb128: can we sync it over and see if that goes away?
<seb128> zyga, sure, you might want to ask #ubuntu-release to let that in for beta though
<seb128> zyga, do you have the bug number for the sync?
<zyga> yes looking
<zyga> bug 1297665
<ubottu> bug 1297665 in checkbox-ng (Ubuntu) "Sync checkbox-ng 0.2.2-1 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1297665
 * zyga looks at the crash dump to see if that might be anything other than misalignment
<zyga> seb128: ok, I've asked in #ubuntu-release, I'll go to test locally built packages
<seb128> zyga, I've synced checkbox
<seb128> let's see what release does
<seb128> zyga, thanks
<zyga> seb128: thanks
<zyga> seb128: can you look at the two merge requests listed in the same bug?
<seb128> zyga, if you approve them can you comment saying so? I can sponsor an upload with those then
<zyga> seb128: sure
<zyga> seb128: done
<seb128> zyga, thanks
<zyga> seb128: yeah, that particular crash is gone
<seb128> great
<zyga> seb128: quick question about those ubuntu branches, how does that work, after they get merged, will launchpad automatically build packages and upload them to the archive or is that just source that needs to be uploaded separately?
<cjwatson> it's just source
<zyga> cjwatson: ok, so to finish that, we need someone to sponsor those upload, correct?
<cjwatson> the automation is the other way round - the branches are (supposed to be) automatically updated from uploads
<cjwatson> I expect so, I haven't followed this discussion
<zyga> cjwatson: ok, the reason we poposed those changes  to ubuntu rather than debian is speed, we hoped that those could be quickly approved and land to trusty before beta (to fix the mismatch we're trying to resolve)
<zyga> cjwatson: so after they are merged, how should we proceed? just ask for sponsorship here?
<cjwatson> sorry, I was just drive-by commenting, don't have brainspace to think about this
<zyga> cjwatson: understood, sorry for keeping you busy
<cjwatson> but it does sound like you need a sponsor (not me :-) )
 * cjwatson goes back to doing battle with ubiquity
<seb128> zyga, don't worry about the lp:ubuntu vcs, we usually don't use those much, I'm going to sponsor the source and that should result in an autoimport in the vcs (if udd doesn't hit import bugs)
<zyga> seb128: sponsor the source, -> upload the merged sources as packages (which will trigger that autoimport to bzr that you mentioned)
<zyga> seb128: sorry for asking novice questions all the time, delivering *to* ubuntu wasn't something I did heavily before
<seb128> zyga, right, I'm just going to take the diff from those merge requests, apply them to the current packages and dput that
<zyga> ok
<zyga> sounds good
<seb128> I might just close the merge requests by hand with a comment when I do that
<seb128> to avoid confusion
<zyga> ok
<zbenjamin> tedg: hey ted did you receive my mail ?
<zbenjamin> tedg: it was about the sdk-launcher
<tedg> zbenjamin, My mail is being wonky... so not yet.
<zbenjamin> tedg: i can pastebin you the contents if you want
<tedg> Sure
<zbenjamin> tedg: http://pastebin.ubuntu.com/7156716/
<tedg> zbenjamin, In general, I think what you're asking for is very orthogonal to what we're trying to achieve with application startup in general.
<tedg> zbenjamin, Let me see if I can come up with some way for you guys to get what you need while not breaking standard startup.
<tedg> zbenjamin, Is there a reason that you're not making a click package and installing that?
<pitti> fginther, ev: does rabbitmq have some kind of builtin failover? or does every consumer just try to connect to a set of servers in an agreed-upon order, so that the primary queue server can go down?
<pitti> (that would still not synchronize the queues between the different servers)
<pitti> fginther, ev: my other question is: is there some best practice how to detect that a worker node went AWOL (grabbing but never ack'ing a ticket, or just stopped grabbing tickets), so that you get notified to fix it?
<pitti> fginther, ev: where "worker node" == thing that consumes requests from a queue
<zbenjamin> tedg: even if i would install the click package i still need to have that controller process and i still need to change the exec line
<tedg> zbenjamin, You can change the exec line before building the click package.
<zbenjamin> tedg: i think patching the desktop file would not be such a good idea for a installed click package
<zbenjamin> tedg: that would force me to rebuild the package every time even if no code changed
<tedg> zbenjamin, Yes
<tedg> zbenjamin, Seems like that'll be lower cost that copying it over USB.
<zbenjamin> tedg: its copying over ssh not over usb
<tedg> zbenjamin, Oh, then building the package is much lower cost than networking.
<zbenjamin> tedg: however we think it would be better to not install the package , because we would need to remove it later then again
<zbenjamin> tedg: zoltan had some more comments on this, maybe he should join the discussion
<tedg> zbenjamin, I would hope you already plan to remove what ever you install :-)
<cjwatson> I don't know if it helps, but note that it would be entirely possible to create another click database just for tests and install packages in there
<chrisccoulson> anyone have any idea why https://errors.ubuntu.com/oops/28760226-a973-11e3-b754-2c768aafd08c failed to retrace?
<cjwatson> we already have three click databases (core, custom, default), doing one more on the fly isn't hard
<chrisccoulson> note, this machine has submitted lots of thunderbird crashes, but all of the traces are useless :(
<zbenjamin> tedg: with my approach the is no install ;)
<tedg> cjwatson, Hmm, that's interesting. Not sure, it seems to me like people would have a test user, so putting it in that user's account is probably good.
<cjwatson> I don't much care, just letting you know it's an option :)
<tedg> zbenjamin, Copying is installing in your approach
<zbenjamin> tedg: but only a directory in /home/phablet/dev_tmp
<cjwatson> (since it isn't necessarily obvious to people)
<tedg> cjwatson, Yes, thanks, it is an interesting idea.
<zbenjamin> tedg: the current deploy method also just uploads what has changed, so that is very fast if only small parts have changed instead of the whole app
<zbenjamin> tedg: i'll be back in a few, lunch is already waiting ;)
<tedg> zbenjamin, K, bring bzoltan :-)
<Laney> zyga: seb128: did those MRs get uploaded?
<directhex> am i missing something, or do LTS enablement kernels not include firmware updates?
<zyga> Laney: not sure,
<Laney> Looks like not
<seb128> Laney, zyga: sorry, I got sidetracked, doing it
<Laney> If someone that's not me does it then I can review them
<Laney> for slippage innage
<infinity> directhex: Firmware updates happen in linux-firmware, generally.
<infinity> directhex: Though, some stuff is in the linux-lts-* kernel image packages directly, sometimes.
<directhex> infinity, i'm failing to see an iwlwifi-7260-*.ucode anywhere for precise :/
<infinity> directhex: That's in proposed.
<seb128> Laney, zyga, do you have changelog entries suggestion?
<directhex> infinity, oh :)
<infinity> directhex: Err, also in updates...
<infinity> Binary files /tmp/nKPVQdZgw6/linux-firmware-1.79.9/iwlwifi-3160-7.ucode and /tmp/diu29w0zXj/linux-firmware-1.79.10/iwlwifi-3160-7.ucode differ
<infinity> Binary files /tmp/nKPVQdZgw6/linux-firmware-1.79.9/iwlwifi-7260-7.ucode and /tmp/diu29w0zXj/linux-firmware-1.79.10/iwlwifi-7260-7.ucode differ
<directhex> infinity, huh. wonder why packages.ubuntu.com doesn't find it
<infinity> iwlwifi-7260-8.ucode in proposed.
<infinity> So, depends on which one you need (-7 or -8)
<directhex> does packages.u.c. file search not consider -updates?
<infinity> directhex: I assume you need -7, if you're using it with lts-saucy (ie: 3.11)
<seb128> zyga, btw, why did debian update checkbox but not plainbox-provider-checkbox? seems like that should be updated in debian and synced
<infinity> directhex: If you're using lts-trusty from the kernel team PPA, you'll need the linux-firmware in proposed.
<directhex> infinity, i'm working blind on new hardware, i don't know yet what level of kernel backportery it needs - just that the wifi is too new for the default kernel
<directhex> canonical certified, apparently. huh. wonder when i last updated my base installer image
<infinity> http://packages.ubuntu.com/search?searchon=contents&keywords=iwlwifi-7260-7.ucode&mode=exactfilename&suite=precise-updates&arch=any
<infinity> directhex: Well, if you're using lts-saucy, you need linux-firmware from updates, if you use lts-trusty (which isn't in the archive yet), you'll need linux-firmware from proposed.  Now you know. :)
<directhex> \o/
<directhex> looks like currently my default install kernel is... linux-lts-quantal. guess that answers the "when did i last update it" question.
<infinity> directhex: There's also the option of 3.2.0 or 3.5.0 with linux-backports-modules.
<infinity> Oh, I guess just 3.2.0.  There's no LBM for lts-quantal.
<directhex> infinity, i'm not at all opposed to a new kernel. using lts-quantal is because i haven't updated my installer image since raring shipped
 * infinity nods.
<directhex> anyway, thanks for the user support
<infinity> Pay it forward by documenting something somewhere for someone. :P
<zyga> seb128: we are working on updates to debian but we though that waiting for sponsorship was risky at this time
<zyga> seb128: updates to debian will include more features, this is really a bugfix for trusty
<seb128> zyga, how come debian doesn't have the same bug/need for fix if they have the same checkbox version
<seb128> zyga, ok anyway, but having a changelog entry would be handy, I'm unsure how to describe the change
<zyga> seb128: so it does but nobody needs that in debian yet :)
<zyga> seb128: and the update will be ready in a few days
<zyga> seb128: changelog 'correct namespace to match expected namespace in checkbox-ng'
<seb128> zyga, thanks
<zyga> seb128: that is fixed in trunk, we'll release updates to debian soon, this is safe to drop on next sync
<ev> pitti: http://www.rabbitmq.com/ha.html - though I'm sure #webops will have some thoughts.
<ev> possibly wgrant as well
<ev> pitti: back in the day, lifeless' suggestion was to write to both rabbit and cassandra. That way you could replay from cassandra when rabbit came back into existence.
<ev> I'd love to see that sort of thing generalised and reused in the many places we're using a queue model
<wgrant> In LP we store all jobs in postgres, and the rabbitmq jobs reference those
<wgrant> It's a bit bad, but less bad than rabbit HA was at the moment.
<wgrant> s/moment/time/
<ev> pitti: to your latter point, we probably want metrics of the workers via (tx)statsd. You could have another process watching the metrics for all the workers and if any of them failed to update the processed count in N minutes, you'd know it was wedged.
<ev> or something less rube goldberg-y
<ev> because when I think HA, I definitely think postgres :-P
<maco> ev: weird the things hanging out with historical reenactors instead of programmers does to your brain. "because when I think historically accurate, I definitely think postgres"
<cjwatson> kirkland: so, bug 1172014
<ubottu> bug 1172014 in ecryptfs-utils (Ubuntu) "encrypted swap device not correctly configured on fresh raring install" [High,Fix released] https://launchpad.net/bugs/1172014
<cjwatson> kirkland: this change caused a regression in ubiquity; not really your fault, ubiquity needed to resolve the UUID= in crypttab because it explicitly zeroes the device
<cjwatson> kirkland: but more importantly, I can't actually make the swap setup work properly even after fixing that ubiquity bug
<cjwatson> kirkland: I think https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1172014/comments/9 has the right of it; the swap space is set up with a random key, there's no container, so how can it have a stable UUID?
<ubottu> Launchpad bug 1172014 in ecryptfs-utils (Ubuntu) "encrypted swap device not correctly configured on fresh raring install" [High,Fix released]
<pitti> ev: thanks for the HA link, will digest in the next days
<ev> maco: :)
<bzoltan> zbenjamin: here
<zbenjamin> bzoltan: meh [15:43:29] <-- tedg (~ted@ubuntu/member/ted) hat das Netzwerk verlassen (Quit: Ex-Chat)
<cjwatson> kirkland: indeed when I reboot after installation, re-point crypttab to /dev/sda5 so that I can cryptdisks_start, copy the new UUID into /etc/crypttab, and reboot, it still doesn't work
<pitti> ev: ack, so a monitoring cron job/process (and who watches the watchers? :-) )
<zbenjamin> cjwatson: do you have a idea when tedg will be back?
<cjwatson> zbenjamin: no, sory
<cjwatson> *sorry
<ev> pitti: you could equally make the processes watch themselves. Spin off a thread that does it.
<ev> but python, threading, yay
<zbenjamin> tedg: bzoltan: ping
<tedg> zbenjamin, bzoltan, howdy folks
 * zbenjamin just waits for zoltan to arrive
<Chipaca> are files in /usr/share/upstart/sessions considered conffiles?
<cjwatson> No
<cjwatson> I mean, whether something is a conffile is governed by whether it's in the package's "conffiles" control file (/var/lib/dpkg/info/*.conffiles)
<cjwatson> but conffiles are generally configuration files, and configuration files must reside in /etc
<cjwatson> https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
<Chipaca> right
<Chipaca> cjwatson: i'm wondering how to point to a multiarch binary from an upstart session file
<Chipaca> not finding much info
<cjwatson> files in /usr/share shouldn't be architecture-specific
<cjwatson> put a wrapper somewhere else?
<cjwatson> I can't really fathom how being a conffile would help :)
<zbenjamin> tedg: ok seems bzoltan is busy right now, lets move the discussion to tomorrow then, or maybe a ML don't know which approach is better
<Chipaca> cjwatson: there seems to be support for having multiarch conffiles in multiple packages not break dpkg
<cjwatson> you are going down a rabbit hole
<Chipaca> cjwatson: yes
<cjwatson> I suggest climbing the other way
<cjwatson> conffiles will at best fail to hinder you
<Chipaca> cjwatson: I'm not sure what value I'm giving users by making my package multiarch
<cjwatson> (and even that is unlikely)
<Chipaca> so I might just make it not be multiarch
<cjwatson> could you make all this concrete, please?  what package is this?
<Chipaca> cjwatson: ubuntu-push-client
<tedg> zbenjamin, K, I'll reply to your mail and CC him.
<cjwatson> Chipaca: does it have any reverse-dependencies?
<zbenjamin> tedg: yeah thats maybe easier thx :)
<cjwatson> it's not in the archive at the moment, I see
<Chipaca> cjwatson: no
<Chipaca> cjwatson: it's in NEW, afaik
<Chipaca> or maybe in proposed?
<cjwatson> Chipaca: I can't really see why a leaf client package would need to be Multi-Arch: same
 * Chipaca looks
<cjwatson> Chipaca: it perhaps ought to be Multi-Arch: foreign
<cjwatson> huh, it is in trusty, I'm obviously just not quite up to date
<Chipaca> it is?
<pitti> ev: we could also think about a "ping" fanout queue (with timeout of e. g. 30 s) and find broken workers that way; no response -> really broken, and on ack the worker coudl check if it has a running job for more than N hours
 * Chipaca refreshes
<cjwatson> hah, that package is nonsensically laid out
<cjwatson> it's using Multi-Arch: same style paths while being Multi-Arch: foreign
<Chipaca> cjwatson: :) I am but an egg
<cjwatson> move the executable to /usr/lib/ubuntu-push-client/ubuntu-push-client
<cjwatson> this is probably just a libexecdir accident
<ev> pitti: so the workers tell the watchdog about their state? And if the watchdog dies we just point a new one at the queue the workers are submitting state to?
<cjwatson> perhaps dh_auto_configure -- --libexecdir=/usr/lib
<Chipaca> cjwatson: i'm putting it there by hand
<cjwatson> sorry,  dh_auto_configure -- --libexecdir=\$${prefix}/lib  I mean
<cjwatson> ok, don't :)
<Chipaca> cjwatson: ok :)
<cjwatson> /usr/lib/<multiarch triplet> paths only make sense in Multi-Arch: same packages
<cjwatson> which would generally be libraries
<cjwatson> I see that /usr/share/upstart/sessions/ubuntu-push-client.conf already points to /usr/lib/ubuntu-push-client/ubuntu-push-client
<pitti> ev: dying watchdog is of course a recursive problem; but cron failing ought to be a really rare event
<cjwatson> Chipaca: so, the whole conffiles thing is a red herring anyway because /usr/share/upstart/sessions/ubuntu-push-client.conf is in the very same architecture-dependent package so it could just be built to embed whichever paths you need; but that would be a different kind of policy violation and as I say doesn't actually make sense, so better to simplify
<pitti> ev: I mean, someome will notice if packages/MPs don't get through, it woudl just be nice to have a place to look for the worker status; so I think with statd or a ping queue or something similar whose ping fanout requests come from cron we should be good enough
<Chipaca> cjohnston: and it's already multiarch:foreign, so all i ineed to du is remove the triplet
<cjwatson> exactly
<Chipaca> cjwatson: ^
<pitti> ev: and we can figure out the set of "expected" workers from the existing logs (they contain host names)
<Chipaca> cjohnston: sorry :)
<ev> pitti: the watchdog dying due to busted code in it? Yeah, but the beauty of that is that all we lose is the ability to kill wedged workers
<ev> we can have a nagios alert on the watchdog process
<ev> which in turn sends to pagerduty
<pitti> ev: so as soon as a worker submits one result into swift, it'll be in the set of "expected to be there" workers
<cjwatson> golang-ubuntu-push-dev arguably ought to be M-A: foreign too, but that's not very important
<pitti> ev: right; at that point I'll gladly hand that over to the CI experts for this :)
<ev> and we get a text message saying, "hey fool, the watchdog is down. We're not going to kill any hung workers until you fix it. But take your time."
<ev> heh
<ev> the experts in being woken up in the middle of the night, you mean
<pitti> ev: I'll think about a proper design on Friday when I'll be typing impaired anyway, just collecting various Lego blocks now to build it with :)
<cjwatson> actually, since golang-ubuntu-push-dev has no dependencies it really doesn't matter
<pitti> ev: no, I mean telling me how to design teh watching of the watchers, etc. :)
<ev> I'll start putting that on job profiles. Must have skills in sleep deprivation.
<ev> oh right
<ev> vila: ^ you're the point of contact on this one :)
<ev> I think we've got the outline of a sensible model there, but we'll need to make sure it's interfaced with nagios
<pitti> ev: watchdog dying should be an once-in-a-year condition (unless it's the whole server itself which goes down), and then it shouldn't be a "ring people out of bed" conditiona s long as the actual tests still come in
<ev> yeah
<pitti> ev: i. e. we expect to have enough redundatn workers that we cna easily get along with 20% of them failing
<ev> we can keep the watchdog code simple
 * ev nods
 * vila reads backlog
<Chipaca> cjwatson: thanks a ton
<cjwatson> np
<ev> I'm super encouraged by how much you get this need for resilience to failure and graceful degradation
<pitti> ev: yes, that was the idea; send a "ping" to a fanout queue, wait 30 s for acks, consider the missing ones as dead; sounds like a 15 line thing
 * ev nods
<pitti> ev: well, so far jibel and I have taken the penalty of not having such a system, so I'm notivated :)
<ev> :)
<pitti> ev: as for nagios: can we tell it something like "the latest report (URL to text file or so) from the watchdog is older than 30 minutes, it must be dead"?
<ev> pitti: it's probably best to have the watchdog touch a file for that, but yes
<pitti> ev: right, I meant something like that
<ev> yeah, entirely doable
<vila> pitti: so, as of today (things will change) the way we do that in the ci engine is to have the test runner monitor the testbed (where the test actually run) and we have a 'engine health' page monitoring the workers (the test runner is the worker reading the rabbit queue)
<vila> pitti: so feedback from adt-run goes to the test runner which can decide the testbed is dead if nothing comes in for too long
<pitti> vila: right, adt-run already has timeouts for everythign it does to the testbed
<vila> pitti: in 2.3.7 already ?
<pitti> vila: forever really
<vila> pitti: hmm, never ran into them then
<fginther> pitti, (sorry your ping was off my page).  rabbitmq can be built for HA, but I haven't looked into that yet. For the second question, there is a way for the server to know that a worker has died (the server recognizes that the other end of the connection is no longer active), but we're not using this now. I'd have to look it up again
<pitti> fginther: thanks
<vila> pitti: ack, I see them now, and the cmdline options too ;)
<vila> exit
<vila> damn focus
<hallyn> if i need to ship a helper script for a udev hook to call, is there a particular place it should go?
<stgraber> hallyn: /lib/udev I believe
<hallyn> just right in there, no subdir?  cool, thanks.
<mpt> âdiv.table-of-contents {â¦max-width: 50%;â¦}â â oh dear
<xyzzymaze> Greetings ... trying to install Trusty BuildDate Mar 25 .. it boots, I can do disc-check, but selecting install ends up black screen. I have Nvidia Geforce 210 card installed. Live sys looks 'up' as ctrl-alt-F2 gets to a session prompt .. thank you!
<doko> zul, python-oslotest wants a python3-hacking b-d ...
<zul> doko:  ok ill fix it up
<jamespage> jdstrand, slangasek: can we get a definitive position on the golang discussion in bug 1267393 for the context of 14.04 please?
<ubottu> bug 1267393 in juju-mongodb (Ubuntu) "[MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang" [High,New] https://launchpad.net/bugs/1267393
<jdstrand> I plan on responding soon-- I am looking into a few things
<jamespage> jdstrand, thanks
<jdstrand> it is very high on my todo
<jamespage> jdstrand, appreciated
<infinity> jdstrand: To be fair, even fixing dynamic linking in golang (which we're not going to do, and even if we help with, won't do in time) doesn't fix the biggest issue.
<infinity> jdstrand: golang upstream is a typical Google project that gives exactly zero shits about stable release support, so we'd be on the hook for digging out and backporting fixes ourselves.  Or give it a firefox/chromium-style upstream version exception, which is madness for a compiler.
<mdeslaur> hehe
<infinity> I'm going to stay out of the compiler argument on that MIR, and jump on the whole "juju-core doesn't ship all its binaries in the archive" thing which, amazingly, no one's even mentioned.
<jamespage> infinity, I think I've pointed at it enough
<infinity> jamespage: Honestly, I think it's a major blocker, and I don't grasp why people seem to handwave over it with a "yeah, we'll fix it some day".
<infinity> jamespage: Cause, either it's not a problem at all, and they can package the binaries, or it's an excuse to hide much bigger problems that need fixing.
<infinity> jamespage: It's pretty black and white in my mind.
<jamespage> infinity, I commented on how that binary is built; but I've left it to the upstream dev team to explain why
<alow> infinity: looking at this patch stuff for libv8 again. You had mentioned whitespace issues, which files?
<infinity> alow: Oh, err.  I'd given up caring and was going to just generate my patch with diff -w
<infinity> alow: But there were a few bits.  Lemme find the tree.
<alow> infinity: I suspect there were one or two
<infinity> Argh.  Total context switch fail...
<infinity> alow: Which branch is the branch I care about again?
<alow> infinity: https://github.com/andrewlow/v8ppc/tree/libv8-3.14
<infinity> src/jsregexp.cc
<alow> yup - I can 'fix' that
<infinity> src/objects.cc
<infinity> src/serialize.cc
<alow> infinity: what diff command are you using to compare the two git repos again?
<infinity> Those three all have a few instances of indentation going wonky.
<alow> infinity: let me fix those 3.. can't be hard
<infinity> alow: That was 'git diff d8d994ca1752c530d2cbf8d9b43b1881b642ddf9 remotes/origin/libv8-3.14' (ie: the diff from my last update and your current HEAD)
<infinity> alow: Of course, if those were whitespace cleanups that you missed in the last update, maybe it's actually fixing something.  Guess I should compare back to the original...
<infinity> alow: Oh, and that might be the case.
<infinity> alow: Yeah, ignore me.
<infinity> alow: That was you cleaning up better, and my diff method finding the cleanups.
<alow> infinity: I'm doing a diff from the original git://anonscm.debian.org/collab-maint/libv8.git and mine https://github.com/andrewlow/v8ppc/tree/libv8-3.14
<infinity> alow: (ie: if I diff from 6b10fef46edfb4dc2a7aed389d75574c40a14243 to your HEAD, those changes aren't there)
<infinity> alow: Diff from 6b10fef46edfb4dc2a7aed389d75574c40a14243 to you is what matters, as 6b10fef46edfb4dc2a7aed389d75574c40a14243 is what the orig.tar.gz is built against.
<alow> infinity: shmm.. when I did this work a while back, I thought I had found more "whitespace" errors in mine.. that I was trying to correct
<infinity> alow: Doing the full diff (instead of the incremental I shouldn't have been doing), the only wonky whitespace I see in your stuff is trailing spaces in a few places.
<infinity> Like aix_gyp.patch, which shouldn't be in the tree at all, probably.
<alow> true
<infinity> alow: Do you know if bumping the v8 version like your current HEAD does has any actual impact on anything (symbol versions, etc), or if it's just cosmetic?
<alow> infinity: it should be cosmetic
<alow> infinity: it should be just the patch level we're bumping here
<infinity> -#define IS_CANDIDATE_VERSION 1
<infinity> +#define IS_CANDIDATE_VERSION 0
<infinity> That may have an impact, though.
<infinity> Ahh, but you backed that out.
<alow> infinity: it was a series of commits I was applying
<alow> infinity: this allowed me to keep the original commits from the master v8 repo
<infinity> Or... IS_CANDIDATE_VERSION has always been 0 in our packages.  Whee.
<infinity> So, neevrmind.
<alow> infinity: exactly :)
<infinity> Maybe I'm reading that boolean backwards, and "1" is used to define "RCs" or something.
<infinity> Or, we've always shipped something that thinks it's a dev/trunk/beta thing.  Whatever.
<infinity> If it works, it works.
<alow> infinity: 0 should be the right value for libv8
<infinity> alow: Anyhow, your current HEAD looks fine to me, now that I rediffed to my base instead of to our last update.  So, ignore my previous whining.
<infinity> alow: I don't suppose you know much about Corentin's mongo/ppc port.  That's much scarier than your v8 stuff. :P
<alow> infinity: uh... I think i've talked with him, but mostly to help him get libv8 building
<infinity> alow: Do you know how much (if any) of it has been submitted/accepted upstream for future versions?
<alow> infinity: of 'it' being what?
<infinity> alow: He's pretty much wrapped every call to anything anywhere in some endian check/flip madness, which makes for a pretty hard to audit diff.
<infinity> alow: "it" being his mongo work.
<alow> infinity: oh.. the mongo stuff. no idea sorry
<infinity> Also the occasional signed/unsigned char fix in here.  It's pretty clear that no one's heavily tested Mongo on ARM either, if they think any of this works today.
<alow> infinity: I'm assuming you're looking at the mongo code. Again, it's pretty foreign to me, haven't looked at it in any detail
<infinity> alow: It's foreign to me too.  And I wish it would stay that way. :)
<infinity> alow: Anyhow, I don't think I have any more to bug you about WRT V8.  I might have questions about node if it doesn't Just Work later today, but the "port" seems pretty simple, given an externally-linked-and-functional libv8, so I doubt it'll give me troubles.
<alow> infinity: sure.. catch me here or drop an email if node has problems
<alow> infinity: oh.. you might need one or two endian changes for BE in the Node code
<infinity> alow: Above and beyond the v0.10.25-release-ppc branch?
<alow> infinity: You can sniff around here https://github.com/andrewlow/node for some of them.
<alow> we have a v0.10.26-release-ppc branch - it includes the endian changes (as does 25)
<alow> compare against v0.10.26-release
<alow> to see the deltas
<infinity> alow: Well, we ship .25, so that's the one I was looking in.
<alow> we also have unstable 0.11.x
<infinity> alow: So, my hope here is that " git diff remotes/origin/v0.10.25-release remotes/origin/v0.10.25-release-ppc | filterdiff -x '*deps/v8ppc/*'" gives me basically what I need.
<seb128> cjwatson, stgraber: hey, could one of you have a look to https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1244736 ? there is a simple suggested change, not sure if it makes sense (basically bailing out of starting the agent if there is already another one running)
<ubottu> Launchpad bug 1244736 in openssh (Ubuntu) "upstart configuration for user launches an extra ssh-agent" [Undecided,Confirmed]
<alow> infinity: I bow to your git diff mastery - yes, it should work
<infinity> alow: Alright, cool.  Will whine later if we're wrong. ;)
<kirkland> cjwatson: yes, this is an unfortunate one
<kirkland> cjwatson: your analysis is correct, we use a random key (and throw that key away) at each boot
<kirkland> cjwatson: otherwise, we have a key management problem
<doko> zul, test failures, missing b-d on six? https://launchpad.net/ubuntu/+source/python-oslotest/0.1-1ubuntu1/+build/5851799
#ubuntu-devel 2014-03-27
<ScottK> doko: Are you going to upload the rebuilds for extensions to drop 3.3 support?
<msx> hello everyone :) I've enjoying 14.04-desktop_amd64 since almost a month now and so far it's shaping as an amazing release - rock solid, fast... really beautiful. However I've found this strange issue I'm unable to debug, may be you can shed some light here guys: whenever I return from susped, there will be a sustained load average of +1. On normal conditions like a fresh boot, the usual load when idle
<msx> could be as low as 0.01 (kudos!!!) but after waking from suspend you won't be seeing the load average drop 1.10~1.20
<msx> Any idea? How could I debug this issue?
<msx> s/i've/i'v been/g :)
<TheMuso> msx: Have you looked at what is eating your resources in system monitor, or using top in a terminal?
<TheMuso> msx: No actual idea what it could be, but knowing what process is using resources is somewhere to start looking at least.
<msx> TheMuso: hey!
<msx> TheMuso: well, actually, top doesn't shows anything unusual; in fact the consume is as about as normal as always BUT the loadaverage is always from 1.10 upwards
<msx> TheMuso: if the load average would start with a 0.x everthing would be perfectly normal
<msx> i'm very intrigued about what could be happening ^_^
<pitti> Good morning
<pitti> slangasek: wooooow, https://code.launchpad.net/~xnox/phablet-tools/py2-3/+merge/205608 landed at last \o/
<pitti> bdmurray, ev: errors now running on prodstack> niice!
<pitti> tvoss: guten Morgen
<dholbach> good morning
 * pitti hugs dholbach
 * dholbach hugs pitti back
<zyga> good morning
<pitti> ev, zyga, fginther: I've been looking for an ack timeout in rabbitmq -- i. e. that a message gets re-queued if the accepting worker doesn't ack it within a given time; I only found some references that this isn't possible, but they are from 2009
<pitti> zyga: sorry, I meant vila
<pitti> ev, vila, fginther: do you know if that's possible?
<vila> pitti: so far, we've managed to always ack (outcome reported whether it succeeded or failed)
<vila> pitti: as fginther hinted, we want to dig that far more
<pitti> vila: so this wouldn't cover the case if the test process gets stuck, but stays alive
<pitti> vila: if the worker node dies properly, the AMQP connection will be terminated and the message requeued, so that's fine
<pitti> but if a test runs indefinitely long, it won't help
<ev> I'm certain it's possible (otherwise why have ack'ed messages at all?). I'll dig in a little bit.
<vila> pitti: but adt-run will timeout in that case no ?
<ev> Oh I misread.
<pitti> vila: usually yes; just playing the "what could possibly go wrong" game :)
<vila> pitti: the testbed and the worker are distinct instances
<vila> pitti: yeah, right ;)
<vila> pitti: planned to be digged to the bottom ;) Feel free to vanguard, I won't be far ;)
<pitti> vila: I've seen an LXC host kernel-panic and stop doing anything for heavily loaded container tests
<pitti> and I'm not sure whether that already was sufficiently dead to drop network connections
<pitti> there's a per-queue and per-message TTL, but that will just kill messages after no worker grabs it for that time, so that's the opposite of what we want
<vila> pitti: LXC host meaning the host handling the container running adt-run right ?
<pitti> right
<pitti> vila: I guess we could implement this manually; the controller would traverse the list of pending (unacked) requests regularly (assuming that this is accessible), and re-queue the ones which haven't been acked after 6 hours
<vila> pitti: so, this design has indeed a fatal failure mode, we avoid that by using (today) a nova instance for the testbed, (future) a MAAS instance for bare metal
<vila> pitti: but in any case, the worker should not be subject to such a failure mode in production (it's ok for local use as it's faster)
<pitti> vila: well, "should" -- it happened; kernel bugs are everywhere :)
<pitti> (or hw)
<vila> pitti: yes, that's why the worker (controlling the testbed) should not be on the same host
<pitti> vila: hm, I think I disagree
<vila> pitti: so it can monitor the testbed in all scenarios
<pitti> it introduces more things that can go wrong, and doesn't really solve the problem
<pitti> as now you need the same kind of sync between controller and worker, AND worker and testbed
<pitti> twice the number of hosts which can fail, and twice the amount of synchronization/acks to do
<vila> pitti: err, it removes one thing that can go wrong: a user test crashing the infra
<pitti> vila: we'll run tests in QEMU, that's not the problem
<pitti> vila: the problem was that the host kernel, or the host's hard disk freaked out on high loads (from LXC, but I don't think that matters that much)
<vila> pitti: right, QEMU is not lxc, that's what a nova instance provides
<vila> pitti: so we separate root causes between worker and testbed and can handle them differently
<pitti> vila: I'll see whether it's possible for the controller to get/check/kill unacked requests
<vila> pitti: so the worker can fail, the message is not acked, another worker takes the ticket
<pitti> vila: you mean it does get acked, but with a failure result?
<vila> pitti: yes
<pitti> vila: because "not acked â another worker takes ticket" is exactly what I'm looking for :)
<vila> pitti: I haven't written tests for that yet, but that's a strong assumption in our design, if it's not guaranteed, we'll have to re-design ;)
<pitti> vila: which assumption do you mean? relying on workers to always eventually acking requests?
<vila> pitti: I've been assured it was a safe assumption though ;)
<pitti> (or dying properly with closing net connections)
<pitti> vila: well, maybe it is
<vila> pitti: either the worker ack the message or the message becomes available in the queue after some time
<pitti> vila: I'm not sure how much active "pinging" rabbitmq does to the accepting worker to determine whether its connection is still alive
<vila> pitti: yup, that's exactly the point that needs to be tested
<pitti> vila: ok; it seems you didn't run into this kind of trouble so far, so perhaps this can be put on the backburner for now?
 * pitti tries what happens when SIGSTOPping the worker
<vila> pitti: that's what we've done, I'm not super comfortable with that but it's on my radar
<vila> pitti: but yes, we didn't run into that case (yet)
<pitti> vila: ok; thanks for your help! (and sorry for keeping bothering you)
<vila> pitti: not bothering at all, happy to share the knowledge there as we acquire it ;)
<pitti> it seems I have a habit that the very first problems I'm thinking of in these new systems are the ones which are impossible or underdocumented :)
<vila> pitti: same here, which led to a reputation of being over concerned ;)
<vila> until things break ;)
<pitti> vila: so if I sigstop a worker (so that it definitively can't serve its network connection), the rabbit server still thinks it's active
<vila> pitti: and to make things clear: the actual design is under construction, so more eyeballs help
<vila> pitti: right, so there should be some way[s] to configure that, hopefully on a per-queue basis
<pitti> only if I control-C it it puts the message back into the queue
<vila> pitti: meeting starting right now
<pitti> vila: ack
<vila> pitti: oh.. interesting, does that mean SIGSTOP must be handled or we miss some safety net already provided in other cases ?
<pitti> vila: no, I was just simulating what happens if the worker suddenly stops responding to net requeusts without closing its network connection properly
<pitti> vila: i. e. the equivalent of what could happen on a kernel panic and processes end up in deep kernel sleep, etc.
<pitti> vila, ev: ah, http://www.rabbitmq.com/tutorials/tutorial-two-python.html officially documents the absence of timeouts
<cjwatson> seb128: thanks - I need to test it but I've stuck a patch derived from that one in my working tree so I don't forget about it
<pitti> so if that turns out to be an actual problem, we can regularly iterate over these queues and kill the workers; but that can (and has to) be bolted on top of the system anyway, so IMHO no need to do this in phase 1
<seb128> cjwatson, thanks
<pitti> vila, ev: but hard-switching off (lxc-stop -k) the worker DTRT, so I think that covers the most common problems
<jamespage> doko_, figured out that eclipse-* failures - gnumail osgi metadata was not quite right - need a drop of javax.activiation
<jamespage> fix uploaded
<vila> pitti: from your url above: 'RabbitMQ will redeliver the message only when the worker connection dies.' so it should be a matter of waiting for the connection to die right ? That can delay nacks, but they will occur no ?
<vila> pitti: at worst, a worker can lose the connection and fail to ack and the same message will be handled twice, but I think handling duplicates will be easier than losing messages
<zyga> hey, quick question, what is the syntax for debian/control, that says package depends on the same version of another binary package from the same source package
<zyga> like libfoo and foo that need to be updated together
<zyga> I recall something like ${Source:vesrsion}
<zyga> but I cannot find any docs about that
<zyga> ${binary:Version}
<zyga> ?
<cjwatson> zyga: package-name (= ${binary:Version})
<cjwatson> zyga: deb-substvars(5)
<zyga> cjwatson: thanks
<cjwatson> There are subtleties in the event that one of the binaries is arch-dependent and the other is arch-independent
<pitti> vila: yes, duplicates isn't a problem in the adt case
<vila> pitti: thanks, I had troubles here, I may have missed some msgs
<pitti> vila: no you didn't miss anything; I was AFK for a bit
<vila> pitti: did you reply to: 'from your url above: 'RabbitMQ will redeliver the message only when the worker connection dies.' so it should be a matter of waiting for the connection to die right ?' ?
<pitti> vila: right
<vila> pitti: i.e. you mentioned a test you did, could it be that the connection wasn't yet dead ?
<pitti> vila: it logically wasn't
<pitti> vila: i. e. it never got a RST, but it wasn't really alive either as the worker was stopped
<pitti> vila: which might approximate what happens if a system freezes due to a hardware failure or kernel panic or similar
<vila> pitti: but a TCP connection should ultimately die (what's the timeout there, 20 mins or something ?), right ?
<pitti> vila: but as I said, we can handle that using nagios and regular ping queues, and just killing hanging workers
<pitti> vila: I don't know, I'm afraid
<pitti> vila: I just waited a few minutes, certainly not 20
<vila> pitti: ack
<vila> pitti: right, one other assumption we did early on, was that rabbit itself is considered reliable so if a msg is received, it won't be lost
<pitti> vila: so, perhaps this is a non-issue as the connection will eventually die; it seems rabbit is being used by quite a number of people, if that was a real problem I'd think that there was a common solution by now
 * vila nods
<pitti> vila: so either way, I think we have the tools to deal with this problem, I was just curious whether I coudl do something like [...], ack_timeout='4 hours'
<vila> pitti: a consequence of the above is that we focus on making sure msgs are properly queued/dequeued and don't have to handle inter components failure modes otherwise
<vila> pitti: yeah :-/
<vila> pitti: but you mentioned TTL at one point ?
<pitti> vila: *nod*, I assume that part is okay; I was playing around quite heavily with randomly killing multiple workers etc., and I never lost one
<pitti> vila: yes, that's the other way around: if a message isn't being picked up by TTL, it gets deleted
<vila> ha, hmm, the opposite of what I'd like ;)
<pitti> vila: so we certainly want to know when that happens (-> again, housekeeping cron job), but not kill messages, but fix the AWOL workers instead
<pitti> so I don't think we want to use that feature
<vila> pitti: agreed
<vila> pitti: oh, you mean it's opt-in ?
<pitti> vila: yes: http://www.rabbitmq.com/ttl.html
<vila> excellent
<pitti> vila: which is certainly handy for some use cases (just not our's here)
<vila> pitti: yup
 * vila go reads those pages and stop annoying pitti with silly questions
<pitti> vila: no no, that's fine :) this is all new to me, too
<vila> pitti: ha, right, one more idea comes back: we can have a different queue where workers send heartbeats so they can be killed if they fail to do so, not sure it's worth it at that point but that's one way to monitor them
<pitti> vila: right, I proposed that yesterday (to fginther, I believe)
<pitti> ah no, to ev
<vila> pitti: hehe GMTA ;)
<pitti> vila: anyway, we can do that, or regularly check pending and unack'ed queue entries in rabbit, or similar
<vila> or rather, good ideas spread, spontaneously ;)
<pitti> vila: we can have a fanout queue, and every worker has to ack in 30 seconds; the set of expected workers comes from the results in swift
<pitti> vila: that was roughly my proposal
<vila> pitti: right, I tend to prefer separate means for separate goals, but... real life decides
<ev> pitti, vila: we must not be the first people to face this problem
<ev> I wonder if there's decent prior work
<ev> though the current approach seems sound
<ev> pitti, vila: perhaps we already covered this, but could the workers not just open('/srv/tr_worker/var/heartbeat.stamp', 'w').close() ? Then the watchdog could just check timestamps to know if it needs to kill the daemon?
<ev> whatever we do, we should definitely have a test for os.kill (worker_pid, signal.SIGSTOP)
<pitti> ev: the watchdog sshs in? If it can ssh, then we shouldnt' have the problem of "hung kernel" in the first place, but yes
<pitti> ev: if that's any easier than checking unack'ed messages in the queue
<vila> ev: what pitti said, we need to cope with unreachable workers
<ev> pitti: no need. Just put the watchdog on every system
<pitti> ev: the watchdog will be affected by crashing hw/kernel just as the adt worker, though
<vila> ev: that's the same as sending a heartbeat so someone still have to monitor the heartbeats from a *different* instance or we're back to square one
<ev> we can have a separate check for "do you respond to ssh? No. Okay, `nova delete` to you."
<pitti> but of course, if the watchdog/ssh don't respond, that's already a "died" condition
<pitti> *nod*
<ev> then juju automatically respawns the worker. In the case of the test runner. Not sure how to do this with lxc containers
<ev> but I'm assuming there's something comparable
<ev> or you could use juju to manage them
<pitti> yes
<ev> since it does that now
<pitti> juju-local can do that
<ev> whoop
<pitti> or just lxc-stop / lxc-start again
<ev> can I just say that I'm so excited for this? :)
<vila> yeah, <vm tech> start/stop
<pitti> excited> +1
<pitti> ev, vila: FYI, I'm working on a spec here: https://wiki.debian.org/MartinPitt/DistributedDebCI
<pitti> ev, vila: once it's ready, I'll send mail for review/commenting
<vila> pitti: ack
<rbasak> cjwatson: any opinion on openssh 6.6? It's "primarily a bugfix release" but it seems quite late now. I just triaged bug 1298280.
<ubottu> bug 1298280 in openssh (Ubuntu) "Update OpenSSH to 6.6" [Wishlist,Triaged] https://launchpad.net/bugs/1298280
<cjwatson> rbasak: I already have it staged and plan to land it
<rbasak> Ah - thanks!
<cjwatson> was talking with Marc about it a few days back
<smoser> slangasek, https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1160079 ? that going to get in ?
<ubottu> Launchpad bug 1160079 in plymouth (Ubuntu) "plymouth aborts in cloud images" [Medium,Confirmed]
<rbasak> mterry: please could you review https://bugs.launchpad.net/ubuntu/+source/juju-quickstart/+bug/1273865/comments/19, which answers your question on this MIR bug?
<ubottu> Launchpad bug 1273865 in websocket-client (Ubuntu Trusty) "[MIR] juju-quickstart, python-jujuclient, urwid, websocket-client" [High,New]
<rbasak> mterry: we have a FFe bug waiting too - if we can get this acked, is this sufficient for main?
<cjwatson> rbasak: openssh> btw you can always feel free to test stuff in git://anonscm.debian.org/pkg-ssh/openssh.git :-)
<rbasak> cjwatson: don't look at me. I just triaged the bug! :)
<cjwatson> if you feel the urge
<cjwatson> ok :)
<cjwatson> it's always worth a try
<rbasak> :)
<mterry> rbasak, yeah both MIR and FFe would be sufficient for main.  I'm looking at that bug
<knocte> does William Hua hang out here?
<rbasak> mterry: fyi, there was some concurrent chat about this in #juju just now. jamespage will update the bug.
<jamespage> mterry, rbasak: commented on bug
<Chipaca> jcastro: hi there. were you aware the askubuntu login thing (via our sso) isn't working?
<jcastro> no
<Laney> knocte: he is attente on this network, but email might be better to reach him
<Chipaca> jcastro: (as an aside, can't you change it to use sso and not lp?)
<knocte> Laney: I'm trying here because email didn't work..
<jcastro> Chipaca, we've asked them to but never put a priority on it
<bdmurray> pitti: could we get the dbg syms updated for lightdm?
<Laney> well, you have the nick
<Chipaca> jcastro: fair enough; maybe if it's broken they'll fix it and change it at the same time :)
<Laney> try a PM
<seb128> knocte, what do you want from him? maybe others can help you?
<bdmurray> pitti: for version 1.9.13-0ubuntu1
<knocte> seb128: a hint on where to start looking to try to fix https://bugs.launchpad.net/bugs/1286605
<ubottu> Launchpad bug 1286605 in unity-gtk-module (Ubuntu) "Unity global menu causes handlers of the "activate" signal of Gtk.Action to be emptied" [Medium,Triaged]
<jcastro> Chipaca, http://meta.askubuntu.com/questions/2837/moving-to-ubuntu-single-sign-on
<jcastro> can you bump that and then I can ping someone
<Chipaca> jcastro: maybe what's happening is that it's under way right now? (and instead of removing the button they disabled it?)
<jcastro> no clue
<Chipaca> jcastro: I can't bump that, no
<Chipaca> jcastro: because I can't log in
<seb128> knocte, k, yeah you want to talk to attente ... he's in utc+10 tz atm though, so he's probably sleeping atm
<jcastro> oh, ok, I can try to hunt someone down
<knocte> ok thanks seb
<jcastro> Chipaca, lp login works for me
<Chipaca> jcastro: when i try to add a comment there is no lp button, so it does look like it's ongoing
<jcastro> I just tried it
<infinity> pitti: How do you feel about the state of psql SRUs?  Are they ready to go today, despite being a tiny bit early?
<Chipaca> jcastro: i'm trying chrome and firefox, no luck in either
<jcastro> Chipaca, when you click the LP button it takes you to the text field, where you have to type in your name and then click log in
<Chipaca> jcastro: the button does nothing
<Chipaca> jcastro: there is no text field
<arges> stgraber: hi. I'm going through your fixes for ifupdown and seeing if they apply to precise. Do you think backporting bug 1072518's fix to precise seems reasonable?
<ubottu> bug 1072518 in ifupdown (Ubuntu) "Restart networking crashes dbus and the desktop manager" [Critical,Fix released] https://launchpad.net/bugs/1072518
<arges> just the preventing ability to stop/restart networking iteractively
<stgraber> arges: hmm, as much as I'd like to see this gone, it'd be a behavior change that some people may (as wrong as it is), rely on
<arges> stgraber: that was my concern as well...
<arges> stgraber: i'll leave that one out then. and just ensure that documentation gets updated
<infinity> It's pretty shocking the number of people who think "restart networking" is the way to reconfigure interfaces.  I wish I knew where this came from originally.
<stgraber> infinity: at least that will simply fail in 14.04, I'm sure we'll get some more bug reports because of that, but at least it won't trash their system anymore...
<arges> https://help.ubuntu.com/12.04/serverguide/network-configuration.html  suggests 'sudo /etc/init.d/networking restart' hmm
<arges> that's fixed in the 14.04 guide
<infinity> stgraber: I already have one bug report because of it, yes.
<infinity> stgraber: Not sure if the error lacks appropriate verbosity, or if the user in question was just silly (I'm assuming the latter).
<infinity> arges: Argh.
<stgraber> infinity: we can't print something on screen when they hit it, so upstart will report a failed to stop and the actual reason is in upstart's log file at /var/log/upstart/networking.log
<stgraber> stgraber@castiana:~/Desktop/rcu$ sudo restart networking
<stgraber> restart: Job failed to restart
<stgraber> stgraber@castiana:~/Desktop/rcu$ sudo tail /var/log/upstart/networking.log
<stgraber> Stopping or restarting the networking job is not supported.
<stgraber> Use ifdown & ifup to reconfigure desired interface.
<infinity> stgraber: Yeah, that's pretty opaque.
<infinity> stgraber: Is there really not a sane way to echo to the controlling tty?  Having *everything* in logs isn't always the best default.
 * arges files a bug against serverguide...
<slangasek> well, a) don't call restart directly, use 'sudo service networking restart'
<infinity> slangasek: That latter is still wrong...
<infinity> (In the cases when it works, it's by accident, not design)
<slangasek> infinity: right, which is b) someone could patch service to tail the log
<infinity> cjwatson: Pretty sure I've praised it at least once before in the last few months, but live-installer on a fast storage device, whee.  2-second base installs.
<infinity> cjwatson: Don't know if it's ever been pondered, but why not swap base-installer for live-installer in netboot as well, and just publish base.squashfs?
<infinity> (Oh, I guess that would mean publishing it to the package mirror, not the CD mirror, that would be a problem)
<infinity> So, nevermind that.
<alow> infinity: how did the node stuff go on top of libv8?
<infinity> alow: Fine, I just needed to add one patch to your set.
<infinity> alow: http://paste.ubuntu.com/7163741/ <-- without that, my ppc64el systems tried to configure as ppc (ie: 32-bit), which didn't work out so well.
<seb128> bdmurray, hey, do you have access  to extra datas for e.u.c reports than the ones in the UI?
<seb128> bdmurray, e.g https://errors.ubuntu.com/problem/85c403c4a05cd32a48a73b226340850faa45e785
<bdmurray> infinity: could you have a look at the patch in bug 1296386?
<ubottu> bug 1296386 in casper (Ubuntu) "[PATCH] Remove 23etc_modules script" [Undecided,New] https://launchpad.net/bugs/1296386
<seb128> bdmurray, is there any way to know why retracing fails, or see if those users are running ppas or get access to a dump of a report?
 * dholbach hugs hggdh
<cjwatson> infinity: yeah, mirroring would be the problem
 * hggdh hugs dholbach :-)
<tarpman> dholbach: hggdh++
<bdmurray> seb128: I'll have a look at the retracer logs for any of those examples.
<infinity> bdmurray: Yes, but not on beta day.  Want to keep it on your list of things to nag about? :P
<seb128> bdmurray, thanks
<alow> infinity: Thanks - I'll add that to our code
<bdmurray> infinity: what makes you think I have such a list?
<infinity> bdmurray: A hunch.
<slangasek> bdmurray: I think he said you should assign it to him
<bdmurray> slangasek: and keep it on the nag list. ;-)
<bdmurray> seb128: outdated debug symbol package for liblttng-ust0: package version 2.4.0~rc4-1ubuntu2 dbgsym version 2.1.1-2
<seb128> bdmurray, that's not likely the problem though
<infinity> alow: It looks like Debian's moved on from .25 to .26.. Do you know if that brings any dangers with it (ABI transition, API breaks, etc)?
<bdmurray> seb128: well that's why it failed to retrace
<infinity> alow: Considering it for us, but only if it's really low risk, since we're close to release.
<seb128> bdmurray, can you see from the log what qtubuntu-android version is installed?
<bdmurray> seb128: its not listed in Dependencies.txt so probably not
<seb128> bdmurray, I though that apport had smartness to resolve the packages containing the files listed in the stacktrace?
<seb128> or in the procmap rather
<alow> infinity: I don't see a big risk moving to 0.10.26 - let me go look at the deltas
<bdmurray> seb128: yes it does, but it just picks the latest package version in the pocket (-updates, etc) when trying to retrace
<seb128> bdmurray, don't we have also some magic to see when a ppa was in use to warn about it?
<bdmurray> seb128: yeah, that'd show up in Tags as 'third-party-packages'
<bdmurray> seb128: well but maybe only for dependencies and not stuff in ProcMaps
<seb128> bdmurray, ok, I guess we are just without a solution for that one then
<seb128> bdmurray, thanks for checking/helping!
<infinity> Does someone upstarty want to tell me why minutes after I've booted, sysvinit jobs seem to run again?
<infinity> slangasek: ^?
<infinity> slangasek: http://paste.ubuntu.com/7163794/ <-- Note the last few lines.
<infinity> slangasek: I see this on my buildds too, and it does genuinely seem to be starting again, not for the first time, as on the buildds, I get apache erroring because it's already running, etc.
<slangasek> infinity: the ondemand init script is special
<slangasek> infinity: and doesn't point to anything running again
<infinity> slangasek: The ondemand thing should be a red herring here, it execs itself in the background.  Unless that's what's causing the rest of this.
<slangasek> infinity: it shouldn't be causing any of the rest of it; but you said "note the last few lines", maybe you want to be more specific? :)
<slangasek> you mean the apparmor profiles stuff?
<infinity> slangasek: When I said "last few lines", I mean "hey look, I'm booted and logged in and, oh neat, a couple of minutes later, I'm starting apparmor and restoring resolver state".
<infinity> slangasek: And, like I said, on my buildds, I see this with apache and launchpad-buildd too.
<infinity> For a long time, I thought it was an oddity with booting without an initrd, so didn't care, but this example is a standard install with an initrd.
<slangasek> infinity: well here's a question, why the heck is something like "dns-clean" running in runlevel 2 instead of in rcS?
<infinity> slangasek: Dunno, but apparmor *is* in rcS, so that's still weird.
<alow> infinity: RE: 0.10.25 -> 0.10.26  http://blog.nodejs.org/2014/02/18/node-v0-10-26-stable/ Mostly it's a bunch of bug fixes. Possibly more changes than you'd like to see, but no API level changes that I'm aware of.
<slangasek> infinity: but I don't know what to make of those messages, anyway; I'm not aware of ever having seen this, and it's even weirder that you're getting messages from /etc/rcS.d/S??apparmor + /etc/rc2.d/S??dns-clean
<mterry> jamespage, regarding juju-quickstart -- there would be value in having it in main as an installer for the universe packages, eh?  I'm not sure what the MIR policy on such installer packages is -- we let ubuntuone do that.  But I'm asking the other MIR team members
<alow> infinity: IMHO - being 'current' has quite a bit of value.
<infinity> slangasek: I imagine it's (re-)running all of rcS and rc2, those are just the only two with output.
<infinity> slangasek: But haven't ever had the time to try to dissect it.
<slangasek> infinity: I could imagine blaming it on a late network interface start, but dns-clean appears to only be wired up for ppp interfaces
<infinity> slangasek: And, again, wouldn't explain the apparmor start.
<slangasek> infinity: the output from those init scripts is using the standard lsb interfaces; it makes no sense at all that they would be the only two with output
<infinity> slangasek: Meh.  Well, I'll have to look into it again when it's not today.
<slangasek> infinity: fwiw the fact that you also have an 'ntpdate' process in your ps output also points me this way
<infinity> slangasek: But there's something weird going on.  Like I said, on my buildds, where it seems clear it's double-starting some things (because the late sysvinit messages on the console also whine about failing due to ports in use), something's up...
<slangasek> infinity: so if you want further debugging, please try to reproduce when booted with --verbose, then capture the upstart-induced dmesgry
<infinity> slangasek: Right.  Will do $later.
<slangasek> but I'm 70% sure that what you're seeing is deferred activation triggered by the network interface coming up
<slangasek> I just don't see the path it's taking
<infinity> slangasek: Does that explanation explain the late apparmor?
<infinity> slangasek: Do we defer all of sysvinity until post-network?
<infinity> sysvinit, too.
<slangasek> infinity: in the sense that there are per-network-interface apparmor hooks (/etc/init/network-interface-security.conf), maybe?  But I don't see where that triggers the init script
<slangasek> infinity: and yes, rc2 waits for static network configuration
<slangasek> so that explains late running of dns-clean (and apache), but not double-running
<infinity> slangasek: I'll dig deeper later and see if I can come up with something more coherent than months of confused memories.
<jdstrand> infinity: curious-- is apparmor starting twice or just very late? jjohansen has seen it start late and, for example, not load profiles (eg firefox) until much later
<jdstrand> infinity: which of course means that his firefox is running unconfined
<jdstrand> we have a medium term solution for pregenerating apparmor cache in kernel postinst, and know how to do it, which would then allow us to not only improve boot performance after install/first boot with new kernel, but allows us to do an upstart job very early since it won't slow boot
<infinity> jdstrand: Without more debugging, hard to say for sure if it's twice or late.
<jdstrand> (or systemd unit, doesn't matter)
<infinity> jdstrand: But if pregeneration and an upstart job is something you think you can safely land at this point in the cycle, that sounds like a better method anyway.
<jdstrand> infinity: is this a server or desktop?
<infinity> jdstrand: These are all servers.
<jdstrand> infinity: we cannot
<jdstrand> this is 14.10 at this point unfortunately
<infinity> Ahh, well.  A man can dream.
<jdstrand> infinity: so, you could quickly login and do a tcpdump that continues to run
<mdeslaur> infinity: please delay the LTS until 14.10. thanks.
<jdstrand> infinity: then login to another console and do 'sudo aa-status'
<infinity> jdstrand: Right, I might ask for debugging tips some day that isn't today. :)
<jdstrand> and look for 'X processes are unconfined but have a profile defined'
<jdstrand> infinity: ack
<jdstrand> we've always known there was a race
<infinity> Certainly, if the first start is that delayed, the idea that a bunch of stuff might be unconfined (like, half my system?) seems a bit less than ideal.
<jdstrand> but in practice, people never really hit it
<jdstrand> we still don't have widespread bug reports
<jdstrand> well, any actually
<jdstrand> it has just been observed on occasion
<jdstrand> infinity: on a server it is less of a concern cause the profile load happens in the upstart job
<jdstrand> before the exec
<jdstrand> the whole generate profile cache in postinst is possibly SRUable btw
<infinity> jdstrand: So, if it's happening in an upstart job, does that mean the console spew from the sysv job is basically redundant and meaningless?
<jdstrand> I think we'll have most of the kernel bits-- beyond that it is mostly kernel packaging and an apparmor SRU
<jdstrand> infinity: no-- the policy load happens in multiple stages. the network-security job makes sure dhclient is handled. upstart jobs are modified to load policy before the exec, like with mysql. then there is everything else that doesn't have an upstart job, like tcpdump
<jdstrand> it is the last stage that is the most problematic
<jdstrand> cause that happens via sysvinit which is racy
<jdstrand> we could move that to an upstart job now, but people would probably get fired
<jdstrand> :)
<jdstrand> "you increased boot time by how long!?!"
<jdstrand> the good news is that we have a plan, we know what to do, and it is scheduled work for later
<jdstrand> that is quite a bit better than even 3 months ago
<jdstrand> (we discussed it at our team sprint recently)
<infinity> jdstrand: I like the precompiling notion.  People notice postinsts sucking a bit less than they notice boot time.
<sbeattie> infinity, jdstrand: it really looks like from infinity's paste that it's starting late, not running twice; note the profile loads im dmesg are from /etc/init/network-interface-security.conf, not from the sysvinit apparmor script
<infinity> jdstrand: I suspect we all remember the good ol' days when we used to always run "depmod" on boot too...
<jdstrand> infinity: (also, the fact that an upstart job loads the mysql policy only to have the sysv script do it later is redundant-- but in that case the cache is present for at least on of them, so it is as fast as the file can be read from the disk)
<jdstrand> infinity: re sucking> absolutely
<jdstrand> sbeattie: oh, you are right :\
<infinity> (Of course, from my weird POV, I notice postinst sucking more than boot time, because I upgrade constantly and never reboot, but I'm preeeeetty sure that's not normal)
<jdstrand> something in trusty is delaying the apparmor sysv run...
<jdstrand> (sometimes)
<jdstrand> like I said, we might need to do an SRU
<infinity> jdstrand: Could it be that slangasek's assertion about network interfaces only delaying rc2 is wrong, and it in fact delays all of sysvinit?  That would pretty much explain that paste.
<infinity> (Since I'm hung up on ntpdate)
<jdstrand> (that said, if someone could figure outwhy it is late and fix it, that would be excellent. /me can't reproduce)
<slangasek> no, it could not
<jdstrand> I unfortunately am not an expert with upstart job interactions
<infinity> slangasek: Kay.  Then back to the weird conclusion and the "not debugging today" thing.
<infinity> jdstrand: Anyhow, I see this on tons of machines and can pretty much reproduce at will, so I'll get together with you guys to see if we can unwind it a bit later.
<slangasek> oh, wait
 * slangasek scratches his head
<jdstrand> infinity: that is good to know
<infinity> (That was a fresh beta2 install from only moments earlier, so nothing weird there at all)
<slangasek> ok, so /etc/init.d/rcS is run from the bottom of /etc/init/rc-sysinit.conf, which does key on static network up
<slangasek> I thought we had better interleaving of /etc/rcS.d with the rest of the system
<slangasek> jdstrand: so yeah, any late apparmoring that you're seeing is actually related to us having made /etc/rc2.d non-racy, without noticing that this also holds up /etc/rcS.d :/
<slangasek> proper fix would be to split out /etc/rcS.d handling, and make it wait for the local filesystem but not the network
<infinity> slangasek: So, curious followup.  Why do I have a console?
<jdstrand> slangasek: oh! it is great to know the cause
<infinity> slangasek: My hvc0 job is "start on stopped rc RUNLEVEL=[2345]", is that basically a complete lie, given how we're running rcS/rc2?
<jdstrand> slangasek: since I use network-manager, the fact that I don't see it locally is consistent with your understanding of the issue, correct?
<slangasek> jdstrand: correct
<jdstrand> I never saw it in a vm cause I almost always do desktop installs in them
<slangasek> infinity: ummmm ok, yeah, I don't know why you would have a console with output from rc2.d showing up then
<slangasek> infinity: because 'stopped rc RUNLEVEL=[2345]' should mean the console starts only after all of rc2.d is done running
<infinity> slangasek: That's what I would think, yes.
<jdstrand> slangasek: so, is there something that can be done for 14.04 for this? (like I said, we can't to the cache pregeneration/upstart job change before 14.10/SRU)
<infinity> slangasek: And really, while delayed boots are annoying (and they are), the larger complaint is actually that these late starts scribble all over the getty, making it confusingly non-obvious that a login prompt has happened. :P
<slangasek> jdstrand: file a bug on upstart, cut'n'paste my comment above about the fix, and we'll see if we can pull it off sanely before 14.04
<infinity> slangasek: I saw the same with the ppc64el cloud images too, but assumed cloud-init was just doing something silly.
<infinity> (Which it might be, but..)
<jdstrand> slangasek: ack, thanks! shall I tag it special somehow or assign it to someone or is the bug enough?
<tester56_> Is there I way I can rebuild a package without installing build-deps on my system? means I trigger something like  dpkg-buildpackage, and it looks for the build-deps, installs them to a temporary directory, compiles everything, moves the final deb package to a destination folder and removes the temporary directory (if specified)?
<tester56_> *a way
<tester56_> damn ... how is that ... I am still here :-)
<jdstrand> slangasek: fyi, bug #1298539
<ubottu> bug 1298539 in upstart (Ubuntu) "apparmor rcS.d sysv initscript is running too late" [Undecided,New] https://launchpad.net/bugs/1298539
<tarpman> tester56_: you're looking for pbuilder or sbuild
<tarpman> tester56_: alternatively, upload it to a ppa and let launchpad do the work
<slangasek> jdstrand: ta
<tester56_> tarpman: thanks, what would you recommend pbuild?
<tarpman> tester56_: pardon?
<tester56_> tarpman: sorry, I wanted to ask: which of the two options would you recommend, pbuilder or sbuild
<tester56_> tarpman: judging from the ubuntuwiki it seems pbuilder is better documented
<tarpman> tester56_: no strong opinion. personally I use sbuild; so do the buildds. others think pbuilder is better for the personal case
<tester56_> tarpman: both use chroot?
<tarpman> yes
<tester56_> tarpman: do they install something like ubuntu-minimal?
<tarpman> tester56_: sbuild does debootstrap --variant=buildd, which is even slightly smaller than that. not sure about pbuilder
<tester56_> tarpman: thanks I will look into both
<tarpman> tester56_: cheers
<jamespage> mterry, ack - I've expressed what I think the position is - but I'm happy to leave the decision to the MIR team
<mterry> jamespage, I think MIR team is happy to consider the two juju MIRs as coupled
<mterry> i.e. like not for 14.04
<doko> Logan_, https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-pycxx/
<jtaylor> fwiw I can't reproduce neither ci.debian
<jtaylor> does gccs [atu]san stuff make sense for shared libraries?
<jtaylor> because libtool strips it ...
<arges> hallyn: hey looking at your upload for libvirt in saucy. mdeslaur mentioned that there may be a security update to libvirt soon. can this fix wait to be re-based on top of the security update?
<mdeslaur> arges: it's going to take me a while before I can push out the security update, might as well do the -proposed cycle first
<arges> mdeslaur: ok that's good to know
<arges> bdmurray: ^^^
<bdmurray> mdeslaur: okay, thanks
<Logan_> doko: wassup?
<doko> Logan_, you did sync the package, now the autopkg test is failing.. are you aware of this?
<Noskcaj> Where can i see the jenkins test failures? I Asked for a sync of pycxx which is aparently not testing properly
<jtaylor> Noskcaj: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-pycxx/
<Noskcaj> thanks
<Laney> Noskcaj: In general linked from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<Noskcaj> Does the failure mean anything to you guys?
<Noskcaj> I have to go to school now, will be back later
<jtaylor> Noskcaj: I can't reproduce it, neither can ci.debian.net
<Laney> I can
<jtaylor> I guess we shuld sync cython to trusty
<jtaylor> oh it is nevermind
<jtaylor> pts out of date
<Laney> python3-cxx-dev has broken symlinks in /usr/share/doc/python3-cxx-dev/examples/
<jtaylor> hm upgrade issue?
<jtaylor> looks fine for me
<Laney> installed in a chroot
<darkxst> gjs i386 tests failed all of a sudden, and I dont have enough internet atm to look into it...
<jtaylor> oO
<jtaylor> were are those symlinks coming from
<jtaylor> my chroot built package does not have them
<infinity> jtaylor: cython is synced, but FTBFS on ppc64el.  And doko keeps ignoring the tests.  Grr. :P
<jtaylor> maybe the numpy ppcel64 patch does not work
<Laney> jtaylor: huh, they're coming from pkgstripfiles
<jtaylor> Laney: why is that creating broken symlinks?
<infinity> It really shouldn't.
<infinity> It's pretty careful about what it links and how.
<jtaylor> why is pycxx in main anyhow?
<jtaylor> its not exactly a much used package
<jtaylor> the few users it has just embed it
<jtaylor> what does pkgstripfiles do? no manpage :(
<Laney> Many things, one of which is making symlinks of identical /usr/share/doc/ files where a dependency exists and they're built from the same package in order to save space
<infinity> Laney: Those links should never dangle, though.
<Laney> No, if they end up doing so it's a bug
<infinity> Laney: It's very careful to only link to packages that the package depends on.
<infinity> Oh, I wonder if one of these has a replaces on the other or something and it's causing havoc.
<infinity>     install|upgrade)
<infinity>         test ! -L /usr/share/doc/python3-cxx-dev || rm /usr/share/doc/python3-cxx-dev
<infinity>     ;;
<infinity> Whee.
<jtaylor> hm whats wrong there?
<Laney> Nah, it's this:
<Laney> + ln -s ../python-cxx-dev/examples/setup.py /home/laney/temp/pycxx-6.2.5/debian/python3-cxx-dev/usr/share/doc/python3-cxx-dev/examples/setup.py
<infinity> Laney: There's nothing wrong with that.
<infinity> Laney: If python-cxx-dev ships that file.
<infinity> Which it claims to: /usr/share/doc/python-cxx-dev/examples/setup.py
<infinity> It's in the dpkg file list, but it ain't on disk. :P
<Laney> (desktop-trusty-amd64)root@iota:/home/laney/temp/pycxx-6.2.5# readlink -m  /usr/share/doc/python3-cxx-dev/examples/test_example.py
<Laney> /usr/share/doc/python3-cxx-dev/python-cxx-dev/examples/test_example.py
<infinity> Oh!
<infinity> I was missing the lack of extra ../
<Laney> Yeah
<infinity> Okay, yeah, that's a straight up bug, but... How?
<Laney> This is quite a surprising bug!
<infinity> Maybe that was never written to grok multiple levels of doc dirs.
<infinity> Cause, other than massive HTML and docs and examples, there usually aren't multple levels, and who would ship those twice? :)
<infinity> -ln -s "../$dep/$f" "$thisfile";
<infinity> +ln -s "$depfile" "$thisfile";
<infinity> Laney: ^-- Betting that would fix it.
<infinity> Oh.
<infinity> No.
<infinity> That would link to the build tree.
<infinity> Whee.
<infinity> But how can this work at all if $f is wrong?
<Laney> I guess you need to count the number of components in $f and go up that many levels
<infinity> Oh, right, $f is right.  I didn't read your output well enough.
<infinity> So it's just that, yes.
<infinity> Just add another ../ per count of / in $f
 * infinity tries this bash-only without forking..
<Laney> good luck with that ...
<Laney> looping over the string doesn't count
<infinity> Laney: Something like this (untested): http://paste.ubuntu.com/7165305/
<infinity> Err.
<infinity> s/prefix/f/ on that first line.
<infinity>                 slashes="${f//[^\/]}"
<infinity> Laney: If you have a build tree available, a test would be cool. :)
 * infinity spins up a chroot.
<Laney> lrwxrwxrwx root/root         0 2014-03-27 22:17 ./usr/share/doc/python3-cxx-dev/examples/setup.py -> ../../python-cxx-dev/examples/setup.py
<infinity> That looks more correct.
<infinity> Laney: The rest of the doc dir still look sane?
<infinity> Laney: If so, I shall upload that ugly looking mess.
<Laney> My way was to remove the slashes and then subtract the lengths
<Laney> Lemme run the test and see if it passes now
<Laney> No more broken symlinks in there
<infinity> Laney: Oh, was your paste with mine or yours?
<Laney> Yours
<infinity> Kay, cool.
<Laney> I was playing in a separate script
<infinity> Uploading, then.  Once I give it a quick test.
<infinity> This probably should have a testsuite entry.
<infinity> And, somehow, I don't care about the test right now...
 * infinity testbuilds and uploads.
<Laney> The pycxx test needs to cp -L
<Laney> Other than that it works
<Laney> jtaylor: ^-- is that something you'd want to have in Debian?
<infinity> Don't see why it would hurt to have it in Debian.
<infinity> It's a no-op on real files anyway.
<Laney> It was a polite way of asking him to kindly include it there. :)
<infinity> Heh.
<jtaylor> sure I can add that
<infinity> I'm a bit shocked no one's ever noticed this problem before.
<jtaylor> isn't -L the default of cp?
<hallyn> bdmurray: i messed up the saucy libvirt update, failed to build - pushed a new one just now which fixed that.  sorry.
<infinity> And wonder if it's worth a scan of a lintian lab for broken doc links.
<Laney> jtaylor: not with -r
<jtaylor> right
<infinity> Laney: Fix is in the queue.
<Laney> Lies
<Laney> Okay, now it is
<Laney> Done
<Laney> Uploaded pycxx, but I'd wait until after pkgbinarymangler is published to accept it
<infinity> Indeed.
 * Laney goes away to play games
<jtaylor> doko: there is a new numpy to merge, as you did the last its probably faster if you do it directly instead of me doing the sponsoring dance
<infinity> jtaylor: Your pycxx was autoaccepted...
<infinity> Or someone else accepted it.
<infinity> Err.
<infinity> Laney: ^
<infinity> jtaylor: Not you. :P
<infinity> jtaylor: But I guess if you upload the -L thing to Debian, we can just sync over Laney's upload.
<jtaylor> yes I'll do so tomorrow
<Laney> infinity: ho hum, should have mentioned it in #-release
<infinity> Laney: Yeah, no big deal.
<infinity> Laney: I was going to just reupload it to get it off the list.
<Laney> Kay
<Laney> Noskcaj: ^^^ your problem turned out to be quite fun (would have appreciated some initial investigation from your side though)
* infinity changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
#ubuntu-devel 2014-03-28
<infinity_> hallyn: *poke*
<infinity_> hallyn: The .so belongs in the -dev package, not the library package (re: cgmanager)
<Logan_> hey infinity :)
<Logan_> doko: pitti sponsored that, not me
<Logan_> I don't even have access to the main component, haha
<Logan_> but I'm flattered that you think I'm a core dev :P
<infinity> Logan_: Hai.
<Logan_> :)
<infinity> Logan_: Or was that just a random hi without a followup? :)
<Logan_> infinity: oh, just a random hi :P
<infinity> zul: Do we ever plan to make use of the "openstack-meta-packages" package from Debian that's been sitting in -proposed for 275 days, or should we remove it and blacklist it as not relevant to how we do openstacky things?
<infinity> Logan_: Well, random hi to you too.
<hallyn> infinity: the .so does?  then what is the point of the library package?
 * hallyn goes to edumacate himself at the pkg guide
<RAOF> hallyn: The .so file is a symlink to the *actual* library, used by ld to resolve -lfoo to libfoo.so to libfoo.so.the.actual.object.with.real.code
<RAOF> So it's only interesting for development, which is why it goes in the development package :)
<hallyn> oh, right.
<hallyn> infinity: so can i re-use that package version since it was rejected?
<infinity> hallyn: Yeahp.
<infinity> RAOF: Thanks for laying the smack down while I smoked.
<hallyn> cool.  thanks.  now i do wonder if i could have kept the .a file in there and hav eit work...
 * infinity needs to start recruiting policy sidekicks.
<infinity> hallyn: Why did you remove the static lib?  I didn't check the bug.
 * RAOF has _asked_ whether ubuntu-archive needs more members :P
<infinity> hallyn: Not that it's required to ship it or not, it's vaguely optional, but it's a nice option to offer in some cases.
<hallyn> infinity: we were confused as to why cgmanager wasn't showing in ldd for lxc.
<hallyn> infinity: i didn't notice at first that the .so wasn't in the pkg
<infinity> RAOF: Didn't we do some training or other for you on some team or other at some point?
<hallyn> so i removed the .a file as i figured builds might prefer the static over dynamic lib if available
<infinity> hallyn: Oh, right, so yeah, with no .so, it would link statically by default, cause that's all there is.
<RAOF> infinity: Yeah, enough to use the bits of archive-admin tooling necessary to do SRUs.
<hallyn> anway if it's all the same whether it is there or not,
<hallyn> then i'll put it back.
<infinity> RAOF: Right, bring it up next week, and let's see about AA indoctrination.
<infinity> RAOF: We do need new blood, but it's not something I like to advertise, cause then we get outside pressure to accept people who shouldn't be doing it.
<infinity> (And yes, I made that statement publically just now on purpose)
<RAOF> :)
<hallyn> infinity: thanks, new version pushed.
<infinity> hallyn: Ta.
<Logan_> infinity: I might be interested
<infinity> Logan_: In?
<Logan_> AA
<infinity> Logan_: You're a little on the shiny and new side for that, yet.
<infinity> Logan_: Let's work on core-dev first. :P
<Logan_> okay :P
<hallyn> oh ffs.
<hallyn> bzr bd done did me wrong
<Logan_> UDD <3
<psusi> cjwatson, a debian user just filed a bug report about the issue we found and fixed in ubuntu regarding the out of order partition table entries causing a failure to update the kernel in parted.  I had sent you a git bundle a while back with that and one other fix for loop labels.  Do you think you could get around to applying it please? ;)
<cjwatson> psusi: oh blast yeah, sorry, I'll take care of that tomorrow
<psusi> cjwatson, cool cool...
<psusi> or, I think I asked you about getting on the debian parted maintainer team and upload/git write access and you said to ask later ;)
<psusi> then I could just push it myself
<psusi> also, those partman patches I fixed up per your request are still waiting ;)
<infinity> cjwatson: ++      macppc|ppc*) host_arch=ppc ;;
<infinity> ++      ppc64*) host_arch=ppc64 ;;
<infinity> cjwatson: What's wrong with this case statement?
<cjwatson> psusi: well, those partman patches did require quite a bit of review ... but yeah, I need to get back to the next iterations of those
<cjwatson> infinity: er, oops.  in my defence I did test-build on ppc64el
<infinity> cjwatson: Well, probably because of this:
<infinity> +-  ppc|ppc64|powerpc|powerpc64)
<infinity> ++  ppc*|powerpc*)
<infinity> +     arch='ppc'
<cjwatson> yeah, so I think it's just dead code
<infinity> IOW, the ppc/ppc64 distinction doesn't appear to matter.
<infinity> Still, the case is wrong. :P
<cjwatson> I'll fix it
<infinity> Ta.
<infinity> Every time I see another one of those uname = target constructs, though, I'm both glad we run linux32 everywhere, and really annoyed that we have to.
<infinity> cjwatson: You could have just reversed the order too. :)
<infinity> cjwatson: (But that works, I don't think we'll ever actually see a ppcel kernel)
<infinity> cjwatson: And, as pointed out, it's probably useless code ANYWAY.
<cjwatson> Right
<cjwatson> I was mostly just trying to line it up roughly with mplayer TBH :)
<hallyn> grumble.  i had to look at that for at least 30 seconds before i saw the problem.
<zul> infinity:  remove it and blacklist it
<infinity> zul: Ta.
<infinity> hallyn: ?
<hallyn> infinity: the patch you quoted above
<infinity> hallyn: Ahh.
<psusi> cjwatson, we seem to get a lot of crash bugs caused by people manually partitioning and not setting up an efi system partition.. think partman-efi should check for that and kick them back to the partitioner if they forgot?
<infinity> I thought it had a check and warning for that already...
<infinity> Template: partman-efi/no_efi
<infinity> Type: boolean
<infinity> # :sl5:
<infinity> _Description: Go back to the menu and resume partitioning?
<infinity>  No EFI partition was found.
<infinity> What triggers that template?
<infinity> Ah.
<infinity> Only on ia64.
<infinity> \o/
<infinity> psusi: See check.d/efi, if you want to sort out a safe way to make that only trip when we need it, but always trip when we do.
<psusi> infinity, isn't partman-efi only loaded on an efi system in the first place?
<psusi> btw, how goes the util-linux slog? ;)
<infinity> psusi: I'm not sure if there's anything smart enough to only load it in the right cases.  Plus, see the comment in the code about Macs (yay, Macs, the most busted EFI implementation ever) maybe not needing the partition.
<infinity> psusi: Then again, it might be a "who friggin' cares, it's 35MB, suck it up princess" situation there.
<infinity> psusi: We unconditionally create a PReP partition on PPC, and not all machines need that, but I doubt anyone gives a crap.
<psusi> infinity, I'm mostly just thinking of making sure that you have an efi system partition if you are going to install grub-efi
<AtuM> yesterday I've started to upgrade 13.10 to 14.04.. let me tell you it's quite an adrenalin rush.. the upgrade told me this morning that it failed.. it's now doing a roll-back..  I hope this machine still boots after all this ;)
<AtuM> I'll try to reboot now that it finished.. let's see
<pitti> Good morning
<pitti> infinity: postgresql SRUs> fine for me, no regression reports upstream either
<pitti> bdmurray: I do see the symbols here: http://ddebs.ubuntu.com/pool/main/l/lightdm/
<pitti> bdmurray: maybe they got picked up over night and were just held by the freeze?
<pitti> Laney, infinity: argh, thanks for fixing the pycxx bits
<AtuM> hmm. .now I can't tell in what state my os is.. it's partially 14.04, partially 13.10...
<AtuM> the kernel is 3.11, but some packages are upgraded :)
<Unit193> lfaraone: Howdy.  Mind a PM?
<AtuM> thrusty repos left behind after upgrade rollback.. this can become interesting
<pitti> doko_: I filed bug 1298824, new libffi is causing havoc :/
<ubottu> bug 1298824 in libffi (Ubuntu Trusty) "libffi 3.1~rc1 regression: crashes on i386; python3.4 crashed with SIGSEGV in g_callable_info_free_closure()" [Critical,Confirmed] https://launchpad.net/bugs/1298824
<pitti> doko_: I added two reproducers
<pitti> doko_: is that something you can look into today, or should we upload a revert for now?
<pitti> jibel: ^ FYI (all the failure messages from overnight); another fail of britney-adt :(
<zyga> good morning
<pitti> slangasek: I have a question for you in bug 1295521; thanks in advance!
<ubottu> bug 1295521 in systemd (Ubuntu) "Installing i386 and amd64 PAM stacks causes shutdown/logout/etc. to break" [Undecided,Confirmed] https://launchpad.net/bugs/1295521
<pitti> jibel: is it still possible to get some post-mortem why libffi wasn't held back? new g-i, pygobject, ffi, and others were all uploaded simulataneously due to teh unfreeze, which certainly didn't help to make matters any easier
<jibel> pitti, yes, I'm looking into it
 * zyga wonders if there's a way to put any patches into the release at this time
<zyga> pure bufixes
<infinity> zyga: Yep, same as always, upload away.
<infinity> zyga: It just gets held for review, but bugfixes will slide in with no issues, unless they're obviously wrong.
<zyga> infinity: ENOUPLOADRIGHTS, we'll release to debian and try to sync them over then
<zyga> infinity: those are all short and well documented so we'll try
<infinity> doko_: Dude, why are we uploading release candidate versions of new upstream libffi waaaay after feature freeze, and weeks before release?
<tjaalton> was there a known bug with apport retracer on lp recently?
<pitti> tjaalton: not known to me; is it stuck again?
<tjaalton> pitti: I'm just going through bugs against the X packages, and see that even crashers with free drivers have useless stacktraces
<tjaalton> this particular one is from mid-feb
<pitti> tjaalton: I can look through the logs for messages like "this dbgsym is missing", if you toss me a bug number
<tjaalton> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1278722 is a good example i think
<ubottu> Launchpad bug 1278722 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in CloseWellKnownConnections()" [Undecided,New]
<pitti> doko_, infinity: I prepared and uploaded a revert, tested with python-cffi and python-gi; so it's ready for the release team to accept if/once we decide we want to do that
<Laney> pitti: no problem - I was surprised to find a bug like this after so long though!
<infinity> Yeah, that surprised me too.
<infinity> AFAICT, that's been broken that way since that feature was added.
<pitti> tjaalton: ah, too bad we can't catch X.org's assertion messages yet; but that bug still has a core dump, maybe one can pry it out from there
<infinity> pitti: Oh, also, I was lazy and didn't write a test-case for multi-level doc symlinks, if you're feeling anal at some point and want to add one to pkgbinarymangler...
<tjaalton> pitti: ah, ok
<infinity> pitti: (I briefly considered it, saw the testsuite was in python, and lost motivation :P)
<pitti> E: Ignore unavailable version '2:1.15.0-1ubuntu3' of package 'xorg-server'
<tjaalton> and I see fresh bugs with proper traces, so let's just assume it's working now :)
<pitti> tjaalton: ^ that was the error
<tjaalton> heh, ok
<pitti> tjaalton: so apparently the retracer got stuck for a bit (we had that due to some weird launchpadlib cache problems; worked around now)
<tjaalton> right
<pitti> tjaalton: sorry about that
<pitti> tjaalton: so, fine to just invalidate those, as they are rather useless
<tjaalton> no worries, hope the bug is fixed anyway, or someone has filed a dupe later
<infinity> pitti: Do the autopkgtest machines run ntpd or anything that might jitter the clock?
<infinity> pitti: I know qemu sucks and all, but I'm really irked that eglibc's testsuite seems to fairly often get such crap time out of those machines. :/
<pitti> infinity: checking; but they have a lot of VMs running in parallel, so they often get stuck in iowait and similar
<pitti> infinity: I just retried eglibc, FTR
<infinity> pitti: Thanks.
<pitti> ntp       5256  0.0  0.0  43756  3128 ?        Ss   Mar25   0:21 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 118:124
<pitti> infinity: ^
<infinity> pitti: It mostly bugs me because I don't want to XFAIL a test that passes on real hardware, nor do I want to be holding up some other random person's package migration, so it seems a bit rock and hard place.
<infinity> pitti: So, yeah, ntpd on a kvm host where the guests get their RTCs via the system clock of the host might not actually be the best idea.
<pitti> we are fairly quick on the retry trigger for unstable tests :)
<infinity> pitti: system jitters, and so do all the guests' fake RTCs.
<pitti> infinity: I guess a cron'ed ntpdate wouldn't be much better, though ?
<infinity> pitti: No, just a boot time ntpdate.  The machines can't lose so many ticks that you need it re-jittering often, I hope?  It's not an Amiga.
<pitti> infinity: e. g. aldebaran has an uptime of 134 days ATM; I guess you can get quite some skew on loaded machines in that time?
<infinity> pitti: In theory, yeah.  *shrug*
<infinity> pitti: A daily cronned ntpdate might be more pleasant, or not worrying about it and retrying tests (or not worrying about skew).  Was more an observation than a demand for change. :)
<infinity> ntpdate might actually be less destructive, not sure how the system interprets its changes.
<infinity> Pretty dure ntpdate actually changes the date, which is entirely different from ntpd inserting and removing ticks.
<infinity> Equally possible that my blaming ntpd is a red herring and it's just that qemu sucks under load.
<pitti> infinity: multiple qemus in parallel aren't very reliable wrt. timing issues indeed; I often see failures when lots of stuff runs in parallel
<pitti> infinity: after the recent eglibc upload I slightly decreased the number of parallel runners, let's hope it helps a bit
<pitti> infinity: yearning for the new world where all this will be quite a bit more flexible
<msx> hi! i'm having GPG errors for ubuntu 14.04 official repositories on main server, i've been using 14.04 and until this very day everything it was a smooth sail, anyone else?
<msx> is this a know issue?
<pitti> infinity: so xfailing this kind of error would certainly not hurt for autokpgtests (as this pretty much should be a rebuild and coarse smoketest only), but we certainly shouldn't xfail it for package builds
<infinity> pitti: That particular failure might at least get harder to trip in 2.20... gettimeofday() was moved to the vDSO, which knock out a few dozen instructions.
<infinity> pitti: Yeah, I think the real solution is for me to build a cut down test package and use that, which will also be more doable in 2.20 (or maybe 2.21) as we're sinking work into making the testsuite run out of tree.
<pitti> infinity: ah, nice; until then, retry button it is :)
<zyga> msx: I haven't seen that, maybe you are behind corrupting http proxy (most are)
<msx> zyga: hei! but this issue just arose earlier today... any idea on how to solve it? may be switching the repo server?
<zyga> msx: without knowing what causes it (it's proably something on your network as I also use the same servers and dind't see any gpg issues) it's hard to say
<msx> zyga: btw, i have a 'transparent' connection, by transparent i mean the only proxies out there should be the ones from my isp (hate that stuff)
<msx> hmmm
<zyga> msx: transparent proxies are known to misbehave
<zyga> msx: try forcing some funny http headers to apt, to force those proxises to refresh, I had issues like that in corporate networks, google for apt http proxy isuses, there's plenty of people with workarounds
<msx> zyga: how do i reset the GPG and force the system to bring them back again?
<zyga> msx: but essentially, the network setup is broken
<zyga> msx: gpg is not broken, you need to re-download them through the proxy
<infinity> It could just be bad timing.  Have you tried "apt-get update" again?
<msx> zyga: okay, tnx a lot!
<msx> infinity: o/
<msx> infinity: yes, a lot within these hours
<zyga> msx: and this is not a support channel, sorry, try #ubuntu and google for this, plenty of good workarounds out there
<msx> zyga: ok! i decided to post here since i'm on 14.04
<zyga> msx: sure, no worries
<zyga> msx: good luck :)
<msx> :D
<msx> zyga: FTR, there's an archive update in progress: #ubuntu+1 06:42:45    TJ- | msx: Archive update in progress; see http://ftp.ccc.uba.ar/pub/linux/ubuntu/
<msx> zyga: tought you might be interested in knowing that :)
<infinity> msx: So, pick another mirror?
<msx> infinity: can you believe that all the four mirrors I already check are in the same state? bless my luck :D
<msx> infinity: tnx anyways!
<msx> s/check/cheked/g
<infinity> msx: archive.ubuntu.com is pretty much never in that state (though is pretty far away from you, sadly)
<msx> infinity: mmm, will give it a try, great
<msx> infinity: error persists using that repo, i keep looking for the error, thanks
<msx> zyga: infinity: after more research it came out it's a bug in apt, issue solve, everything's here: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1263540/comments/7
<ubottu> Launchpad bug 1263540 in apt (Ubuntu) "Apt-get reports NO_PUBKEY gpg error for keys that are present in trusted.gpg." [Undecided,Confirmed]
<msx> thanks for your help guys
<infinity> cjwatson: You know how we keep getting into conversations with people every 7.5 days about when you want C/P/R/B and why?
<infinity> cjwatson: A random googling earlier for I don't recall what led me to this table: https://wiki.debian.org/PackageTransition
<infinity> cjwatson: Might be a handy thing to just toss at people instead of having the same 20-minute discussion every time.
<infinity> Although, it could use some tidying up.  12 is definitely wrong.
<cjwatson> infinity: good idea
<Chipaca> statik: o/ :)
<statik> o/
<statik> long time :)
<Chipaca> yup :)
<doko> Riddell, is there a reason that calligra needs to be built with GCC 4.7?
<Riddell> doko: there was, krita wouldn't compile with 4.8 I think, not tested in recent times though
<doko> Riddell, builds with the default
<doko> Maintainer: Michael Vogt <mvo@debian.org>
<doko> Standards-Version: 3.7.3
<doko> mvo: do you know this guy?  ^^^
<Riddell> doko: oh you tested it? thanks
<doko> Riddell, yes. amd64 only
<nturner_> Is anyone else seeing https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1281806 ? With the final beta release announcement, I'm concerned that this bug hasn't even been triaged.
<ubottu> Launchpad bug 1281806 in unity (Ubuntu) "Alt-Tab switcher regularly goes into "flicker loop of death" or just hangs" [Undecided,New]
<nturner_> I'm guessing unity is the wrong package, but I'm not sure what is. Should I reassign this to compiz? Something else?
<nturner_> I'm willing to try stuff to help debug this, but I'm not sure what would be helpful.
<ogra_> nturner_, try #ubuntu-desktop ...
<seb128> nturner_, check with bregma but I don't think it's known, first time I see it mentioned, might be due to some specific local options
<nturner_> ogra_, ok
<nturner_> seb128, I'm seeing this on both systems I've been testing trusty on, different hardware install histories...
<nturner_> s/hardware/hardware,/
<seb128> nturner_, stock config, never touched ccsm or any compiz option?
<nturner_> I'm willing to reset to a stock compiz config (plus disabling Alt = HUG keybinding ;-) to test --- what dirs should I delete? ~/.compiz? Anything else?
<nturner_> er, s/HUG/HUD/ =)
<ogra_> try a guest login for a start
<ogra_> or create a new user
<gQuigs> does my packaging change request here: https://bugs.launchpad.net/ubuntu/+source/mongodb/+bug/1295723  make sense?
<ubottu> Launchpad bug 1295723 in mongodb (Ubuntu) "libv8-dev backport breaks some dependencies" [Undecided,New]
<rbasak> gQuigs: IMHO, technically there is no mongodb packaging bug there, although I understand why it would be useful to you for cloud archive backports.
<rbasak> gQuigs: except that we don't support doing what you're doing to the cloud archive in that way anyway.
<rbasak> gQuigs: I think the danger here is that we make the change, you rely on it, and then something upstream changes and breaks you in a way that we can't fix.
<rbasak> (since the libfoo-ver-dev thing isn't policy or even common)
<rbasak> Or that we get a future proliferation of bugs wanting the same thing in other packages, all to fix something in the cloud archive which is fundamentally wrong anyway.
<rbasak> The "right" way to control this is with apt pinning. Could you perhaps view this as a general solution for anybody who wants to install extra packages in such an unsupported combination? Ie. make the cloud archive low pin priority in general?
<gQuigs> rbasak: this is the first I'm hearing that it's ok for the cloud archive to break things like this
<rbasak> gQuigs: in that case maybe I should get my assertion checked by others in my team
<gQuigs> rbasak: there is no big warning on this page, https://wiki.ubuntu.com/ServerTeam/CloudArchive
<rbasak> gQuigs: my understanding is that you aren't expected to be able to install arbitrary other packages on a system where the cloud archive is enabled
<rbasak> (since it bumps versions of dependencies exactly how you're seeing)
<rbasak> Normally this isn't an issue, since installations running the cloud archive don't run anything else.
<rbasak> gQuigs: why is pinning the cloud archive not a suitable solution for you?
<bdmurray> pitti: ah, maybe
<ahasenack> hi guys, do I need to ping someone about a trusty bug-fix upload? https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=landscape-c
<ahasenack> or is it "automatic"?
<alesage> tedg, apropos of our earlier convo this just came into existence: http://developer.ubuntu.com/apps/quality/
<alesage> IMO balloons is doing a good job of public writing on 'how we test ubuntu' :) , sure he'd be interested in your feedback
<tedg> alesage, Yeah, seems like he's mostly dealing with apps. Which is fine, but we need it for the core as well.
<balloons> tedg, what do you need / looking for?
<alesage> balloons, we were just having an inspired chat about quality :) and our test plans
<tedg> balloons, We were talking about something that pulled together how the different parts of TestPlans and MergeCheck lists work. Like vs. unit tests, etc.
<jibel> bdmurray, you have a bot that detects if people have xorg-edgers ppa enabled and invalidates bug reports if they do. Do you think the logic could be included into the release-upgrader and abort with that indication? instead of failing with a generic message and users reporting bug.
<jibel> bdmurray, I know it is a specific case but very frequent cause of failure
<tedg> balloons, Perhaps a children's book, with illustrations, "The story of a line of code getting into Ubuntu" :-)
<alesage> tedg, so funny, like that "I'm just a bill" schoolhouse rock cartoon
<tedg> alesage, I was thinking more like the "Water Cycle" cartoons, but that's perhaps just because it's rainy here today :-)
<balloons> tedg, did you see http://www.theorangenotebook.com/2014/03/a-simple-look-at-testing-within-ubuntu.html?
<balloons> it was inspired by the "explain to me like I'm 5"
<bdmurray> jibel: there is bug 1069133 that xnox was going to work on
<ubottu> bug 1069133 in ubuntu-release-upgrader (Ubuntu) "Get upgrade error 12.04 - 12.10 "Could not determine upgrade" - xorg from ppa" [Medium,Triaged] https://launchpad.net/bugs/1069133
<balloons> I don't think it mentions anything you don't know, but I'm guessing you want something like this that covers a bit more on the development side?
<jibel> bdmurray, ok, thanks
<bdmurray> jibel: they get the generic could not calculate the upgrade error message?
<tedg> balloons, Ah, cool, yes. Perhaps the 8 year old version :-)
<balloons> tedg, we had a session at vUDS on my ideas of a developer/release workflow from a quality perspective. If I'm understanding you correctly, this is what you'd like to see a highlevel doc on
<balloons> it was of course from an app developer perspective
<balloons> http://summit.ubuntu.com/uds-1403/meeting/22183/application-development-best-practices/
<jibel> bdmurray, apparently they do, and even experienced users like brendand are trapped by this. See bug 1298891 for example
<ubottu> bug 1298891 in ubuntu-release-upgrader (Ubuntu) "Can't upgrade from Saucy to Trusty" [Undecided,New] https://launchpad.net/bugs/1298891
<balloons> tedg, I like the childrens book idea :-) How a line of code gets into ubuntu
<alesage> great idea :)
<bdmurray> jibel: I guess fixing bug 934371 would help.
<ubottu> bug 934371 in ubuntu-release-upgrader (Ubuntu) "Unresolvable problem message does not help users and results in less useful bug reports" [Medium,Triaged] https://launchpad.net/bugs/934371
<alesage> tedg also you might be interested in this thomi-post: http://www.tech-foo.net/on-test-levels-and-coverage.html
<balloons> ^^ don't expect your 8 yr old to get this :-)
<alesage> very true
<alesage> more tedg's speed ;)
<brendand> jibel, yeah i can't get past that. i assume it's related to the 'unofficial packages' bit, but which ones?
<jibel> brendand, try reverting xserver-xorg-video-ati -intel -radeon and -nouveau to the versions from the archive, you currently have somegitrev-0ubuntu0sarvatt~saucy
<brendand> jibel, yeah i noticed that in the log - hopefully it works. i have the archive version now
<brendand> jibel, http://paste.ubuntu.com/7168918/
<brendand> oop - vmware is still from there
<brendand> guess that's not relevant though
<brendand> i'll revert it anyway
<doko> mlankhorst, tjaalton: there are xorg ftbfs, weston and xorg-gtest, see http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140307-trusty.html
<ogra_> jodh, i'm looking for a way to make an upstart job fire only if another job couldnt be started, do you know of any examples for such a case ?
<jodh> ogra_: you mean http://upstart.ubuntu.com/cookbook/#run-a-job-only-if-another-job-fails ?
<ogra_> something like: start on can-not-start foo
<ogra_> lol
<ogra_> blind me
<ogra_> jodh, thanks :)
<jodh> ogra_: if you care about exactly _how_ the job failed, you can interrogate the signal/exit code - see stopped(7)
<ogra_> cool, but i think i'm fine if it simply didnt start
<doko> Sweetshark, seb128: libreoffice-voikko still ftbfs
<Sweetshark> doko: against 4.2.3~rc2-0ubuntu1 ?
<doko> Sweetshark, https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5703954
<doko> ahh, the new didn't yet migrate
<Sweetshark> doko: yep. that one still build against 4.2.1
<slangasek> pitti: 1295521> the analysis there is hilariously wrong; I don't have time at the moment to dig into it, but the idea that installing i386 pam modules is going to break your amd64 lightdm is absurd
<Chipaca> who knows about the messaging menu from the dbus level?
<seb128> Chipaca, larsu but he's having a day off today, maybe try email?
<seb128> Chipaca, or maybe tedg can help you
<Chipaca> seb128: ta
<seb128> yw!
<tedg> Chipaca, D-feet :-)  What are you looking for?
<Chipaca> tedg: putting something into the messaging menu, via dbus :)
<Chipaca> tedg: I tried looking around for the API, but it seems it's not published
<tedg> Chipaca, Sure, we'd really prefer you used the lib. Is there a reason you can't?
<Chipaca> tedg: there doesn't seem to be docs about those either :D
<Chipaca> tedg: but also, unless things have changed, wrapping a lib not built for testability in a testable way is harder than calling dbus directly
<Chipaca> tedg: willing to give it a try though :)
<tedg> Chipaca, What is this for, QML/Qt/etc?
<Chipaca> tedg: nope
<Chipaca> tedg: all i'm binding with is glib, at least for now
<Chipaca> tedg: program itself is golang, if that helps?
<tedg> Chipaca, Hmm, not sure if the lib will work then as it requires glib mainloop.
<Chipaca> ldd says libwhoopsie, glib-2, pthread, sqlite3, pcre, and the usual system ones
<Chipaca> yeah, that'll be a problem
<tedg> Chipaca, What project is this for?
<tedg> Chipaca, Or, more specifically, what are you planning to put in the messaging menu?
<Chipaca> tedg: ubuntu-push; push notifications
<tedg> Chipaca, Notifications of what?
<Chipaca> tedg: right now, system updates
<Chipaca> tedg: but anything, later on
<tedg> Chipaca, Those don't belong in the messaging menu
<Chipaca> tedg: where do they belong?
<Chipaca> longer term, any app that asks to get their notifications there, would
<tedg> Chipaca, I would say system settings, but in general the messaging menu is for messages from other humans. Not a computer state.
<Chipaca> tedg: system settings have an indicator?
<tedg> Chipaca, Nope, but I believe the plan is it could have emblems
<Chipaca> so, until something else is implemented, where do these go?
<tedg> Chipaca, Ether :-)
 * cjwatson grumbles at packages that run configure in their clean target
<mpt> Chipaca, what are you talking about?
<cjwatson> oh, wait, maybe this particular one is my fault
<Chipaca> mpt: where to display notification of system updates, beyond the transient bubble
<doko> Riddell, https://bugs.launchpad.net/ubuntu/+source/calligra/+bug/1299096
<mpt> Chipaca, if there is a transient bubble, that is a bug
<ubottu> Launchpad bug 1299096 in calligra (Ubuntu) "clean up build dependencies" [Undecided,New]
<mpt> Chipaca, are you working on PC or Touch?
<Chipaca> mpt: touch
<Chipaca> mpt: why is it a bug?
<mpt> Chipaca, https://wiki.ubuntu.com/SoftwareUpdates#Prompting
<Chipaca> mpt: does that apply to touch?
<Chipaca> looks like it
<Chipaca> mpt: wow
<Riddell> thanks doko
<Chipaca> mpt: do you know if the software packages side of this is implemented?
<happyaron> well, expect lots of last minute changes from Ubuntu Kylin, :(
<tedg> Chipaca, So somewhat related, I don't think push should "put things in the messaging menu" I think it should "notify the app and allow it to put things in the messaging menu" so that local configuration can be take into account.
<Chipaca> tedg: the app is not running
<Chipaca> tedg: that local configuration needs to be in push itself
<tedg> Chipaca, Sure, I think that apps should provide an untrusted helper for that, not put that logic in push.
<mpt> Chipaca, I know there was work to combine system updates and app updates in the same UI, I havenât kept track of whether itâs finished
<tedg> Chipaca, We can't put logic for, i.e. the Facebook app, in push.
<Chipaca> tedg: i disagree, i think that is exactly where we can put it
<tedg> Chipaca, Hoping you're going to define a Turing complete configuration language :-)
<Chipaca> mpt: do you know who was doing this work?
<mpt> Chipaca, I donât remember, but seb128 will know
<mpt> Chipaca, barry was one
<Chipaca> seb128: please pretty please know
<tedg> Chipaca, The reality is that the configuration could be as complicated as "only show me notification for members of my family"
<Laney> Chipaca: We got click and system updates in system-settings now
<Laney> the emblem thing in the scope isn't done, don't know if that is possible atm
<Chipaca> Laney: I'm ... not sure what that means :)
<Laney> which bit?
<Chipaca> having click and system updates in there
<Laney> That's what you were asking to know.
<Chipaca> hmm
<Chipaca> Laney: ok :) good. How do you display that you have a system update and click updates?
<Chipaca> mpt: maybe that's a question for you; how (if at all) should it look if you have both kind of updates?
<Laney> It should do what the design asks for
<Chipaca> it doesn't
<Chipaca> unless "Ubuntu touch" is a system update?
<Chipaca> Laney: is that it? In those pics "Ubuntu Touch" is the system itself?
<Chipaca> Laney: also, does this mean settings:///system/system-update no longer works?
<Laney> Yes, and yes it should - that is exactly this
<Chipaca> ah, so click will be listed there as well as the system
<Chipaca> ok
<Chipaca> Laney: who would know about the emblems?
<Chipaca> that is: who would know whether putting an emblem on an icon in the launcher works? seb128?
<Laney> mhr3 I guess
<Chipaca> ah, ok
<Chipaca> he's off :(
<Chipaca> ah, no, i spy him :)
<mpt> Chipaca, yes, âUbuntu Touchâ is a system update
<Chipaca> mpt: yup. figured that out.
<Chipaca> Laney: but click isn't yet putting a counter up, is it? (so i don't need to bother about syncing with that just yet)
<tvoss> Chipaca, saviq might know, too
<Chipaca> mhr3 just told me to check with Saviq :)
<Chipaca> Saviq: ehlo
<Laney> We don't have any emblems yet
<Saviq> 501 Syntax: EHLO nickname
<Laney> Just the parts that are inside system-settings itself
<Saviq> Chipaca, wassup?
<Chipaca> Saviq: question for you (i'm told): can i put an emblem (actually a counter?) on an icon on the launcher on the phone?
<Saviq> Chipaca, you could (i.e. it's implemented in the launcher), there's no api for it yet, though
<Chipaca> Saviq: what does that mean? there's no api at what level?
<Saviq> Chipaca, I assume you're thinking about the push notif daemon, as that's the only thing that actually could keep the counter updated?
<Chipaca> Saviq: yes :)
<Saviq> Chipaca, so yeah, we need to make an api
<Chipaca> Saviq: otoh push doesn't (yet!) know about click updates, but that can wait (says I)
<tjaalton> is amd64 the default image offered for trusty?
<tjaalton> or will it be
<Chipaca> Saviq: it isn't exposed over dbus?
<Saviq> Chipaca, no, not atm
<Chipaca> ah
<Saviq> Chipaca, we didn't have a use case for it yet, so didn't implement it
<slangasek> pitti: followed up on bug #1295521
<ubottu> bug 1295521 in systemd (Ubuntu) "Installing i386 and amd64 PAM stacks causes shutdown/logout/etc. to break" [Undecided,Incomplete] https://launchpad.net/bugs/1295521
<Saviq> Chipaca, and I'm thinking the current unity7 api doesn't fit
<Saviq> Chipaca, as IIUC you can only set that from the app in question, not from outside
<tjaalton> looks like 64bit is the default offered on ubuntu.com, nice
<Chipaca> Saviq: i seem to recall being able to abuse it to update from the 'outside' (by just telling it you're the 'inside'), but it wasn't the supported thing
<Chipaca> Saviq: so yeah. I can haz?
<Saviq> Chipaca, how soon do you need / want it? can we plan that api for real, or do we want a quick hack?
<Chipaca> Saviq: well... what's the time difference between those two options?
<Chipaca> I've got to choose who to piss off :)
<Saviq> Chipaca, no idea really :)
<Saviq> Chipaca, it's not a huge API, but we'd have to talk to a few people
<Saviq> Chipaca, on how this should work
<Chipaca> Saviq: who would those people be?
<Saviq> mzanetti, hey, we're talkin' about the launcher count emblems
<mzanetti> ah
<Saviq> mzanetti, and how we can expose that to the push notifications backend
<mzanetti> hmm ok
<Saviq> Chipaca, meet mzanetti :)
<mzanetti> hellp Chipaca
<mzanetti> hello, even
<Chipaca> mzanetti: hello!
<tvoss> Saviq, might be good to check with thostr_ on Monday, too
<Saviq> Chipaca, so, a) $you-facing APIs' owner is thostr's team
<Saviq> tvoss, yeah, â that
<mzanetti> right yes. originally Wellark was planning how to do this
<mzanetti> not sure how far he has come with it
<Saviq> but he's probably electrocuted himself by now
 * Chipaca is unsurprised
<mzanetti> do we already have another interface between that service and unity8?
<Saviq> Chipaca, so, let's set up a meeting for Monday and hope that no one skips it?
<Saviq> mzanetti, well, we have notifications, but that's fdo
<mzanetti> ok. I'll wrap some brain cells around it in the meantime
<Chipaca> I've got about a week of other things I can do while we work this out; does that sound reasonable, or should I dilute my meds?
<Saviq> Chipaca, sounds ok, it's a relatively small thing
<mzanetti> yeah, guess so too
<Chipaca> mzanetti: Saviq: thank you!
<Saviq> [...] and we probably need to tweak notifications, so that when you tap the app launched isn't the one that sent the notification
<mzanetti> so yes, lets meet on Monday
<Chipaca> Laney: tedg: mpt: and thank you too, sorry to have worried you (if I did)
<Saviq> Chipaca, you set the meet up? you, mzanetti, Wellark, thostr, /me?
<Chipaca> Saviq: wrt notifications, that already works
<Chipaca> Saviq: anybody else?
<mzanetti> sounds right...
<Chipaca> setting it up
<Saviq> Chipaca, /me and thostr are in London next week
<Chipaca> gasp
<Saviq> not sure about Wellark
<Chipaca> we can meet irl :) i'll be in london on monday pm
<Chipaca> i'll set it up anyways
<Saviq> nope
<__lucio__> Chipaca, add me to the meeting to
<__lucio__> o
<Saviq> Chipaca, yeah, my point exactly
<Chipaca> __lucio__: should I add you to the --- yeah
<Saviq> __lucio__, you've been working out, eh?
<Chipaca> Saviq: on freenode he's "special"
 * Chipaca laughs at his own python joke
<Saviq> Chipaca, Â«specialÂ», eh?
<Chipaca> Saviq: in python, __method__ is a special method
<Saviq> I know
<__lucio__> i think of myself more as MAGIC
<Chipaca> ah ok :)
<Chipaca> magic is a perlism!
<Chipaca> boo, hiss
<Saviq> Chipaca, remember, I actually managed to contribute stuff to candiru / curucu ;D
 * Chipaca loved perl, but it's a secret love
<Chipaca> Saviq: i remember :)
<Saviq> Chipaca, ok, see you Monday, then!
 * Saviq just got the invoice memo twice... will I get paid twice, too?
<Chipaca> Saviq: mzanetti: __lucio__: Wellark: sent. Holler if time is wrong.
<mzanetti> Chipaca: it does conflict with unity8 standup. But if its just once still works for me
<mzanetti> I guess the same for Saviq
<Chipaca> this is a one-off, yes; but also, we can move it
<Chipaca> i just threw it in there
<Saviq> Chipaca, should be fine
<seb128> Chipaca, I'm back, there is quite some backlog and I'm not sure I want to read it, do you still have questions for me?
<Chipaca> seb128: nothing but praise, sir. Nothing but praise.
<seb128> haha, good ;-)
<tvoss> asac, ping
<hallyn> (stupid q alert) will autoconf always cause libraries to be built before binaries in a pkg?
<hallyn> it's *doing* it, just wondering ifi need to be leaving hints so it will always do it for the binaries depending on the libraries
<smoser> anyone else recently tried 'do-release-upgrade -d' from precise (to trusty)?
<smoser> i'm prompted on /etc/default/rcS
<smoser> a file i didn't chnage
<cjwatson> hallyn: autoconf doesn't have a whole lot to do with it; that's more at the automake level.  if you've told automake that the binary is linked against the library then it'll finish building the library before attempting the link
<hallyn> cjwatson: but is adding "-lmylib" to binary_LDADD enough to tell automake that?
<hallyn> i expect so...
<cjwatson> hallyn: should be
<hallyn> cool, thanks
<hallyn> (like i say it *is* working, but that could have been coincidence :)
<cjwatson> hallyn: I think, anyway.  I'd recommend looking at the generated Makefile.in to see if it has the right dependencies
<cjwatson> I believe you're safe in relying on inspection at this level
#ubuntu-devel 2014-03-29
<ion> Ah, redundant window borders were finally removed. Iâm happy.
<sladen> none more black
<basiclaser> hey guys, i want to make an 'app' patch that i can share amongst linux/debian/ubuntu users which will perform mathematical operations on the displayed system time, without effecting the underlying system clocks dependencies. Just augmenting the visual widget
<basiclaser> just doing something to the visual menu element, is there a way to do this across linux distros or are many differing time objects used?
<Noskcaj> pitti, Should i package gnome-icon-theme 3.12, since gnome-icon-theme-extras has decided it needs 3.12 as a depend
<Noskcaj> I didn't know about the change till just the, and it's from misc:depends
<Noskcaj> *then
<infinity> pitti: Hrm, the autopkgtest stuff seems to have serious issues with comments in build-dep lines.
<infinity> pitti: See the lintian failures, where all the missing packages are stuff that comes after the comment in the middle of build-deps in debian/control.
<infinity> Hey, lazyIRC, is there a HOWTO on the wiki somewhere for doing autopkgtests at home?
<infinity> Ahh, http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test might be what I'm after.
#ubuntu-devel 2014-03-30
<Noskcaj> How do i upload stuff directly? I got upload rights for parole a few days ago, but wasn't told how i use them
<psusi> Noskcaj, dput
<Noskcaj> Do i need to target anywhere specific or will it just work?
<infinity> Noskcaj: debsign foo.changes && dput ubuntu foo.changes
<Noskcaj> ok, ty
<infinity> Noskcaj: On ubuntu, the default target should already be "ubuntu", but it never hurts to be specific either.
<ScottK> Although I generally change the default to something non-working so I don't upload to ubuntu when I mean a PPA.
<rbanffy> Hi folks. I would like to add a 1920x1080 display mode for undetected (as in "the f* switch blocks EDID") monitors to the gnome-control-panel "display" panel. From what I got from the source, the resolutions look like they are coming from a deeper component. Would anyone suggest the right place to add this?
<infinity> yofel: Multiple dashes in Debian versions are generally not a good idea.
<yofel> infinity: upstream version is "2.8.1-1", what should I change that to?
<yofel> it's technically permitted, so I kept it...
<infinity> yofel: I would have just gone with 2.8.1.1 or something, but meh.
<infinity> yofel: You're right, there's nothing technically wrong with your version, but there are a lot of bad version string parsers out there. ;)
<yofel> yeah, sadly ^^
<yofel> I can re-upload if you want?
<infinity> yofel: That would probably make my inner pedant happy.
<yofel> ok, let's do that then :D
<infinity> yofel: Actually, nevermind.  If that's really the upstream version, we'll call it good.
<infinity> (Weird way to version though, thanks upstream)
<yofel> it's thanks to them missing corruption before release, so we get 2.8.1 again, as... 2.8.1-1 -.-
<infinity> Yeah.  Just a strange way to re-version. ;)
<infinity> The upstream I work most closely with (glibc) has had to re-roll before, and our method was 2.15 -> 2.15.0
<infinity> (And I guess if screwed up twice, we'd go with 2.15.0.0?)
<infinity> (Or give up, because we're in the wrong business)
<infinity> yofel: Anyhow, after thinking it over a bit, I accepted the upload.  Don't bother redoing it.
<infinity> yofel: was just a knee-jerk reaction to the ugly version. :P
<yofel> most of the time at kde we either have enough time to catch any issues, or they just wait until the next version. Most of the time...
<yofel> yeah, I can understand that ^^
<infinity> Laney: Was your cinnamon upload meant to address bug #1266336?
<ubottu> bug 1266336 in cinnamon (Ubuntu) "Cinnamon desktop hangs when selecting menu" [Undecided,Confirmed] https://launchpad.net/bugs/1266336
<fhassan> Any chance of moving Trusy release to April 8? (end-date of Windows XP support)
<infinity> fhassan: No.
<infinity> fhassan: Releasing 9 days after that isn't exactly world-ending, it's not like XP users are all going to magically switch OSes on that day.  It's also not like MS releases security updates every day. :P
<cjwatson> XP users are by definition not the sort of people who jump at new OS releases ...
<infinity> Indeed.
<infinity> All the XP users who actually like new OS releases are probably on 7 or 8 by now (or, indeed, jumped ship for Linux or MacOS years ago)
<Laney> infinity: nope, it was an FTBFS fix
<infinity> Laney: Ahh, kay.  Then I'll keep that blocking bug blocking it, then. :P
<infinity> (Someone in Debian really needs to pick that stuff up again... Or remove it)
<cody-somerville> So, with Quantal coming to EOL sometime in April, is the supported upgrade path through the already EOL Raring or directly to Saucy?
#ubuntu-devel 2015-03-23
<psusi> so I'm looking at a bug report that appears to be caused by an incorrect dependency in the ubuntu-mate-live package, only no such package appears to exist... how can this be?
<ScottK> psusi: That's presumably the metapackage used for installing the live system from the installation ISO.  It'd be controlled by the ubuntu-mate seeds.
<psusi> ScottK, ahh... so why doesn't it show up in packages.ubuntu.com or apt-cache?
<ScottK> Because it's only on the ISO, not in the archive.
<psusi> so the package is actually built as part of the iso construction process, rather than being in the archive and just *installed* when building the iso?
<psusi> seems like an odd thing to do...
<BenC> Anyone around that handles @ubuntu.com mail forwarding?
<BenC> infinity: Are you able to do that?
<ScottK> BenC: AFAIK it's a launchpad thing.
<infinity> BenC: ubuntu.com mail forwarding is determined by your launchpad status, in a few ways.  What's the issue you're having?
<mardy> mvo: hi! When you have some time, can you help me understand if bug 1393697 is still valid or if I'm doing something wrong?
<ubottu> bug 1393697 in click (Ubuntu) "Cross qmake to the chroots" [High,Confirmed] https://launchpad.net/bugs/1393697
<infinity> didrocks: So, upstart split.  I caught your messages on Friday, but wasn't sure what your concern was.
<infinity> didrocks: FWIW, systemd's init-mangling binaries (reboot, etc) know how to talk to upstart.
<infinity> didrocks: So, init=/path/to/upstart should work even with systemd-sysv installed.
<infinity> mvo: Your apt testsuite fix didn't seem to fix the testsuite.
<didrocks> infinity: oh really? I didn't know/look about this (I know that init=/sbin/upstart works, but didn't try init-mangling binaries). Ok then, no blocker thus, will work on this
<infinity> didrocks: Kay.  I'm here to help/review/advise/whatever.  I want this in and tested to some degree before I freeze for Beta later today.
<infinity> didrocks: I suspect (but haven't confirmed yet) that the broken split is also the reason why the first reboot after upgrade doesn't work.
<infinity> didrocks: My guess is that upstart doesn't have enough upstart left to actually reboot itself. :P
<didrocks> infinity: yeah, seems to match what we have seen with the autopkgtests
<didrocks> infinity: finishing my morning backlog and then on this
<infinity> didrocks: \o/
<infinity> didrocks: regarding the "systemd can talk to upstart" bit, the only caveat there that I know of is that "telinit u" intentionally refuses to talk to upstart because of an upstart bug pitti and I found a few weeks ago (upstart rexecs argv[0] instead of the upstart binary, which is HILARIOUS when /sbin/init becomes something else)
<infinity> didrocks: But I think that's a wart we'll just have to live with if people want to install systemd-sysv+upstart and then run upstart as their base init.
<mvo> infinity: I noticed it, hrm, hrm
<mardy> mvo: Hi! I wrote you before, but then you client disconnected so I'm not sure if you've seen it:
<mardy> mvo: hi! When you have some time, can you help me understand if bug 1393697 is still valid or if I'm doing something wrong?
<ubottu> bug 1393697 in click (Ubuntu) "Cross qmake to the chroots" [High,Confirmed] https://launchpad.net/bugs/1393697
<didrocks> infinity: agreed (fun this eexec argv[0] when you are a symlink/alternative-like ;))
<mvo> mardy: aha, I have not seen this, thanks, let me check
<infinity> mvo: If you tell me that test is basically just crap and inconsequential, I'm happy to let apt slip in.  I'd like it in for the beta, so it gets wider testing/abuse.
<infinity> mvo: Of course, fixing the testsuite would be better.
<infinity> didrocks: I didn't bother hunting commit logs, but I assume (or hope) the reexec functionality was written before /sbin/init became a symlink.
<infinity> didrocks: If not, then it's extra special, yes. :)
<didrocks> heh, who knowsâ¦ ;)
<mvo> infinity: so the test is basicly "does it show download progress" (as we had a issue were no download progress was displayed for https). so the test needs to run long enough so that apt can generate data on that but not too long to not delay the test suite too much, looks like I need to tweak the value again :/ but yeah, its essentially a false positive as on other systems it works
<infinity> mvo: Testsuites aren't mean to be fast, if you need to hitch up for 5 on 10 seconds to get good data, just do it.
<infinity> s/5 on/5 or/
<mvo> infinity: I agree, its jsut that I also run it locally so I don't want it to be toooooo slow :)
<mvo> infinity: but yeah, I will make it a bit slower and that should fix it
<infinity> mvo: As a man who runs the glibc testuite regularly, I have something approaching zero sympathy. ;)
<mvo> haha
<infinity> Laney: Are you doing anything about the remmina component-mismatches?
<infinity> Laney: Either an MIR for nxproxy/nxcomp or dropping the plugin deps from remmina-dbg or something.
<seb128> Laney is on vac this week
<infinity> seb128: Oh.  Any urge to look at his breakage? :P
<seb128> can't we just demote the -dbg?
<infinity> seb128: We could do that too, yes.
<seb128> I would do that and let Laney do something else next week if he wants
<infinity> seb128: I'll just commit that to the seeds.
<seb128> thanks
<infinity> doko_: How close are gcc-4.9 in unstable and vivid?  I'm trying to sort out some ppc64el glibc testsuite failures on Debian that don't show up in Ubuntu, and running out of people to blame.
<didrocks> infinity: interestingly, there are some files shipped by both upstart and upstart-bin currently, package installation was saved by the Replaced version
<infinity> seb128: Hrm, of course, that'll probably drop all the plugins too, so we might want to pick a few (or all but nx) to explicitly seed.
<infinity> didrocks: Ew.
<infinity> didrocks: Well, this should solve that screwup too, I hope. ;)
<infinity> didrocks: I'd expect upstart-sysv to contain exactly the set of files that conflict with systemd-sysv, upstart-bin to be empty and depend on upstart, and the world to be a happier place.
<infinity> didrocks: Oh, and whatever conflicts with sysvinit-core too, if that's a different intersection.
<didrocks> infinity: yeah, it's what I'm doing. I'm still wondering about some man pages like inittab or control-alt-del
<didrocks> should be in the upstart package, not upstart-sysv, but they are of no use if running under systemd
<didrocks> and can puzzle some usersâ¦
<infinity> didrocks: ./usr/share/man/man5/inittab.5.gz is in sysvinit-core, so that belongs in upstart-sysv.
<infinity> didrocks: If control-alt-del is upstart-specific, use your best judgement?
<dholbach> good morning
<mlankhorst> hm where is the documentation about why static linking is bad?
<infinity> didrocks: (sysvinit-core is only in Debian, so grab a copy of the unstable deb and list contents, should be helpful)
<didrocks> infinity: ok, refilling coffee to try to optimize my judgement then :p
<didrocks> infinity: thanks for the hint, doing this!
<infinity> mlankhorst: In many people's heads.
<mlankhorst> infinity: yeah but I need to get it in someone else's head
<infinity> mlankhorst: And it's not as cut and dried as "static linking is bad", it's "static linking is bad if more than one component in the system can/will use the same library".
<tjaalton> mlankhorst: the steam/mesa thread?-)
<mlankhorst> yeah..
<LocutusOfBorg1> good morning developers
<rbasak> Can someone pull mysql-5.6 into main please? I presume no MIR needed as it supercedes mysql-5.5 that was already in main.
<LocutusOfBorg1> rbasak, I see it already in main
<doko> infinity, debian has the state from December
<LocutusOfBorg1> https://launchpad.net/ubuntu/+source/mysql-5.6/5.6.23-1~exp1~ubuntu3
<LocutusOfBorg1> the latest ubuntu3 is already in main :)
<infinity> doko: Can ubuntu gcc binaries more or less install and run on unstable without breakage?  That's probably my quickest path to seeing if that's the difference before I go bisecting.
<rbasak> LocutusOfBorg1: oh, so it is, thanks. Looks like someone already acted on the email to ubuntu-release (I'd only just seen it)
<zsombi> guys, a recent upgrade on vivid causes this https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1434547
<ubottu> Launchpad bug 1434547 in glibc (Ubuntu) "package libc6 2.21-0ubuntu1 failed to install/upgrade: subprocess new pre-installation script returned error exit status 128" [High,Confirmed]
<zsombi> the update-manager just hangs on libc6 upgrade
<infinity> zsombi: Yes, I've seen the bug.  I've not managed to reproduce it yet to figure out why it's happening for some people.
<seb128> you have somebody who gets the issue, that might help to get debug info?
<zsombi> infinity: ok, maybe also it is worth to mention that my w510 with NVidia, latest driver simply kicks me back to teh login screen after I fixed the libc6 installation from terminal
<zsombi> infinity: the same doesn't happen on VMWare Fusion, so perhaps this is related to the nvidia driver..
<infinity> doko: Also, dropping -m32 from gcc-4.9 breaks grub2.  Can we please re-enable it for vivid?
<infinity> doko: I'm not sure I see the motivation for dropping it if it breaks both the upstream kernel and grub.
<infinity> doko: On ppc64el, that is.
<doko> rbasak, I don't see it pulled in
<infinity> zsombi: I'm the wrong person to complain to about nvidia drivers sucking. :)
<zsombi> infinity: np, was just lamenting :D
<doko> infinity, ok, re-enbling for vivid too :-/
<zsombi> infinity: btw it works wioth 3.19.0-7 kernel...
<infinity> doko: Who was responsible for those upstream commits?  amodra?
<doko> him and msebor
<infinity> doko: I might have a chat with him about it, since it broke both the upstream kernel defconfig (which is silly), and -m32 -mbig-endian, which I can't think was the intent.
<doko> infinity, well, I thought cjwatson was using the powerpc cross compiler for that ...
<infinity> doko: No, we switched from the cross to the native as soon as it was fixed to be able to build freestanding cross-endian binaries.
<doko> gcc binaries, yes should be fine, but conflicts with the gcc man packages from non-free
<doko> ahh
<infinity> doko: And that seems like a rather useful feature, so disabling it makes little sense to me.
<doko> anyway, I argued once upstream in the bug report, and it was closed as won't fix
<infinity> doko: Noting also that, in the thread, amodra himself claims he's building his own compilers with -m32 turned on for debugging purposes, so...
<infinity> doko: But yeah, I'll chat with him out of band about it.
<infinity> doko: I don't disagree that being able to turn it off is a sane option, I just disagree with the default.
<infinity> doko: Any chance you could get 4.9 uploaded ASAP, so the kernel team can get a kernel upload in before beta freeze?  4.8 and cross and such can trickle in later, less picky about those as long as we get -m32 before release.
<Cimi> does anyone know why my /etc/pm/config.d/modules doesn't work anymore after systemd transition in vivid?
<doko> infinity, currently preparing, yes
<infinity> doko: \o/
<didrocks> infinity: ok, seems it works fine with my tests: transition without issue (thanks god, at least, no conffiles to migrate), systemd by default and starts upstart, upstart by default, upstart by default and starts systemdâ¦
<didrocks> infinity: did some additional fixes as well to always have the available entries available in grub + some transition not supported clenup
<didrocks> cleanup*
<didrocks> infinity: mind having a look? http://people.canonical.com/~didrocks/upstart_sysv/
<didrocks> will be that + the touch seed change to dep on upstart-sysv instead of upstart
<ogra_> didrocks, you coordinated that with QA ?
<cjwatson> didrocks: /bin/sh scripts should use [ ... ] && [ ... ] rather than [ ... -a ... ]
<didrocks> ogra_: didn't, only tried on my qemu
<ogra_> jibel, ^^^
<cjwatson> (TBH all scripts should, the -a/-o syntax rules are a nightmare)
<cjwatson> also I think our usual is "which" rather than "type" for portability
<didrocks> cjwatson: ok, I mirrored what we executes in systemd-sysv, happy to change though
<infinity> didrocks: I'll have a look in an hour or so, avoiding a context switch.
<didrocks> sure
<cjwatson> it probably works in practice then and I'm just whining :)
<infinity> didrocks: Conflicts in systemd will also need updating, and the dependencies of "init".
<didrocks> infinity: see my 2 others patches in the same dir :)
<infinity> didrocks: Shouldn't be much more than that, but a grep of Packages files wouldn't hurt.
<infinity> didrocks: Ahh. :)
<didrocks> cjwatson: no worry, better to get it right, as I'm doing a systemd upload at the same time, changing it as well
<infinity> didrocks: I didn't load it yet. ;)
<didrocks> :)
<infinity> didrocks: Right, I'll get back to you in an hourish.  But thanks in advance!
<didrocks> infinity: no worry, just poke me once done (doing the samme update to address cjwatson's remarks)
<didrocks> cjwatson: better now? http://people.canonical.com/~didrocks/upstart_sysv/upstart_sysvinit.debdiff (I'm updating systemd as well to that syntax)
<kpcyrd_> hello. I'm running ubuntu 14.04 and would like to report that httpie is currently broken
<kpcyrd_> it depends on python-requests, but it's incompatible to the latest version of python-requests
<kpcyrd_> requests.compat.is_windows and requests.compat.is_py26 have been removed, but are in use by httpie
<kpcyrd_> is this the right channel for this?
<cjwatson> didrocks: yep, thanks
<didrocks> thank you for the suggestion :)
<mgedmin> kpcyrd_, I think the best thing to do is to report a bug (ubuntu-bug httpie)
<tsdgeos> mysql 5.6 broken :/
<kpcyrd_> mgedmin: I'm not that sure what's going on. is_windows and is_py26 still exist in reqeusts.compat, but I can't import them. Can somebody try to reproduce this?
<kpcyrd_> from requests.compat import is_windows
<mgedmin> works fine in 14.10
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/httpie/+bug/1213247 already exists
<ubottu> Launchpad bug 1213247 in httpie (Ubuntu) "httpie requires requests < 1.0, raring ships with 1.1.0" [Undecided,Confirmed]
<asac> cjwatson: infinity: cyphermox: anyone of you could help unblock our grub MP? https://code.launchpad.net/~jamesodhunt/snappy/bug-1412737/+merge/249976
<mgedmin> raring and saucy are out of support, aren't they?
<mgedmin> is that the same bug?  kpcyrd_?
<kpcyrd_> mgedmin: "reported on 2013-08-16" it was working on my box 1-2 weeks ago
<kpcyrd_> httpie and python-requests have been updated last week
<mgedmin> a new bug report with steps to reproduce and the full error traceback would really be useful
<kpcyrd_> on the other hand, I've checked the source of compat.py and this should be working
<cjwatson> asac: didn't realise that was blocked on me, I gave jodh a verbal ack ages ago ...
<cjwatson> asac: I'll fill that in on the MP as well
<kpcyrd_> I'm not 100% sure this isn't just broken on my box
<mgedmin> in that case pastebin the error please
<asac> cjwatson: thanks!
<kpcyrd_> mgedmin: https://paste.debian.net/162701/
<mgedmin> kpcyrd_, can you tell me what you see if you do python -c 'import requests; print(requests.__file__)'?
<kpcyrd_> /usr/local/lib/python2.7/dist-packages/requests/__init__.pyc
<mgedmin> kpcyrd_, /usr/local screams "user did a sudo pip install requests" to me; this can and will break things
<kpcyrd_> mgedmin: wups.. yeah, this could be the case. I installed something with pip on friday
<kpcyrd_> yeah, I think this is the reason. sorry and thanks for your help
<doko> tjaalton the xauth MIR is still incomplete
<tjaalton> doko: yes
<tjaalton> i'll just drop the tests, too much effort
<ejat> hi .. i got welcome to emergency mode after upgrade vivid
<ejat> what should i do ?
<infinity> didrocks: The systemd-sysv Conflicts might need to get a bit more messy.
<infinity> didrocks: Some versioned conflicts on upstart/upstart-bin (<< split_fix) or similar.
<mardy> mvo: did you have a chance to look into that qmake issue?
<BenC> infinity: I feel like you responded, but my scrollback doesnât show itâ¦
<infinity> BenC: What did I respond to? :)
<infinity> BenC: Oh, ubuntu.com mail stuff.  Yes, what's the issue you're having?
<didrocks> infinity: hum, indeed, it needs to conflicts against upstart before the split (I don't think against upstart-bin, though?)
<infinity> didrocks: Oh, not -bin, indeed.  Just upstart before this current fix.
<didrocks> agreed, doing
<infinity> didrocks: Otherwise, systemd and i-s-h look fine, now slogging through the upstart diff.
<didrocks> good luck!
<BenC> infinity: I need it to point to my gmail instead of swissdisk
<infinity> didrocks: What's with this lxcguest bit you dropped?
<didrocks> infinity: did I drop it? /me looks
<infinity> didrocks: No, I can't read.
<didrocks> infinity: yeah, the diff isn't easy to read due to the new package
<infinity> didrocks: Right, it was removal of upstart-compat-sysv from the conflict lines that broke my visual tracking. :P
<infinity> didrocks: What was upstart-compat-sysv?  Something short-lived in utopic?
<didrocks> infinity: this was something pre-precise even
<didrocks> the package doesn't exist anymore, hence the drop
<infinity> Fair enough.
<didrocks> (not in ubuntu nor debian)
<didrocks> infinity: note that I'm sure we can clean up way more, I just did a few I found on the way
<infinity> +Pre-Depends: upstart,
<infinity> Trailing comma intentional?  And also, was there a valid reason to make it a pre-dep instead of a dep?
<infinity> On, in fact, it's both a pre-dep *and* a dep. :P
<didrocks> infinity: I'm always using trailing coma to avoid future diff-noise (but I'm not that opinionated in a case like upstart, where all deps are one after another). For the predeps, there is a postinst calling update-grub
<infinity> didrocks: Yeah, the pre-dep seems to match what systemd-sysv does too, but fair enough.
<infinity> s/but/so/
<doko> that works now ...
<doko> (gdb) compile code printf("Hello world\n");
<doko> Hello world
<infinity> +sbin/telinit lib/sysvinit/
<infinity> That's just confusing, but matches what we have today.
<didrocks> indeed, I kept the symlinks we have to not add confusion
<infinity> didrocks: So, that all looks correct, as far as one can review something so large.
<didrocks> infinity: good, I got requested to upload upstart to a silo to get a quick QA test (only upstart), then I start pushing that to -proposed
<didrocks> first upstart
<infinity> didrocks: Does the output of  "dpkg -L upstart-sysv && dpkg -L upstart" match the old output of "dpkg -L upstart && dpkg -L upstart-bin"?
<didrocks> then, once published, systemd (so that we don't get in the "debian" case with skipping autopkgtest for upstart boot)
<infinity> didrocks: ie: did any files go missing? :)
<ejat> didrocks: thanks
<didrocks> infinity: yeah, I checked the numbers
<didrocks> infinity: and run --list-missing
<didrocks> ejat: yw!
<infinity> didrocks: Excellent.  Looks good to me, then.
<ejat> didrocks: systemd boot faster \0/
<didrocks> infinity: let's hope we are not going to break the image build, fingers cross :)
<ejat> btw .. any way to load vmhgfs on boot ?
<infinity> didrocks: The silo tests may fail if they're not sure how to test.  Though if they're just dist-upgrading and testing, that should work, thanks to the transitional upstart-bin.
<didrocks> infinity: they need rather to apt-get install upstart-sysv on Touch
<didrocks> (I detailed that)
<infinity> Oh, right.  And that.
<infinity> So, if they know how to test, should all go fine.
<didrocks> yeah, should be good, and then, I'll update their seed once all done
<infinity> didrocks: I'm up all night (obviously), so give me a poke when it's all landing in proposed, and we can make sure the autopkgtest stuff is clearing up and life looks saner.
<didrocks> infinity: will do, thanks for the review!
<infinity> didrocks: No, no, thanks for doing the work.
<didrocks> yw :)
<didrocks> ejat: let me look in 5 minutes if there is any known bug about this
<infinity> didrocks: Oh, and fix the systemd conflicts before you forget we had this conversation. :)
<didrocks> infinity: done already :)
<infinity> \o/
<ejat> didrocks: ok thanks a lot
<didrocks> ogra_: around? Seems like I can't upload anymore to the silosâ¦
<cjwatson> didrocks: Depends are satisfied when the postinst runs; maintainer scripts are only a justification for Pre-Depends if it's the preinst
<didrocks> sil2100: ? ^
<ogra_> didrocks, which silos ? vivid ones should surely work for all core devs
<ogra_> (i would assume RTM too but am not sure)
<didrocks> cjwatson: so, I don't see any reason to have the Pre-Depends in systemd-sysv then, I can clean up this one too
<didrocks> ogra_: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012
<cjwatson> didrocks: (might be for some other reason, perhaps less risky to leave alone ...)
<didrocks> cjwatson: yeah, let's handle in two steps maybe? Keeping it like that and I'll discuss this with pitti
<infinity> didrocks: If it's working like this today, I'd leave it be.  Pre-Depends make apt's resolver grumpy, but in a case like this that obviously has no loops, it should be fine.
<didrocks> +1
<didrocks> ogra_: no core-dev in https://launchpad.net/~ci-train-ppa-service/+members#active?
<infinity> s/grumpy/work harder/
<cjwatson> Doesn't necessarily have to be in members
<cjwatson> You can use newComponentUploader on a PPA
<ogra_> didrocks, then i'll leave that to sil2100
<didrocks> ogra_: mind sponsoring otherwise?
<cjwatson> And adding ubuntu-core-dev to ci-train-ppa-service which gets lots of mail spam might make people grumpy
<infinity> Yeah, the FTBFS spam from silos is insane.
<infinity> I lean on the delete key every morning.
<cjwatson> oh, though ubuntu-core-dev has a team e-mail address set, so it might be passable, but still
<didrocks> infinity: oh, you have rights to push there, mind doing it with the debdiff I gave you? (landing-012)
<didrocks> let's not delay this on wrong permissionsâ¦
<infinity> didrocks: Yeah, I'm pretty sure I have the powers to do that.
<didrocks> you are in the list, so I guess you get the spam :)
<infinity> didrocks: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012 ?
<didrocks> infinity: correct
<infinity> "You can upload packages to this PPA" sounds like LP saying I can do it. :P
<infinity> I'll grab your diffs and send 'em up.
<didrocks> thanks!
<didrocks> infinity: well, only upstart
<cjwatson> Perhaps an admin should do: for distro in ubuntu ubuntu-rtm; do for silo in $(seq -w 1 30); do edit-acl -A ppa:ci-train-ppa-service/$distro/landing-0$silo -p ubuntu-core-dev -t upload add; done; done
<sil2100> didrocks: huh?
<didrocks> sil2100: can't upload to the silos
<cjwatson> though it's another thing that has to be configured per-silo
<sil2100> wth
<mvo> mardy: I reproduced it, does it help if you run "qt5-qmake-arm-linux-gnueabihf" in your build dir instead of qmake? or
<infinity> didrocks: Just upstart?  Kay.
<didrocks> infinity: yeah, I plan to do manual uploads anyway (as I want the systemd autopkgtest to use the new upstart), so just for the QA team to test the upstart part which should be enough for me
<sil2100> didrocks: not sure why, but indeed the team doesn't have core-devs included in it, just single people
<cjwatson> Anyone in ~ci-train-ppa-service could do the above, in fact
<cjwatson> sil2100: ^- see what I said above
<infinity> Dear patch, thanks for making all those 0-length files instead of deleting them.
<infinity> Oh, because that's what the diff said.
<infinity> Weird.
<didrocks> hum? they are removed here
<cjwatson> On the whole this would be better for people, although it would be convenient if I could remain a direct member so that I can admin your silos using launchpad-ppa-self-admins capability :)
<didrocks> $ LANG=C ls debian/upstart-bin*
<cjwatson> (same might go for infinity)
<didrocks> ls: cannot access debian/upstart-bin*: No such file or directory
<infinity> didrocks: Yeah, just a minor diff/patch bug, removing files is "hard".
<sil2100> I wonder why didrocks is not in ci-train-ppa-service in the first place
<didrocks> sil2100: conspiracy obviously ;)
<sil2100> :|
<sil2100> ;)
<sil2100> eh
<cjwatson> incidentally, implication of the above command line is that ppa:foo/bar/baz now works as a synonymous archive reference for ~foo/bar/baz in the LP API, as discussed here a week or two ago
<didrocks> ejat: couldn't find any reference downstream or upstream (apart from an archlinux forum stating the same), mind opening a launchpad bug, and ideally, forwarding it upstream?
<mvo> mardy: hm, nevermind, what is the project I can reproduce this with easiest? I'm not sure if this a chroot issues or something with the wrapper
<infinity> didrocks: Uploaded.
<didrocks> infinity: thanks! let's see how it goes :)
<mardy> mvo: anyone, really, but you can use this one: https://github.com/mardy/ttrss
<ejat> what title should i put ? please advise ..
<ejat> under systemd ?
<didrocks> ejat: yeah, under systemd, mention "vmhgfs" (vmware) fs type (and paste your fstab)
<mardy> mvo: is qt5-qmake-arm-linux-gnueabihf something that gets installed in the chroot regardless of the framework version? My chroot is for 14.10 (I want to target the BQ devices first)
<mvo> mardy: it gets installed on 15.04, I need to check on 14.10 - does it help if you manually install it?
<mardy> mvo: I've tried to patch click and add that package to click/chroot.py, but when I create the chroot, it says that that package is not found
<mardy> mvo: and searching in packages.ubuntu.com tells me that that package exists only in vivid
<mvo> mardy: aha, then its probably best to discuss with bzoltan, I think he mentioned that this is in the sdk ppa(?)
<mardy> mvo: OK; although, I'm using that ppa. But let's see...
<infinity> doko: Okay, using Ubuntu GCC and binutils on unstable gets me the same failures, so you're off the hook, but now I'm even more confused. ;)
 * infinity shelves that for now.
<infinity> doko: That gcc-4.9 fixed both the kernel and grub, thanks.
<Dvine> devils
<sitter> didrocks, ogra_: hey, any news on bluez5?
 * ogra_ isnt working on it 
<didrocks> sitter: no, as told last time, it's on the phonefundation's team radar for touch support but I feel now that it has low chances to be ready in timeâ¦
<didrocks> sitter: you can sync up with ricmm once he's around, he's working on it
<didrocks> or ChickenCutlass maybe? ^
<ogra_> ricmm is on vacation
<roaksoax> doko: howdy! so we tested pythoon-django16. Seems to be working fine. We are gonna be looking into apparently unrelated issues, and move forward with it
<ChickenCutlass> didrocks its on our list for this sprint
<roaksoax> doko: do you need me to upload it, or will you one we are comfortable with it?
<sitter> Riddell: ^ what do we do about bluetooth?
<doko> roaksoax, no, please upload and git rid off my name in the changelog ;)
<didrocks> ChickenCutlass: do you think it will land in vivid? (we are after beta now), I guess the kubuntu team is quite stuck (more than us on unity desktop, as we keep our ppa ready, but not blocked on it)
<roaksoax> doko: haha ok
<ChickenCutlass> didrocks not sure yet.  will let you know soon
<roaksoax> doko: so how do I go about getting it in Main? File an MIR?
<didrocks> ChickenCutlass: sure! do you mind keeping sitter and Riddell in the loop as well for the kubuntu side?
<ChickenCutlass> of course
<didrocks> thanks :)
<sitter> lovely thanks
<doko> roaksoax, not needed, just another version which already was in main
<roaksoax> doko: ok, cool
<teward> hey i have a question, is there a reason we're all still on gnupg 1.x and not gnupg 2.x in the releases by default?
<roaksoax> doko: done! uploaded
<doko> roaksoax, accepted
<doko> jamespage, are there standing FFes for the python-oslo.policy and python-semantic-version packages?
<infinity> teward: Because we've not chosen to diverge from Debian, and their plan was to move post-jessie, I believe.
<roaksoax> darkbasic: awesome! thanks!
<roaksoax> err
<roaksoax> doko: awesome! thanks! :)
<jamespage> doko, yes - this bug:
<jamespage> https://bugs.launchpad.net/ubuntu/+bug/1434526
<ubottu> Launchpad bug 1434526 in Ubuntu "[FFe] new packages to support OpenStack Kilo-3 milestone" [High,Triaged]
<doko> jamespage, can python-semantic-version be synced?
<jamespage> it has been
<doko> so oslo not yet in debian
<doko> tjaalton, please could you fix xauth today or tomorrow?
<jamespage> doko, no - the oslo packages won't be in debian anytime soon
<jamespage> doko, they are linked directly to the openstack release being packaged - we're on kilo, debian only has juno in experimental and icehouse in unstable/testing
<jamespage> doko, hence the direct uploads to ubuntu for oslo.policy and oslo.log
<jamespage> doko, semantic-version has been synced - its in the NEW queue as well
<jamespage> doko, broadley the oslo-* packages fall under the general exception we have for openstack projects for feature freeze - upstream will bump and align as we move towards release -will settle down once we have kilo-3 in archive (hopefully this week)
<doko> yes, but somebody has to review the sources first
<tjaalton> doko: yep
<jamespage> doko, yup
<teward> infinity: OK - it caused problems with my enigmail plugin (which will no longer support anything earlier than gpg2 starting next update) in Thunderbird, hence my asking
<teward> infinity: thankfully gpg2 is in the trusty repos so i'm relatively OK.  thanks for the answer :)
<infinity> teward: Really?  That's a bold move on the part of enigmail upstream.
<teward> infinity: let me see if i can get it to tell me the error again, and i'll screenshot
<teward> infinity: ahh, okay, 1.9 is their transition - https://www.enigmail.net/support/transition_to_gnupg2.php
<teward> but since enigmail 1.6 they've suggested gpg2
<teward> gpg 2.x *
<teward> infinity: so it looks like enigmail 1.9 will cease support for gnupg < 2.0
<infinity> teward: Fun.
<infinity> teward: Oh well, we have gnupg2 all the way back to lucid, so it should generally not be a big deal.
<teward> infinity: except that it's not default installed, hence my concern users will be like "HOW DO I DO DIS" (sorry i have a low view of end users today after the flood I got in my email about a PPA this morning >.<)
<teward> infinity: granted that's an issue for the next cycle but meh
<infinity> teward: I hope that more users are using the enigmail package, which should just switch the dep when 1.9 ships.
<infinity> s/more/most/
<teward> mmm
<teward> infinity: we can only hope
<teward> won't help us back on trusty, it's only 1.7 in there
<infinity> teward: To be fair, the intersection of "people who install enigmail to GPG sign mail" and "people who know how to install packages" should be pretty high.
<teward> mhm
<infinity> teward: It's updated to match thunderbird updates.
<teward> infinity: *is it*?
<infinity> teward: So, when we update the enigmail package to 1.9, the dep switches, life goes on.
<teward> ah
<rbasak> Is there a standard way to mention a bug in debian/changelog without causing it to auto-close?
<rbasak> Do I just hack the changes file?
<seb128> rbasak, just use an invalid syntax to mention it?
<infinity> mvo: It seems you really can't win with that test.
<seb128> like "bug #..."
<seb128> rather than "lp..."
<seb128> rbasak, or use the bug url
<infinity> rbasak: I tend to use "LP: 123456" (ie: omit the #)
<ubottu> Launchpad bug 123456 in xine-lib (Ubuntu) "podcast crashes amarok" [Undecided,Fix released] https://launchpad.net/bugs/123456
<infinity> rbasak: But anything that's invalid syntax works.
<infinity> ubottu: Shut up.
<infinity> rbasak: Just check your .changes to make sure it doesn't have the closure line in it.
<Unit193> ubottu: shaddap
<ubottu> :X
 * ogra_ usually writes "launchpad bug: #12345"
<ubottu> Launchpad bug 12345 in isdnutils (Ubuntu) "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345
<rbasak> seb128, infinity, ogra_: OK, thanks. Seems a bit horrible, but I'll do it :()
<cjwatson> I usually say "LP #nnnnnn"
<rbasak> :)
<rbasak> Hmm. Now I have to pick! :)
<infinity> rbasak: Colin's a traitor, his opinion doesn't count anymore.
<seb128> rbasak, or get it to autoclose and reopen manually
<seb128> if you prefer
<cjwatson> Ha
<cjwatson> The regex is in /usr/share/perl5/Dpkg/Vendor/Ubuntu.pm if you need to check against it
<cjwatson> The reason I don't use LP: nnnnnn is that that pattern doesn't work in Debian with closes:; its syntax is a bit more permissive
<infinity> mvo: I think I'm just going to let your apt in, despite the failure, but pretty please figure out how to fix that some day. :P
<cjwatson> (the # is optional for closes:)
<infinity> cjwatson: For Debian, I use s/closes/addresses/ (or whatever) for referencing-but-not-closing.
<cjwatson> Yeah, that works too
<infinity> I do want a reopens: or reverts: or something, though.
<alex-k>  
<didrocks> infinity: hum, seems that the upstart autopkgtests failed
<didrocks> infinity: the weird part is that the failure is passing during the test build, so I would feel it's something in the testbed environment not correctly setup by the autopkgtest itself
<didrocks> not ok 54 - with single line command writing lots of data fast and exiting
<infinity> didrocks: That's a nondeterministic test, I retried already.
<didrocks> infinity: ah ok, "known one", good :)
<dobey> init: invalid option: --user
<dobey> hrmm :-/
<infinity> didrocks: And, indeed, build 98 passed.
<didrocks> infinity: I'm waiting for upstart to be on the release pocket to rebuild ubuntu-touch-meta, then, I think we'll be good (of course, we'll need to transition rdepends on upstart-bin to upstart, but that can wait)
<infinity> didrocks: Yeah, transitioned rdeps don't *need* to happen before vivid releases, but it would be nice.
<infinity> didrocks: Also, upstart-bin should be seeded in supported so it doesn't fall out to universe before release.
<infinity> didrocks: I'll do that now.
<didrocks> infinity: if I have a window after beta freeze, I'll handle this, one thing less on the list
<didrocks> infinity: indeed
<didrocks> thanks
<infinity> didrocks: Done, and upstart should migrate on the next britney pass.
<infinity> didrocks: You might need init-system-helpers migrated too before you rebuild touch-meta, depending on how germinate decides to resolve everything.
 * infinity gives it a pass, none of the failures looks related.
<didrocks> infinity: ok, waiting for the next britney pass + publisher run
<infinity> didrocks: Just double-check the diff after you run the update script to make sure it didn't do something Very Stupid. :)
<didrocks> infinity: sure, if the diff doesn't make sense, I'll directly pester you I guess :)
<infinity> didrocks: Heh.
<infinity> Bleh, the systemd autopkgtest seems very, very unhappy.
<didrocks> hum, connecting to the internal one
<didrocks> infinity: something went wrong with the test bed? seems like amd64 was more cooperative
<infinity> didrocks: Maybe.  I'll give it a kick.
 * infinity is annoyed that we can't retry a single arch.
<flexiondotorg> When will the repos get frozen for the next beta?
 * dobey is annoyed that vivid proposed apparently breaks "init --user" :-/
<infinity> flexiondotorg: I sent an email that mentioned that not too long ago. :P
<infinity> dobey: It does?
<dobey> infinity: seems to. i'm using adt-run to run some autopkgtests, with a setup command which starts a user session with "init --user" and if i enabled the proposed pocket, it fails with "init: invalid option: --user"
<didrocks> infinity: at least, they (amd64 and i386) both run with the same version of upstart, so not that
<infinity> dobey: By "init", are you expecting "upstart"?
<didrocks> dobey: well, init is systemd
<didrocks> you should change it by the upstart path
<infinity> dobey: And, if so, did your test depend on "upstart" to make that happen?
<ginggs> hi, anyone from ubuntu-archive able to look at LP: #1432552 and LP: #1432576 please?
<ubottu> Launchpad bug 1432552 in ants (Ubuntu) "Please remove armhf, powerpc and ppc64el binaries" [Undecided,Incomplete] https://launchpad.net/bugs/1432552
<ubottu> Launchpad bug 1432576 in kissplice (Ubuntu) "Please remove 32-bit (armhf, i386 and powerpc) binaries" [Undecided,New] https://launchpad.net/bugs/1432576
<infinity> dobey: Anyhow, two solutions to that.  Either depend on upstart-sysv, or stop thinking "init --user" is a thing and call upstart  directly for user sessions.
<didrocks> infinity: yeah, we may have broke some of those tests :)
<didrocks> broken*
<dobey> infinity: it's not my test that depend son "init --user"
<dobey> infinity: it's the "ubuntu-touch-session" script that is part of autopkgtest
<dobey> hmm
<infinity> dobey: Okay, that wasn't helpful debugging.  How is "ubuntu-touch-session" expecting "init" to be upstart?  That's what needs fixing.
<dobey> infinity: i'm not sure. but if the packages were rearranged in vivid now, how can i make it work correctly for both vivid and utopic?
<infinity> ginggs: No one really answered doko's question on that first bug.  "The Debian maintainer arbitrarily restricted the arches" isn't the right answer.
<didrocks> dobey: infinity: let me do a quick upload of ubuntu-touch-session to not break autopkgtests
<didrocks> it already work on phone anyway as we install init, but let's ensure the script is using the upstart path
<didrocks> and that will be compatible with utopic, if this needs backporting
<dobey> didrocks: ubuntu-touch-session is a script in autopkgtest, not a separate package
<dobey> at least, the one i'm referring to, is
<didrocks> dobey: I'm talking about the ubuntu-touch-session script in ubuntu-touch-session package
<doko> infinity, ginggs: well, they probably need some love
<flexiondotorg> infinity, Heck. Tonight. Could you spin a new ubuntu-mate-meta package? There are a few minors changes that fix bugs. The seeds are up to date.
<doko> infinity, and more disk space on the buildds ;-P
<dobey> didrocks: yeah, that's something completely different
<infinity> doko: Yeah, the disk space issue will be addressed this week.
<didrocks> dobey: ok, not sure which one you are talking about then
<dobey> didrocks: one second, i'll link you
<infinity> dobey: So, how is upstart becoming the default init in your case?  Are your tests depending on it, or is ubuntu-touch-session mangling things to make it so?
<dobey> didrocks: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/autopkgtest/vivid/view/head:/setup-commands/ubuntu-touch-session
<ginggs> doko, infinity: yeah and 4.4.2-1 fail on everything except i386 and amd64 ( https://buildd.debian.org/status/logs.php?pkg=insighttoolkit4&ver=4.4.2-1&suite=sid )
<didrocks> dobey: ok, let's fix it (and yeah, it will be backward compatible)
<didrocks> not touching the -session one yet, only running on touch and no time for the additional QA tonight
<cjwatson> infinity: I wonder how much of the disk issues are just ddebs.
<infinity> ginggs: Why are logs from a year and a half ago interesting or relevant?
<doko> could be. these is swig generated code
<infinity> cjwatson: Not much.
<infinity> cjwatson: For the two cases I know of, anyway, the build trees are just enormous.
<infinity> cjwatson: generating ddebs doesn't help, but we can't be saved from that.
<infinity> flexiondotorg: Lemme give it a kick.
<flexiondotorg> infinity, Many thanks.
<cjwatson> infinity: Hm, OK, I thought I'd looked and found a gigabyte plus of ddebs from the last few days due to things like Thunderbird uploads.
<cjwatson> infinity: But maybe that isn't enough to matter.
<infinity> cjwatson: When we're talking about a 50G root filesystem not being enough because a build needs 60G, yeah, a gig of ddebs doesn't matter.
 * cjwatson nods
<infinity> cjwatson: Getting ddebs out of public_html will make the rootfs available space more deterministic, though, which is nice.
<cjwatson> Right, that was my thought.
<infinity> cjwatson: Like, the kernel is borderline, and cleaning the filesystem before build makes it juuuust fit.
<infinity> cjwatson: Do you know if the scalingstack disk images are squishy sparse images of some sort or other?
<infinity> cjwatson: Pondering how big we can get away with making them while making (perhaps faulty) assumptions that N giant builds won't happen at once on a compute node, where N is enough to ENOSPC the host.
<didrocks> infinity: was I right that you did override the lcxfs and ofonophonesim autopkgtests for init-system-helpers?
<didrocks> infinity: also, the lxc tests seem stuck (blocking as well init-system-helpers)
<infinity> didrocks: init-system-helpers should migrate, I think I just missed the window for the last run.
<cjwatson> infinity: I'm not totally certain, that's probably a pjdc kind of question.  They're built by modifying the stock cloud images.
<infinity> didrocks: And yeah, I'm aware of the lxc tests being wedged, but not entirely sure why.
<didrocks> I guess that's why the adt queue is growingâ¦
<infinity> cjwatson: After asking the question, I realized it was a stupid question, of course the images are sparse, or they'd be massive.
<ogra_> "disk space is cheap"
<ogra_> :P
<infinity> cjwatson: But still worth seeing if disk overscommit is plausible, if openstack has a good unwind strategy or if it would just wedge the world.
<infinity> ogra_: It is, except when it's not.  But yes, more disk is the better option.
<ogra_> :)
<infinity> stgraber: Do you know what's up with the lxc and lxcfs autopkgtest failures?
<infinity> flexiondotorg: ubuntu-mate-meta claims no changes found since the Mar 17 upload.
<infinity> flexiondotorg: Are there pending commits to the seeds that haven't happened, or were you mistaken about it needing an update?
<dobey> didrocks: so can you explain to me the solution for this init --user change (and why it broke)?
<infinity> dobey: Fundamentally, assuming "init" is upstart on anything but a touch system is wrong.
<infinity> dobey: And assuming that on touch is still not future proof.
<stgraber> infinity: not really
<stgraber> infinity: hallyn's looking into some of the lxc problems though. Short answer for both is systemd
<infinity> stgraber: I figured you'd have a better chance at a guess than I would. :P
<didrocks> dobey: I guess you test depends on upstart instead of upstart-sysv. Now init is in upstart-sysv and not upstart anymore. so "init" corresponds to systemd
<dobey> infinity: ok, but why did it break exactly? the upstart packaging was rearranged, and so whatever provided that, is not being installed any longer?
<didrocks> dobey: the change is just to replace init with upstart
<stgraber> messed up cgroup config appear to break part of lxc and that may also affect lxcfs
<flexiondotorg> infinity, Push a seed update 1 hour ago - http://bazaar.launchpad.net/~ubuntu-mate-dev/ubuntu-seeds/ubuntu-mate.vivid/revision/99
<dobey> didrocks: so just run "upstart --quiet --user" instead? and just require the "upstart" package to be installed?
<infinity> dobey: The packaging was shuffled, yes.  So if a test depends on "upstart" to make init==upstart, it should be depending on upstart-sysv.  But if the test only needs upstart user sessions, not upstart as system init, it makes more sense to call "upstart --user".
<didrocks> dobey: yeah, sounds like what your test want, so that will be the new relationship
<dobey> ok, i'll tweak the script as installed and see if that works, real "quick"
<didrocks> I guess apart from systemd and upstart tests, all other autopkgtests only cares about upstart as user session daemon
<infinity> flexiondotorg: Ahh, that won't work until ubiquity-slideshow-ubuntu migrates to the release pocket.
<didrocks> dobey: I'm building the autopkgtest locally before pushing (running the tests)
<flexiondotorg> infinity, Ah, OK.
<didrocks> infinity: shouldn't the override been taken into account now? (still not considered after 2 update_excuses generation)
<dobey> didrocks: i don't know if the tests for the package do something that runs that script or not; i suspect not
<infinity> didrocks: Hrm.  Can I not spell?  This is possible.
<didrocks> autopkgtest builds fine with tests passing here, pushing
<didrocks> infinity: dobey: ^
<dobey> didrocks: and i think it's probably better to ping pitti and get this fixed directly upstream, rather than just uploading a "fix" to the package
<didrocks> dobey: yeah, working less though when pitti is on holidays
<didrocks> dobey: but don't worry, he even has a git-format-patch waiting for him
<dobey> ok
<didrocks> (for this and a lot of other things)
<infinity> flexiondotorg: Is that the only change you're waiting on?
<infinity> flexiondotorg: (for your meta, I mean)
<flexiondotorg> infinity, Yes, because I didn't realise someone had been good enough to update it on the 17th ð
<infinity> didrocks: Oh, bah.  It's the britney bug where it processes hints in order, and later ones win even if the versions are lower.
 * infinity kills vorlon's hint.
<ogra_> thats using the wrong namespace anyway :P
<infinity> flexiondotorg: Alright, I'll kick it again once your slideshow exists.
<didrocks> infinity: oh, indeed, easily trapped :p
<flexiondotorg> infinity, Thank you very much. It may seem like a small thing, just that package. But...
<flexiondotorg> infinity, Ubuntu MATE has been approached by an OEM. They want to test the next beta :)
<infinity> flexiondotorg: No small thing, Ubuntu's always been about polish.  Glad to see flavours living up to that.
<ginggs> infinity: just wanted to show they haven't built in debian for a long time and we are about to release an old version because of this.
<infinity> ginggs: Except that's not the version in Ubuntu, and ours fixed that bug.
<ginggs> doko: i've only just seen your debian bug #780659 now
<ubottu> Debian bug 780659 in src:insighttoolkit4 "insighttoolkit only built on amd64 and i386" [Normal,Open] http://bugs.debian.org/780659
<hallyn> stgraber: systemd is thwarting me:
<hallyn> ubuntu@lxcv1:~$ sudo systemctl stop cgmanager
<hallyn> Failed to get D-Bus connection: Operation not permitted
<hallyn> ?
<infinity> ginggs: The kissplice arch restriction looks just as suspect.  Not sure why people don't fix bugs instead of papering over them.
<infinity> ginggs: 10 to 1 odds say that fixing compiler warnings like "kissReads.c:359:19: warning: assignment makes pointer from integer without a cast" would magically make it work on 32-bit arches.
<dobey> didrocks: oh, seems to work here for my tests too, btw
<ginggs> infinity: ok, thanks for looking into those bugs. it is obviously better to try to get the builds to work on all arches
<infinity> ginggs: Well, it's not always obviously better, but when the reason a build doesn't work is "upstream sucks at C", that's the maintainer's job to fix, not handwave and work around. :P
<didrocks> dobey: phew, thanks for confirming
<dobey> didrocks: now if i could just get autopilot to do the right thing with my actual tests :)
<didrocks> dobey: ahah, that's another story! :)
<infinity> didrocks: Hrm, I'm going to have to force systemd in without waiting on its tests, I guess.
<infinity> didrocks: Cause the old systemd Conflict: upstart, and that's going to start horribly breaking computers shortly.
<didrocks> infinity: yeah, they passed on amd64 anyway, and I wrote some of the failing tests, I can ensure there is nothing related to usptart in them
<infinity> If people upgrade blindly.
<dobey> infinity: true. unfortunately, sometimes the package maintainers suck at C and think they know better than they do, too. ran into that the last time i tried to use handbrake. had to fix the "security fix" patches that were actually causing crashes, remove some other patches, and rebuild, to get it remotely usable :-/
<didrocks> infinity: yeah, better to force
<didrocks> infinity: proposed-migration didn't run for almost 15 minutes btw, I wonder if vorlon's override had some magic to not make it crash :p
<infinity> didrocks: Or you're just impatient. ;)
<didrocks> infinity: maybe because I'm waiting for the publisher cycle to rebuild ubuntu-touch-meta and call it a day, indeed :)
<infinity> dobey: Turns out people in general suck, this is the joy of open source, we get to tell people they suck via submitting patches smugly!
<infinity> didrocks: A watched ftpmaster never publishes.
<dobey> infinity: that's why i'm a practicing misanthrope.
<infinity> didrocks: Ooo, I think my systemd hint got in just under the wire.
<infinity> timestamp: Mon 2015-03-23 12:28:25 -0600
<infinity> I: [Mon Mar 23 18:29:16 2015] - Loading hints list from data/vivid-proposed/Hints/adconrad
<infinity> Here's hoping those clocks are aligned.
<didrocks> infinity: ahah, let's cross fingers :)
<infinity> final: byobu,init-system-helpers,psensor,systemd
<infinity> \o/
<didrocks> sweet!
<infinity> flexiondotorg: And, of course, after waiting for it to publish, I actually looked at the seeds you changed...
<infinity> flexiondotorg: ship/ship-live don't affect metapackages, they just affect how CDs are built.
<infinity> flexiondotorg: So, no upload needed, this will magically work on the next image build.
<infinity> flexiondotorg: Err, except that it won't work.
<infinity> flexiondotorg: oem-config only ever installs the ubuntu slideshow (you might note that no other flavour has an oem-config-slideshow)
<infinity> flexiondotorg: You might want to revert those seed changed for now, and we can sort out what to do about it a bit later.
<infinity> flexiondotorg: Cause, for now, you'll end up with the mate slideshow on the ISO, but ubiquity/oem-config will try to install the non-mate version, and the world will end in tears.
<kirkland> infinity: thanks
<hallyn> stgraber: so seriously, i'm missing something about systemctl usage.  as root i do 'systemctl list-units' and get "permission denied"
<hallyn> have yo useen that happen?
<hallyn> well,
<hallyn> root@lxcv1:~# systemctl list-units
<hallyn> Failed to get D-Bus connection: Operation not permitted
<infinity> flexiondotorg: I reverted that seed change of yours.  If you really want to be a unique snowflake with your own oem-config slideshow, we'll have to discuss how to make that work (or, ubiquity patches welcome).
<infinity> flexiondotorg: But, for now, it would have broken your ISOs, so reverted to avoid that.
<stgraber> hallyn: hmm, nope
<hallyn> a reboot typically fixes it, but it's happened to me twice now
<sarnold> hallyn,stgraber, quick Q re lxd images, how does one compute the sha256sum of a directory?
<hallyn> ?
<stgraber> sarnold: it's not a directory
<hallyn> apparently we have some docs to clear up
<elfy> mmm - why's an upgrade in vivid that's wanting to upgrade upstart-bin expecting to install a bunch of 32bit packages
<stgraber> sarnold: lxd images are tarballs containing a rootfs/ directory and a metadata.yaml file. That compressed tarball is what we hash
<sarnold> hallyn,stgraber, search for "unique" https://github.com/lxc/lxd/blob/master/specs/command-line-user-experience.md
<stgraber> ah yeah, need to fix that one, good cach :)
<stgraber> *catch
<sarnold> want an issue?
<stgraber> nah, I'll send a branch now
<sarnold> okay, thankls
<stgraber> hallyn: https://github.com/lxc/lxd/pull/427
<sarnold> stgraber: is that hash of the compressed tarball or uncompressed tarball?
<stgraber> sarnold: it's a hash of the tarball as it was uploaded. So if it's an uncompressed tarball, then uncompressed, if it's compressed, then compressed.
<infinity> elfy: It's confused.  Let the archive settle.
<sarnold> stgraber: okay, thanks
<stgraber> sarnold: the idea being that sha256sum <file> will match the hash used to refer to it after you import it into lxd
<elfy> infinity: ok - I did wonder, but also got asked - thanks
<infinity> elfy: That's a remarkably weird behaviour on apt's part, though.  I wouldn't have expected it to break differently. :P
<infinity> elfy: Hrm, on mine, is just holds upstart-bin, which seems more sane.
<infinity> s/is/it/
<elfy> infinity: apt seems to be doing it right, synaptic is playing games ...
<infinity> elfy: Oh, wow, people still use synaptic?
<elfy> infinity: they do ...
<infinity> elfy: Anyhow, once the archive has settled to the point where apt appears to offer a sane upgrade, can you cancel that and see if synaptic is happier too?
<infinity> elfy: Should be another 30m or so at most, I'd think.
<elfy> infinity: will do
<infinity> elfy: The sane upgrade, fwiw, should involve installing "upstart" as a new package, and otherwise just a bunch of upgraded packages.
<infinity> elfy: Assuming it's a system with systemd-sysv installed.
<elfy> infinity: it is
<infinity> elfy: Right.  So, that's what the upgrade should look like when the archive settles.  Lots upgraded, and upstart new.
<elfy> okey doke
<hallyn> merged
<infinity> didrocks: Did you want me to do the ubuntu-touch-meta update in a bit?  It looks like I'll still be awake for another half hour or so anyway.
<didrocks> infinity: no, that's fine, I see it through rmadison just now, so I guess it's just a question of 15 minutes, I can wait a little bit more
<didrocks> I'll just update, if the diff is fine, I will dput and done
<infinity> didrocks: Mirrors should be good.
<didrocks> infinity: yeah, already building the metapackage + trying an upgrade path here
<didrocks> infinity: \o/ upgrade path is what is expected (upstart installed, the rest upgraded), and the diff on ubuntu-touch-meta is what you would expect, no bad surprise here
<didrocks> pushing
<infinity> didrocks: Trying the upgrade with update-manager too.
<infinity> didrocks: update-manager seemed to DTRT too.
<didrocks> infinity: good news to end the day (and you should go to bed) \o/
<didrocks> we may have some autopkgtest failures on the "expect init to be upstart if upstart bin is installed"
<didrocks> but let's handle that as they come (if any)
<infinity> didrocks: Might be a few, but I do hope that's not a common thing to do.
<didrocks> I hope too
<didrocks> infinity: ok, with that, have a good night and see you tomorrow :)
<infinity> didrocks: Thanks again, and g'night.
<didrocks> yw! thanks for your review and getting the packages passing by
<Noskcaj> Do anyone want to sync libssh2 before we freeze? It fixes 0003-CVE-2015-1782
<ubottu> The kex_agree_methods function in libssh2 before 1.5.0 allows remote servers to cause a denial of service (crash) or have other unspecified impact via crafted length values in an SSH_MSG_KEXINIT packet. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1782)
<Noskcaj> And no other changes
<infinity> Noskcaj: Done.
<Noskcaj> :)
<mdeslaur> roaksoax: can you please merge in the utopic security update into your vivid django package: https://launchpad.net/ubuntu/+source/python-django/1.6.6-1ubuntu2.2
<Noskcaj> Riddell, Do you have a few minutes to help me fix libgit2-glib?
<doko> barry, can python3-enum34 be removed in vivid?
<barry> doko: probably, given that python3.4 has it.  not sure what the effects would be for virtualenvs or systems that have been upgraded (and would have older python3's).  but then maybe pip is good enough.  so probably yes, but i don't want to commit to "yes" ;)
<doko> I'm too tired, making too many mistakes. good night
<roaksoax> mdeslaur: will do! thanks
<_habnabit> not sure if this is the right channel, but it seems more correct than #ubuntu, at least. i'm trying to find the source for avahi 0.6.31-4ubuntu4; http://packages.ubuntu.com/source/vivid/avahi links to https://code.launchpad.net/~ubuntu-desktop/avahi/ubuntu which only appears to be 0.6.31-1ubuntu1. https://code.launchpad.net/avahi doesn't seem to list any other ubuntu branches, either
<tarpman> _habnabit: https://launchpad.net/ubuntu/+source/avahi/0.6.31-4ubuntu4
<_habnabit> tarpman, oh okay thanks
<_habnabit> tarpman, how did you know where that was?
<dobey> _habnabit: https://launchpad.net/ubuntu/+source/avahi ?
<_habnabit> dobey, yeah, but the package.ubunutu.com page doesn't link there?
<tarpman> _habnabit: I don't remember where I learned it... :/  if you search for "avahi" on LP, dobey's link is near the top; also bug pages have links to different source pages at the top
<dobey> _habnabit: well, the branch it links to *should* have it, but it looks like the branch import broke at some point, so it's out of date
<_habnabit> okay
<_habnabit> anyway thanks
<micahg> you can also use pull-lp-source from ubuntu-dev-tools
<_habnabit> oh, okay
<_habnabit> that will pull from the right place always?
<micahg> well, that'll get you the latest tarball
<_habnabit> ah
<micahg> debcheckout should DTRT most of the time for VCS as well (except in cases like this where it's not up to date)
<_habnabit> i wanted the bzr repo because i'm making an internal fork; avahi-daemon interacts oddly with unprivileged containers, and i need to patch it for now
<elfy> infinity: so yea - everything is happy now
<_habnabit> relatedly, if i was going to do that, is there a particular versioning scheme i should use so that my own packages somehow supersede ubuntu's? this isn't something i've had to do before
<tarpman> _habnabit: generally, tack on your own version after the ubuntuN, see dch(1)'s -l/--local argument
<_habnabit> tarpman, does -l have a default prefix it adds? afaict from the manpage it just suffixes whatever you want
<_habnabit> tarpman, the 'backport creation' page suggests using a ~ delimiter
<_habnabit> er, prefix = delimiter
<dobey> you should just append ".0~youridentifier1" to the version for example
<_habnabit> okay
<tarpman> _habnabit: ~ makes it sort earlier, backports use it so that upgrading to a new stable works later
<tarpman> _habnabit: dch -l local â turns 0.6.31-4ubuntu4 into 0.6.31-4ubuntu4local1 (for example)
<_habnabit> so if i then make avahi 0.6.31-4ubuntu4.0~habnabit1 it'll supersede, say, -4ubuntu5 ?
<tarpman> dobey: just curious, what's the purpose of the .0~ part?
<tarpman> _habnabit: no, but you can avoid that via pinning, see apt_preferences(5)
<_habnabit> ah okay
<tarpman> _habnabit: generally if the ubuntu package gets e.g. a security update, you'd probably want to rebase on that (IMO)
<_habnabit> true
<tarpman> that's how I manage my local repo, anyway. dch -l, pinning so I don't get caught by surprise, and rebasing asap when security updates happen
<tarpman> others have their own workflows :)
<dobey> tarpman: .0 makes it newer than current version, ~foo makes it older than next version
<dobey> so if a security update comes, that will get preferred, if it's not pinned or such
<micahg> well, technically, ~ makes it less than whatever is before it, so in this case, the .0
<dobey> micahg: well right, but the .0 is in case the next version becomes N.1 or such, rather than N+1
<dobey> ie, the same reason ubuntu packages often are 0ubuntu1 when they are newer than what's in debian
<micahg> right, so, technically, .0 is superseding the current version and making it lower than the next :), the ~foo part is commonly used for distro versioning (i.e. ~ubuntu15.04)
<micahg> or for branding...~avahipatch15.04
<_habnabit> another versioning question: if the avahi in 14.04 is 0.6.31-4ubuntu1, and there was a security fix released, what would the version used be? 0.6.31-4ubuntu3 is the version that's in 14.10, so presumably you can't reuse that version
<micahg> 0.6.31-4ubuntu1.1
<_habnabit> ah okay
<_habnabit> that makes sense then
<tarpman> i've also seen some done with the release version, e.g. ubuntuN.14.04.1
<micahg> that would be for a new upstream
<tarpman> ah, ok
<micahg> you can see examples here: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<sheap> Is there a reason as to why the Release file for the ddeb precise-security on http://ddebs.ubuntu.com/ is broken?
<sarnold> sheap: broken in what way? it validates against the Releases.gpg file..
<sheap> sarnold: there's no architecture or component list
<sheap> it also hasnt been updated since august 2014
<sarnold> sheap: aha, I see. I don't know enough about ddebs to know if those shuold be present or not.
<sarnold> .. trusty-security has them though. I wonder why precise-security doesn't.
<sheap> sarnold: does it?
<sheap> I see that same issue on all the security repos...
<sarnold> sheap: sigh, no, yhou're right, I was still looking at the archive.ubuntu.com rather than ddebs. can't rad.
<sarnold> read either.
<sheap> yea none of those security repos have been updated, very curious
<bschaefer> does ubuntu sync from debain experimental?
<hallyn> oh no, my cgmanager fix wasn't quite right...
<ari-tczew> bschaefer: nope. only on sync request
<bschaefer> ari-tczew, thanks!
<ari-tczew> (automatically - no)
<hallyn> anyone here know how to tell system to not to create a slice for a daemon?
<sarnold> hmm, no pitti online; who else should get poked when the apport retracers seem missing?
<hallyn> (hm, i guess my last commit was ok, just untidy)
 * hallyn bbl
#ubuntu-devel 2015-03-24
<sheap> how would I file a bug against one of the servers/services/mirrors that ubuntu provides?
<sarnold> sheap: iirc ddebs is pitti's area of expertise but I haven't seen him around  lately; maybe a mail to ubuntu-devel?
<sheap> sarnold: ah okay, thanks for your help :)
<micahg> are you sure it's an ubuntu mirror?
<micahg> hrm, I meant one operated by Canonical
<sarnold> micahg: it's an oddity with ddebs.ubuntu.com Releases file
<micahg> ah
<infinity> hallyn: I do like "reassuring flow".
<infinity> hallyn: Also, congrats on being the last pre-freeze upload.
* infinity changed the topic of #ubuntu-devel to: Archive: Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<hallyn> infinity: \o/  do i get a prize?
<hallyn> i'm not happy about it :(
<infinity> hallyn: Your prize is a sense of emptiness and loss.
<hallyn> it makes no sense.  one uptodate laptop, one uptodate vm.  unpriv vivid containers on one get services in custom cgroups;  on the other ,not.
<hallyn> infinity: np, i water that down iwth some johnny walker black
<elfy> just installed with the beta2 for us - works great if you've got US keyboard - no keyboard layout page, not had time to look at anyone else's images - bug 1435714
<ubottu> bug 1435714 in ubiquity (Ubuntu) "Keyboard layout missing during install setup" [Undecided,New] https://launchpad.net/bugs/1435714
<dholbach> good morning
<ogra_> didrocks, you broke ubuntustudio it seems, is there a -meta change missing ?
<ogra_> (imae builds that is)
<ogra_> *image
<didrocks> ogra_: oh, can be, are they still using upstart?
<ogra_> might be, it fails with an upstart dep problem
<didrocks> ogra_: do you have a link? I'm going to give a look
<ogra_> The following packages have unmet dependencies:
<ogra_>  upstart-bin : Depends: upstart but it is not going to be installed
<ogra_> E: Unable to correct problems, you have held broken packages.
<ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntustudio
<ogra_> oh, meh
<didrocks> ogra_: btw, I was wondering, those links are reachable by anything? I always have to look at my legs
<didrocks> logs*
<ogra_> ignore me, seems it built
<didrocks> ogra_: :p
<ogra_> dont look at your legs :)
<ogra_> thats bad for your neck
<didrocks> ogra_: yeah, I try to preserve them :)
<ogra_> ah, wait
<ogra_> amd64 built, i386 still fails
<didrocks> yeah, they are using systemd-sysv though, so the change should be a noop
 * didrocks looks
<ogra_> different error
<ogra_> ignore it
<ogra_> upstart wise all seems fine there
<didrocks> ogra_: right, seems only archive not reachable
<ogra_> infinity, seems all flavours fail in "P: Deconfiguring file /etc/apt/sources.list"
<didrocks> so, I didn't broke them :)
<ogra_> didrocks, you did ... but only the builds before :)
<didrocks> ogra_: just on my question about the links, do you know anywhere in the launchpad interface to reach them?
<ogra_> you mean the build logs ?
<didrocks> ogra_: well, it built during the transition, so yeah :p
<didrocks> ogra_: yep
<didrocks> ogra_: was to expect for anything which built before systemd migrates to the release pocket
<ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/<dist>/<suite>/<flavour>
<didrocks> ogra_: yeah, so just knowing the patternâ¦ that was my guess, thanks!
<ogra_> not sure if you can access older ones than the handfull that is shown there (i doubt we throw them away, but have no idea how to access them)
<didrocks> ogra_: that was my wondering, I think I'll do some pattern storage in my browser, thanks!
<ogra_> well, i'm sure cjwatson coulld tell you if/where they are kept
<ogra_> (they might probably even be accessible via lp-lib, who knows :) )
<didrocks> can be ;)
<cjwatson> ogra_: no UI for them but you can indeed use the fairly obvious interfaces in launchpadlib
<ogra_> :)
<cjwatson> start from https://launchpad.net/+apidoc/devel.html#livefses
<cjwatson> ogra_,didrocks: alternatively, a quick non-LP way is to navigate through the image build logs in http://people.canonical.com/~ubuntu-archive/cd-build-logs/
<ogra_> oh, we still keep that ?
<cjwatson> every one of those that dispatched a livefs build includes a link to the LiveFSBuild object in LP at the top of the log
<cjwatson> of course
<didrocks> cjwatson: yeah, I was using that previously, but it's really not as handy as the launchpad logs
<didrocks> didn't notice the link though, thanks for the tip cjwatson :)
<cjwatson> didrocks: yeah, at some point I might add proper batch navigation with next/previous etc. in there.  feel free to file a bug against Launchpad itself as a reminder
<ogra_> didrocks, was your goal to remove upstart from the images ? that definitely failed on touch ... http://people.canonical.com/~ogra/touch-image-stats/146.changes
<ogra_> it only added upstart-sysv
<ogra_> (your seed change kind of indicates you wanted to remove it)
<cjwatson> ogra_: upstart-sysv Pre-Depends: upstart
<ogra_> oh, fine then
<didrocks> ogra_: upstart is now "upstart + upstart-bin - upstart-sysv"
<didrocks> (and now upstart-bin is empty)
<didrocks> cjwatson: bug #1435742 FYI
<ubottu> bug 1435742 in Launchpad itself "Add some livefs build batch navigation" [Undecided,New] https://launchpad.net/bugs/1435742
<cjwatson> ta
<didrocks> thank you :)
<flexiondotorg> Now that the repo is frozen, do I need to do anything differently regarding Debian syncs that fix bugs?
<flexiondotorg> Normally, I just subscribe the ubuntu-sponsors, but should I be subscribing ubuntu-release now as well?
<Riddell> Noskcaj: how did you get on with git-glib?
<cjwatson> flexiondotorg: No, ubuntu-release are notified in other ways
<cjwatson> (after the sync happens)
<flexiondotorg> cjwatson, Thanks.
<cjwatson> flexiondotorg: You only need to subscribe ubuntu-release if you feel you need to get an up-front exception, e.g. for a feature change
<flexiondotorg> cjwatson, Understood.
<flexiondotorg> cjwatson, I would appear Ubuntu MATE does not have image builds queued for Beta 2 :(
<flexiondotorg> cjwatson, How can I get Ubuntu MATE added to Beta 2?
<ogra_> flexiondotorg, there was a mail on the release ML
<flexiondotorg> ogra_, Still new to this. Not on that ML. Subscribing now.
<ogra_> oh, heh ... seems that was a typoed Beta1 call :P
<flexiondotorg> ogra_, Is there anything that can be done to include Ubuntu MATE in Beta2?
<cjwatson> flexiondotorg: => infinity
<flexiondotorg> cjwatson, Thanks.
<ogra_> i'm not sure how the process is, usually someone sends a call for participation to the ML
<flexiondotorg> ogra_, OK. Last time I was invited via IRC>
<ogra_> and the flavoour release managers answer if they want to take part ... doesnt seem to be the case this time
<ogra_> so yeah, infinity is your best bet
<flexiondotorg> ogra_, What time zone is infinity in?
<cjwatson> oh, your last batch of image builds failed
<cjwatson> that would be why
<cjwatson> looks like a transient network issue
<flexiondotorg> cjwatson, Oh.
<ogra_> cjwatson, yeah, with a weird connection error when deconfiguring sources.list
<ogra_> i pinged infinity above already
<ogra_> flexiondotorg, he is in canada
<ogra_> but in his case that means nothing
<flexiondotorg> ogra_, ;)
<ogra_> infinity is in an infinite TZ :)
<cjwatson> I've just kicked a rebuild
<flexiondotorg> cjwatson, Thanks.
<flexiondotorg> cjwatson, Will the rebuild be sufficient to enter Ubuntu MATE into Beta 2 or will I still need to follow up with infinity?
<cjwatson> flexiondotorg: I don't recall.  You'll find out from iso.qa.ubuntu.com in a bit.
 * flexiondotorg nods
<flexiondotorg> cjwatson, Ubuntu MATE 20150324.1 has landed in Beta 2 :)
<cjwatson> cool
<flexiondotorg> cjwatson, Can you tell me if the PowerPC image is on its way?
<cjwatson> you could look yourself in the build logs
<cjwatson> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-mate/vivid/
<cjwatson> looks like it built fine, so presumably beta 2 isn't configured to include it but it's there as a daily build
<cjwatson> any changes to that would be an infinity question
<flexiondotorg> cjwatson, Thanks.
<asac> cjwatson: who would be good to get https://code.launchpad.net/~snappy-dev/livecd-rootfs/core_update/+merge/250245 reviewed?
<cjwatson> asac: slangasek should be able to assign somebody
<asac> cjwatson: he is out the whole week
<asac> who has enough know how to do first round?
<cjwatson> asac: ah, well he delegated mvo for foundations matters
<cjwatson> asac: so try him
<asac> mvo: ^^ can you find someone ?
<LocutusOfBorg1> hi developers!
<mvo> asac: sure
<melodie> hello
<melodie> I have been browsing the web and asking on help chans, no one knows about the information I'm seeking, so I thought some devs should know? Can someone tell me how the installer manages to install grub-efi on a machine using efi/uefi on gpt, whereas only grub-pci is in the iso? I checked here: http://cdimage.ubuntu.com/ubuntu/releases/14.04.2/release/ubuntu-14.04.2-desktop-amd64+mac.manifest
<melodie> and of course it's the same in the community derivatives
<cjwatson> melodie: It's in the pool, not in the squashfs; manifest only lists the latter.  See .list
<melodie> hi cjwatson
<cjwatson> The pool has various packages as .debs that don't make sense in the squashfs but need to be available for optional or opportunistic installation.
<cjwatson> Arguably grub-pc shouldn't be in the squashfs either, but there's probably some reason it's tedious to avoid.
<melodie> is that why the command "apt-cache policy grub-efi" doesn't show it as installed?
<cjwatson> It won't show it as installed if you're looking in a live session, no.
<melodie> I mean in the live
<melodie> ok
<cjwatson> That's expected and normal.
<cjwatson> Though I also wouldn't expect literally "grub-efi" to be installed, since that's a transitional package.
<melodie> where in the iso is the pool? Is it even there?
<cjwatson> It's carefully hidden in the top-level directory named "pool"
<melodie> that would be grub-efi-amd64 or so perhaps?
<cjwatson> Just to make it hard for you to find
<cjwatson> It would be grub-efi-amd64, yes
<melodie> ok
<melodie> one more that none knew, if you don't mind. Do Windows updates risk to damage the Grub installed bootloader later, making the access to Ubuntu impossible? (my user isn't a tech person)
<cjwatson> I'm very much not a Windows expert.  My understanding is that that is not normally a problem, though.
<melodie> ok :)
<cjwatson> Some Windows applications fiddle about with the boot area in nasty ways, but GRUB takes countermeasures to protect itself from that.
<melodie> oh? !
<cjwatson> It has built-in error correction code so that it can survive a small number of its own sectors being overwritten.
<melodie> are there official docs about the actual state of dual-boot with Windows 8/8.1?
<cjwatson> Of course not if another full-blown boot loader is installed over the top.
<cjwatson> No idea.
<melodie> alright, thank you.
<melodie> cjwatson is there a way to make a custom version having the same properties as an official one? ie: creating a meta package including custom theme and configuration files, then installing that meta package on a minimal ubuntu version? (mini iso or else?)
<cjwatson> melodie: Sorry, I don't know
<melodie> ok
<doko> Riddell, you updated libgit2 without caring about libgit2-glib: https://launchpad.net/ubuntu/+source/libgit2-glib/0.0.22-1build2
<Riddell> mm yes, on my todo list
<Riddell> Noskcaj: did you get anywhere with that?
<cjwatson> 13:17 -queuebot:#ubuntu-release- Unapproved: libgit2-glib (vivid-proposed/universe) [0.0.22-1build1 => 0.0.22-1build2] (no packageset)
<cjwatson> 13:17 -queuebot:#ubuntu-release- Unapproved: accepted libgit2-glib [source] (vivid-proposed) [0.0.22-1build2]
<cjwatson> Ah, that was doko's attempted and failed rebuild
<doko> yeah, didn't check before upload
<infinity> ogra_: When you said "all flavours failed", you were exaggerating, I guess?
<infinity> ogra_: I certainly see a lot of images on the ISO tracker.
<infinity> Though, certainly not as many as should be there. :/
<ogra_> infinity, nope, i wasnt... i had one mail per flavour in my inbox
<ogra_> except for touch ... which uses ports.u.c
<infinity> Tempted to just respin the world instead of sorting out what failed and what didn't.
<ogra_> i think colin did that already
<infinity> ogra_: Most of the images there are from my run, not his.
<ogra_> ah, k
<ogra_> yeah, he probably only meant MATE
<infinity> Hence my exaggeration comment.
<flexiondotorg> infinity, I think Xubuntu are missing i386.
<doko> seb128, please could desktop have a look at http://people.canonical.com/~ubuntu-archive/component-mismatches.txt and maybe seed things where needed?
<doko> Mirv, tjaalton, mlankhorst: ^^^ same please
<seb128> doko, sorry, busy with other things today but I can try tomorrow, but if somebody else has slots to work on that please do
<didrocks> doko: 5 entries are due to indicator-applet/gnome-panel wanted to be pulled in main, but it's a false positive. seb128 pointed me at http://irclogs.ubuntu.com/2014/10/07/%23ubuntu-devel.html#t16:18 (seems you already discussed this case)
<seb128> https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/1367719
<ubottu> Launchpad bug 1367719 in germinate (Ubuntu) "germinate (maybe?) fails to detect a closed loop on a package currently being processed" [Undecided,New]
<seb128> that was the bug mentioned when we had the discussion previous cycle
<cjwatson> infinity: I only did anything about MATE FWIW
<cjwatson> seb128: Oh, that turned out to be something altogether different and more confusing
<cjwatson> seb128: And guess who didn't write it down in the bug
<infinity> cjwatson: Yeah, the dates implied as much.
<seb128> cjwatson, I see, time to do that then? ;-)
 * cjwatson finds the remaining bit of IRC log
<seb128> cjwatson, the issue didn't get fixed though? because it seems it's being discussed again/still problematic on component-mismatch
<cjwatson> It didn't get fixed, no.  I've updated the bug
<seb128> thanks
<infinity> didrocks: *poke*
<didrocks> infinity: hey
<melodie> cjwatson after finishing the install, grub-efi does not seem installed, it still boots directly to Windows without any choice. (just for your information, don't know yet if I'll put a bug report)
<infinity> didrocks: Check out that email I bounced you from pitti.
<cjwatson> melodie: OK, well I'm sorry about that, but I'm not working on this stuff at the moment
<infinity> didrocks: Can you evaluate if that commit he's alluding to is a dire enough bugfix that we want it in the beta?
<cjwatson> melodie: so I guess file a bug if you think something is broken
<didrocks> infinity: sure looking and back to you in few minutes
<melodie> cjwatson I have to check if it is a bug or if some tweaks are known to have to be done manually (such as copying some files, removing other filesâ¦) who would be an expert in the matter?
<cjwatson> melodie: Try giving details in #ubuntu-installer once you're reasonably sure it's not your bug
<melodie> thanks cjwatson I am going there right away (yes I'm sure I didn't produce the bug)
<tjaalton> doko: mesa/xserver changes look fine there
<doko> tjaalton, so demote the rest?
<tjaalton> doko: the rest? libegl1-mesa-drivers is a dummy package so that's fine, xserver-xephyr was in main due to remmina which I don't care about. the other binaries from these source pkgs of course need to stay in main :)
<didrocks> infinity: the patches (there are 2: one from Lennart and a fix later from Martin) are quite instrusive, but I think it worthes a try, backporting them
<mlankhorst> doko: not sure if anything needs xephyr..
<didrocks> infinity: do you have a bug reference handy?
<infinity> didrocks: Nope, it was just something pitti mentioned in passing.
<didrocks> ok
<infinity> didrocks: You already know more about it than I do. ;)
<didrocks> (I feel I should add "sadly" :p)
<infinity> Heh.
<didrocks> infinity: ok, currently building (a good 20 minutes), will then install, do a couple of reboots and traditional tests. Keeping you posted
<infinity> didrocks: Kay.  Would be nice if we could reproduce the thing it's meant to be fixing and test that it's fixed.
<infinity> didrocks: But if not, whatever.  WCPGW, right?
<didrocks> infinity: yeah, it's a race unfortunately where the mount point is available before the device nodeâ¦
<didrocks> infinity: it's only the init system, minor :p
<bdmurray> xnox: Is there a way to stop an upstart user job temporarily?
<lamont> dear thermald, must you log every 4 seconds?
<Cimi> Ursinha, hi, would be possible to trigger the build of https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/1390136.laggy-backends/+merge/252754 ?
<Ursinha> Cimi: I just triggered a rebuild, not sure why that was there waiting for 23 hours? I'd have to have a look
<Ursinha> Cimi: it's also more effective if you ping cihelp on #ubuntu-ci-eng with such requests :)
<Cimi> Ursinha, ok, thanks :)
<doko> roaksoax, jamespage: please could you subscribe to the python-bcrypt bug reports? b-d of python-django (https://bugs.launchpad.net/ubuntu/+source/python-bcrypt/+bug/1427861)
<ubottu> Launchpad bug 1427861 in python-bcrypt (Ubuntu) "[MIR] python-bcrypt (b-d of python-django)" [Undecided,In progress]
<jamespage> doko, ack
<jamespage> done
<didrocks> infinity: ok, seems that at least I didn't trigger new bugs with this systemd version: various vms tested under qemu, and my own system
<didrocks> infinity: my partitions (even those with ecryptfs) are still mounted, I can play with an usb key and get it automounted/shut downâ¦
<doko> thansk
<didrocks> and tmpfs on /tmp is ok as well
<didrocks> I wonder if that would fix a known bug I saw, one sec
<tyhicks> thanks jamespage :)
<didrocks> well, no, at least, it didn't regress it
<didrocks> infinity: 219-4ubuntu10 uploaded
<infinity> didrocks: Kay.  If/when we get a serious keyboard bug sorted out that affects $world, I'll let it into the next build.
<didrocks> infinity: sure, poke me if you notice/heard of anything
<seb128> infinity, hey, ogra_ claims that the new glibc requires other things to rebuild to stop crashing, is that true? that sounds wrong, for sure if that's the case it means there is some abi change and we should fix that rather than paper over with rebuilds?
<seb128> ogra_, ^ moving discussion here
<infinity> seb128: That seems entirely untrue, what is this claim based on?
<ogra_> <seb128> ogra, did anyone mention that to infinity?
<ogra_> <ogra> i think rsalveti|lunch is still investigating
<ogra_> <ogra> we know that pulse broke the same time libc landed ...
<ogra_> <ogra> buut we dont have actual evidence it is libc's fault yet
<ogra_> just for the context :)
<seb128> <ogra> charles, yeah, likely needs a rebuild for latest libc ...
<infinity> ogra_: On armhf, or all arches?  Define "broke".  Is there any interesting debugging info?
<seb128> to give some more context
<ogra_> infinity, as i said, jhodapp and rsalveti are investigating
<seb128> infinity, http://pastebin.ubuntu.com/10670042/ was mentioned in the discussion
<ogra_> infinity, i dont think we have any way to test audio on non armhf (the x86 emulator doesnt provide any audio)
<infinity> Not seeing a ton of evidence there that glibc is at fault, but happy to be involved when people have more info.
<seb128> rsalveti, ^
<ogra_> right, it just started happening the same time libc landed
<infinity> ogra_: Was that an image upgraded in-place from 2.19 to 2.21, or a fresh build with 2.21?
<ogra_> infinity, how do you mean "fresh build" ? every image is a fresh build, we dont support dist-upgrade
<ogra_> (or apt)
<ogra_> sadly it started happening while the importer was disabled ... usually you only have like ten packages changing between two images ... the libc landing came in with a rather big chunk due to that http://people.canonical.com/~ogra/touch-image-stats/144.changes
<ogra_> infinity, honestly it could be everything on that above list ... which is why nobody pinged you yet ... but i think davmor2 reported something with media playback in his testing too
<infinity> ogra_: Well, that's what I meant.  Was it a clean image, or an image with an upgraded libc for testing purposes.
<ogra_> ah, no, we all see it on the recent images since 144 came out
<ogra_> 143 works fine
<davmor2> infinity: both, On friday it was latest vivid plus libc from vivid-proposed, Monday it was already in the image and displayed the same breakage
<ogra_> bug 1435867
<ubottu> bug 1435867 in Ubuntu Music App "cannot play next or previous song in music player" [Undecided,New] https://launchpad.net/bugs/1435867
<ogra_> this is the related bug btw
<infinity> davmor2: Oh, that was the media-hub thing I was told about in testing?
<davmor2> infinity: Yeap
<infinity> Right, and the backtrace I got at the time was unreadably useless. :/
<davmor2> infinity: about right :(
<flexiondotorg> cjwatson, Remember that grub-pc issue? - https://bugs.launchpad.net/ubuntu-mate/+bug/1426436
<ubottu> Launchpad bug 1426436 in ubuntu-mate "15.04-Beta-1: Package 'grub-pc' has no installation candidate" [Critical,In progress]
<flexiondotorg> cjwatson, It is still affecting some installs. Trying to gather some feedback about affected systems.
<flexiondotorg> cjwatson, Do you have an insight/ideas you can share with me?
<rsalveti> infinity: ogra_: davmor2: I'm investigating this issue now
<davmor2> rsalveti: you rock \m/
<rsalveti> a lot of things changed in 144, so hard to know for now
<ogra_> right
<rsalveti> ogra_: infinity: yeah, updated just libc, rebooted, and was able to reproduce the problem
<doko> happyaron, is it ok to demote these fcitx packages? fcitx-libs fcitx-libs-gclient fcitx-libs-qt fcitx-module-quickphrase-editor fcitx-qw fcitx-table-all fcitx-table-bingchan fcitx-table-cangjie fcitx-table-dianbaoma fcitx-table-erbi fcitx-table-wanfeng fcitx-table-wbpy fcitx-table-wubi fcitx-table-ziranma fcitx-tools
<infinity> flexiondotorg: Looks like your ship-live seed isn't quite working as expected.
<flexiondotorg> infinity, Any ideas as to what I can change?
<infinity> flexiondotorg: Not sure, poking at it in a sec.
<cjwatson> flexiondotorg: Sorry, I'm unlikely to be able to help
<infinity> flexiondotorg: Also, why did you remove oem-config-slideshow entirely?
<flexiondotorg> cjwatson, OK.
<flexiondotorg> infinity, Because OEM config does work with no slideshow present.
<infinity> flexiondotorg: Ahh, and no data's better than the generic data?  Fair enough.
<Quintasan> mvo: Is it possible to backport fix for debian #778375 to trusty?
<ubottu> Debian bug 778375 in apt-transport-https "apt-transport-https: segfaults" [Serious,Fixed] http://bugs.debian.org/778375
<flexiondotorg> infinity, There is an OEM going to be using this and they prefer just the progress bars rather than Ubuntu slides in Ubuntu MATE.
<flexiondotorg> infinity, So looking at this - http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-mate.vivid/ship-live
<flexiondotorg> infinity, No grub stuff mentioned at all.
<infinity> flexiondotorg: Yeah, I know.  I'm trying to wrap my head around it.
<flexiondotorg> infinity, Thank you!
<mvo> Quintasan: yes, will you help with the SRU paperwork :) ? is there a bug for this already in ubuntu?
<Quintasan> My SRU skills are a little bit rusty but yeah.
<mvo> Quintasan: I head out for dinner now, but happy to do that
<mvo> Quintasan: lets talk later/tomorrow, I'm european timezone
<Quintasan> utc+1 here
<flexiondotorg> infinity, All the flavours seems to have sip-live that doesn't include grub - http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.vivid/ship-live
<infinity> flexiondotorg: No one else seeds it explicitly in ship-live, they inherit it from boot.
<flexiondotorg> infinity, Ah, OK.
<infinity> Although, I don't see grub-pc in /pool/ for a lot of people.
<infinity> Very confusing.
<infinity> This has been true going back to trusty, though, so maybe we always expected to get it over the network.
<infinity> Or this has been buggy forever, and no one noticed.
<infinity> Oh, or grub-pc is in the livefs for others...
<cjwatson> Pretty sure it's there due to kernel dependencies or something
<cjwatson> Yeah, via boot
<infinity> Yeah, so it's in the livefs for everyone but mate.
<flexiondotorg> infinity, Feedback I've had from the Ubuntu mATE community is this has been an issue for sometime.
<infinity> Curious.
<flexiondotorg> Is the order in STRUCTURE important? For example - ship: boot desktop installer d-i-requirements
<infinity> ship isn't relevant.
<flexiondotorg> I'm just using ship as an example.
<infinity> Oh.
<cjwatson> The top-to-bottom order in STRUCTURE is important.  In some corner cases, the left-to-right order within a single line can matter if things are non-deterministic anyway and so germinate ends up picking a different random package to satisfy a Provides or similar, but it normally doesn't matter.
<infinity> I bet it's because you do the --no-install-recommends thing.
<infinity> Yup.
<flexiondotorg> infinity, Yeah, I did wonder. Sadly, I have to.
<infinity> linux-image Recommends grub.
<cjwatson> flexiondotorg: uh, didn't I explain this to you weeks ago?
<cjwatson> I distinctly remember the conversation, and I have grub-pc added to ubuntu-mate.vivid/ship-live in my local checkout
<infinity> Which means lubuntu probably has this bug too, or they've worked around it elsewhere.
<flexiondotorg> cjwatson, Yes. And I started submitting patching to the packages that I could avoid this.
<cjwatson> which I was only likely to do if pastebinning it to you
<cjwatson> but the kernel clearly can't change its Recommends
<flexiondotorg> cjwatson, I did add grub-pc to ship-live as you suggested.
<Quintasan> mvo: bug #1435984
<ubottu> bug 1435984 in apt (Ubuntu) "SRU: apt-transport-https segfaults when downloading from SBT repository" [Undecided,New] https://launchpad.net/bugs/1435984
<infinity> cjwatson: So, the ship-live addition seems to fail curiously, as in it's not there on the images.
<cjwatson> oh, I see
<infinity> cjwatson: But really, it should just be in the livefs, like it is for everyone who gets it for free via recommends.
<cjwatson> probably because it inherits from something else and so germinate thinks it already has it
<infinity> cjwatson: Yes, likely that.
<cjwatson> indeed, ship-live inherits from boot
 * infinity nods.
<cjwatson> which is aaaaaaaaarguably incorrect but maybe not worth rocking the boat on
<cjwatson> so yeah, add grub-pc to live
<flexiondotorg> cjwatson, Wilco.
<cjwatson> preferably with a comment explaining that this is due to --no-install-recommends
<flexiondotorg> cjwatson, infinity Just grub-pc?
<flexiondotorg> cjwatson, Understood.
<cjwatson> grub-pc is the only one in this particular maze of twisty passages
<cjwatson> but we'll see
<cjwatson> sorry I didn't understand properly earlier
<infinity> Huh.  lubuntu has grub-pc in their livefs.  I wonder how.
<infinity> Dumb luck, I guess.
<flexiondotorg> cjwatson, infinity Many thanks for helping me with this.
<flexiondotorg> I'll push updated seeds in a sec.
<flexiondotorg> And rebuild.
<cjwatson> Lubuntu doesn't have Feature: no-follow-recommends in its live seed
<cjwatson> So it gets the Recommends of ubiquity
<infinity> cjwatson: Ahh, it's only in some other bits, I guess.  And in livecd-rootfs.
<cjwatson> I'd recommend that ubuntu-mate do the same if it doesn't break things
<cjwatson> But there may be some reason it isn't practical right now
<flexiondotorg> cjwatson, Sadly, I need no-follow-recommends in the live seed.
<cjwatson> So in that case, it may in fact be worth checking through the Recommends of ubiquity
<cjwatson> Recommends: grub-pc | grub | grub-efi, dmraid, btrfs-tools, ubuntu-drivers-common, lvm2
<infinity> Changing anything two days before a milestone is probably not practical, but it really should be cleaned up.
<flexiondotorg> cjwatson, Without it the indicator-* stuff pull in pretty much all of Unity.
<cjwatson> You're adding grub-pc, you already have dmraid, so perhaps you should add btrfs-tools, ubuntu-drivers-common, lvm2
<infinity> flexiondotorg: There are ways to fix that, but yeah, not today.
<flexiondotorg> infinity, I have been submitting patch to indicator-* to add MATE support so I don't have to no-follow.
<flexiondotorg> infinity, But for some that patching is not trivial.
<flexiondotorg> cjwatson, Thanks for the tips on other packages.
<flexiondotorg> I'll check those now.
<flexiondotorg> cjwatson, How does this look to you? http://bazaar.launchpad.net/~ubuntu-mate-dev/ubuntu-seeds/ubuntu-mate.vivid/view/head:/live
<cjwatson> flexiondotorg: seems fine
<cjwatson> (though you don't need "#" to introduce a comment in seeds; it just has to not begin with " * ")
<flexiondotorg> cjwatson, Thanks for looking and think for helping.
<flexiondotorg> cjwatson, I know I don't need # for comments, but old habits... ;)
<flexiondotorg> *thanks for helping
<Jeremy26> Hi.  Which #irc chan is the right place to deal with GRUB2+UEFI installer failures for PRE-release Vivid?  Afaict, there's breakage -- and I'm trying to help get this addressed befor the release.
<dz0ny> hi
<doko> infinity, would you accept gccgo-5 during the freeze? changes to libgo only
<infinity> doko: I'd have to respin for libgcc1, so ideally not.
<infinity> doko: But go ahead and upload, I can block in proposed and let it through if there's a reason for another respin.
<doko> ok
<doko> infinity, uploaded, and gmp is waiting too, correcting a recommends to keep gcc-4.8 quiet in universe
<infinity> doko: Ta.  I assume gccgo-5 needs sagari to build happily?
<doko> yes, testsuite is on
<infinity> doko: Alright, I'll let it in when that kernel build is done, then.
<infinity> I guess I could give armhf a head start and cancel the ppc build.
 * infinity does that.
<rsalveti> infinity: so the media-hub issue is actually an issue between gstreamer and pulse
<rsalveti> infinity: it fails to seek/pause, causing either a crash (fails to lock a mutex) or a cond_wait that stays forever
<rsalveti> which, for whatever reason, only happens with the new libc
<infinity> rsalveti: Possibly due to (ironically) bugfixes in threading on ARM? :P
<rsalveti> infinity: that would be my guess as well
<rsalveti> works fine with x86
<infinity> rsalveti: Trawling git commits between 2.19 and 2.21 show a fair number of fixes from Will Newton along those lines, but nothing looks obviously wrong to me.
<infinity> rsalveti: If one could construct a small test case that would let us pass blame one direction or the other, that would be nice.
<rsalveti> yup, that's what I'm trying to do
#ubuntu-devel 2015-03-25
<rsalveti> infinity: opened bug 1436162 to track the issue, still investigating though
<ubottu> bug 1436162 in pulseaudio (Ubuntu) "[pulsesink] abort at pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:118, function pa_mutex_unlock() with libc 2.21" [Undecided,Confirmed] https://launchpad.net/bugs/1436162
<rsalveti> infinity: is there any sane way to bisect glibc?
<hallyn> slangasek: hi, i'm out the next two days, but if you have time would you mind looking at / sponsoring http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.36-3.dsc into sid
<happyaron> doko_: some of them, definitely not all
<dholbach> good morning
<doko> happyaron, you need to seed these, or depend on these, or recommend these
<infinity> rsalveti: The upstream project, sure, the package, slightly less so...
<svenx> GunnarHj: ref langpack-locales; i'm trying to get my autoinstaller (FAI) to set up locales for both debian and ubuntu. debian's 'locales' package has its debconf locales/locales_to_be_generated multiselect. there doesn't seem to be anything similar for langpack-locales. say, when i need en_US.utf-8 and pl_PL.utf-8 on a system
<svenx> GunnarHj: are there alternatives to debconf for this sort of config?
<infinity> svenx: The traditional Ubuntu way to get en and pl locales is to install language-pack-{en,pl}
<infinity> svenx: I do plan to bring the Ubuntu and Debian locale packaging a bit closer together, so it's less surprising moving between them, but that's generally the expected "normal" way to to do it in Ubuntu.
<svenx> infinity: hm, okay. that's fair. i had hoped to avoid the 16 additional en_* locales, but it's not a big deal :)
<svenx> i'll just install those packages for now
<infinity> svenx: The other option is just a late_cmd to "locale-gen pl en" (or a subset)
<infinity> svenx: "locale-gen en_US.UTF-8 pl_PL.UTF-8" would get you exactly what you want, for instance.
<svenx> infinity: ahh, that's perfect. i had constructed a wrong locale-gen command, apparently. so it didn't work
<svenx> this works much better
<infinity> svenx: That said, if the machine intends to have users who use things locally, you kinda want langpacks to go with the locales anyway.
<svenx> infinity: agreed
<infinity> svenx: If this is a server that just needs the locales to be able to serve web content happily, then that's less interesting, I agree.
<svenx> that's the case here. it's just a few admins with different workstation locales, so it's nice to avoid the warnings
<infinity> svenx: Ahh, yeah.  I find Debian's "locales-all" package is the easiest way to avoid that pain, and I intend to make locales-all work in Ubuntu too, it just keeps taking a back seat to fixing actual bugs. :P
<infinity> rsalveti: The core from the crash might be nice.
<infinity> rsalveti: Lemme see if I can reproduce on shedir.
<GunnarHj> svenx: Saw you got help. I was about to suggest
<GunnarHj> sudo locale-gen en_US.UTF-8 pl_PL.UTF-8
<GunnarHj> too.
<svenx> GunnarHj: yep, it works nicely
<Riddell> no sweetshark this week?
<mdeslaur> Riddell: he's in #ubuntu-desktop if you're looking for him
<strikov> jodh: hi James! rbasak told me that you may have some clue on the current state of upstart in vivid; i'm trying to install upstart to run some tests which were not ported to systemd yet; while upstart package installs w/o any issue i get 'Name "com.ubuntu.Upstart" does not exist' while trying to use upstart; should this work or it's completely broken now? Thanks
<rbasak> strikov: are you rebooting into upstart after installing it? Or is systemd will in use there?
<strikov> rbasak: few weeks ago upstart package removed systemd but now it doesn't; that might be the issue
<strikov> rbasak: what do you mean by 'rebooting into upstart'; any cmd line changes? it worked just from the box few weeks ago
<rbasak> strikov: I'm not sure exactly, but I'd expect things not to work unless upstart is actually your system init
<rbasak> Is it possible that you're still using systemd?
<rbasak> Maybe try /sbin/init --version to see
<rbasak> (systemd gives an error; upstart reports itself)
<strikov> rbasak: error, it looks like i need to manually remove systemd; hope i won't break the instance :)
<didrocks> strikov: if you want to boot with upstart, you need now to install upstart-sysv
<strikov> didrocks: thanks, trying
<didrocks> (to boot it by default, note that you have a grub entry anyway to boot it if needed while keeping systemd as the default)
<infinity> strikov: If your goal is replacing the system init, you want "upstart-sysv", we shuffled the packages around a bit.
<infinity> strikov: Oh, didrocks said that. :P
<strikov> I see. So 'upstart' package adds grub entry and upstart-sysv does complete switch. Is it right?
<strikov> didrocks: infinity: thanks!
<infinity> strikov: "upstart" does the same thing "systemd" is.  That is, installs a non-conflicting init system that doesn't take over all the conflicting binaries like /sbin/init
<didrocks> strikov: yeah, upstart contains the binaries, upstart-sysv do what is necessary to set upstart as default
<dz0ny> fyi recovery mode(boot option) also expects upstart but is run with systemd. Enabling network then fails
<dz0ny> also per spec if some critical unit fails to start it should put itself to systemd recovery/emergency target
<dz0ny> but does not
 * dz0ny had problems recovering from bad dkms build
<didrocks> dz0ny: interesting, the fallback to emergency mode definitively work (can tell you that with messing a lot with system units), but I guess we never played with the recovery entry mode, mind filing a bug?
<dz0ny> didrocks: sure just tell me where :)?
<dz0ny> i mean to which package should i attach bug
<didrocks> dz0ny: I would say systemd first, adding the systemd-boot tag please
<rsalveti> infinity: found the issue
<rsalveti> infinity: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good1.0/+bug/1436162/comments/6
<ubottu> Launchpad bug 1436162 in pulseaudio (Ubuntu) "[pulsesink] abort at pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:118, function pa_mutex_unlock() with libc 2.21" [Undecided,Confirmed]
<rsalveti> infinity: we're basically disabling futex_atomic_cmpxchg_inatomic with latest glibc
<rsalveti> because it gets built with an older kernel header
<rsalveti> as a consequence, it can't really guarantee that more than one pcond_wait will result in the correct mutext count, when it gets a broadcast signal
<rsalveti> checking now the minimal kernel that should, in theory, support futex_atomic_cmpxchg_inatomic for arm already
<infinity> rsalveti: 3.14.3
<rsalveti> infinity: SMP support for futex_atomic_cmpxchg_inatomic was added in 2.6.38, but it requires !CPU_USE_DOMAINS.
<infinity> rsalveti: Right, which means we can't make assumptions.
<rsalveti> the restriction for CPU_USE_DOMAINS was removed in 3.14.3
<infinity> rsalveti: But if we had that on unconditionally before (however incorrectly) and no one complained, we can carry a local patch to return to that state.
<rsalveti> infinity: the problem is that it's always disabled atm
<rsalveti> even if you have a compatible kernel
<infinity> rsalveti: The bigger question becomes, though, why things are breaking with that assumption in play.
<infinity> rsalveti: Not always, I just assume you're testing on ancient Android kernels. :P
<mardy> mvo: hi! Not sure if this is a bug, but if I run dpkg-architecture in an 14.04 armhf chroot, DEB_HOST_ARCH is armhf; if I run the same in a 14.10 chroot, I get amd64
<rsalveti> infinity: always because this is a build time decision
<rsalveti> and we're building with a kernel header that is old enough for the check to disable it completely
<infinity> rsalveti: Oh, indeed.  Sorry.
<infinity> rsalveti: No, we're not building with old kernel headers.
<infinity> rsalveti: But we are building with an old minkver.
<rsalveti> exactly, that is the one used
<rsalveti> the define was  2.6.32
<infinity> Right.
<infinity> But that has nothing to do with headers, just saying.
<rsalveti> sorry, thought it was getting that from the header, but you know better
<infinity> Anyhow, those ASSUME defs are correct.  So, it would be nice to know why things break in that configuration.
<infinity> But if we were incorrectly building with that on before, we can do so again.
<infinity> rsalveti: YOu can tell which headers it was built against by running the libc6 binary.
<rsalveti> got it
<rsalveti> they break probably because pthread_cond_wait depends on atomic operations
<rsalveti> and in this case we had more than one thread waiting on the same condition
<infinity> Oh, no you can't.  Huh.  I wonder who pulled that out.
<infinity> rsalveti: Well, that's the thing.  pthread_cond_wait should have a fallback implementation.
<infinity> rsalveti: But, whatever.  Can hunt that later.  For now, I'll confirm that this is a regression in how we're building and locally patch it.
<rsalveti> but would it be completely safe still even if not using the correct calls?
<rsalveti> right
<infinity> rsalveti: A safe implementation could be written, it would just be slow.  So, the fallback is obviously buggy.
<rsalveti> right
<rsalveti> it's still something we want to use if the kernel supports though
<rsalveti> too bad it's a build time decision
<mvo> mardy: it certainly sounds like one, let me reproduce
<infinity> rsalveti: Making all those branches be runtime decisions would slow down libc a whole lot.
<rsalveti> infinity: right, but sucks from a distro pov
<rsalveti> I know we have other components requiring a newer kernel, not sure what is currently the minimal one to be supported by our release
<infinity> rsalveti: For the most part, building for an older target isn't really a big deal.  We lost one or two syscalls and noone actually cares (and we can run in chroots on older kernels, which is handy).
<infinity> rsalveti: But in this case, yeah.  Ick.  Seems we're damned if we do, damned if we don't right now.
<mardy> mvo: sorry, my mistake: in the 14.10 chroot, I was inside a "maint" command; to get the env right, I need to use the "run" command
<infinity> rsalveti: I'm not happy about reverting this (since it's correct), but less happy about spending the next week trying to fix the fallback to not be broken.
<mvo> mardy: aha, ok. thanks
<mardy> mvo: anyway, could click set the PKG_CONFIG_PATH?
<infinity> rsalveti: Anyhow, I assume fixing this isn't blocking anyone from getting on with life, and I can land it after the beta?
<infinity> rsalveti: (Also, I'd just been looking at those commits, which was why the "3.14.3" response popped off the top of my head so readily, heh)
<infinity> rsalveti: But I couldn't reproduce the issue, so looking at the commit was as far as I'd gotten.
<rsalveti> infinity: this is currently a critical issue for touch, so if could land sooner would be nice
<rsalveti> we basically can't use multimedia at all
<rsalveti> but I know we have the beta restrictions, so not sure
<rsalveti> infinity: when is beta going to be released, tomorrow?
<infinity> rsalveti: I have no urge to respin the beta images just for this, but I can prep it now, block it in -proposed, and let it through if something else forces a respin.
<infinity> rsalveti: Otherwise, yeah, beta should happen tomorrow.
<rsalveti> infinity: cool, sounds like a good plan
<mvo> mardy: how should it be set?
<mardy> mvo: whenever I open a "run" command, I type "export PKG_CONFIG_PATH=/usr/lib/arm-linux-gnueabihf/pkgconfig/:${PKG_CONFIG_PATH}"
<mvo> mardy: ok, I think then that makes sense indeed
<mardy> mvo: otherwise pkg-config only looks in /usr/lib/pkgconfig/, and there isn't much there
<mvo> mardy: does https://bugs.launchpad.net/ubuntu/+source/click/+bug/1436368 look ok?
<ubottu> Launchpad bug 1436368 in click (Ubuntu) "set PKG_CONFIG_PATH" [Undecided,New]
<mardy> mvo: thanks, subscribed
<dobey> mvo, mardy: that seems weird. is that because it's the x86 version of pkg-config command being run i guess?
<mvo> dobey: yes
<dobey> ok yeah, makes sense to set it then, but i think for the cross-chroots we probably want to make sure /usr/lib/x86_64-linux-gnu/pkgconfig isn't in the path as well
<seb128> hum
<seb128> cyphermox, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1435714
<ubottu> Launchpad bug 1435714 in ubiquity (Ubuntu Vivid) "Keyboard layout missing during install setup" [High,In progress]
<infinity> seb128: Is that not fixed?
<seb128> cyphermox, I'm unsure if that's the same issue, but with today's daily ubuntu-desktop amd64, installing in french give a /etc/default/keyboard which has XKBMODEL=""
<cyphermox> seb128: yeah, are you saying it's still happening?
<seb128> same for XKBLAYOUT and VARIANT and OPTIONS
<cyphermox> ok
<seb128> infinity, ^ I guess that means not fixed?
<seb128> or the fr issue is a different one
<infinity> seb128: Or cyphermox just hates the French.
<cyphermox> does it happen with fr only?
<seb128> cyphermox, I don't know, I just did a french install, can try another locale if you wanty
<cyphermox> I don't know
<seb128> let me try a german one
<infinity> seb128: You're positive it was today's daily with that version of ubiquity?
<cyphermox> can you check /usr/lib/ubiquity/console-setup/keyboard-configuration.postinst to see if it's good?
<cyphermox> hopefully I have the right path
<cyphermox> I have desktop-amd64 now, I can check it quick
<seb128> infinity, let me check, I download this morning around 11 european time
<infinity> My ISO will be here some day so I can check...
<seb128> I'm booting it
<seb128> can't check from the iso menu since that machine is uefi and I don't get the nice menu where I can do f1 to get info
<seb128> infinity, cyphermox, no, that iso has ubiquity .16, sorry about that
<seb128> http://cdimage.ubuntu.com/daily-live/current/vivid-desktop-amd64.manifest as well
<seb128> infinity, cyphermox, we didn't get a respin with the new ubiquity?
<infinity> seb128: Hrm, current might not be.
<seb128> seems so
<infinity> seb128: 20150325 has the right version.
<seb128> bah, current is not current :-)
<infinity> Hence why the ISO tracker references by build number, not the current directory.
<cyphermox> it's not right
<seb128> hehe
<seb128> sorry for the noise
<arges> infinity: hey, whats with the new pending-sru.html page? i see autopkgtest failures, how should i be resolving/handling these? if the failure is a test case-problem, is there a way of re-running / etc.
<arges> infinity: not sure if I'll get to much today, but I just dont want to mess things up
<infinity> arges: Right now, we're not gating on any of that, just providing it as extra info.  Use at your discretion, I guess.  I've been perusing some here and there to see if they relate to the package uploaded or appear to just be broken tests, etc.
<arges> infinity: Ok, makes sense to me.
<infinity> arges: I don't think we'll be able to fully gate on autopkgtest for SRUs like we do for devel until we clean up a LOT of tests (and also make the infra less wobbly), so right now, it's just there to help inform your promotion decisions.
<arges> infinity: yea if i see a legit failure, i'll investigate / comment on bug. thanks
<infinity> arges: As for how to retry them, click the internal link instead of the external link, log in, and retry.
<arges> ack
<infinity> arges: Any intersection of core-dev and "can get to that bit of the Canonical network" can retry.
<infinity> arges: Obviously, I'd prefer that second restriction go away, but I think that'll require a move from Jenkins (*spit*) to something sensible.
<arges> yea i understand how fragile jenkins is
<Riddell> bdmurray: could you review bug 1436328 ?
<ubottu> bug 1436328 in apport (Ubuntu) "FFe apport-kde qt5 port" [Undecided,New] https://launchpad.net/bugs/1436328
<bdmurray> Riddell: I don't think I'm in the right team to actually do anything about an FFe.
<bdmurray> Oh, I see your comment now though.
<Riddell> happyaron: fcitx is in ubuntu unity? how come I still see ibus in the seeds for it?  what do I need to do to change kubuntu?
<happyaron> Riddell: it's now default for zh_* locale, still using ibus for others. we're trying it to decide whether we can make it default for everyone in vivid+1
<happyaron> Riddell: so what you want, the same as ubuntu unity, or make it default directly?
<happyaron> doko: perhaps that's not happening in this cycle, they'll be pulled by language-selector in next cycle once fcitx replaces ibus for everybody
<doko> happyaron, ok, demoting
<happyaron> ok
<Riddell> happyaron: um I don't know, I was kindae hoping you'd know!
<happyaron> Riddell: I tend to have fcitx default for everyone in Kubuntu, but let's discuss with GunnarHj, if we want a different setup (fcitx default for everyone) from unity then we need his help
<GunnarHj> happyaron, Riddell: I'm here now. What's up?
<happyaron> GunnarHj: hey, will it be harmful if we add im:${LANG}:fcitx:${pkgs} for non-zh languages?
<happyaron> I think that's what we need to have fcitx default for everyone in Kubuntu (remove ibus from its seed)
<GunnarHj> happyaron: Does Kubuntu want fcitx default for everyone in 15.04?
<happyaron> GunnarHj: we are discussing that, :)
<Riddell> GunnarHj: we want whatever works best but none of us kubuntu people know that
<GunnarHj> happyaron, Riddell: As far as I can tell out of the box, the approach which has been implemented for Chinese is generic, and can be used for any language.
<happyaron> GunnarHj: it's temporary solution for Ubuntu unity, I doubt if we need the process for Kubuntu. Fcitx itself has much better integration with plasma desktop
<happyaron> i.e. kimpanel plasma widget, kcm module
<GunnarHj> happyaron: Would it be necessary to remove ibus from the seed? What about people who upgrade their Kubuntu version and used ibus up to now?
<Riddell> GunnarHj: the seed currently has ibus-qt4 and ibus-qt5 in it, they can be removed easily enough
<happyaron> GunnarHj: yes removing is required, and otherwise nothing will change, like what we did in Ubuntu (don't touch existing installations)
<GunnarHj> happyaron: Since im-config (now) has ibus as default you mean?
<happyaron> yep
<GunnarHj> happyaron: I see. Btw, upgrades won't probably be a problem for those using ibus and want to keep it. Upgrading shouldn't uninstall ibus.
<happyaron> GunnarHj: yes, and we need a l-s change to suggest installations of fcitx packages when needed
<happyaron> AFAIK check-language-support is used in Kubuntu
<GunnarHj> happyaron: Hmm... check-language-support & friends are indeed used in all the flavors. Did you see what I just did in pkg_depends? I'm not sure how to handle different approaches in various flavors...
<happyaron> no didn't see it, it's trapped in queue I guess?
<GunnarHj> happyaron: You can look at the branch (linked from the bug report).
<happyaron> ok I see
<happyaron> GunnarHj: I wonder if it will harm to add lines like im:ja:fcitx:fcitx-anthy
<happyaron> GunnarHj: this means only when fcitx is installed, fcitx-anthy is pulled in.
<happyaron> or this will install fcitx for everyone? (by ubiquity?)
<GunnarHj> happyaron: I don't think it would install fcitx (unless fcitx-anthy depends on it).
<happyaron> GunnarHj: I'm a bit confused, fcitx is seeded in "live", will that make check-language-support returns fcitx packages for all languages specified?
<GunnarHj> happyaron: Personally I tend to think it would be better to treat Japanese just like Chinese. But maybe they aren't ready.
<happyaron> me too, but there's no agreement yet
<GunnarHj> happyaron: Only for Chinese... Not sure what you asked.
<happyaron> GunnarHj: I'm think if it's possible to have fcitx default for everyone for Kubuntu only, and that means check-language-support would need to be able to suggest fcitx packages for other languages
<happyaron> but wonders if that will effectively make fcitx installed for everyone on Ubuntu
<GunnarHj> happyaron: The "Kubuntu only" is a problem. I'm not sure how to deal with it.
<happyaron> GunnarHj: then let's make it the same as Ubuntu unity
<GunnarHj> happyaron: That would certainly be easiest.
<happyaron> ok
<GunnarHj> happyaron: Have you thought about the other flavors? Xubuntu, Lubuntu...
<GunnarHj> happyaron: Probably their seeds should be changed as well.
<happyaron> yep
<GunnarHj> happyaron: Is it on your list? ;)
<happyaron> let me make some MPs
<happyaron> yes as of now, :)
<GunnarHj> Great.
<happyaron> GunnarHj: would you mind add im:${LANG}:kde-runtime:kde-config-fcitx to pkg_depends?
<GunnarHj> happyaron: Do you mean im::kde-runtime:kde-config-fcitx ? (i.e. for any language)
<happyaron> no, just zh-hans and zh-hant
<GunnarHj> happyaron: Ok, will do.
<happyaron> great
<happyaron> Riddell: https://code.launchpad.net/~happyaron/ubuntu-seeds/kubuntu-1430893/+merge/254134
<Riddell> happyaron: why is that only in the installer?
<Riddell> happyaron: do you know who makes kde-config-fcitx ? it'll need a kde frameworks 5 port
<happyaron> Riddell: kde-config-fcitx is made by fcitx upstream,
<happyaron> will check with him for that
<happyaron> Riddell: about the installer-only change, check-language-support will prevent them to be removed for languages that expects to have fcitx installed
<happyaron> Riddell: other languages still use ibus, in vivid.
<happyaron> this makes the situation in sync with Ubuntu unity
<Riddell> happyaron: oh clever
<happyaron> Riddell: do I need to propose another MP for kubuntu-plasma5.vivid?
<Riddell> GunnarHj: happyaron: im::kde-runtime:kde-config-fcitx is fine for vivid but kde-runtime will go away in future, maybe change it to kio while we're here for plasma5?
<Riddell> happyaron: no there is no kubuntu-plasma5 in vivid that was just temporary in utopic
<happyaron> ok
<GunnarHj> Riddell: So it's still kde-runtime in vivid?
<Riddell> GunnarHj: kde-runtime is kdelibs4 which is in vivid but will go away in the future, kio is an equivalent package in kde frameworks 5 land
<GunnarHj> Riddell: Right, but is kio present in vivid, so we could refer to it now? Or will that change have to wait?
<Riddell> GunnarHj: yes it's present on vivid
<Riddell> GunnarHj: so change now would be good
<GunnarHj> Riddell: Ok, will do.
<GunnarHj> happyaron, Riddell: Revision 312 and 313 are now in the upload queue, waiting for approval.
<GunnarHj> https://code.launchpad.net/~ubuntu-branches/ubuntu/vivid/language-selector/vivid
<happyaron> Riddell: kcm-fcitx's KF5 port is ready, I can upload that, can you handle the approval?
<Riddell> happyaron: ooh yes please :)
<Riddell> thanks GunnarHj :)
<bdmurray> xnox: Should bug 1066480 still be assigned to you?
<ubottu> bug 1066480 in ubiquity (Ubuntu Vivid) "Installer doesn't show encrypted partitions" [Critical,Triaged] https://launchpad.net/bugs/1066480
#ubuntu-devel 2015-03-26
<pitti> Good morning
<pitti> wgrant: hm, did anything go wrong with a recent LP rollout or so? a bug list like https://bugs.launchpad.net/ubuntu/+source/autopkgtest is now missing the "sort by" UI, and on bugs the tasks don't have expanders any more
<wgrant> pitti: Hm, maybe one of the apache upgrades went awry.
<pitti> it's also really slow this morning
<seb128> pitti, the "order by" headers are displayed here
<pitti> hm, not here, I tried various pacakges
<wgrant> seb128: JS is cached very heavily.
<Unit193> Does that if JS isn't on.
<wgrant> It's just because pitti's been lazy lately and clearly hasn't looked at any bug pages :P
<pitti> wgrant: heh yes, it's called "holidays" :)
<dholbach> good morning
<pitti> wgrant: I've looked at dozens of bug pages today, what can I do to flush/update the cache?
<wgrant> pitti: Oh, sorry. To clarify, JS serving was broken by an apache upgraded an hour ago, but it only affects people who haven't used LP yet this week.
<wgrant> We're debugging.
<pitti> wgrant: ah, that clarifies it; thanks :)
<wgrant> pitti: Should be fixed now. An arguably slightly overzealous mod-wsgi CVE fix.
<pitti> wgrant: yay, thanks
<pitti> seb128, tyhicks: (post-holiday catch-up): what's the latest word on bug 1430557? AFAIR you two looked into this two weeks ago?
<ubottu> bug 1430557 in schroot (Ubuntu) "sbuild / schroot unmounted encrypted home directory" [High,Triaged] https://launchpad.net/bugs/1430557
<seb128> pitti, see comments #6 to #9 on https://bugs.launchpad.net/ubuntu/+source/click/+bug/1427264
<ubottu> Launchpad bug 1427264 in click (Ubuntu) "using ecryptfs, creating frameworks fail to bind mount issues" [High,Triaged]
<seb128> pitti, basically with systemd mounts use  MS_SHARED and it's suggested to rprivate or rslave
<seb128> not sure what's the status of getting that change actually uploaded though
<Unit193> pitti: You were gone, hope you had fun. I was going to comment, netbook had a fun version of the systemd daemon-reload bug, plymouth would start back up, while in an active session. :P
<pitti> Unit193: yep, I know; I sometimes get that in a VM
<dz0ny> hehe
<dz0ny> happened few times when gnome-session crashed
<Unit193> It's...Interesting.  Simple plymouth quit  works at least, so mildly amusing.
 * dz0ny disables plymouth right after purging that chat and music app, tracker and online accounts thingy
<darkxst> dz0ny, would like to see a backtrace of that gnome-session crash if you can get one
<darkxst> hey Unit193, pitti
<Unit193> darkxst: Howdy.
<dz0ny> darkxst: can't be done, something about core dum not having right number of bytes
<dz0ny> and tty was disabled after that
<darkxst> Unit193, I started refactoring ppa-versions to use regex and what not, hold of playing with it for a few days
<dz0ny> i had to reinstall everything
<dz0ny> but if it happens again you will get it :)
<darkxst> dz0ny, I see that sometimes on our retracers (invalid core dumps)
<Unit193> darkxst: Nice, hopefully not too much effort to merge. :P
<darkxst> dz0ny, is it the login session or greeter session that is crashing?
<dz0ny> login-session
<darkxst> dz0ny, replace gnome-session with a wrapper, and then use ssh to attach to the gdb session
<dz0ny> mhm
<dz0ny> darkxst: the important thing is, that it didn't happened since re-install
<darkxst> ok
<seb128> didrocks, pitti, do you have standard templates/wiki instructions for bugs like https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1436691 ?
<ubottu> Launchpad bug 1436691 in upstart (Ubuntu) "Essential files are missing" [Undecided,New]
<pitti> seb128: that one seems pretty clear, it seems the upgrade missed the installation of upstart-sysv?
<seb128> pitti, do we know how is that possible?
<pitti> an apt log would certainly be helpful
<didrocks> I guess the upgrade should have installed systemd-sysv instead (as we ensure to at least have one init)
<didrocks> seb128: can you get the logs for that one? (as you pinged us about it, you know the guy or just looking at random upstart bugs?)
<seb128> didrocks, I'm just looking at the most recent reported bugs on launchpad, just to see the feedback from beta
<seb128> going through the first 10 pages or so
<didrocks> ah ok :)
<Odd_Bloke> Is there a common way of checking if a service is running which will work under upstart and systemd?
<Odd_Bloke> invoke-rc.d looks like it has a different output format and different return codes.
<flexiondotorg> cjwatson I've been stuck on the motorway for 3 hours. Using phone for IRC.
<flexiondotorg> Caja is in the upload queue.
<flexiondotorg> Fixss
<flexiondotorg> Fixes a segfault. Can you find someone who can let it into the vivid archive please?
<cjwatson> Ask on #ubuntu-release
<cjwatson> That's a release team thing, I'm not in that any more
<flexiondotorg> I'm going to be stuck here till 4pm
<flexiondotorg> OK. Will fiddle with IRC toget to release
<cjwatson> Sorry but I can't proxy for you on this
<cjwatson> Fighting with juju
<ogra_> infinity, oh, is the glibc in proposed supposed to be the only fix i need to make media playback work on the phone again, do you know ?
<ogra_> (or are there pulse changes/rebuild required)
 * ogra_ would happily test but i dont want to trash my install
<ogra_> bah, being brave and just instlling the packages wasnt such a good idea it seems ...
<pitti> Odd_Bloke: "service foo status" isn't too bad, unfortunately under upstart it returns a wrong exit code (always 0), so you need to parse its output too
<cjwatson> pitti: Welcome back!  Do you need anything from us in order to be able to prepare ddeb-retriever for new ddebs?
<pitti> cjwatson: mostly just time, I'm afraid; so if anyone wants to take a stab at this, it might get done faster
<cjwatson> I did have a look but was having difficulty getting my head around d-r's model of what it caches where
<pitti> between the post-holiday backlog, easter holidays, and me getting dragged into the snappy sprint there won't be that much time left in the next few weeks
<cjwatson> Do you have a local test setup or anything?
<pitti> cjwatson: no, I don't; there's a test suite which mocks some stuff, but not a full "run against fake launchpad" integration test
<cjwatson> Well, I guess I mean more a local staging site than tests as such
<cjwatson> Something to play around with
<cjwatson> I suppose I could just stub out the actual downloads
<pitti> cjwatson: no, so far I just ran it against production, usually against a temp data dir
<pitti> and just download the stuff from today, etc.
<cjwatson> Oh, you can do that?  That would help I guess
<cjwatson> And I do have germanium access
<pitti> cjwatson: yes, that's --archive-root
<pitti> ~/www â ubuntu, ~/www/ubuntu-rtm â RTM
<cyphermox> hey pitti!
<pitti> hey cyphermox, how are you?
<LocutusOfBorg1> Hi Folks, what does this mean? https://jenkins.qa.ubuntu.com/job/vivid-adt-libvncserver/16/console
<cyphermox> pitti: pretty good, you?
<LocutusOfBorg1> I see a failed but I don't understand what
<cyphermox> LocutusOfBorg1: means there was a failure in jenkins
<LocutusOfBorg1> yes, but I see SUCCESS and after "FAILED"
<LocutusOfBorg1> I understand what is jenkins, but I don't understand the failure
<cyphermox> yeah, it couldn't pass on the right state from the executors to the upstream job
<cyphermox> we can rerun this I guess
<LocutusOfBorg1> (ok so I understood correctly the output)
<LocutusOfBorg1> spurious failure
<LocutusOfBorg1> I don't know however why I did receive the mail, but nevermind
<LocutusOfBorg1> pitti, ^^^^
<LocutusOfBorg1> :)
<pitti> cyphermox: quite well, I really enjoyed the holidays
<pitti> LocutusOfBorg1: another jenkins b0rkage, I'm afraid
<pitti> I'll retry the failed tests
<cjwatson> pitti: Hm, OK.  I doubt I'll get to it today, but perhaps soon, then.
<LocutusOfBorg1> thanks as usual!
<infinity> ogra_: Should be, yes.
<ogra_> well ...
<ogra_> http://paste.ubuntu.com/10683761/
<ogra_> :(
<ogra_> i only installed libc-bin, libc6 and multiarch-support ...
<ogra_> rsalveti, is just trying to repro
<tyhicks> pitti: I need to find some time to look at my proposed solution in LP: #1427264 closer - I was told that it doesn't work for trusty schroots
<ubottu> Launchpad bug 1427264 in click (Ubuntu) "using ecryptfs, creating frameworks fail to bind mount issues" [High,Triaged] https://launchpad.net/bugs/1427264
<Riddell> mvo:
<Riddell> mvo: any thoughts on bug 1426132 ? the upgrade from utopic wants to install baloo4 rather than baloo-kf5
<ubottu> bug 1426132 in baloo-kf5 (Ubuntu) "baloo is not replaced by baloo-kf5 on dist upgrade" [Critical,Triaged] https://launchpad.net/bugs/1426132
<Riddell> which breaks kubuntu-desktop from installing
<rsalveti> ogra_: yeah, fails to boot here as well =\
<rsalveti> latest mako image + new glibc
<rsalveti> makes no sense though
<rsalveti> the boottest for it went fine
<rsalveti> https://jenkins.qa.ubuntu.com/job/vivid-boottest-glibc/lastBuild/
<mvo> Riddell: meh, that looks bad. if you (or someone else) can reproduce it, I wonder if it also happens with vivid apt?
<mvo> Riddell: i.e. if apt is upgraded first (and only apt and its direct dependencies) before doing the upgrade
<infinity> rsalveti: Makes shockingly little sense, given the single-line patch whose outcome could only be either "be broken the same as before" or "be fixed".  But maybe the build corrupted?
<rsalveti> infinity: yeah, the patch would not cause this for sure
<rsalveti> still checking what failed to start
<Riddell> mvo: I can reproduce it, I'm on a system now which has just failed with the problem
<mvo> Riddell: do you happen t have a snapshot of the state before?
<mvo> Riddell: that is the most interessting part :)
<mvo> Riddell: anything special that needs to be done to get into this state? or is it just "upgrade kubuntu 14.10 to 15.04" ?
<Riddell> mvo: no but it's just a fresh kubuntu utopic install no changes
<infinity> mvo: I think the bug report has the hint, in that it's removing two packages to install one.  apt doesn't generally like that.
<Riddell> I added a "baloo" transitional package last night but it doesn't seem to have helped
<rsalveti> infinity: ogra_: unity-system-compositor: error while loading shared libraries: libGLESv2.so.2: cannot open shared object file: No such file or directory
<infinity> Riddell: The transitional package will just make it worse, since you got all the versions wrong.
<rsalveti> so it seems to be an issue with ld
<rsalveti> infinity: ogra_: ldconfig fixes it
<Riddell> infinity: what makes you say I got the versions wrong?
<infinity> Riddell: Package: baloo-kf5
<rsalveti> still unclear why this didn't automatically happen though
<infinity> Replaces: baloo (<< 5.0)
<infinity> Riddell: But baloo has an epoch.
<infinity> rsalveti: The postinst should be running ldconfig...
 * infinity tests this on x86.
<ogra_> rsalveti, wow, i would have expected the libc postinst to call that
<infinity> It triggers it.
<infinity> And it worked fine here.
<infinity> Just now.
 * infinity tries on armhf to be sure.
<ogra_> rsalveti, yeah, confirmed, i got my session back
<ogra_> i assume we wouldnt have seen that in an actual image build since *something* would have called ldcondifg at some point
<infinity> Yes, libc-bin and libc6 both.
<infinity> And any number of other packages.
<ogra_> yay, and i can listen to streaming radio and switch channels again :)
<ogra_> so the root cause is definitely fixed
<infinity> How were you installing the packages on your phone?
<infinity> Cause, seriously, literally the last thing the postinst for libc6 does is call ldconfig on configure.
<infinity> And just confirmed it works fine on armhf too.
<ogra_> wget them to a dir in ~/ ... remount / rw ... dpkg -i *.deb ... remount / ro ... reboot
<infinity> So, it's very specific to your environment.
<ogra_> could be
<seb128> rsalveti had the same issue though?
<ogra_> yeah
<infinity> seb128: I meant "his environment" as in the phone, not *his* phone.
<seb128> oh, ok :-)
<ogra_> right, rsalveti has the same environment
<geser> pitti: Hi, do you know by chance if the systemd (packaging) helpers cope well with a backslash in a unit name? (run-vmblock\x2dfuse.mount)
<infinity> ogra_: Processing triggers for libc-bin (2.21-0ubuntu4) ...
<infinity> ogra_: That's code for "running ldconfig now". :P
<infinity> ogra_: And certainly produces sane ldconfiggish results for me here.
<ogra_> yeah, i know
<ogra_> running it manually got me fixed
<ogra_> seems for some reason the postinst didnt run though
<infinity> ogra_: That's a bit strange.
<ogra_> right, since davmor2 obviously saw the issues when he tested the initial upload ... so it must have been run for him back then
<infinity> ogra_: Yeah, and working for reboot tests, which effectively just do dpkg -i && reboot, right?
<ogra_> no idea what they do :)
<ogra_> they might make the system completely writable and reboot with writable rootfs first ... while i only remounted rw temporary
<ogra_> not sure how rsalveti did his install
<davmor2> ogra_: I just enabled the repo and did sudo apt install libc-bin libc6 multiarch-support
<ogra_> davmor2, right, so on a fully writable system
<davmor2> ogra_: yeap
<davmor2> ogra_: did phablet-config writable-image
<ogra_> yeah
<ogra_> i didnt ...
<ogra_> rsalveti, how did you install ?
<infinity> ogra_: Oh, so you might have had bits of /etc redirected or other weirdness?
<ogra_> infinity, well, technically these bits are also there in davmor2'S case
<ogra_> it is just that / is rw from boot on, the bind mount farm gets processeed in both cases
<ogra_> thats why i waiting to hear how rsalveti installed
<ogra_> and if his system is completely or just temporary writable ... if we used the same method then it is surely caused by this
<davmor2> ogra_: from his mail
<davmor2> For the lazy ones:
<davmor2> (from host) $ phablet-config writable-image
<davmor2> (from target):
<davmor2> phablet@ubuntu-phablet:~$ sudo apt-add-repository ppa:rsalveti/ppa
<davmor2> phablet@ubuntu-phablet:~$ sudo apt-get update
<davmor2> phablet@ubuntu-phablet:~$ sudo apt-get install libc-bin libc6 multiarch-support
<davmor2> phablet@ubuntu-phablet:~$ sudo reboot
<rsalveti> ogra_: infinity: just dpkg -i
<ogra_> davmor2, i'm taking about the test a few mins ago
<ogra_> using the proposed package
<ogra_> (not the ppa)
<davmor2> ogra_: ah fair enough :)
<ogra_> rsalveti, on a fully writable system ?
<ogra_> or did you remount
<infinity> Yeah, the PPA package wouldn't require an ldconfig.
<infinity> But the proposed one does.
<rsalveti> ogra_: infinity: fully writable: http://paste.ubuntu.com/10684062/
<infinity> However, the postinst should be running.
<infinity> So it shouldn't matter.
<rsalveti> ops, that's a replace from the same version
<rsalveti> let me find out the previous output
<ogra_> yeah, seems then the mounting doesnt have any effect :/
<ogra_> right, i had the same output
<ogra_> no word about triggers
<infinity> rsalveti: Replace for the same version should still be running the libc-bin triggers.
<infinity> This will all get papered over in an image build anyway, but WTF.
<rsalveti> then this is already enough to show up the issue
<infinity> rsalveti: A manual dpkg -i (replacing, not upgrading, same as you) here runs triggers just fine.  So there's something deeply wrong with the phone filesystem. :/
<infinity> This isn't happening on a filesystem with no inotify support, is it?
<rsalveti> nops
<ogra_> infinity, no-install-recommends and we dont use ubuntu-standard ... that would be the two most significant changes (beyond the bindmount farm)
<infinity> ogra_: Yeah, neither of those two things make a difference.  Especially not when running dpkg -i on a single deb.
<ogra_> right
<infinity> ogra_: I feel like this is a puzzling thing I want to know the answer to, but like it's also not really relevant to this specific fix.  The only thing that made it relevant is that that upgrade requires an ldconfig run.
<ogra_> right, i think we can put it into a box and re-visit it once such a prob arises again
<dmsimard> Hi guys. Could I get a few pairs of eyes on what I believe to be an important bug.. ? https://bugs.launchpad.net/initramfs-tools/+bug/1436098
<ubottu> Launchpad bug 1436098 in initramfs-tools "Pre-seeding linux-generic-lts-utopic in a trusty install lacks the utopic kernel initrd and results in a kernel panic at first boot" [Undecided,New]
<Odd_Bloke> Is there any harm in having a service that doesn't exist in After= in a systemd service definition?
<infinity> dmsimard: Responded.
<doko> Mirv, qt ping
<infinity> ogra_: Well, there's certainly a bug here that affects your QA process if triggers don't get run on manual installs.
<dmsimard> infinity: Thanks.
<ogra_> infinity, can you let me know once the package migrated, so i can spin a new image ?
<ogra_> (i assume that happens today ?)
<infinity> ogra_: The plan was to have it happen this morning, but we're still arguing with one last beta bug that we may or may not fix.
<infinity> ogra_: Though, if we do fix the beta bug, I'll probably let glibc in on that respin anyway.
<ogra_> ok
<strikov> pitti: o/
<strikov> pitti: i'm mostly done with juju packaging for vivid and have one question; in the bug you proposed a way to run upstart-dependent tests by installing upstart from the test itself: https://bugs.launchpad.net/juju-core/+bug/1409639/comments/13
<ubottu> Launchpad bug 1409639 in juju-core (Ubuntu Vivid) "juju needs to support systemd for >= vivid" [High,Triaged]
<pitti> hey strikov
<strikov> pitti: what is simpler/better to do: (a) create juju 1.22 package w/o this fix and manually move it from -proposed to -released or (b) to include this hack into the tests
<pitti> strikov: your choice really -- if you want to continue running the tests for upstart, let the test install upstart-sysv; otherwise disable the test in d/t/control
<pitti> strikov: personally I think (b) is better as you keep testing both init systems
<pitti> strikov: or, an intermediate approach would be to have the test check which init system you are using, and skip tests for the "other" one
<pitti> strikov: i. e. the "under upstart" test skips itself under vivid, but runs under <= utopic, and the "under systemd" test skips itself for <= utopic
<pitti> strikov: check with [ -d /run/systemd/system ] if systemd is running; if not, you can assume upstart (under ubuntu)
<strikov> pitti: thanks a lot! i thought a bit and i like your point about testing both upstart and systemd; theoretically juju should support both on vivid so it might be useful to verify that
<pitti> strikov: I meant that you usually want to make the same package work on all releases, don't you?
<pitti> strikov: so keeping the tests identical too might be easier to maintain
<strikov> pitti: yes, so if current init method is system -- i check juju against it, then switch to upstart and check it as well; if i'm using upstart -- i check juju only against upstart
<pitti> strikov: note that since I typed that comment the package you need to install changed to "upstart-sysv"
<strikov> pitti: i already met this issue ;)
<strikov> pitti: does /tmp/autopkgtest-reboot requires any root permissions for the test?
<pitti> strikov: yes, you must call it as root
<strikov> pitti: ack, tnx
<didrocks> phew
 * didrocks hates fiber operators
<didrocks> they unplugged me to plug another one
<pitti> wb didrocks!
<didrocks> had to go to the cave
<didrocks> find my fiber number
<didrocks> and replug myself
<seb128> didrocks, anyone has access to the board? they don't have in a closed box?!
<rbasak> We have that problem here with POTS. Technicians who can't find dial tones assume pairs aren't in use and use them for something else. So doing things like DSL with no POTS voice service is dangerous.
<didrocks> seb128: well, they have torx screws
<seb128> no lock?
<didrocks> seb128: and didn't even need to go upstair
<seb128> weird...
<didrocks> there was a screwdriver next to it :p
<didrocks> just too a long time to find the right cable
<didrocks> well, first identifying it was this
<didrocks> and no a random issue on line
<seb128> didrocks, smart thinking, I wouldn't even have though about going to the cave to check the arrival myself I think ;-)
<seb128> like I would have blamed their side or the modem or the street cable...
<didrocks> seb128: well, I know where it was, so really worthed a check :p
<seb128> :-)
<seb128> didrocks, you left just when pitti said he had to revert one of your systemd changes, I first though you rage closed IRC ;-)
<didrocks> ahah, seems like it was a nice timing!
<pitti> heh, I thought the same
<pitti> I was afraid of didrocks saying "oh no, not another one" and breaking down in tears
 * pitti hugs didrocks
 * didrocks hugs pitti back
<didrocks> no, blame lazy fiber technicians :p
 * seb128 hugs didrocks and pitti
<pitti> oh, hugfest!
<seb128> :-)
 * pitti donne une accolade retour Ã  seb128
 * didrocks hugs seb128 back
<shadeslayer> bdmurray: uf, sorry about that
<shadeslayer> I'll add it to my todo list
<strikov> To fix tomcat7 tests I need to update keys and certs inside the source tree (old ones expired). I'd usually come up with a patch inside d/patches but some of the files I need to update are binaries. Is there any non-destructive way (patch but not source tree modification) to do that? Thanks.
<mdeslaur> strikov: yeah, source format 3.0 supports binary files...but I can never remember the magic incantation to do it...let me search a bit
<strikov> mdeslaur: thanks
<mdeslaur> strikov: you modify the binary files in the tree and you add the path to a file called debian/source/include-binaries
<strikov> mdeslaur: i don't do any quilt magic manually, right?
<mdeslaur> nope, all files listed in debian/source/include-binaries will get put in the debian tarball
<strikov> mdeslaur: awesome, thanks!
<mdeslaur> strikov: ah! an example: https://launchpad.net/ubuntu/+source/serf/1.3.3-1ubuntu0.1
<strikov> mdeslaur: that worked, again thanks for helping
<mdeslaur> strikov: cool, np!
<LocutusOfBorg1> nk
<LocutusOfBorg1> hi developers, syncing tomcat 7.0.56-2 from debian will fix the build failures
<LocutusOfBorg1> a.k.a. 1432715
<LocutusOfBorg1> I guess
<Riddell> mvo: so no ideas on baloo packaging?
<mvo> Riddell: not right now, sorry but I had a super busy day, I can try to reproduce tomorrow morning
<Riddell> mvo: thanks, it's really weird I've no idea why it would want baloo4 at all
<mvo> Riddell: it looks a lot like a ordering bug in apt, we had those before, really hard to track down unfortunately, but maybe if I can reproduce I can create a easy(?) workaround
<doko> roaksoax, your maas upload removes slangasek's changes, and doesn't change the python django dependency ...
<roaksoax> doko: the maas upload didn't remove slangasek 's changes since we backported those changes to 1.7
<doko> ahh
<roaksoax> doko: but yes, it is missing the changes for packaging, which I'll take care of
<roaksoax> doko: i was hoping we would release 1.8 this week, but seems might not happen
<teward> hey stupid question but why did I get jenkins emails this morning...?  if anyone knows
<infinity> teward: The content of the mail might be informative...
<teward> infinity: Jenkins Failure - vivid-adt-nginx 42
<teward> neither of the links there actually resolved (E:NoDataReturned)
<teward> more curious why I got em
<infinity> teward: I'd assume you got them because you uploaded the last nginx.
<teward> ahhh ok
<infinity> teward: You should have gotten a followed "Fixed" mail, by the looks of things.
<teward> infinity: indeed.  wondering why it died initially though, cause it looks like the next build worked fine
<infinity> s/followed/followup/
<teward> was there something up with jenkins on the first one?
<infinity> teward: Looks like a weird infra problem, as it seems to have registered a success as a failure. :P
<teward> indeed, it's why i was curious :)
<infinity> Given that pitti manually kicked off the next build, I guess he is/was aware of it.
<teward> infinity: so, I should only be concerned if it actually has failures?
<teward> (and not this weird infra problem)
<infinity> teward: Yeah.
<teward> cool, i can put away the hard drive with all the nginx packages i've done work on xD
<teward> thanks
<teward> (also is the first time I've ever had an email from jenkins)
<infinity> You're lucky.
<infinity> I get flapping testsuite spam all the time.  Lots of tests really need fixing, as does the infrastructure running them. :/
<teward> infinity: heheh.  My last nginx build in sbuild exploded with a nondeterministic build failure and no apparent reason for it to fail but meh
<teward> rebuilding the chroots now just in case it's a chroot problem, but meh
<teward> so i hear you (got a lot of alerts last night xD)
<doko> infinity, just found https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1386524
<ubottu> Launchpad bug 1386524 in valgrind (Ubuntu) "Update Ubuntu 14.04 with full Valgrind LE support." [Undecided,New]
<doko> would you mind updating to 1.10.1 to the version in vivid?
<infinity> doko: Does valgrind have a decent testsuite that it actually passes, and/or any other way to validate it meaningfully?
<infinity> doko: On the one hand, "it's just a debugging tool" makes a good argument for updating it, since it shouldn't affect anyone at runtime, on the other hand "it's just a debugging tool" means it's less useful on an LTS when we expect most active development to be happening in 15.04, 15.10, etc.
<infinity> doko: Sooo... Maybe!
<micahg> doko: any reason to keep around gcc in universe?  I'd like to file removal requests (or work towards that where appropriate)
<infinity> micahg: gcc-4.8?  It still has things that build-dep on it.
<micahg> was starting with 4.4, but asking in general
<doko> micahg, well, fixing build failures would be more important ;)
<micahg> doko: I started looking into some of those also, but some of the compilers have build failures as well and this is one way of addressing ;)
<infinity> doko: What's the rationale for the new upstream version of tbb?
<doko> infinity, builds on arm64 and ppc64el
<infinity> doko: I like that rationale.  Too painful to backport specific fixes, I assume?
<doko> infinity, well, I started looking, but gave up
<infinity> doko: Wait, the version in unstable builds on arm64 and ppc64el
<doko> infinity, yes, but not in -proposed
<doko> I cancelled the ppc64el build, but that one fails too. my testbuild is in doko/toolchain
<infinity> Weird.  Fair enough.
<infinity> The rdep list is short, I assume you're prepared to deal with fallout if someone screams.
<doko> mdeslaur, libgcrypt11 doesn't like you
<infinity> Looks like it should stop producing libgcrypt11-dev
<infinity> Though, if 20 produces 11-dev, does that imply that we can safely just rebuild the world and drop 11 entirely?
<infinity> I'm all for that.
<sarnold> where did 1.5.4-3+really1.6.2-4ubuntu1 come from? IU don't see it here: https://launchpad.net/ubuntu/+source/libgcrypt11/+publishinghistory
<infinity> sarnold: libgcrypt20 produces it.
<infinity> sarnold: Hence the next couple of lines I typed. :P
<sarnold> infinity: aha :) thanks
<infinity> In my copious free time this evening, I might try rebuilding all the libcgrypt11 rdeps.  If they're all happy with 20, we'll just rebuild the world and drop 11 like a bad habit.
<infinity> If they're not happy with 20, we need to revert this weird 11-dev == 20 assumption.
<infinity> So, worth the test regardless.
<mdeslaur> infinity: I was making a libgcrypt11 package without -dev, should I wait?
<infinity> mdeslaur: Well, if the supposed claim that 20 == 11 is true, we should aim to drop 11.
<infinity> mdeslaur: And if it's not true, we need a new 11 with a version-bumped 11-dev and the 11-dev from 20 dropped.
<infinity> mdeslaur: So, yeah, no point in your upload, IMO.
<mdeslaur> ok, I'll wait to see what your test rebuild shows
<mdeslaur> infinity: let me know how it turns out
<infinity> mdeslaur: Yeahp.
<doko> crap, the gmp ftbfs on armhf persists
<infinity> doko: That looks a lot like a glibc testsuite failure that binutils 2.26 (or, something backported from 2.26 to your 2.25 branch) caused.
<infinity> doko: Had to do with mixing and matching PIE and non-PIE code.
<infinity> doko: Though, why you'd only see it on armhf is a mystery, so it's probably not that issue, just looks like it.
<infinity> doko: But, maybe compiling that test with some PIE would make it happy.  Who knows. :P
<doko> well, I'll have to check. but I already reverted that hjl patch
<infinity> Oh, did you?  I didn't notice cause I'd already future-proofed my testsuite anyway.
<infinity> Anyhow, it's probably not that regardless, cause that wouldn't be just ARM.
<doko> ahh, it's another one
<doko> PR 15228
<doko> https://sourceware.org/bugzilla/show_bug.cgi?id=18167
<ubottu> sourceware.org bug 18167 in ld "[2.25 regression] binutils fails to link gmp on ARM32" [Normal,New]
<doko> that will be for tomorrow ...
<infinity> doko: Nice to see amodra calling out hjl's cowboy code. :P
#ubuntu-devel 2015-03-27
* infinity changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Mirv> doko_: qt pong
<pitti> teward, infinity: yes, jenkins broke down again yesterday, sorry for the noise
<pitti> Good morning
<dholbach> good morning
<Tribaal> hi guys! I found a regression in LXC on Vivid, how can I help with fixing it, besides opening a launchpad bug?
<pitti> Tribaal: I suggest talking to stgraber or hallyn, they are upstream (but probably both asleep right now)
<Tribaal> pitti: I shall
<geser> pitti: Hi, do you know by chance if the systemd (packaging) helpers cope well with a backslash in a unit name? (run-vmblock\x2dfuse.mount)
<pitti> geser: I haven't seen those myself yet, so I'm afraid I don't know
<geser> pitti: during an update a couple days ago, I got some messages where I'm not sure if expected or the result of the \ in the filename
<geser> like "Failed to get unit file state for run-vmblockx2dfuse.mount: No such file or directory" (no \ before the x2d) and "run-vmblock\x2dfuse.mount is a disabled or a static unit, not starting it."
<geser> the package was "open-vm-tools-desktop"
<Odd_Bloke> pitti: I've added a Wants/After dependency on (e.g.) foo.service; is that safe if foo.service doesn't exist on the system?
<pitti> Odd_Bloke: yes, it is
<pitti> Odd_Bloke: that's what Wants= is for: if it doesn't exist, it is ignored
<pitti> Odd_Bloke: (contrary to Requires=)
<Odd_Bloke> Great, that's what I thought.
<Odd_Bloke> Thanks!
<flexiondotorg> Morning. pitti dholbach I've got some feedback about a couple of bugs (one critial in my opinion) and what looks like a trivial fix for both.
<flexiondotorg> pitti, dholbach The fix involves grub. Something I am still learning about. Is there someone I can discuss the potential fix with the ensure there are not unintended side affects?
<flexiondotorg> pitti, dholbach The bugs are:
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1368784/
<ubottu> Launchpad bug 1368784 in virtualbox (Ubuntu) "Utopic Virtualbox guest gets only up to resolution of 640x480" [High,Confirmed]
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1386005
<ubottu> Launchpad bug 1386005 in plymouth (Ubuntu) "Password not accepted graphical boot for encrypted root system" [Critical,Triaged]
<flexiondotorg> Both appear to be resolved by adding 'GRUB_TERMINAL=console' to '/etc/default/grub' and running 'update-grub'.
<dholbach> flexiondotorg, I'm not sure I'm a good person to discuss these bugs with - I have no idea about any of them :-/
<dholbach> pitti might know, or somebody in the foundations team
<flexiondotorg> dholbach, I'm asking who I should discuss them with ;)
<dholbach> ah ok
<flexiondotorg> dholbach, Guessed it would be foundations but the only guys I know in that team are not in my timezone :(
<dholbach> https://launchpad.net/~canonical-foundations/+members#active
<flexiondotorg> dholbach, Thanks.
<dholbach> anytime
<pitti> flexiondotorg: there's a chance that cjwatson has time to comment on this, but he's working on other things now
<flexiondotorg> pitti, Yeah, I'm trying to not ping cjwatson for everything ;) I know he is a busy man.
<pitti> but it seems odd that this would be flavor specific, unless it's a specific problem wiht the plymouht theme?
<flexiondotorg> pitti, No flavour specific.
<flexiondotorg> pitti, Reproducable on all flavours I tested.
<pitti> either way, if this is right, then this would be an "unbreak my system" setting which really shouldn't be in a config file but just be the default
<pitti> flexiondotorg: ah, specific to virtualbox then
<pitti> flexiondotorg: yeah, QEMU's various graphics card sometimes act up on plymouth too, indeed
<flexiondotorg> Yes, that bit is specific to VirtualBox. But the more important fix is being able to enter the full disk encryption passphrase.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1386005
<ubottu> Launchpad bug 1386005 in plymouth (Ubuntu) "Password not accepted graphical boot for encrypted root system" [Critical,Triaged]
<cjwatson> pitti,flexiondotorg: Not at the moment, sorry.
<pitti> flexiondotorg: can you select a different graphics card in virtualbox?
<pitti> that helps with qemu, anyway
<cjwatson> GRUB_TERMINAL=console affecting things indicates that the problem is likely with the graphical console handover to plymouth.
<rbasak> hallyn: so about http://paste.ubuntu.com/10626570/
<rbasak> It needs the Breaks/Replaces upstart -> upstart-bin as you pointed out.
<rbasak> I noticed that that one of the packages (I think apparmor?) has some documentation on how to use apparmor-profile-load - that probably needs to be updated.
<rbasak> And the mechanism added to ensure that init-system-helpers is pulled in by every package that uses apparmor-profile-load. infinity suggested that dh_installinit grep for apparmor-profile-load and if found add init-system-helpers to ${misc:Depends}.
<rbasak> And then to rebuild affected packages (from my list).
<rbasak> Or maybe given the list is small it's OK to require that packages depend on it manually, and then document that where apparmor packaging has it documented already?
<rbasak> It looks like lxc would need to explicitly depend on it anyway - or maybe skip it and depend on apparmor and use the new /lib/apparmor/profile-load instead?
<GunnarHj> pitti: Hi Martin!
<pitti> hey GunnarHj, how are you?
<GunnarHj> pitti: Fine, thanks. Hope you are too.
<GunnarHj> pitti: Hoping for your input at bug #1435492. The switch to bash in lightdm and gdm means that ~/.bashrc gets sourced unlike before. Good or bad? Or are you neutral?
<ubottu> bug 1435492 in lightdm (Ubuntu) "Xsession crash after login (fix for #678421 breaks)" [Undecided,New] https://launchpad.net/bugs/1435492
<pitti> GunnarHj: I am, yes, had some nice vacations
<pitti> GunnarHj: queueing, I'll respond in the bug report
<GunnarHj> pitti: Ok, thanks.
<rbasak> Bug 1432715 - FTBFS on Trusty to to the date, but no user-impacting issue right now. SRU-worthy? Might be useful for the security team or any future SRUs. Do we have any process to leave a fix somewhere for someone to find it later in case an update to Trusty is needed?
<ubottu> bug 1432715 in tomcat7 (Ubuntu Trusty) "tomcat7 ftbfs in vivd (test failures)" [High,Confirmed] https://launchpad.net/bugs/1432715
<rbasak> mdeslaur: ^^ do you have an opinion on this please?
<mdeslaur> rbasak: I don't think it's SRU-worthy...typically when something FTBFS people will look to see if it got fixed in later releases
<rbasak> mdeslaur: OK, thanks. We'll leave it.
<mdeslaur> leave the bug open, I'll close it next security update
<rbasak> ack
<doko> Mirv, please could you have a look at component mismatches and tell if everything can be demoted, which wants to be demoted?
<infinity> tedg: remote-login-service is originally your code, right?  Can you have a look at why the testsuite fails miserably when built on vivid (or, alternately, tell me that no one cares and I can remove it :P)
 * infinity seeds upstart-sysv to keep it in main.
<Mirv> doko: the "binary only movements to universe" portion? qml*/qt* listed seem fine to be in universe for now. qml-module-qtlocation qml-module-qtpositioning may be wanted back at some point, and same for the qmake-arm-cross but currently the SDK is in universe too
<Mirv> qtdecla* are transitional dummy packages
<infinity> rbasak: Depending directly on apparmor only makes sense if you *require* apparmor to function.  The nice thing about the i-s-h wrapper is that you can make the apparmor use conditional.
<infinity> rbasak: But I agree that if the number of packages that call profile-load is reasonably low, it's just as sensible to make them manually depend on it, just like you'd manually depend on any other non-Essential binary you call.
<infinity> rbasak: Where "it" is init-system-helpers, not apparmor...
<rbasak> infinity: you mean for lxc depending on apparmor? Yeah - I don't know whether lxc *requires* apparmor or not, but I get what you're saying if it doesn't.
<rbasak> infinity: OK - thanks. Saves us having to hack on dh_installinit then.
<infinity> rbasak: I'm almost positive it doesn't depend on it.
<rbasak> Fair enough then.
 * Mirv wishes our x86 builders would be as fast as ppc64el builders
<infinity> Mirv: I love it when an arch leapfrogs another, and you hear weird statements like that. :)
<Mirv> :)
<infinity> Mirv: powerpc used to be the fastest ten years ago too, and then we stopped upgrading them for a decade until they were the slowest.  And now they're the fastest again.  Whee.
<infinity> rbasak: The nice thing is that init-system-helpers is in minimal so, while packages calling that wrapper absolute MUST depend on init-system-helpers, it's also true that it's a bug you can afford to get wrong, since 99% of people will have it installed. :P
<Mirv> yes I still remember the 20h qtwebkit powerpc builds
<infinity> rbasak: So, we can fix as we spot the issues.
<rbasak> infinity: OK, thanks. I'm more comfortable now that you've seen our plan and have no particular objection to anything :)
<infinity> Mirv: "I wish x86 was as fast as powerpc" still isn't as comical as "I wish x86 was as fast as armhf", though (often uttered by people who do massive numbers of builds in parallel, like doko, where kishi's scale out beats the Intel buildds' scale up every time)
<tedg> infinity, I can take a look, dbarth was looking after it for a while too, he may have hints as well.
<tedg> infinity, Do you have a build log?
<pitti> GunnarHj: replied
<infinity> tedg: http://lucifer.0c3.net/~adconrad/remote-login-service_1.0.0-0ubuntu3_amd64.build
 * tedg clicks
<infinity> tedg: One of the failures there is clearly just an attempt to write to ~/.cache, which shouldn't be expected to exist, but the rest look more seriously broken.
<tedg> Yeah, looks like the new libnm might have changed things a bit for it.
<infinity> tedg: Unless they're all fallout from that same class of bug, in which case it would work on our buildds (where ~buildd does actually exist), but it's still wrong.
<tedg> infinity, It's so wrong it's right?
<infinity> Heh.
<infinity> I keep meaning to remove ~buildd from our buildds, but need to do it at the very beginning of a cycle to have a hope of fixing all the naughty packages that assume $HOME should exist during build.
<infinity> tedg: Anyhow, if you could fix this (or tell me to drop it), that would be great, it's the only package keeping libgcrypt11 in the archive now.
<infinity> tedg: Which a rebuild would solve... If it could build. :)
<tedg> infinity, I think that it's still being used by the unity7 greeter, so we couldn't drop it this late. But I don't know if anyone is actually using the feature, I think we stopped pushing it.
<infinity> tedg: Right, well, I'm guessing fixing it won't be hard for someone who knows the code.
<tedg> There I think dbarth would know more, but I'm guessing we could drop it in Waffling Walrus.
<dbarth> infinity: this service is not maintained anymore; i would suggest to disable and switch to universe
<dbarth> tedg: yes, exactly
<cjwatson> dbarth: Dropping a package to universe doesn't make a difference in terms of whether it keeps old library packages in the archive.
<infinity> dbarth: It's already in universe.  Dropping it from the archive is what I was referring to (if no one can be bothered to fix it).
<mdeslaur> kill it with fire! :)
<dbarth> ah ok
<dbarth> well, then yes; i think the package can be dropped
<infinity> dbarth: Alright, works for me.
<dbarth> infinity: if you want to file a bug for the build failure; i can comment on it to request the package being removed from the archive
<dbarth> to have a record of the request
<tedg> dbarth, Then should we remove lightdm-remote* as well?
<infinity> tedg: It doesn't depend on it.  Should it have?
<infinity> In fact, nothing depends on remote-login-service
<tedg> infinity, No, unity-greeter calls those if remote-login-service tells it to. If there's no one to tell it to, they'll just not be used.
<dbarth> tedg: yes, as a consequence
<dbarth> good catch
<infinity> tedg: Alright, removing remote-login-service, tell me what else should go with it.
<infinity> tedg: lightdm-remote-session-freerdp and lightdm-remote-session-uccsconfigure?
<tedg> infinity, lightdm-remote-session-freerdp lightdm-remote-session-uccsconfigure
<tedg> infinity, Yes, we'll also shorten the average package name by like 10 characters :-)
<mdeslaur> lol
<infinity> tedg, dbarth: All gone from vivid.
<dbarth> infinity, tedg: thank you
<flexiondotorg> pitti, cjwatson Sorry, was in a meeting all morning.
<flexiondotorg> pitti, cjwatson - No, you can't change the "video card" in virtualbox.
<pitti> Riddell: note that in your apport upload you are missing mitya57 's followup syntax fix -- like that it just crashes (http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2933)
<Riddell> pitti: oh doh, please reject
<roaksoax> slangasek: was IPv6 UEFI boot/pxe boot Broken?
<flexiondotorg> pitti, cjwatson - I've tested creating /boot/grub/custom.cfg which set the termina input and output to console. That "fixes" the VirtualBox resolution.
<flexiondotorg> pitti, cjwatson - I'm now creating a system with full disk encryption to see if the same "fix" allow entry of the passphrase.
<flexiondotorg> pitti, cjwatson - I'm still interested to know if there are potential drawback to this approach?
<cjwatson> It's not suitable in general; it makes the GRUB menu much less capable and useful.
<cjwatson> Fine for narrowing down a bug, or for a local workaround, but it's not a good general fix.
<flexiondotorg> cjwatson, OK, understood.
<flexiondotorg> cjwatson, What about if I was to create a new configuration file /etc/grub.d that detects the presence of VirtualBox and apply this workaround?
<cjwatson> No, stop this.
 * flexiondotorg stops.
<cjwatson> My guess is that a kernel or maybe X developer needs to look at it.
<cjwatson> We shouldn't hack out the graphical handover in GRUB just for this.
<cjwatson> If we do need to, there's a blacklisting mechanism already, but it's a last resort.
<cjwatson> (grub-gfxpayload-lists)
<cjwatson> We generally only use that for non-free drivers where we therefore have no alternative.
<cjwatson> flexiondotorg: Now, we do have vmware listed in grub-gfxpayload-lists, so it wouldn't be without precedent to add the relevant virtualbox IDs there first; but a kernel developer should have a look first.
<cjwatson> s/ first//
<flexiondotorg> cjwatson, OK. I'll try add the vbox IDs to see if the end result is the same.
<cjwatson> flexiondotorg: Right; this is less invasive than GRUB_TERMINAL=console because it only disables the handover, not GRUB's entire graphical terminal system.  However, it's also not suitable in general because it disables the system that permits flicker-free boot (insofar as that works properly, but anyway)
<cjwatson> Fortunately not many systems appear to need it ...
<flexiondotorg> cjwatson, Thanks for the information. All interesting stuff.
<flexiondotorg> cjwatson, Adding 11_virtualbox to the grub-gfxpayload-lists works. In as much that graphical boot is disabled, therefore I can always enter my ful disk encryption passphrase and the resulting Vbox resolution is sensisble.
<cjwatson> flexiondotorg: OK, can you chase this up with #ubuntu-kernel?  If they declare it hopeless then I'm happy to change grub-gfxpayload-lists
<doko> pitti, is the systemd auto pkg test regression real?
<flexiondotorg> For reference, here is the ID for the VBOX video device: v80eedbeef.*
<flexiondotorg> cjwatson, I'll follow up with #ubuntu-kernel and report back.
<cjwatson> flexiondotorg: Thanks
 * flexiondotorg updates some bugs with relevant info first.
<pitti> doko: uh, it seems it started failing during my holidays, indeed; not an infrastructure issue at least
<pitti> apparently the RT overrode that
<flexiondotorg> cjwatson, Got a nic I can ping in #ubuntu-kernel?
<cjwatson> flexiondotorg: No
<strikov> Hi guys. Is it right that package creates /etc/systemd/system/<packagename>.service symlink during installation? This symlink points to /lib/systemd/system/<packagename>.service I thought that /etc/systemd/ is something used on top of /lib/systemd which mean that this symlink is useless. Where I'm wrong?
<pitti> doko: I'll wave through the blocked packages
<pitti> didrocks: hm, http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-systemd/137/ARCH=i386,label=adt/consoleText started failing on i386 during my holidays (consistently since then)
<pitti> all of the failed tests involve lightdm; do you happen to know some changes related to that?
<pitti> it coincides with https://launchpad.net/ubuntu/+source/lightdm/1.13.2-0ubuntu1, so that could be a possible reason
<flexiondotorg> cjwatson, For completeness. My notes show that I "fixed" the entering your full disk encryption pass phrase issue in my unofficial Ubuntu MATE 14.10 by removing the graphical Plymouth theme and leaving just the text theme.
<doko> pitti, and looking for php-zeta-console-tools, gmsh, swift
<doko> jamespage, is swift a real regression?
<flexiondotorg> cjwatson, The pass phrase entry is not limited to just VirtualBox. Many different hardware video devices are also affected.
<cjwatson> flexiondotorg: It's possible that plymouth is failing to deal correctly with being entered in text mode.  I'm sure somebody here can help out with that, but I'm sorry, I can't.
<didrocks> pitti: ah, it's consistent, we thought it was random. I would bet on this systemd upload
<didrocks> pitti: sorry s/systemd/lightdm/ yeah
<arges> hallyn: have you seen bug 1434999? I'm not exactly sure which apparmor rule to fix, any ideas? thanks
<ubottu> bug 1434999 in libvirt (Ubuntu) "Creating a new VM in virt-manager fails because of apparmor permissions" [High,Confirmed] https://launchpad.net/bugs/1434999
<flexiondotorg> cjwatson, I've discussed the Vbox video issue in #ubuntu-kernel. Concensus is to blacklist the vbox video device ID in grub-gfxpayload-lists
<flexiondotorg> cjwatson, Do you want me to prepare a merge proposal or a debdiff?
<flexiondotorg> cjwatson, Or will you take it on?
<slangasek> roaksoax: yes, ipv6 uefi boot is broken, bug #1229458
<ubottu> bug 1229458 in grub2 (Ubuntu) "grubnetx64.efi tftp client does not work over ipv6" [High,Confirmed] https://launchpad.net/bugs/1229458
<pitti> flexiondotorg: I suggest preparing a bug with a debdiff, and please paste the IRC conversation in it too for the records
<flexiondotorg> pitti, This is the existing bug - https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1368784/
<ubottu> Launchpad bug 1368784 in virtualbox (Ubuntu) "Vivid and Utopic Virtualbox guest gets only up to resolution of 640x480" [High,Confirmed]
<flexiondotorg> pitti, Can I added the #ubuntu-kernel discussion to it and attach the debdiff there?
<pitti> flexiondotorg: sounds good
<flexiondotorg> pitti, Thanks.
<cjwatson> flexiondotorg: Bug is fine, yes
<cjwatson> flexiondotorg: No need for a debdiff given when you've already added there
<cjwatson> flexiondotorg: Uploaded, thanks
<hallyn> arges: not clear to me either.  i think jdstrand knows what's up
<sarnold> that's not the first bug report I've seen with unexpected lttng-ust-wait-5 denials
<jdstrand> hallyn, arges: I've been quite clear-- don't change the policy, disable lttng-ust
<jdstrand> or make the open non-fatal
<jdstrand> if you adjust the policy, we break guest isolation
<jdstrand> we can't do that
#ubuntu-devel 2015-03-28
<hallyn> arges: jdstrand:
<hallyn>    - d/rules,control: Enable use of lttng for userspace tracing.
<hallyn>  -- James Page <james.page@ubuntu.com>  Fri, 13 Mar 2015 07:42:45 +0000
<hallyn> jamespage: ^  this is causing trouble (bug 1434999 )...
<ubottu> bug 1432644 in libvirt (Ubuntu) "duplicate for #1434999 VM permanently tries to read /dev/shm/lttng-ust-wait-5" [High,Confirmed] https://launchpad.net/bugs/1432644
<hallyn> meh, i think a deny rule is going to be the way to go
<hallyn> i don't think removing the dependency is going to be acceptable
<sarnold> at least the deny could be undone locally if someone wanted to use the tracing capabilities
<sarnold> rebuilding to put it back would be a lot more effort
<hallyn> yeah.  ok, i guess i'll go ahead and push with that fix
<hallyn> hm, but what's the path
<hallyn> /dev/shm/lttng* ?
<hallyn> http://paste.ubuntu.com/10692865/
<hallyn> weird thing is it seems like every error message documented is lttng-ust-wait-5.  something magical about 5?
<hallyn> oh, there is - ./include/lttng/ust-abi.h:45:#define LTTNG_UST_ABI_MAJOR_VERSION                5
<hallyn> smb: i pushed a (trivial) libvirt update, just fyi
<sarnold> hallyn: ah, thanks, that -5 was driving me crazy :)
<hallyn> i still left it as lttng-ust-wait-* in case major version changes :)
<sarnold> having seent oo much of python-[123].[5678901234].. kinds of things, a nice * is sometimes perfect :)
<hallyn> all right, to bed with me - \o
<sarnold> nn
<jdstrand> hallyn: interesting-- I was under the impression that the denial was causing vms to not start. I'm of course fine with an explicit deny if it is a harmless denial
<hallyn> jdstrand: oh, maybe i misunderstood.
<hallyn> if that's the case then i don' tknow how to handle it.
<hallyn> i don't think disabling it in ceph will be acceptable
#ubuntu-devel 2015-03-29
<hallyn> arges: bug 1432644 - you had claimed that bug blocked qemu-kvm users from creating vms.  I don't see that.  i see a few (16) annoying messages in syslog but vms start just fine.
<ubottu> bug 1432644 in libvirt (Ubuntu) "VM permanently tries to read /dev/shm/lttng-ust-wait-5" [High,Fix released] https://launchpad.net/bugs/1432644
<MasterPiece> !help
<ubottu> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<sidi> hi, currently developing patches for nautilus's ubuntu package. i know how to add patches and rebuild a deb, but what i want now is to build a source tree with all the existing patches added, so i can test my code on top of this tree. How can I achieve that?
<sidi> somewhat bzr bd -S seems to be what I want but I dont know where the source ends up. orig.tar.xz packages dont appear to contain local patches
<rbasak> sidi: a Debian source package consists of a .dsc, .orig.tar.gz and (usually) .debian.tar.gz. The .debian.tar.gz contains the patches. Build the .dsc with sbuild, which will pick up the other two files automatically.
<rbasak> sidi: eg. https://wiki.ubuntu.com/SimpleSbuild
<nabukadnezar43> are there minimal images of ubuntu daily?
<nabukadnezar43> apperantly it's called core
<sidi> rbasak, say i already have my own working tree, with some patches i wrote and applied and know are valid. I can of course build the whole package with bzr bd and test it, but what i want is to extract the source code of this working tree, along with the already written trees, to manually hack and build it like i'd do with a tarball downloaded off the internet (so I can write the next patch)
<sidi> it seems to me most tools only want an existing source package (either from apt-cache) or local
<sidi> so i'd need to build a source package from my working tree to set up this "hacking" source directory?
<rbasak> sidi: you can install all build dependencies locally if you want (or in a schroot). Then apply all patches with "quilt push -a" but you'll need to set up quilt first - https://wiki.debian.org/UsingQuilt
<Unit193> nabukadnezar43: Like http://archive.ubuntu.com/ubuntu/dists/vivid/main/installer-amd64/current/images/netboot/mini.iso ?
<rbasak> sidi: finally, run "debian/rules build" to build the tree. If the packaging is done well, then you can change the source and "debian/rules build" again
<sidi> rbasak i'm using quilt atm, i followed http://packaging.ubuntu.com/html/patches-to-packages.html
<sidi> i'm not sure i got that bit.
<sidi> what would be the benefit of using sbuild by the way, over just using quilt? I expect to have the non-amd64 packages built on the PPA, not to do it myself
<rbasak> sbuild builds in a clean environment. Eg. without any additional packages apart from the build dependencies. So other stuff cannot influence the build.
<nabukadnezar43> Unit193 thanks that's what i was looking for
<Unit193> nabukadnezar43: Great!  I presume you can find the 32bit one if needed too.
<rbasak> (also then you don't have to install all the build dependencies locally, so you don't clutter up your dev system itself)
<nabukadnezar43> yes but amd64 is what i need
<infinity> Unit193: FWIW, linking to http://cdimage.ubuntu.com/netboot/ is a lot less typing and much easier for people to remember more than 5 seconds after you tell them. :)
 * infinity notes that he needs to remove Saucy from that list, and does so.
<Unit193> infinity: ...That, would help.  Yes.  Kind of wondered why it wasn't there at one point, turns out..
<Unit193> Thanks.
<Unit193> Well I'm a genius...
<elfy> ...
<sidi> rbasak i see. i dont think it's a very big deal though if i've only installed an ubuntu for that purpose? or will i reliably run into trouble if i dont use sbuild? (mainly trying to avoid some work here, i wont be needing this build system for more than 1 or 2 months...)
<maxb> You can probably do most experimental dev work just find without sbuild, but you will always face the possibility of undeclared build-deps or other detected quirks causing a different result on builders to your local testing
<rbasak> sidi: yeah, what maxb said. So it depends on what sort of thing you're changing.
<rbasak> If you're messing with stuff that has little to do with the packaging, then you should be fine.
<sidi> alright i see
#ubuntu-devel 2016-03-28
<hikiko> slangasek, https://paste.ubuntu.com/15537883/ that's the "crash"
<hikiko> xserver is killed
<hikiko> maybe xserver is killed by systemd (?)
<hikiko> slangasek, that's my syslog http://pastebin.com/VJLsg8Ce
<hikiko> (the end of it)
<jdstrand> cjwatson: hey, fyi, missing parenthesis: bug #1562827
<ubottu> bug 1562827 in debmirror (Ubuntu) "Global symbol "$subdir" requires explicit package name at /usr/bin/debmirror line ..." [Undecided,New] https://launchpad.net/bugs/1562827
<rharper> are there any packages with daemons which have had to transition their service name (/etc/init.d/<name>) ?  I'm looking for examples, specifically if one can create aliases to aid the transition (existing scripts may refer to one name would fail after upgrading and the service now has a new name)
<nacc> rharper: not sure if it helps, but would dpkg-maintscript-helper's dir_to_symlink help? (or possiby the other direction)
<rharper> nacc: I'm looking for precedence actually
<rharper> I can create the symlink in any number of ways
<rharper> but currently find /etc/init.d -type l returns nothing;
<rharper> so I don't just want to start doing something without some discussion;
<nacc> oh i see
<rharper> rbasak already responded to the squid3 bug as someone raised concern that the squid package now uses service-name: squid , instead of squid3;
<nacc> right, i was just trying to think of other daemons that might have the version in the name
<rharper> the two in-archive cases, squidGuard and squid-deb-proxy are handled AFAICT (they both work post upgrade after fixing up one of the squid postinst scripts w.r.t the name of the service) ;
<rharper> nacc: heh, apache2
<rharper> but that's a different thing entirely
<nacc> yeah :)
<nacc> slangasek: luckily there's (alphabetically speaking) a big chunk of just rebuilds coming up, as they are all pear/pecl packages
<slangasek> nacc: did you see the follow-up on the phoronix-test-suite bug?
<slangasek> (just now)
<slangasek> ah, yes you did ;)
<nacc> slangasek: yep, will update it, thanks
<sarnold> congrats mwhudson :)
<mwhudson> sarnold: :-)
<nacc> mwhudson: congrats!
<nacc> woo, down to 325 packages to modify for php5 dependencies ...
<sarnold> \o/
<nacc> technically < 300 probably, based upon what's still not hit the reverse-dependencies service (and a set of ~30 auto-rebuilds just submitted)
<nacc> i'm learning to hate all php code quite quickly, though :)
<jgrimm> \o/
<sarnold> ureadahead seems unhappy, this is the second one of these i've seen today https://launchpadlibrarian.net/250163458/UbiquitySyslog.txt
<sarnold> e.g. ureadahead:/usr/lib/python3.5/gzip.py: Error retrieving chunk extents: Operation not supported
<tsimonq2> is there a way I can use an schroot of archs like armhf, arm64, ppc, etc. on my amd64 machine that I'm on now?
<slangasek> nacc: looks like the following packages have failed their no-change rebuild, I haven't looked to see why: phing php-apigen php-console-table phpdox
<nacc> slangasek: phing's is weird
<nacc> https://launchpadlibrarian.net/250245945/buildlog_ubuntu-xenial-amd64.phing_2.13.0-2build1_BUILDING.txt.gz
<nacc> there's a stray parentheses in that help2man command?
<tsimonq2> cyphermox: I've been talking to you, would you happen to know an answer ot my question? :)
<tsimonq2> *to
<nacc> tsimonq2: mk-sbuild takes arch optoins
<nacc> tsimonq2: i've had ... mixed results figuring them out :)
<tsimonq2> nacc: oh, any notable quirks?
<slangasek> nacc: buggy regexp that doesn't cope with Ubuntu-style version numbers
<nacc> slangasek: ok, it built fine here with release and proposed pockets, so not sure why it failed in lp
<slangasek> nacc: did you update debian/changelog for your test build?
<tsimonq2> and on the FTBFS tracker, bug 1547395 is linked for libquvi, but it really points to bug 1546957 , that should be linked instead
<slangasek> (he asks, rhetorically ;)
<ubottu> bug 1547395 in luasocket (Ubuntu) "MIR: new dependencies for libquvi-scripts / libquvi" [Undecided,New] https://launchpad.net/bugs/1547395
<ubottu> bug 1546957 in lua-lpeg (Ubuntu) "[MIR] lua-lpeg, needed by nmap" [High,Incomplete] https://launchpad.net/bugs/1546957
<nacc> slangasek: ah, :)
<cyphermox> tsimonq2: it depends, arm might work (but slowly), and I don't recall ever making ppc work properly in a schroot unfortunately, but I didn't really try that hard
<tsimonq2> cyphermox: thanks, I'll play with it :)
<cyphermox> tsimonq2: if you want to make it easy on yourself to get the chroots, I use sbuild-launchpad-chroot which downloads the tarballs straight from launchpad
<nacc> slangasek: apologies, i'll retest here
<tumbleweed> win 31
<nacc> slangasek: looks to be thes ame issue for php-apigen, and two of the others is a missing php-mbstring dep, will fix and submit bugs
<slangasek> nacc: build failure also for php-finder-facade
<nacc> slangasek: yep that's also mbstring related
<tsimonq2> cyphermox: oh cool thanks :)
<mwhudson> are there any tricks for lts->lts testing?
<mwhudson> i guess i can just create a trusty lxd and run do-release-upgrade in it...
<stgraber> not really, make a snapshot before and use do-release-upgrade (straight dist-upgrade isn't supported)
<stgraber> you may run into container-specific failures but we're still interested in those (we have fixed a few packages that try to create device nodes and other weird things on upgrade in the past)
<cyphermox> mwhudson: if you want desktop instead of server, be aware that there is bug 1555237
<ubottu> bug 1555237 in ubuntu-release-upgrader (Ubuntu) "Upgrade from 14.04.4â 16.04 dies midway taking out the session." [Critical,In progress] https://launchpad.net/bugs/1555237
<mwhudson> stgraber: extracting 'xenial.tar.gz'
<mwhudson> Must be connected to a terminal.
<mwhudson> ?
<mwhudson> i guess i can ssh into the container
<stgraber> mwhudson: or run things inside a "script /dev/null" session
<mwhudson> cyphermox: nah, i don't do anything users interact with, remember? :)
<stgraber> some things indeed are picky about having a visible backing pts device
<cyphermox> mwhudson: just making sure ;)
<mwhudson> stgraber: this is the screen that do-release-upgrade is launching, i think?
<mwhudson> cyphermox: yeah, thanks for the tip :)
<stgraber> mwhudson: yep
<stgraber> mwhudson: screen is unhappy when it can't find its /dev/pts device (in this case because the pts in question is in the host namespace)
<stgraber> mwhudson: I made a hackish glibc which fixed that but it needs a bit more work to be sane :)
<mwhudson> heh heh
<mwhudson> the whole tty/pty business is ... on the complicated side
<stgraber> mwhudson: tl&dr is that ttyname() returns an empty string when the controling tty (/proc/self/fd/0) can't be dereferenced, rather than returning the non-derefed (yet perfectly working) path
<tsimonq2> !info libcommons-net-java-doc
<ubottu> Package libcommons-net-java-doc does not exist in wily
<tsimonq2> !info libcommons-net-java-doc xenial
<ubottu> libcommons-net-java-doc (source: libcommons-net-java): Apache Commons Net (API documentation). In component universe, is optional. Version 3.4-2ubuntu2 (xenial), package size 285 kB, installed size 7344 kB
<stgraber> infinity: if you're bored and feel like fixing a glibc bug ^ :) otherwise whenever I am bored and feel like hacking on glibc, I may send a patch :)
<nacc> slangasek: how would you like to handle php-gnupg? upsream has  apatch that makes it work with php7, but it only passes 33% of the tests. They claim that is true for php5 too. I've not found a log for the php5 build yet
<tsimonq2> does libcommons-net-java have a MIR? I'm not seeing one and it would solve the FTBFS for commons-vfs. It's also not in the MIR bugs list. Just confirming either way
<slangasek> nacc: I am indifferent to most of these individual packages in universe; anything that doesn't work can be removed or left broken, and if php-gnupg's testsuite isn't /regressing/, that's good enough for me
<nacc> slangasek: yeah, it's not regressing afaict, but i am unable to find autopkgtest runs for php5-gnupg to confirm?
<slangasek> nacc: then nobody cared enough about the package to set it up for autopkgtest, and I don't think we should care either?
<nacc> slangasek: ok i didn't realize it needed that step, but now i recall you setting that flag in a control file, so it all becomes a bit clearer
<nacc> slangasek: yep, the old build failed the same amount:
<nacc> https://launchpadlibrarian.net/228695259/buildlog_ubuntu-xenial-s390x.php-gnupg_1.3.6-1_BUILDING.txt.gz
<nacc> so, was that build done somehow with a flag saying failing the build is ok? as for me on my system, the build fails at that point where not all tests are passed?
<nacc> slangasek: ok, those 5 build failures should be rsolved now
<mwhudson> hmm running do-release-upgrade under ssh in a screen resulted in the ssh connection dropping
<mwhudson> er
<mwhudson> hmm running do-release-upgrade under ssh in a *lxd container* resulted in the ssh connection dropping
<sarnold> mwhudson: was that a fully-updated 14.04 LTS container? or an "initial install" sort of image? that feels vaguely like a a systemd-logind issue I saw..
<mwhudson> sarnold: just whatever lxd launch ubuntu-daily:trusty gets you
<sarnold> 1543883
<mwhudson> bug 1543883
<ubottu> bug 1473800 in systemd (Ubuntu Trusty) "duplicate for #1543883 restarting logind during systemd update causes screen to lock" [Medium,Fix committed] https://launchpad.net/bugs/1473800
<sarnold> mwhudson: ah then that's probably got this fix already..
<mwhudson> i'd assume so
<mwhudson> when i ssh back into the lxd everything seems happy
<mwhudson> but it's a bit unsettling
<sarnold> very
<sarnold> especially since not everyone will think to start the upgrade in a shell or tmux
<sarnold> sigh screen..
<mwhudson> well do-release-upgrade does that for you
<mwhudson> but that dies too
<mwhudson> it seems
<mwhudson> i guess that's even more unsettling :)
#ubuntu-devel 2016-03-29
<mwhudson> hm, running do-release-upgrade under a screen i created worked fine
<mwhudson> hm the next question is how do i do lts to lts testing of a package change i want to make?
<slangasek> mwhudson: bypass do-release-upgrade and just use apt-get dist-upgrade
<mwhudson> oh ok
<slangasek> nacc: so your rebuild.3 list includes php-hamcrest, which I know I just did a non-no-change upload of...
<mwhudson> that's not supported but actually works in practice?
<stgraber> mwhudson: depends on the lts-to-lts in question, sometimes, as was the case with multiarch, the source apt isn't capable of understanding some package relationships in the target series, in which case the upgrade will blow up
<stgraber> mwhudson: that's why we don't support dist-upgrade officially
<mwhudson> ok
<stgraber> mwhudson: do-release-upgrade downloads an upgrader tarball which contains the apt and dpkg of the target series
<mwhudson> that shouldn't be a problem trusty->xenial?
<stgraber> yeah, I'm not aware of any big archive change which would be a problem
<stgraber> however if you do find an apt bug, then you'll be stuck :)
<mwhudson> oh no i might break a container!
<mwhudson> this happened to an upgrade again: http://paste.ubuntu.com/15548112/
<mwhudson> is there some idle timeout somewhere?
<stgraber> could be logind or something killing your session
<sarnold> no details of any sort printed? how annoying
<mwhudson> i also get this when i log back in: http://paste.ubuntu.com/15548150/
<mwhudson> should i file a bug for this?
<mwhudson> (and if so, which project?)
<cyphermox> mwhudson: there's not enough to know there, you'd want to look at /var/log/dist-upgrade if it mentions anything to clue you in which package has an issue, otherwise it might be ubuntu-release-upgrader
<cyphermox> the ssh session seems to die too early to be because of stuff being upgraded, though
<mwhudson> there's nothing much odd looking in /var/log/dist-upgrade
<nacc> slangasek: argh, sorry! just forgot to update the list
<nacc> slangasek: that's the only one that should be cross-listed
<mwhudson> well that odd session killing behaviour doesn't happen when you just run dist-upgrade
<mwhudson> so i guess that's a ubuntu-release-upgrader bug
<cyphermox> err, we don't do stuff to the session in u-r-u
<cyphermox> or at least, not that I can think of would make sense, or that I've noticed in the code so far
<cyphermox> I also already did an upgrade successfully not that long ago, a few days maybe
<mwhudson> hmm
<mwhudson> it could also point to a problem in lxd i guess?
<mwhudson> cyphermox: did you do your upgrade in lxd or a real system?
<cyphermox> file a bug against ubuntu-release-upgrader, and make sure the logs are included (whatever is in /var/lib/dist-upgrade, as well as the apt-clone tarball if possible)
<cyphermox> it was a VM, but not lxd
<cyphermox> I may be wrong about the upgrade being successful. that would be a good data point for the desktop upgrade issues too
<mwhudson> ah i've killed the lxd
<mwhudson> will reproduce in a moment
 * mwhudson gets ready to use his new superpowers for the first time
 * sarnold stands back
<mwhudson> no regular expressions are involved
<mwhudson> filed https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1563168 fwiw
<ubottu> Launchpad bug 1563168 in ubuntu-release-upgrader (Ubuntu) "14.04 -> 16.04 upgrade in lxd container dies most of the way through" [Undecided,New]
<cpaelzer> good morning
<dholbach> good morning
<mwhudson> my first upload to ubuntu appears to have migrated fine without exploding the universe, i guess that's good :)
<infinity> mwhudson: Alternately, whatever you screwed up is something our infrastructure doesn't catch. ;)
<mwhudson> infinity: yeah, probably
<mwhudson> haha
<mwhudson> i was thinking of making some joke along the lines of "given that there is a lxd upload every 10 minutes or so we'll find out soon"
<mwhudson> and it turns out that lxd was published in -proposed *3 minutes ago*
<infinity> :)
<infinity> mwhudson: If lxd is your testcase, I'm assuming the implication is that you've finished the go-default migration and all should be good?
<infinity> lxd built everywhere, so that's a good sign.
<mwhudson> infinity: yeah, that's all done, it was just some tweaking today
<mwhudson> and a new patch from IBM
<infinity> mwhudson: Well, congrats on getting your upload on.  Sorry I wasn't there to give another +1, but clearly I wasn't needed. :P
<mwhudson> thanks!
<cpaelzer> jamespage: that dpdk upload of last wednesday still doesn't show up but also isn't in update_excuses
<infinity> cpaelzer: It's sitting in the unapproved queue, awaiting review.
<infinity> (long weekends hurt)
<cpaelzer> infinity: oh thanks, at least I found it now
<cpaelzer> infinity: is there anything I can do to help?
<infinity> Other than "not upload 26k diffs"?
<cpaelzer> infinity: yeah other than packaging bleeding edge stuff that feels like it could take 25k patches every day :-/
<cpaelzer> just trying to get things stable and working til release
<infinity> Understood.  If no one beats me to it tonight, I'll review it in the morning.
<cpaelzer> infinity: thanks, and double thanks for identifying where it currently resides
<xnox> infinity, lovely, but what is that?
<infinity> xnox: systemctl status
<xnox> hahahahaha
<xnox> Failed to initialize libzfs
<xnox> fun
<cjwatson> jdstrand: Yep, thanks, will sort out ASAP.  Feeling very stupid about that one, I swear I tested but obviously not quite the final thing I uploaded.  I'll also add a syntax check to the build process so that sort of thing can't happen again.
<martinst-> slangasek ping
<Mirv> ok I managed to find out that new glibc is the cause for bug #1560528. so I'll leave the bug to be against glibc while commenting out the test on 32-bit archs in order to get forward with new Qt upload.
<ubottu> bug 1560528 in qtbase-opensource-src (Ubuntu) "tst_LargeFile::mapOffsetOverflow started failing on 32-bit xenial" [Undecided,Incomplete] https://launchpad.net/bugs/1560528
<ogra_> smoser, pingaling ... seems cloud-init messes up a lot more on snappy (like creating a duplicated /e/n/i config now)
<ogra_> (snappy creates that itself on first boot from snappy config)
<ogra_> smoser, bug 1563296 for you
<ubottu> bug 1563296 in cloud-init (Ubuntu) "cloud-init 0.7.7~bzr1189-0ubuntu1 adds duplicated network config in /etc/network/interfaces.d/ in snappy leaving the boot completely network-less " [Undecided,New] https://launchpad.net/bugs/1563296
<doko> tumbleweed, are you asking for a FFe for pypy 5.0?
<spineau> cyphermox: hello
<spineau> cyphermox: I commented on your tpm2-tools bug, https://bugs.launchpad.net/ubuntu/+bug/1561834/
<ubottu> Launchpad bug 1561834 in Ubuntu "[FFE] [needs-packaging] tpm2-tss and tpm2-tools" [Wishlist,Confirmed]
<spineau> cyphermox: I've started to use the TSS tpmtest tool
<spineau> cyphermox: you also could consider adding it to one of the existing binaries
<spineau> cyphermox: it's not super verbose about the errors when it fails but it can certainly help developers/testers
<cyphermox> ok
<spineau> cyphermox: I looked at it this morning and upstream commits quite often to this tool, so I guess it's useful at least for them :)
<spineau> cyphermox: sorry to jump quite late in the review though
<LocutusOfBorg> hi folks, can anybody please retry https://launchpad.net/ubuntu/+source/libvirt/1.3.1-1ubuntu8/+build/9336238 https://launchpad.net/ubuntu/+source/libvirt/1.3.1-1ubuntu8/+build/9336239 https://launchpad.net/ubuntu/+source/libvirt/1.3.1-1ubuntu8/+build/9336243
<LocutusOfBorg> they should build now and make libvirt migrate
<LocutusOfBorg> @core-devs ^^
<udevbot> Error: "core-devs" is not a valid command.
<caribou> LocutusOfBorg: ok, will do
<LocutusOfBorg> thanks
<LocutusOfBorg> how is it possible?
<LocutusOfBorg> damn
<LocutusOfBorg> universe-main?
<LocutusOfBorg> thanks, but LP: 1532198 needs to be sorted out before
<ubottu> Launchpad bug 1532198 in zfs-linux (Ubuntu) "[MIR] zfs-linux" [High,Incomplete] https://launchpad.net/bugs/1532198
<slangasek> martinst-: hi
<Skuggen> Anyone here familiar with dbconfig-common? I've been looking into LP: 1563274, but I can't find a simple solution
<ubottu> Launchpad bug 1563274 in mysql-5.7 (Ubuntu) "dbconfig-mysql sets blank port in config" [Undecided,New] https://launchpad.net/bugs/1563274
<LocutusOfBorg> infinity, did you get the time to dig into lp: 1562480?
<ubottu> Launchpad bug 1562480 in glibc (Ubuntu) "fp-compiler not installable on powerpc since glibc 2.23" [Undecided,New] https://launchpad.net/bugs/1562480
<LocutusOfBorg> I'm trying to read the code, but without real hw is impossible I think
<cyphermox> Laney: hey
<infinity> slangasek, stgraber, kees, mdeslaur: Tee Bee?
<mdeslaur> infinity: ah! yes
<smoser> can someone please confirm ? i'm
<smoser> in xenial, nothing from udev will write /etc/udev/rules.d/70-persistent-net.rules
<smoser> previously it would get written with a header like:
<smoser> # This file was automatically generated by the /lib/udev/write_net_rules
<smoser> # program, run by the persistent-net-generator.rules rules file.
<smoser> but '/lib/udev/write_net_rules' is gone now. as is 'persistent-net-generator.rules'
<cjwatson> jdstrand: do my debmirror fixes supersede RT#89946, or is that an independent problem?
<jdstrand> let me check. I think it is a different problem
<sarnold> smoser: pit ti sent this around a while ago https://lists.ubuntu.com/archives/ubuntu-devel/2015-May/038761.html
<sarnold> smoser: I'm not sure it was 100% done, but it looks like ifnames uses /lib/udev/rules.d/80-net-setup-link.rules instead
<jdstrand> cjwatson: rt is still an issue
<smoser> sarnold, thank you
<tumbleweed> doko: do you want me to? :)
<tumbleweed> I've spent the last two weeks fighting with it
<tumbleweed> doko: do you have access to a big endian porterbox with lots of RAM? I want to find if a patchset I'm proposing makes a significant difference on big endian. And it'll take me another couple of days on debian's porterboxes
<Pharaoh_Atem> nacc: so, I've got a port of libvirt-php that is *supposed* to work on php7, which I'm getting some folks at my workplace to help complete so that I can submit it back upstream
<Pharaoh_Atem> nacc: it's available here in the php7 branch: https://gitlab.com/Conan_Kudo/libvirt-php7
<Pharaoh_Atem> nacc: do you know what the latest date it can be, before we'd have to make a decision on dropping a package?
<Pharaoh_Atem> because I'm trying to get the timelines worked out so that I can get everything done and submitted upstream in time
<nacc> Pharaoh_Atem: depending on the importance, we might be able to leave it as uninstallable
<nacc> Pharaoh_Atem: it's good, in some sense, that it's in universe
<Pharaoh_Atem> because there's not much in the way of guarantees there?
<nacc> well, if it was in main, that wouldn't be an option
<sarnold> there's always kicking it out of main, too :)
<nacc> Pharaoh_Atem: what's your tentative eta?
<Pharaoh_Atem> nacc: I'm trying to pull together the finishing work within the next week or two, and try to get it reviewed and upstream a week afterward
<Pharaoh_Atem> I'd like to pull the timelines in more, but it's getting really hard to get resources
<Pharaoh_Atem> from what Remi said, the current tree should be buildable, but I have no idea how well it works because the test coverage is abysmal
<nacc> Pharaoh_Atem: yeah so that'd be outside of getting into 16.04 if it's not available upstream yet, but let's sync up again tmrw (i'm trying to get as much of the list that can be done completed)
<Pharaoh_Atem> okay
<Pharaoh_Atem> nacc: do you know what the cutoff date would be to get it into 16.04?
<Pharaoh_Atem> I can try to get things prioritized to make it in, or at least provide a squashed patchset to apply while it sits in review
<nacc> https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule
<Pharaoh_Atem> so would the April 14th date be the correct one?
<Pharaoh_Atem> ls
<Pharaoh_Atem> >_>
<nacc> final freeze implies bugfixes only, so really it should be sooner than that, afaqict
<nacc> but since it's in universe ...
<nacc> and it's not seeded, is it?
<Pharaoh_Atem> how would I know if it's seeded?
<nacc> it's not
<nacc> `seeded-in-ubuntu libvirt-php`
<Pharaoh_Atem> ah
<Pharaoh_Atem> yeah, it's not
<elbrus> Skuggen: /me received the bug about dbconfig-common, thanks
<elbrus> I will need to think about it
<elbrus> and indeed, probably not a trivial solution
<slangasek> nacc: somewhat curious why all of these php-horde packages that are being changed now only to adjust test deps didn't show up as regressions when stuff was migrating earlier
<slangasek> nacc: e.g. maybe things that only have test deps on php5 should be left to the end?
<slangasek> or I guess these also have runtime deps for which they need no-change rebuilds, hmm
<nacc> slangasek: right, they really need no-change rebuilds, but then their test will forcibly use php5
<slangasek> gotcha
<nacc> (afaict)
<slangasek> nacc: sorry, ignore my vain attempt to reduce the number of uploads I'll be sponsoring today ;)
<nacc> slangasek: :) yeah it's a bit ugly; i'm going to go and try to clean up excuses again now and respond to the bugs from over the weekend
<elbrus> Skuggen: do you know if /etc/mysql/debian.cnf is already fixed in mysql-server-5.7? Because dbconfig-common takes its defaults from there...
<Skuggen> Hang on, let me take a look at it.
<elbrus> Skuggen: ignore my last comment
<Pici> 25
<nacc> slangasek: fyi, the php-pear failures (only on amd64) might be transient autopkgtest issues?
<Skuggen> elbrus: Ah :D
<nacc> slangasek: can you check and possibly resubmit those?
<Skuggen> If you want to look at it, though, it's here: https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.7.git/tree/debian/mysql-server-5.7.postinst#n160
<slangasek> nacc: let me get through this sponsorship queue first and I'll look
<nacc> slangasek: sounds good, thanks
<elbrus> Skuggen: so indeed debian-sys-maint logs in via the socket so doesn't have this issue
<Skuggen> elbrus: We did actually find a bug in the 5.7 postinst when investigating the dbconfig issue; The debian-sys-maint user doesn't have access to grant other users access, which will cause installation of redmine/phpmyadmin to fail if mysql-server-5.7 is already installed
<Skuggen> Yeah, it shouldn't be affected by this issue
<elbrus> Skuggen: you are coordinating/working as Debian mysql team as well, right?
<Skuggen> Yeah
 * elbrus is more a Debian guy than an Ubuntu guy
<slangasek> neat, did not know syncpackage had a -V option
<nacc> slangasek: ah that's handy!
<slangasek> nacc: especially since php-horde-mapi 1.0.8-1 is now available
<infinity> slangasek: syncpackage has a -V option.
<Skuggen> The packaging I linked to is actually primarily for Debian, but we just apply a couple of changes for Ubuntu, like removing the libmecab-dev build-dep
<nacc> i was just looking for that and had given up for php-horde-mapi bug
<elbrus> Skuggen: mariadb-server is/was setting the password to the empty string.. is that also going to fail?
<nacc> slangasek: yeah, i should see if i can patch requestsync to take one too :)
<slangasek> infinity: that's super neat!  now tell me something I don't know
<Skuggen> elbrus: Both mariadb and mysql have changed to set root access through unix socket only if the password supplied is empty
<Skuggen> Er, nevermind, that only affects the root user during installation of the server
<Skuggen> But no, string options can be blank
<elbrus> Skuggen: and dbconfig-common during any database operation
<infinity> slangasek: Emus can sprint at 30mph.
<elbrus> because that runs as root
<slangasek> infinity: actual thought process: "darn, there's a newer version of php-horde-mapi that invalidates this sync request.  But wait, a sync is just an LP API call, and LP has imported the older versions too... I wonder if there's an option..."
<elbrus> and takes the password from /etc/mysql/debian.cnf
<Skuggen> elbrus: Ah, right, so if dbconfig installs the server it will set an empty root password?
<elbrus> (as agreed with Otto Kel...)
<infinity> slangasek: But yes, syncpackage is just (yet another) wrapper around copy-package, so if it didn't take a -V, it would have been trivial to add one.
<elbrus> Skuggen: eh... dbconfig doesn't install the server
<infinity> slangasek: I feel like half our tools are friendly wrappers around copyPackage(), which doesn't say much for the friendliness of copy-package(1) itself. :P
<Skuggen> elbrus: I'm a bit confused. Does dbconfig use the root user or debian-sys-maint (which is the one in debian.cnf)?
<elbrus> it just uses the credentials in /etc/mysql/debian.cnf to log into the local server to create the database and users
<slangasek> infinity: syncpackage does a copy-package plus other things (bug closures)
<Skuggen> elbrus: Then it's using debian-sys-maint, and that's fine
<elbrus> Skuggen: debian-sys-maint if the server is mysql-server and root if it is mariadb server
<infinity> slangasek: Fair.  Other wrappers are also a bit more interesting (like sru-release).
<elbrus> dbconfig just takes it from /etc/mysql/debian.cnf, so I don't care what is there
<Skuggen> I'm not 100% sure about mariadb, but that should be fine for mysql
<infinity> slangasek: Of course, then there's copy-proposed-kernel, which other than filtering *-signed, is pretty much JUST a wrapper so we don't have to remember copy-package args.
<infinity> slangasek: But whatever works. :P
<elbrus> I talked to the maintainer of mariadb at FOSDEM and we agreed that this was the best
<elbrus> the autopkgtests of dbconfig-common also test both mariadb and mysql
<Skuggen> elbrus: Yeah, using debian.cnf will work fine. Mysql still uses that in the same way in the maintenance scripts. Only difference in 5.7 is that we removed a deprecated option from it (basedir)
<elbrus> do you know why the previous test used mysql-server-5.7 and the latest test mysql-server-5.6?
<Skuggen> Which latest test?
<elbrus> autopkgtest of dbconfig-common
<infinity> elbrus: If mysql-5.7 is still in -proposed (I assume it is), the default is to test against the release pocket.
<slangasek> nacc: I beat you to php-horde-kolab-storage already (it was blocking migrations over the weekend)
<elbrus> that is how I already knew that it was broken, but the latest test appeared to be fixed
<nacc> slangasek: ah ok, thanks!
<elbrus> infinity: but it tests once against proposed to check?
<Skuggen> elbrus: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mysql-5.7 is what I've been looking at
<slangasek> nacc: I've noticed a few times that your patches are out-of-date wrt the archive; are you using pull-lp-source to make sure you always get the latest version when you start working?  Or is it just a delay between when you grab the package and when you submit the bug?
<Skuggen> Uploading of 5.7 to proposed would trigger it to test against it
<infinity> elbrus: When a dep is uploaded, we test rdeps against it, and that's what we record as the current state for that pair of packages.
<elbrus> Skuggen: than I am sooooo glad that I have those tests... I would have been a pain if we discovered afterwards
<infinity> elbrus: So, what you're seeing in http://autopkgtest.ubuntu.com/packages/d/dbconfig-common/xenial/amd64/ is, essentially, a statement that "updating ucf doesn't break dbconfig-common, but updating mysql does".
<Skuggen> elbrus: Same here. For instance I know this will also break phpmyadmin, but that didn't show up there :)
<nacc> slangasek: i think it's just the latter, i'll try to be more diligent about checking that going forward
<elbrus> that is because phpmyadmin uses dbconfig-common
<elbrus> or something else?
<Skuggen> It can also use mysql as a backend, in which case it'll break with the same blank port option error
<infinity> elbrus: So, the outcome of that is that we'd let ucf migrate, but we won't let mysql migrate until both mysql and dbconfig-common get along.
<infinity> elbrus: If that makes sense?
<elbrus> sure
<elbrus> so that puts presure on the solution as I expect that Ubuntu 16.04 wants to ship with 5.7
<infinity> Indeed, that's the goal, though time is certainly running out on realizing it.
<Skuggen> elbrus: There is a potential stop-gap solution we could do on the mysql end if this is too big a task
 * elbrus is also involved with php7.0 transition... 
 * elbrus would like it that these things happen earlier in the cycle
<Skuggen> Yeah :|
<Skuggen> We could patch the mysql client to allow the empty port option as it was in 5.6, but that really shouldn't be a lasting solution
<elbrus> Skuggen: agree, but it would buy us time to find a proper solution
<elbrus> without rushing
<Skuggen> Yeah. I'm going to test it tomorrow.
<infinity> elbrus: It seems that everyone's best work happens right after you announce a freeze; the obvious solution is for me to open a new cycle with "we will be frozen for the next six months, no major changes allowed" and watch the uploads roll in.
<slangasek> nacc: php-horde-javascriptminify-jsmin was also done already
<elbrus> :)
<Skuggen> infinity: But you'd have to keep adding freeze cycles as people get wise to it :)
<Skuggen> elbrus: I just wanted to get some feedback on whether this was simple to fix in dbconfig and I was just too confused by it to spot it :)
 * elbrus always tries to not rush things in, but indeed we also did it for lazarus (which now fails on powerpc because of glibc update)
<infinity> Skuggen: Yup, it's like the alarm clock rewing arms race.
<infinity> s/rewing/rewind/
<infinity> elbrus: Yeah, I was looking into the fpc/ppc thing over the weekend a bit.  Still not solved, but I got... Somewhere.  I think.  Ish.
<elbrus> Skuggen: I don't think it is trivial as it requires careful thinking about corner cases
<elbrus> infinity: I heard from ginggs
<Skuggen> Ok. I'll test the client patch tomorrow then. We really need to get these test issues cleared up :)
<Skuggen> This should fix the redmine failures as well
<elbrus> Skuggen: redmine is using dbconfig-common as well...
<Skuggen> Yeah
<Skuggen> Both redmine and phpmyadmin get database config files from dbconfig, so the issue propagates to them
<elbrus> indeed
<elbrus> but redmine probably got tested seperately because it does not require mysql (it can work with other dbs)
<Skuggen> I'll post an update to the bug once I've tested the patch
<slangasek> nacc: I think I'm keeping up with all of the patches you're attaching, but you might want to make sure when you're adding a patch to a bug for an already-uploaded bug that you reopen the bug
<nacc> slangasek: similarly, the php-crypt-gpg failure with ubuntu2 is a infra issue (internal timeout)
<nacc> slangasek: yep, duly notied
<slangasek> nacc: yeah, the php-pear failures are marked 'tmpfail' on ci.u.c, unfortunately these just show up as 'regression' on update_excuses and there's no autoretry
<slangasek> (retried now)
<nacc> slangasek: ah ok, thanks!
<nacc> slangasek: it seems like php-fdomdocument should go through, as the version of phpdox actually in the archive now did pass its tests?
<nacc> same for php-fxsl
<slangasek> nacc: usual process, we retry those tests now that the new version is in xenial so that we confirm that the cross-configuration works and there really aren't any regressions.  I'll retry those now
<nacc> slangasek: ok, thanks
<nacc> slangasek: make sense, i'm just not allowed to resubmit
<slangasek> yep
<slangasek> nacc: have you started your Ubuntu developer application yet?
<nacc> slangasek: no, that's on my todo for this week
<slangasek> ;)
<slangasek> nacc: oh and php-apigen FTBFS again
<nacc> slangasek: i believe it needs the patch from LP: #1563098
<ubottu> Launchpad bug 1563098 in php-apigen (Ubuntu) "Update d/rules UPSTREAM regex" [Undecided,Fix committed] https://launchpad.net/bugs/1563098
<nacc> does it still fail with that?
<slangasek> nacc: pretty sure that's the one I just uploaded
<slangasek> yeah it is
<slangasek> heh, https://launchpadlibrarian.net/250345806/buildlog_ubuntu-xenial-amd64.php-apigen_4.1.2-1ubuntu1_BUILDING.txt.gz
<slangasek> nacc: did you build-test this, or blindly trust my regexp? ;)
<slangasek> nacc: I think my regexp is right but that it's not properly escaped for makefile
<nacc> slangasek: blind trust :) my own fault will fix it locally and update
<nacc> slangasek: given that the build has failed, can i submit an update to the existing version?
<nacc> slangasek: or does it need to be an ubuntu2?
<slangasek> nacc: must be ubuntu2. once the source is accepted by Launchpad, the version is burnt
<nacc> ok, thanks
<nacc> slangasek: is there any reason the regex couldn't just be: 's/.*(//;s/-.*).*//' ?
<slangasek> nacc: it's less generally correct for Debian versioning; the Debian part of the version number is always the part after the /last/ -
<nacc> slangasek: so, sed 's/.*(//;s/-[^-]*).*//'
<nacc> ?
<martinst-> slangasek ping
<slangasek> nacc: try and see, I think
<infinity> nacc: Are you trying to split debian versions?
<infinity> echo 2:1.2.3-5-09-0ubuntu1 | sed -e 's/\([0-9]*\):\(.*\)-\(.*\)/Epoch: \1, Upstream: \2, Debian: \3/'
<infinity> Something like that works.
<infinity> Though less friendly when all the components aren't there...
<slangasek> infinity: he just needs the upstream version, and is trying to adjust the existing Debian packages' buggy regexp
<slangasek> infinity: and he's parsing dpkg-parsechangelog output in one step
<cjwatson> jdstrand: Thanks for checking
<Saviq> slangasek, hey, I've a feeling new cmake will cause us a lot of trouble: bug #1563548
<ubottu> bug 1563548 in cmake (Ubuntu) "CMake 3.5's pkg-config support broken" [Undecided,New] https://launchpad.net/bugs/1563548
<Saviq> mterry, FYI â
<slangasek> Saviq: <self censoring>
<infinity> slangasek: Right.  Well, my above crap regex lays out the components, but obviously fails if some aren't present.  Needs to be a bit more complex to adjust for the fact that all but the middle one are optional.
<slangasek> WHO put cmake 3.5.0 into the archive past the freeze?
<infinity> slangasek: I find it's easier (or, easier to read), if one just does it in three steps instead of one scary one.
<LocutusOfBorg> slangasek, LP: 1534263
<ubottu> Launchpad bug 1534263 in cmake (Ubuntu) "[FFe] [merge request] Import cmake-3.5 series to Ubuntu Xenial 16.04LTS" [High,Fix released] https://launchpad.net/bugs/1534263
<Saviq> ok so maybe not *that* much headache, but at least unity8 doesn't build, and I can find a few more projects relying on those variables that are suddenly empty in cmake 3.5 for no good reason
<doko> tumbleweed, well, it's in main, but as a b-d, so with the archive-reorg on the horizon, it still could be demoted
<Saviq> they should be there as far as I can read https://cmake.org/cmake/help/v3.5/module/FindPkgConfig.html
<slangasek> Saviq: cross-build for unity? or native build?
<Saviq> slangasek, native unity8 build
<slangasek> LocutusOfBorg: ^^ please figure out why Saviq's build isn't working
<Saviq> LocutusOfBorg, we rely on the _INCLUDEDIR variable to find some shared .h files, that var (and LIBDIR and VERSION) are now empty
<slangasek> LocutusOfBorg, Saviq: I give this until my end of day to get sorted, and then I am uploading a revert of the cmake merge
<LocutusOfBorg> slangasek, probably that path cross stuff in ubuntu2 might be the clue
<Saviq> LocutusOfBorg, that's a diff between 3.2 and 3.5's cache for pkg_check_modules(GLIB2 glib-2.0) http://pastebin.ubuntu.com/15555106/
<LocutusOfBorg> Saviq, can you please try with the shiny just uploaded cmake 3.5ubuntu2?
<Saviq> LocutusOfBorg, sure, trying
<mwhudson> slangasek, infinity, nacc: if you are doing things to debian versions with regexes, consider just given up and writing perl instead
<slangasek> twitch no
<mwhudson> Dpkg::Version is more readable than a regex...
<Saviq> LocutusOfBorg, FWIW this is native build, not cross, so I'd be surprised
<LocutusOfBorg> Saviq, I saw your bug report as soon as you opened it, and I liked it already in the 1534263 bug
<LocutusOfBorg> Saviq, building cmake on my wily, lets see
<LocutusOfBorg> Saviq, I have not confirmed
<LocutusOfBorg> slangasek, (please read)
<LocutusOfBorg> but your issue is the following code
<LocutusOfBorg> include(FindPkgConfig)
<LocutusOfBorg> if you read that FindPkgConfig file
<LocutusOfBorg> if(EXISTS "/etc/debian_version")
<LocutusOfBorg>   include(${CMAKE_ROOT}/Modules/MultiArchCross.cmake OPTIONAL RESULT_VARIABLE _INCLUDED_MULTIARCH_TOOLCHAIN_FILE)
<LocutusOfBorg> endif()
<Saviq> ah so maybe it is the missing bit after all
<Saviq> that'd be good
<LocutusOfBorg> so probably this is defined in many other places, and somewhere it is blowing up stuff
<LocutusOfBorg> it might seem not related, but cmake does rely on it in other places
<slangasek> ok
 * LocutusOfBorg tried to remove it once ago, when he did some merge work
<LocutusOfBorg> anyhow, 90% of the build completed, let me test
 * LocutusOfBorg was traveling on train, otherwise he could have restored the block tag quickly
 * Saviq sad nobody tried a cross-build when uploading new cmake :/
<Saviq> we're really not treating our cross story with the attention it deserves
<LocutusOfBorg> Saviq, some autopkgtestsuite might be good
<LocutusOfBorg> anyway, I have been to busy and sick today to help as I wished
<LocutusOfBorg> and I did my contribution a little bit late
<LocutusOfBorg> I hope to fix everything in the next few hours, fever permitting
<slangasek> Saviq: sorry, I was aware of the request to include a new cmake in xenial and that the cross-support might not have been handled, but I had not seen the FFe request or that pitti had granted it
<nacc> infinity: yeah, what slangasek said; i wonder if there should just be some DEBHELPER option for doing it for you, but I've noted down your example; I think we've got the buggy regexs fixed for now
<Saviq> LocutusOfBorg, afraid it doesn't help
<LocutusOfBorg> Saviq, I saw
<LocutusOfBorg> debugging
<LocutusOfBorg> in file FindPkgConfig.cmake:111 the variables are correctly filled
<LocutusOfBorg> Saviq, I got it
<LocutusOfBorg> probably
<LocutusOfBorg> Saviq, please test
<LocutusOfBorg> in FindPkgConfig.cmake
<LocutusOfBorg> -          _pkgconfig_set("${_pkg_check_modules_pkg}_${variable}" "${${_pkg_check_modules_pkg}_${variable}}")
<LocutusOfBorg> +          _pkgconfig_set("${_pkg_check_prefix}_${variable}" "${${_pkg_check_prefix}_${variable}}")
<nacc> slangasek: i'm not able to reproduce the php-horde-http failure from autopkgtest, and the error doesn't make a lot of sense to me, as i only changed the running to be php-cli (so it'd be the php7 runner) ... could that be a transient issue?
<nacc> slangasek: php-horde-mapi is a real failure and i'm trying to figure out how best to deal with it, might be a bit convoluted :/
<slangasek> nacc: perhaps it's because php-horde-exception was uploaded in parallel, which means php-horde-http is being tested against the old version of php-horde-exception, which was still set up for php5?
<slangasek> nacc: so not "transient", but ordering; can be given a straight retry once php-horde-exception is resolved, which is bound up with php-horde-mapi that you just mentioned
<nacc> slangasek: yep, that does look likely, thanks for clarifying
<LocutusOfBorg> slangasek, can you please sponsor the debdiff?
<slangasek> LocutusOfBorg: link?
<LocutusOfBorg> https://launchpadlibrarian.net/250356853/debdiff
<LocutusOfBorg> just attached to the bug
<LocutusOfBorg> upstream messed up the parameters of the macro
<LocutusOfBorg> this patch is *so much* conservative, I keep both variables in the CMakeCache.txt file
<LocutusOfBorg> even if one seems rather useless
<LocutusOfBorg> you can also drop that line, I honestly think it was just a typo
<nacc> slangasek: ok, so I need some guidance here: there are two packages, src:php-seclib and src:php-phpseclib, v1.0 and v2.0 of the same library. Debian has repackaged the latter so they are coinstallable, because the former is backwards compatible to PHP5 (which they still support). Upstream seclib is not updating 1.0 to PHP7 compliance because upstream 1.0 is BC to PHP4 :) There was a point in the Debian
<nacc> package where they had broken BC and we probably woudl have passed the php-horde-mapi tests, but it broke BC and they reverted in Debian.
<nacc> slangasek: i see two ways forward: 1) we diverge from debian's php-seclib and put the php7 patch back in
<nacc> 2) we migrate the dependencies on php-seclib to php-phpseclib and remove php-seclib
<nacc> but the debian packaging for php-phpseclib allows for both to be installed, so the php files in php-phpseclib get put in /usr/share/php/phpseclib ... which in turn makes them not in the usual place for callers
<slangasek> LocutusOfBorg: uploading.  You've tested that this fixes Saviq's problem?
<LocutusOfBorg> I'm updating the bug report with V=1
<nacc> slangasek: so either way we'd diverge from debian, and i'm not sure which is better; debian's chagnelog (in git) also mentions not all users will be php-seclib 2.0 ready, although I'm not 100% on what the means
<LocutusOfBorg> slangasek, that was the testcase I used to dig into the issue
<slangasek> nacc: it sounds to me like re-patching php-seclib would be the quickest fix and require the least amount of chasing loose ends
<LocutusOfBorg> so, yes, I confirm the variables are correctly filled on a xenial amd64 pbuilder clean chroot
<LocutusOfBorg> and it seems a stupid upstream typo I'm going to report
<nacc> slangasek: yeah, let me see if we can do that easily
<LocutusOfBorg> damn damn damn
<LocutusOfBorg> my holy glories about contributing to cmake codebase vanished
<LocutusOfBorg> https://anonscm.debian.org/cgit/pkg-cmake/cmake.git/commit/?id=b71943bca4ed372568050d460960764ca2b3d4aa
<LocutusOfBorg> two hours ago, version 3.5.1 landed in Debian
<LocutusOfBorg> *exactly* the same fix
<sarnold> awww
<sarnold> better luck next bug :)
<nacc> slangasek: would you be ok with a sync to a version that's not current in Debian (1.0.1-3 vs. 1.0.1-4; we currently have 1.0.1-1) or would you rather we take 1.0.1-4 and revert the revert? I'm not sure which is clearer
<LocutusOfBorg> sarnold, I already had one bug in kernel codebase, already fixed but not merged because of 4.6 window not yet open blah
<sarnold> LocutusOfBorg: \o/
<LocutusOfBorg> patch sent, but somebody was quicker for a few days
<sarnold> aww
<LocutusOfBorg> and it happened with glib on sparc
<LocutusOfBorg> happy to see people faster than me :D
<sarnold> the other user found it first? hehe
<LocutusOfBorg> I reported the bug on glibc it was fixed on 2.23 already, but debian and ubuntu were a little bit behind the latest release
<LocutusOfBorg> and sparc not a release arch anymore, so nobody noticed it
<LocutusOfBorg> slangasek, honestly I think because of the fixes in 3.5.1 (little changes, trivial to check, no new features and so on), 3.5.1 might be a better candidate for xenial
<LocutusOfBorg> but maybe I'll propose a debdiff if no new bugs are opened
<infinity> If we're committed to 3.5, 3.5.1 is likely better, yes.
<infinity> (Saying that without looking, mind you)
<LocutusOfBorg> I think we are committed to 3.5, if things don't break, or if things breaks and we can fix them quickly :)
<Saviq> slangasek, LocutusOfBorg, confirmed fixes
<rharper> slangasek: jgrimm: I generated a new debdiff for squid3 (https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1473691); this includes the dist-upgrade fix I identified on Monday;  it would be good to get this uploaded into proposed (to replace the current one) so we can further test squid in proposed with dist-upgrade and other scenarios.
<ubottu> Launchpad bug 1473691 in squid3 (Ubuntu) "[FFe] squid: Update to latest upstream release (3.5)" [Wishlist,Fix committed]
<LocutusOfBorg> <3 Saviq
<LocutusOfBorg> thanks
<LocutusOfBorg> slangasek, if you want to sponsor again https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/1563580
<ubottu> Launchpad bug 1563580 in cmake (Ubuntu) "please merge cmake from debian" [Undecided,New]
<LocutusOfBorg> but you have to dget -u http://incoming.debian.org/debian-buildd/pool/main/c/cmake/cmake_3.5.1-1.dsc
<LocutusOfBorg> or from my ppa :)
<Saviq> LocutusOfBorg, FWIW glib-2.0_INCLUDEDIR is incorrect according to https://cmake.org/cmake/help/v3.5/module/FindPkgConfig.html
<jgrimm> rharper, awesome.  thanks for looking at that. lingered longer than I'd wanted.
<Saviq> prefix should always be there
<LocutusOfBorg> Saviq, the new bug dropped it
<sarnold> rharper: oy, 21M debdiff?
<LocutusOfBorg> I agree, and this is why I opened a new bug with a new debdiff
<LocutusOfBorg> and no patch, since there is an upstream fix
<rharper> sarnold: big jump
<jgrimm> rharper, did debian have a bug there?
<rharper> sarnold: 3.3 to 3.5.12; long overdue of course
<Saviq> LocutusOfBorg, ah, ack
<rharper> jgrimm: I didn't attempt to recreate on debian;
<sarnold> man that's gonna make users happy, they've been grumbly about the ages of the squid packages for a while :) thanks
<rharper> sarnold: yea, and squidguard works again!
<sarnold> \o/
<rharper> sarnold: rabask did almost all of the work
 * doko grumbles why this took three years ...
<rharper> I helped track down the dist-upgrade from trusty (with configured squid-deb-proxy/squidguard) setup that kickinz1|eod documented thoroughly in the bug
<sarnold> doko: presumably because it was held off slightly too long the first time around, 2.5 years ago.. hehe :)
<rharper> rbasak is out for a bit and jgrimm doesn't want to wait any longer
<Saviq> slangasek, LocutusOfBorg, thanks a bunch!
<LocutusOfBorg> thanks to you
<LocutusOfBorg> I hope to see cmake 3.5 in ubuntu
<LocutusOfBorg> I already failed for libpng1.6
<LocutusOfBorg> I'm leaving
<LocutusOfBorg> bye! if there are any troubles, please drop a note on bug reports
<LocutusOfBorg> and I'll followup
<LocutusOfBorg> tomorrow I'll have irc blocked at @company
 * LocutusOfBorg takes the remaining 4 hours of rest
<doko> LocutusOfBorg, https://launchpad.net/ubuntu/+source/cmake/3.5.0-1ubuntu3/+build/9414306
<sladen> ssh -D
<doko> gvingback ..
<LocutusOfBorg> doko, makes no sense with the patch
<LocutusOfBorg> doko, probably uploading 3.5.1 from the bug 1563580 is better
<ubottu> bug 1563580 in cmake (Ubuntu) "please merge cmake from debian" [High,New] https://launchpad.net/bugs/1563580
<LocutusOfBorg> because the patch introduces an useless variable in cache, and maybe it can trigger an output of some warnings
<doko> LocutusOfBorg, let's migrate this to the release pocket first
<LocutusOfBorg> doko, sure
<LocutusOfBorg> actually the upstream commit has a patch for two files
<LocutusOfBorg> one regarding ncurses
<LocutusOfBorg> so the failure might be because of an incomplete patch too
<LocutusOfBorg> my builds seems fine https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/6241790/+listing-archive-extra
<slangasek> nacc: syncing to 1.0.1-3 sounds good to me
<nacc> slangasek: ok, bug filed (LP: #1563579)
<ubottu> Launchpad bug 1563579 in phpseclib (Ubuntu) "Please sync phpseclib 1.0.1-3 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/1563579
#ubuntu-devel 2016-03-30
<slangasek> doko: did you give back cmake on arm64 again?
<slangasek> because it seems to be failing repeatedly, and being given back
<slangasek> (before I ever get to look at the build log)
<doko> slangasek, it was on the same buildd. will stop giving it back
<slangasek> doko: so there's a buildd-specific problem?
<doko> slangasek, I don't know, but usually I retry arm64 builds before I report issues
<slangasek> doko: heh, ok
<doko> so yes, maybe I should record arm64 ftbfs before I give these back
<slangasek> doko: and I see uploads for openjdk-7 dropping out of main, thanks :)
<doko> yeah, 6 already removed, 7 in universe, and hopefully removed as well
<nacc> slangasek: building and then will test a new version of mythtv with dpkg-maintscript-helper additions, and then will be done for the day (so your inbox can rest easy :)
<slangasek> nacc: heh; I just sponsored the php-horde-crypt change, but I also just noticed that php-horde-crypt 2.7.0-1ubuntu1 passes its tests again together with php-horde-http 2.1.5-3ubuntu2
<nacc> slangasek: ah ok ... so maybe timing again; I don't think it should do any harm, and it will mean if we do have a network blip, it will skip & not fail, i think
<slangasek> nacc: none of these are network blips, it's the deliberate network filtering policy on the autopkgtest runners
<nacc> slangasek: oh i see, horde-http being a the newere version fixed the issue properly, got it
<slangasek> nacc: yeah, seems so
<teward> stupid obvious question, but, does landscape-client in Xenial not work the way it should with Landscape?  I only ask because in trying to set up an actual Xenial server, following my workflow of configuring it to Landscape, it chokes during server ISO setup...
<slangasek> nacc: hmmm which arch was having the weird kernel timeout related bugs from one of the php test suites?
<doko> infinity, please have a look at https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1560528
<ubottu> Launchpad bug 1560528 in qtbase-opensource-src (Ubuntu) "tst_LargeFile::mapOffsetOverflow started failing on 32-bit xenial" [Undecided,Incomplete]
<doko> slangasek, failed again, this time on a different buildd: https://launchpad.net/ubuntu/+source/cmake/3.5.0-1ubuntu3
<slangasek> doko: yep; trying to figure out if this is related to another bug we saw with a php package's testsuite on one of the armen architectures
<slangasek> doko: that was php-imagick on armhf; but I guess that's also running on a 64-bit kernel, so could be the same issue
<slangasek> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/p/php-imagick/20160323_112011@/log.gz
<slangasek> hmmmm completely different kernel version, though
<slangasek> (3.13.0-45 vs. 4.2.0-30)
<nacc> slangasek: i think it was armhf w/ imagick?
<nacc> slangasek: also, i tihnk php-horde's failed amd64 test, php-horde-data's i386 failed test are transient; php-horde-mapi may need to be manually kicked now that seclib is in
<nacc> slangasek: and oddly horde http failed again ... will investigate in the am
<stgraber> roaksoax: package renames AND copyright updates, you really like to make my life difficult...
<stgraber> I'm sure the diff would actually be readable without all that stuff...
<sarnold> where does the '3819' come from in the ulimit -a output? it's also in e.g. systemctl show fwupd  or systemctl show sshd
<sarnold> the usual grep -rl 3819 /etc /usr /lib  didn't do the trick
<slangasek> nacc: php-horde-mapi retriggered
<slangasek> sarnold: "3819"? for what limit?
<sarnold> slangasek: both pending signals and max user processes
<slangasek> sarnold: those numbers are calculated dynamically based on available system RAM IIRC
<sarnold> interesting
<sarnold> # for u in $(systemctl list-unit-files  | awk '{print $1}') ; do systemctl show  $u | grep 3819 ; done | wc -l
<sarnold> 800
<sarnold> hehe
<slangasek> nacc: php-horde-http failed again because it was still picking up the old -exception-, didn't wait long enough
<slangasek> nacc: oh, rather, php-horde-exception is still blocked by php-horde-mapi, so *definitely* didn't wait long enough
<slangasek> nacc: php-horde-http still fails, and this time I don't know why because it was using the new php-horde-exception
<pitti> Good morning
<stgraber> good morning pitti
<stgraber> pitti: the lxc adt failure on ppc64el is an actual regression, I just sent a branch upstream to fix it and cherry-picked the fix already. It's in the queue now if you have a minute to review.
<pitti> stgraber: accepted, thanks
<pitti> stgraber: wow, was the mirror default dropped accidentally, or was this somehow able to get along without ports.u.c. all this time?
<stgraber> pitti: thanks, going to go get some sleep now :)
<stgraber> pitti: the Debian maintainer sent a branch to set a default MIRROR so that debootstrap would be happy in Debian
<stgraber> pitti: but he apparently didn't know that we don't have all arches on archive.ubuntu.com :)
<pitti> stgraber: squid3> btw, you know debian/pkgname.maintscript ?
<stgraber> pitti: (and I apparently suck at review and didn't notice it)
<stgraber> pitti: I sure do and squid3 is a mess. I just uploaded it because I accepted a buggy one earlier and felt bad :)
<pitti> heh, thanks
<stgraber> also squid3 is cdbs... not that it matters much in this case, but it makes it just that much more painful to deal with
<pitti> coreycb: can you please look at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#swift ? your swift upload has been trapped by the regression for 3 weeks
<pitti> yofel: FYI, baloo-kf5 segfaults during its tests on 32 bit (i386 and armhf); so it's been stuck in -proposed for 3 weeks already
<alkisg> bdrung, bdrung_work, good morning, about xul-ext-adblock-plus, I see that you uploaded version 2.7.2+dfsg-1~ubuntu16.04.1~ppa1 a while ago, did you managed to get it to work with the extension signing etc?
<alkisg> I managed to get the presigned .xpi to work with this command:
<alkisg> # wget https://update.adblockplus.org/latest/adblockplusfirefox.xpi -O /usr/lib/firefox/browser/extensions/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}.xpi
<alkisg> If there are no alternatives, maybe xul-ext-adblock-plus could just package the signed blob?
<alkisg> Or is there some way that I'm unaware of, to get the 2.7.2+dfsg-1~ubuntu16.04.1~ppa1 to work for all users?
<Unit193> https://sources.debian.net/src/firefox/45.0.1-1/debian/patches/prefs/Don-t-auto-disable-extensions-in-system-directories.patch/ :P
<alkisg> Unit193, bdrung has already proposed a patch there: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1532484
<ubottu> Launchpad bug 1532484 in firefox (Ubuntu) "Don't warn about unsigned extension installed via Debian packages" [High,Confirmed]
<alkisg> ....but chrisccoulson replied,  "This isn't something that we're going to be changing in Ubuntu", dunno why
<Unit193> alkisg: Heh, was mostly kidding there, sorry that wasn't more clear.
<mwhudson> can i get an Opinion
<infinity> mwhudson: Grilled cheese sandwiches are best if you don't add anything other than the cheese.
<Unit193> infinity: I like bread with mine.
<RAOF> We have a new candidate for History's Greatest Monster: infinity!
<mwhudson> i've been asked to sponsor a merge from debian, and it disables a feature in debian by not having the libxxx-dev package in build-depends
<infinity> Not uncommon.
<mwhudson> which seems a little smelly, it's fine for the buildds i guess but it means a developer building the package on her system might get different functionality
<infinity> Generally to keep things out of main (or to avoid filing an MIR :P)
<mwhudson> i guess the lesson here is "autoconf sucks"?
<mwhudson> infinity: i think this is actually not the case here :-)
<Unit193> mwhudson: Look at irssi.
<infinity> mwhudson: Correctly, it should drop the build-dep *and* use --disable-feature, but people rarely bother with the latter.
<mwhudson> infinity: it's to avoid an ffe i think :)
<mwhudson> (it's tgt, there's stuff from you on the bug)
<mwhudson> Unit193: do i have to? :-)
<infinity> Is there?
<Unit193> mwhudson: No.
<mwhudson> infinity: ok, noted
<infinity> I'm asked to comment on bugs often.
<infinity> Refresh my memory?
<mwhudson> infinity: https://launchpad.net/bugs/1555700
<ubottu> Launchpad bug 1555700 in tgt (Ubuntu) "Please merge tgt 1.0.63 from Debian (unstable)" [Undecided,New]
<infinity> Was this the libaio thing?
<mwhudson> infinity: you didn't comment, but irc logs were pasted
<mwhudson> unless they were excellent forgeries of logs :-p
<mwhudson> yeah, the aio thing
<infinity> mwhudson: Anyhow, yeah, dropping the build-dep is a common way to achieve that.  Strictly speaking, you're right, and one would also either use Build-Conflicts or (more sanely) pass --disable-thing to configure, but Debian and Ubuntu have moved to a "there's no way we can conflict with everything correctly and specifying every single configure option is a pain" stance, combined with "oh, look, source uploads and clean build chroots", so...
<infinity> mwhudson: Basically, yes, "the user's build might differ" sucks a bit, but also who cares.
<mwhudson> infinity: ack
<Unit193> d/control needs an easier way to have added build-deps in derivs, or 'build-recommends' to replace the silly dephere | something in main thing. :/
<mwhudson> there must be some punctuation that doesn't have meaning to dpkg left, right?
<infinity> We could build everything in ubuntu in an ubuntu build-profile, and you could use "Build-Depends: foo, bar <!ubuntu>, baz"
<infinity> But really, the effort there would be convincing Debian maintainers to take your patch.
<alkisg> In LTSP we've implemented directives like X-Ubuntu-Depends: etc to use the same packaging in both Debian and Ubuntu
<Unit193> infinity: What if I'm the Debian maintainer?  ;)  Problem being, something Ubuntu isn't OK with either.
<infinity> Unit193: Sure, if you're the Debian maintainer, it's a bit easier, but if you're the Debian maintainer, you also don't have a hard time tracking your own merges, I suspect. ;)
<infinity> The real issue with Debian deltas are all the "lost" merges from drive-by bugfixes.
<Unit193> infinity: Can't upload to Debian or Ubuntu, so moot on the sponsors queue.  And indeed. :/
<Unit193> infinity: BTW, I'm right in thinking Ubuntu has the same stance as Debian on GPL/OpenSSL linkage?
<infinity> Unit193: Yes.
<Unit193> Figured, dang.
<infinity> It's usually not hard to get upstream to agree to a license exception.
<infinity> Especially if they wrote their application to use openssl. :P
<Unit193> They did and would like it, but they won't as they can't contact all contributors.
<infinity> Personally, I'm of the opinion that if the work is 100% original code and was obviously a derived work from day 1 (ie: it always linked to OpenSSL), the exception is implied, but that's not a particularly sane legal argument.  And falls down hard as soon as the project pulls in any GPL code from elsewhere, or if the openssl-using bits were written later, or...
<Unit193> So I just end up building it too.  LibreSSL to save the day? /s
<infinity> Unit193: LibreSSL would have the same issue, it's an OpenSSL fork.
<Unit193> Anywho, I'll stop bugging you unless you feel 'uploady'.
<infinity> I'm feeling more sleepy than uploady.
<Unit193> 3am here.
<mwhudson> oh hell why does trying to build things in my trusty schroot unmount my home directory :(
<dholbach> good morning
<infinity> mwhudson: Unmount it in your host, you mean, or fail to mount it in the schroot?
<mwhudson> infinity: in my host
<infinity> mwhudson: !
<infinity> mwhudson: That's special.
<mwhudson> infinity: adt-run did it once too!
<mwhudson> but yes
 * infinity resists the urge to get involved and sleeps instead.
<mwhudson> i have the # Mount a large scratch space for the build, so we don't use up
<mwhudson> # space on an LVM snapshot of the chroot itself.
<mwhudson>  stuff in the schroot profile
<mwhudson> which given i don't use lvm is probably a touch pointless
<mwhudson> infinity: go to bed
<infinity> mwhudson: If you use ephemeral chroots with a tmpfs for the overlay (like I do), then the scratch is useful.
<mwhudson> i don't think i do that
<mwhudson> union-type=overlayfs
<mwhudson> anyway, go to bed :)
<infinity> mwhudson: I use union-type=overlays combined with:
<infinity> schroot         4.9G     0  4.9G   0% /var/lib/schroot/union/overlay
<infinity> mwhudson: Which makes build-deps install basically instantly.
<mwhudson> hm
<infinity> But then I build in a scratch, cause disk speed at build time is less important.
<infinity> # Mount a large scratch space for the build, so we don't use up
<infinity> # space on an LVM snapshot of the chroot itself.
<infinity> /var/lib/sbuild/build	/build	none	rw,bind		0	0
<infinity> /home			/home	none	rw,bind		0	0
<mwhudson> infinity: do you have encypted home dir?
<infinity> Nein.
<infinity> Full disk.
<mwhudson> luks or something?
<infinity> Or something, yes.
<infinity> (oh, and lest that "schroot" confuse you, it's just this:)
<infinity> schroot  /var/lib/schroot/union/overlay  tmpfs  defaults,size=25%  0 0
<infinity> Basically, gets you best of both worlds.  tmpfs for build-dep installation (especially when also backed by a proxy of some sort) means that step happens in seconds, then the build happens on a real ext4 filesystem in the scratch dir and can take all the space it wants (and not suffer weird bugs due to being on overlayfs)
<mwhudson> yeah i have squid-deb-proxy installed and omg i'm so glad i did that
<infinity> home mounted for sbuild profiles is entirely optional, but I'm lazy and reuse the same "custom" profile for sbuild and schroot.
<bdrung_work> alkisg, no update on the signing issue.
<mwhudson> well that was all very exciting
<mwhudson> there is a bug about this, apparently fixed in xenial
<mwhudson> (i'm still on wily)
<mwhudson> grabbing the schroot packaged from xenial didn't fix the problem though
<alkisg> bdrung_work: are you interested in packaging the signed .xpi? Or should I do that in some PPA of my own, until some other method is found?
<mwhudson> https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/1430557
<ubottu> Launchpad bug 1430557 in schroot (Debian) "sbuild / schroot unmounted encrypted home directory" [Unknown,Confirmed]
<alkisg> chrisccoulson, is it possible to get a reason why bdrung_work's patch for signed extensions can't be accepted?
<bdrung_work> alkisg, i am against packaging signed xpi file as they are not the preferred form for modifications
<alkisg> bdrung_work, ok, thanks, I'll override the xul-adblock-plus package from my ppa
<bdrung_work> alkisg, as alternative, you can still disable the signed xpi check in about:config
<alkisg> bdrung_work: I tried with lockPref and it's not working for all users that way
<alkisg> For single users, it does work
<alkisg> *per user
<alkisg> I don't want to have to tell to all the 5-10 year old students how to go to about:config...
<bdrung_work> valid point
<alkisg> I also asked chrisccoulson for a reason behind his refusal in your bug report, but no reply there either
<alkisg> Debian did accept a similar patch...
<jamespage> morning all
<Unit193> alkisg: And you can't just override it in something like  /usr/lib/firefox/browser/defaults/preferences/unit193.js  ?
<alkisg> Unit193: for some reason, the usual method for overriding it doesn't work... I tried: lockPref("xpinstall.signatures.required",false);
<alkisg> It did disable it in about:config, yet it was not actually working
<alkisg> Maybe the firefox devs are thinking that this is a very significant to allow it to be overriden by the sysadmin, they want it per user? dunno.
<alkisg> *a very significant setting
<Unit193> Actually meant like Debian did, but again not tested that I just ship signed. :P
<alkisg> Debian patches firefox (iceweasel) afaik
<alkisg> bdrung also proposed a patch for firefox, but it's not getting accepted...
<alkisg> OK thank you guys, I'll package the adblock plus blob in a PPA
<Unit193> (It's actually just 'firefox' now.)
<alkisg> Ah, nice!
<Saviq> pitti, hey, did you recover over Easter?
<Saviq> pitti, have a question about britney - we've removed the only test from qtmir and qtmir-gles (because it was a "does-it-build" test, not suitable for britney, especially in the new trigger-based britney)
<Saviq> now britney will complain that this is a regression because there's no tests at all
<Skuggen> infinity: Patched mysql-5.7 to work around the dbconfig issue. Seems to work fine, so once rbasak is back tomorrow we can do another upload, I think
<Skuggen> elbrus: ^
<pitti> Saviq: I did recover, thanks! I hope you had some nice holidays too
<Saviq> pitti, actually now looking at http://autopkgtest.ubuntu.com/packages/q/qtmir/ maybe it's ok with it after all...
<pitti> Saviq: qtmir does not have a Testsuite: any more, so why would britney try to run a test for it?
<pitti> Saviq: do you have the excuses URL of that silo?
<Saviq> pitti, seems to be running here https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-066/excuses.html
<pitti> Saviq: oh, is that the silo that drops the test?
<Saviq> pitti, no, the test is dropped in trunk already
<pitti> Saviq: it's "always failed", so it won't block anything
<Saviq> https://bazaar.launchpad.net/~mir-team/qtmir/trunk/revision/461
<pitti> Saviq: and gsettings-qt should run against the qtmir in the archive/overlay, not in the silo
<Saviq> pitti, ok let's see how it fares, I think it was less happy on xenial, but there's no excuses for that yet
<pitti> but if that still has the tests, they will just run the old one, and if it's the new package without tests it wouldn't be triggered any more
<Saviq> pitti, ok, I'll let you know if I have trouble after all, thanks
<pitti> Saviq: ack, thanks
<Saviq> pitti, yeah, it's unhappy on xenial for some reason https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-066/excuses.html
<Saviq> pitti, what's also weird is that it's not running tests for unity8 for some reason
<Saviq> and don't ask me what's "-ginkgocadx"
<pitti> Saviq: ah, qtmir in landing-066 xenial still has Xs-Testsuite: autopkgtest
<pitti> Saviq: so apparently this somehow came back
<pitti> or wasn't removed properly
<doko> mwhudson, docker.io ftbfs on s390x
<Saviq> pitti, oh.... debian/control... forgot to remove in there indeed, will have a follow-up MP
<Saviq> pitti, any idea why unity8 tests don't run there? it's in the silo...
<Saviq> huh... it doesn't have Xs-Testsuite: autopkgtest Â¿?
<pitti> Saviq: unity8 lost its Testsuite: header
<Saviq> waaat
<pitti> (XS- prefix is obsolete, btw)
<Saviq> wonder if it ever had it...
<pitti> and normally it is being added automatically
<pitti> if there's a d/t/control
<pitti> nope, no debian/tests/ in unity8
<Saviq> but it's there... https://bazaar.launchpad.net/~unity-team/unity8/trunk/files/head:/debian/tests/
<Saviq> pitti, why do you say it has no d/t/control?
<Saviq> https://launchpadlibrarian.net/250392626/unity8_8.12+16.04.20160330-0ubuntu1.diff.gz lists it (granted, no XS-Testsuite: autopkgtest - since it was added automagically as you say)
<pitti> Saviq: erk, sorry, was mis-looking at qtmir
<Saviq> maybe it's not auto-added any more and we need it explicit now?
<pitti> http://ppa.launchpad.net/ci-train-ppa-service/landing-066/ubuntu/dists/xenial/main/source/Sources.xz does not have the header, though
<pitti> or maybe it's only added for v3 sources, not sure how dpkg handles that
<Saviq> ok, so we need that header explicit now, /me will add (and drop from qtmir)
<pitti> but xenial's unity8 has a Testsuite: header, the PPA doesn't
<Saviq> that explains things, thanks pitti
<pitti> Saviq: oooh!
<pitti> Saviq: there's no relevant diff in the source
<pitti> Saviq: but robru recently changed to building sources not in a schroot
<Saviq> probably
<pitti> and I bet he's using the old trusty dpkg-dev to build the sources, that doesn't add Testsuite: yet
<pitti> before we'd have used xenial's dpkg-dev to build sources
<Saviq> yup
<pitti> that explains why the header isn't auto-added any more
<xavigarcia> pitti: Hi there!
<pitti> hello xavigarcia
<xavigarcia> pitti: I'd like to ask you a question about upower
<xavigarcia> pitti: I'd need to change the configuration ONLY for the phone... to use percentages and poweroff the phone
<pitti> xavigarcia: that's a matter of presentation
<xavigarcia> pitti: do you know if there's any other way to overwrite the config file other than using dpkg-divert?
<pitti> upower tells you percentages and absolute limits
<pitti> and it does not "power off" the phone
<pitti> oh, for critical action you mean
<pitti> sorry, I thought you meant the hold reboot/shutdown API
<xavigarcia> pitti: I did some tests last week, and it did it... yeah... it's for the critical action
<pitti> xavigarcia: it's a conf file, so you can just change the values
<xavigarcia> pitti: this is the MR I wanted to land: https://code.launchpad.net/~xavi-garcia-mena/ubuntu/vivid/upower/percentages-power-off/+merge/289935
 * ogra_ would do it from a livecd-rootfs hook script (as i said in the other channel)
<pitti> does HybridSleep really work on a phone?
<pitti> and hibernate?
<pitti> I would have thought we disable that, and let it fall back to power off
<xavigarcia> pitti: I neede to change it to PowerOff
<xavigarcia> pitti: that's the main change in the config
<ogra_> hibernate doesnt (not enough swap)
<ogra_> according to the comment that should automatuically fall back to PowerOff without you doing anything
<pitti> so I'd think that it's easiest to keep such config changes central in the image build scripts (livecd-rootfs), otherwise just change the file and put that into the overlay
<ogra_> yeah
<xavigarcia> pitti ogra_: that was my initial intention
<xavigarcia> pitti, ogra_: that's why I already had the MR, but Pat was asking to do that in a separated package
<xavigarcia> pitti, ogra_: but as upower is already managing the config file I don't see any other way to do that than using dpkg-divert
<ogra_> xavigarcia, just use sed
<pitti> no, don't divert a conffile, this is going to blow up
<xavigarcia> ogra_, pitti: well, that's another option, but not the best, as the config file is still maintained by upower :/
<ogra_> thats fine on the phone, really
<xavigarcia> ogra_, pitti: I think I will retry the overlay again
<ogra_> we dont support apt upgrades
<pitti> well, you never dist-upgrade that anyway
<xavigarcia> ogra_, pitti: oh, ok... thanks for the reminder!
<ogra_> sed -i 's/^UsePercentageForPolicy=.*/^UsePercentageForPolicy=true/' /path/to/UPower.conf
<ogra_> just put something like that in a livecd-rootfs hook script
<xavigarcia> ogra_ we could maybe add that to the ubuntu-phone-session package...
<xavigarcia> sorry, ubuntu-touch-session
<ogra_> nah, just do it at build time
<ogra_> no need to run that every session startup and to slow down the start
<xavigarcia> ogra_ but in fact...if we apply it at build time... what would be the difference to adding it to the config file?
<ogra_> bzr branch lp:livecd-rootfs ...
<ogra_> add your snippet under: live-build/ubuntu-touch/hooks/
<ogra_> and creat an MP from that
<ogra_> the difference is that it will also apply if you switch to a new upower version without you having to hack the package
<xavigarcia> ogra_: I see.... thanks for the pointers!
<xavigarcia> ogra_: Could you please take a look to the following MP? https://code.launchpad.net/~xavi-garcia-mena/livecd-rootfs/bug-1317860-upower-poweroff-phone-only/+merge/290454
<xavigarcia> ogra_: I've assigned it to you... the config change was already reviewed last week in the following MP: https://code.launchpad.net/~xavi-garcia-mena/ubuntu/vivid/upower/percentages-power-off/+merge/289935
<xavigarcia> ogra_: it was rejected after Pat asking to do it in a different way... but it was previously approved
<ogra_> xavigarcia, commanted ... please give it to sil2100 to merge it in the overlay livecd-rootfs though
<ogra_> *commented even
<xavigarcia> ogra_: cool... thanks!
<ogra_> i'm happy to merge it in xenial once it landed in teh overlay (for consistency)
<xavigarcia> sil2100: ^
<xavigarcia> sil2100: please see ogra's messages and my MP link
<pitti> Saviq: FYI, I just deployed the fix for bug 1544917
<ubottu> bug 1544917 in Auto Package Testing "Retry says "does not have any test results" on reported Regressions" [Low,Fix released] https://launchpad.net/bugs/1544917
<Saviq> pitti, ack, thanks :)
<sil2100> o/
<sil2100> xavigarcia: on it
<xavigarcia> sil2100: great, thanks!
<caribou> slangasek: just saw LP: #1563027 after doing the work on this this morning
<ubottu> Launchpad bug 1563027 in vsftpd (Ubuntu) "vsftpd 3.0.3-3ubuntu1 fails to start on installation" [High,Confirmed] https://launchpad.net/bugs/1563027
<slangasek> caribou: well, it's all yours :)
<caribou> slangasek: just wondering if I should just revert the value or wait to hear from the DM first
<slangasek> caribou: IMHO there's no need to revert, this is pretty much the only change in -proposed and it can just sit there until resolved
<caribou> slangasek: thought so; I'll wait to hear about the DM then
<rharper> slangasek: I'm testing wily squid3 upgrade to xenial with the existing proposed package;  I'm trying to confirm if a wily -> xenial upgrade also trips the same logic from debian and if the /etc/init.d/squid3 service file exists (where it didn't for trusty -> xenial upgrade);
<nacc> ha! as brief as it might be, excuses is nearly php clean right now :)
<nacc> slangasek: thanks for all your help, as usual!
<teward> is the ubuntu-server metapackage new in Xenial?
<nacc> slangasek: just sent another sync request which will clear out the remaining one that should be fixed
<teward> I... just answered my question
<nacc> teward: looks like it acc'g to rmadison
<teward> nacc: i have a question as to why lxc is installed as part of it by default
<teward> :/
<nacc> teward: it's on the server seed
<ogra_> is it ?
 * ogra_ thought it was added to -standard
<nacc> lxc (from lxc) is seeded in:
<nacc>   ubuntu-server: daily
<ogra_> i wonder why (given we (will) have it in desktop by default as well)
<ogra_> standard would seem more logical
<slangasek> standard is inherited by all flavors; this is an Ubuntu Server+Desktop product decision
 * teward scratches his head
<doko> openjdk-7 demoted
<ogra_> slangasek, ah, but that means not all ubuntu features will work in all flavours
<teward> ogra_: i'm going to stop the !crosspost that i appear to be doing, and going to stick to here specifically, did I miss an email chain where this was discussed?
 * teward might have, receiving too many emails a day
<ogra_> not sure if there were mails
<ogra_> theer were definitely several announcements that it will come in 16.04 throughout the development cycle
<ogra_> and at UOS
<teward> mmm, well i've been so engrossed in nginx lately and my own studies I guess the mails slipped by me
<slangasek> ogra_: if you expect this to land in standard, you'd better start a discussion with the flavor teams via ubuntu-devel
<teward> it seems odd, though, that container support would be needed - but I think this needs to be discussed more, because if it's included on every server, and they never use it, why should it be in the ubuntu-server seed *shrugs*
<teward> my own opinion though :)
<teward> and by 'they' i mean any user of the server installer and server flavor of Ubuntu
<ogra_> slangasek, i dont expect it anywhere ... it was just my assumption that we call it a default ubuntu feature nowadays (iirc it is also the base of supporting snappy packages which i imagine flavours would like)
<teward> oh that explains it :)
 * teward facedesks
<ogra_> but i trust the persons that made the decision that they thought about it ;)
<ogra_> teward, why is that ...
<teward> ogra_: well, afaict it's not in -standard, only -server.  the head-scratching left behind makes me think that if it should be in -standard but isn't, then there's something missing
<teward> ogra_: because i'm old fashioned :)
 * ogra_ will surelÃ¶y prefer to run servers as snappy packages over debs at any time
 * teward comes from the world of old-fashioned "Start with absolutely basic, add what's necessary"
<ogra_> yeah
<teward> ogra_: indeed, but once I saw you state that it's the base of snappy packages, that answered the question
<teward> as i said, "oh that explains it :)"
<ogra_> right
 * teward isn't well versed in Snappy yet
<slangasek> rharper: so, followed up to the squid3 bug with more explanation.  I think you overlooked that trusty was upstart-only, there was no init script shipped in the package in trusty; /this/ is why the upgrade path behaves differently between trusty and wily
<rharper> slangasek: ok;  I'm trying to figure out if this is something we introduced or are just incompatible with the postinst from debian;  it sounds like we need to do something different since debian didn't deal with upstart service scripts?
<slangasek> rharper: you need to do what I outlined in the bug
<rharper> slangasek: perfect, thanks
<nacc> slangasek: question on mythtv: currently, there are no conffile listed for mythweb; is that expected?
<teward> ogra_: I think we need to have lxc defaults changed
<teward> ogra_: lxcbr0 on a default install is given 10.0.3.1, but this conflicts in my own network - I have many maps in the 10.* IP space around, and I bet there will be IP range conflicts like this in other deployments
<teward> (default install of Server)
<ogra_> teward, file a bug :)
<teward> would if LP would respond to me trying to reaoch it
<ogra_> (i'm not in any way an lxc guy ... better talk to stgraber )
<cyphermox> teward: there might be conflicts in any possible range one might pick
 * teward blames Comcast
<teward> cyphermox: true, but then this brings up other questions: if it's likely to cause IP conflicts and routing conflicts, why is it in the standard images again?
<teward> i know ogra stated Snappy, but it brings up more questions then
<slangasek> nacc: I have no idea; what do you see in mythweb that you think should be a conffile
<slangasek> ?
<teward> s/then/than answers/
<nacc> slangasek: the one you wanted me to move, /etc/php5/apache2/conf.d/20-mythweb.ini
<cyphermox> that isn't my call. I'm just saying that no matter what app, no matter what IP range you'll pick, you'll always run the risk of conflicts since it's all an arbitrary thing in a finite pool of resources
<slangasek> nacc: guess I should look ;)
<nacc> slangasek: for reference, LP: #1562184
<ubottu> Launchpad bug 1562184 in mythtv (Ubuntu) "Update to PHP7.0 dependencies" [Undecided,Incomplete] https://launchpad.net/bugs/1562184
<teward> guess i'll bring up my concerns at the server team meeting then
<teward> 'cause that's where it's incorporated by default
<stgraber> twlxcbr0 is disappearing in a few days
<nacc> teward: --^
<stgraber> we're just waiting for juju to be done switching to lxdbr0 and then we can have lxd stop pulling lxcbr0 into the cloud and server images
<teward> ah
<teward> stgraber: okay, that makes sense, because the ISO i tested last week with regards to the keyboard layout selection thing not working didn't have this. the iso I have from yesterday's batch (20160329) had it, and it actually broke net routing when the thing first came up (same subnet ranges due to overlap, so routing blew up)
<teward> I have a workaround temporarily in my installation, but eh
<stgraber> hmm, lxcbr0 has been around by default in all images since wily (for server and cloud), so if you didn't have it before, that was a bug :)
<teward> stgraber: i never tested wily :P
 * teward shrugs
<slangasek> nacc: $ dpkg-deb -R ubuntu/pool/multiverse/m/mythtv/mythweb_0.28.0+fixes.20160325.2520617-0ubuntu2_all.deb mythweb
<slangasek> $ cat mythweb/DEBIAN/conffiles
<slangasek> /etc/default/mythweb
<slangasek> /etc/php5/apache2/conf.d/20-mythweb.ini
<slangasek> $
<teward> in any case, i'm not a fan of routing blowign up in my face on a default setup
<teward> fortunately it's a VM that I can recreate, assign to different subnets, etc. but
<slangasek> nacc: so, that looks like a conffile to me; not sure where you were looking, but DEBIAN/conffiles is authoritative (and with a modern package, is autopopulated by debhelper based on "is this file in /etc Y/N?")
<nacc> slangasek: weird, apt doesn't show it; but does in my rebuilt one (which was buggy, fixing still) that included dpkg-maintscript-helper
<slangasek> nacc: I'm not aware of any option to apt to show conffiles
<nacc> slangasek: it does by default, or did for my package
<nacc> which is why i was confused :)
<slangasek> when running what command?
<nacc> apt-cache show ...
<slangasek> nacc: ok, not sure why that ever showed you conffiles, I've never known it to do so and it doesn't here :)
<nacc> slangasek: for refrence, http://paste.ubuntu.com/15560435/
<nacc> i wonder if it's something that dpkg-maintscript-helper does
<cyphermox> slangasek: when the package is installed?
<nacc> cyphermox: yeah, i had the older version installed, though, and it doesn't show any
<nacc> cyphermox: testing the upgrade path
<nacc> hence my confusion :)
<cyphermox> (that's my guess, I see conffiles for n-m, but only for the specific version installed, not others in cache)
<nacc> slangasek: cyphermox: well, either way, it's fine, i think i see what i did wrong with my change. But was curious
<rharper> slangasek: looking at 'removing etc/init.d/squid3 on upgrade';   IIUC, the new package scripts that get called are newpkg.preinst and newpkg.postinst;  the preinst script is called with 'upgrade' but postinst is called with 'configure' ; should I attempt to remove the old service script in preinst then (when $1 is upgrade)? or just test for existence in postinst and remove there during configure?   the ideal spot seem
<rharper> s to be (previous version of squid's postrm upgrade call; which could remove old files) but that doesn't seem right since the current package doesn't do that;
<robru> pitti: yes, train is trusty. let me know if you need me to backport dpkg-dev or something.
<infinity> rharper: Or, use dpkg-maintscript-helper?
<slangasek> rharper: you should call dpkg-maintscript-helper with the appropriate args, unconditionally
<slangasek> cyphermox: my test case for this was 'apt-cache show base-files', which certainly should be installed ;)
<cyphermox> hrm, fun ;)
<cyphermox> ah, maybe there's something there
<cyphermox> n-m show Status: install ok installed
<cyphermox> base-files doesn't
<cyphermox> that said, I don't think that's the cause of my upgrade bugs ;)
<slangasek> cyphermox: right, which means somehow your apt-cache show is merging contents from /var/lib/dpkg/status (which is also where the Conffiles are), maybe that's what you're seeing for a package that's installed but is *not* available at that version in the cache?
<cyphermox> I see three versions of n-m in cache, one of which is the one installed
<nacc> it might be explainable, but IMO violates the principle of least surprise :)
<nacc> as the version in /var/lib/dpkg/status, here (of base-files) is the one installed
<nacc> and /var/lib/dpkg/status does list hte conffiles entries
<nacc> while apt-cache show does not
<nacc> dunno how it decides :/
<slangasek> cyphermox: well, yes it's in the cache but I'm guessing 'apt-cache policy' shows it as locally installed and not available from any source
<cyphermox> ah, maybe yeah
<slangasek> nacc: I notice a few of the tasks on LP: #1544352 are stuck as fix committed; at least one of these, jquery-goodies, seems to be a case of the upload going missing.  Can you double-check these and set them back to a non-fix-committed state for me if I need to reupload?
<ubottu> Launchpad bug 1544352 in libfpdf-tpl-php (Ubuntu) "[PHP7] After bootstrapping, these PHP packages can be rebuilt" [Undecided,Fix committed] https://launchpad.net/bugs/1544352
<nacc> slangasek: will do
<slangasek> nacc: and sorry, on mythweb I guess I should have explained more about dpkg-maintscript-helper.  While this is the maintainer script interface, you should never put this in the maintscripts directly (because DRY); this ought to be in debian/mythweb.maintscript instead, which debhelper (via dh_installdeb(1)) will pick up and include
<slangasek> nacc: do you want to redo, or should I go ahead and fix it up on my side?  the latter is probably faster overall
<nacc> slangasek: ah interesting; i was just going off `man dpkg-maintscript-helper` and a few other exampels in the archive already
<nacc> slangasek: should we modify that manpage? as it explicitly says to do what i did :)
<slangasek> nacc: yeah, the 'SEE ALSO' at the bottom of that manpage is unfairly subtle
<nacc> heh
<slangasek> and yes, +1 for better documentation
<nacc> slangasek: if you can fix it up, that's fine with me -- the change is logically the same to me
<slangasek> I'm sure your maintainer script snippets are technically correct, they're just unmaintainable ;P
<nacc> right
<slangasek> nacc: btw, mythtv is stuck in -proposed for un-php reasons (mysql-5.7).  maybe that's something that could use a bit of help?
<nacc> slangasek: i think it's a known thing that rbasak is working on
<nacc> but let me check
<slangasek> ok
<nacc> yeah it's the mysql 5.7 transition stuff, which is blocked right now while they verify the upgrade path
<slangasek> nacc: ah, also your patch is against the xenial version of mythtv, not the xenial-proposed... will fix
<nacc> slangasek: argh, sorry! i think it should be pretty similar
<rharper> infinity: slangasek: thanks!  should prior-version include the XubuntuY part of the previous versions or just the source version ?
<infinity> rharper: The manpage has a whole section on how to select prior-version correctly.
<rharper> hrm
 * rharper rereads
<infinity> COMMON PARAMETERS
<infinity>        prior-version
<infinity> (three paragraphs follow)
<infinity> rharper: TLDR; you probably want it to be 3.5.12-1ubuntu4~
<infinity> rharper: Except... Wait.  Which conffile are you removing?
<rharper> infinity: I've read those now, 3 times;  it's not clear to me yet;
<rharper> infinity: /etc/init.d/squid3
<infinity> rharper: Cause stgraber already did that in the last upload.
<infinity> http://launchpadlibrarian.net/250372995/squid3_3.5.12-1ubuntu2_3.5.12-1ubuntu3.diff.gz
<rharper> infinity: ok, let me look at 1ubuntu3 then;  and see what else i need to do as slangasek help figure out for fixing upgrade paths
<sladen> kirkland: kudos for the press coverage
<ricotz> infinity, hi, would you have a moment to sync a package? https://bugs.launchpad.net/ubuntu/+source/plank/+bug/1563778
<ubottu> Launchpad bug 1563778 in plank (Ubuntu) "FFe: Sync plank 0.11.1-1 (universe) from Debian unstable (main)" [Undecided,New]
<infinity> ricotz: Iz done.
<ricotz> infinity, thank you!
<elbrus> Skuggen: thanks (I don't think you are "working around the dbconfig issue", but rather "give the world some time to adjust to the new mysql behavior")
<doko> slangasek, your mythtv upload has a .orig left. do you want to re-upload?
<slangasek> doko: I certainly don't /want/ to ;)
<doko> ok, I'll do it
<mwhudson> doko: i know about docker.io/s390x, arguing with ibm about it
<Skuggen> elbrus: Yeah, I agree that going straight from silently accepting the behavior to throwing errors is a bit sudden :)
<elbrus> yup, I read your upstream bug report
<slangasek> mwhudson: is xnox in the loop on said arguing? :)
<Skuggen> At least for options like port where an empty value will work
<mwhudson> slangasek: no, but i can add him i guess
<mwhudson> arguing is sort of the wrong word
<mwhudson> commiserating
<mwhudson> (the whole situation is just painful)
<slangasek> heh
<mwhudson> here is the pain: https://go-review.googlesource.com/#/c/20949/2
<slangasek> ahaha fun
 * doko looks at updating lua ...
<slangasek> doko: because... ?
<infinity> slangasek: I can haz verbal +1 on merging lintian so it stops whining about my packages living in the future?
<slangasek> infinity: is that about Standards-Version?
<infinity> slangasek: Standards-Version and uscan/watch version, in my case.
<doko> infinity, slangasek: so which of the NEW packages would be still appropriate? trying to look at the go uploads from December
<slangasek> infinity: weak verbal +1, would still want a queue review, though I guess lintian isn't release-critical
<infinity> slangasek: Will stage in my staging PPA to make sure the testsuite doesn't completely blow up like it does on every single merge. :P
<slangasek> doko: per standing policy, any of them are "appropriate", some of them are higher priority than others.  I have dibs on tpm2-* though
<infinity> doko: The go ones are totally appropriate, if they pass review.
<infinity> slangasek: Ooo.  How long until archive reorg? :)
<infinity> slangasek: lintian could be a sync if it was done. :P
 * infinity will merge it with a lower-than-debian version so we can sync over when we get there.
<xnox> mwhudson, is that what makes docker.io FTBFS in xenial now? =)
<mwhudson> xnox: yes
<xnox> mwhudson, enjoy! i'm glad i don't support packages in universe. And slangasek will back me up on that =)
 * xnox goes back to hacking curtin, MAAS and all things nice
<infinity> doko: If you have a moment https://bugs.launchpad.net/ubuntu/+source/libdata-alias-perl/+bug/1564082
<ubottu> Launchpad bug 1564082 in libdata-alias-perl (Ubuntu) "[MIR] libdata-alias-perl" [Undecided,New]
<cjwatson> infinity: by not-very-much-coincidence I was just starting work on the LP changes to allow tweaking the ogre model
<infinity> cjwatson: I assume we're all agreed on what that model is.
<cjwatson> AIUI it should allow supported to b-d on unsupported but free must still only b-d on free.
<infinity> cjwatson: Bingo.  I figured we'd both reach that obvious conclusion without external influence anyway.
<cjwatson> so {main, universe} -> main universe, {restricted, multiverse} -> main restricted universe multiverse
<cjwatson> and it'll be a flag on distroseries so that we can quickly flip the behaviour back if it breaks
<infinity> xnox: Oh.  I should have told you that I already tried -fno-pie -no-pie on s390x and it didn't help.
<cjwatson> (do analyse as much as possible beforehand though ...)
<infinity> xnox: (for glib2.0)
<xnox> infinity, yeah, it doesn't look like pie issue. pie things don't hang usually, just misbehave in wtf ways.
<xnox> unless it's ftw ways, then you know it's an endian issue =)
<infinity> xnox: PS, try not to use the archive as test-build infra. :P
<infinity> Oh.
<xnox> infinity, i have enough test-build infra =) but yeah, retry build was unnecessary
<infinity> I can't read.
<infinity> That was doko doing that.
<xnox> infinity, unless we get a notes field and/or "disable retry button"
<infinity> doko: I already tried -fno-pie -no-pie for glib2.0, that's not the issue, sadly.
<doko> infinity, done
<xnox> people will keep stabbing things
<pitti> robru: the "auto-add Testsuite: field" does seem to cause some trouble indeed; I guess backport vs. fixing packages is between you and sil2100, but if it's not too hard to run this on xenial that might be easier
<infinity> doko: And thanks on the MIR.
<doko> xnox, infinity: I'm tempted to not run the tests on s390x, they succeed on a local machine
<doko> but having the glib2.0 for the test rebuild would be nice
<infinity> doko: They do?  They sure didn't work for me when I was testing...
<infinity> doko: Is your local machine up to date?
<xnox> doko, what's your libc and kernel?
<doko> infinity, at least with -no-pie
<xnox> is that devac02?
<mwhudson> xnox: yeah, i'll get this sorted one way or another
<doko> yes
<robru> pitti: i do intend to update to xenial shortly after its release as we currently rely on many backports and I'd like to get rid of that. Can you file a bug explaining the issue in more detail?
<mwhudson> xnox: my main concern is getting the same thing into xenial as will go into 1.6
<xnox> doko, devac02 may have be running a hacked up kernel from apw
<mwhudson> er 1.7 i mean
<mwhudson> although even then we can cope
<robru> pitti: not sure how urgent this is, if you can wait until after xenial is released or if we should fix it sooner.
<infinity> xnox: If it works on that machine with an up-to-date glibc, that would be a good datapoint.
<infinity> xnox: Then we can go kernel bisecting.
<xnox> 2.23-0ubuntu2
<xnox> 4.4.0-16-generic
 * infinity raises his brow.
<infinity> Is that the archive's -16, or something else?
<infinity> cat /proc/version_signature
<xnox> Ubuntu 4.4.0-16.32-generic 4.4.6
<infinity> orly.
<xnox> hm... i wonder what libc is inside the doko's chroot though
<infinity> Okay, let me update a buildd to that and smack the retry button.
<infinity> Oh, check his chroot first. :P
<doko> xnox, all current from proposed
<infinity> Okay, lemme doctor up a buildd with the new kernel.
<xnox> also 2.23-0ubuntu2
<xnox> infinity, yeah that's a thought
<pitti> robru: done, bug 1564084
<ubottu> bug 1564084 in Bileto "Does not automatically add "Testsuite:" header any more" [Undecided,New] https://launchpad.net/bugs/1564084
<pitti> Saviq: ^
<robru> pitti: thanks
<infinity> xnox: Alright, building with new kernel.
<infinity> xnox: OTOH, I see nothing in the -16 upload that would relate to this.
<infinity> xnox: Can I get some SSH love to the machine where it works?
<doko> tumbleweed, https://bugs.launchpad.net/ubuntu/+source/pypy/+bug/1564088
<ubottu> Launchpad bug 1564088 in pypy (Ubuntu) "FFe: update to pypy 5" [Undecided,New]
<nacc> Pharaoh_Atem: can you sync up with ondrej and remi and find out what is to be done with php-horde-mongo? php-mongo is deprecated with php7, i afaict
<tumbleweed> doko: I'm still deciding about another patch (slow test builds are slow)
<mwhudson> the way packages disappear from the +source page while they're in the process of migrating from -proposed to -release is pretty odd
<infinity> mwhudson: Hit the publishing history, it'll show it's pending publication.
<infinity> mwhudson: But yes, that "pending" should be on the previous page, many of us agree.
<mwhudson> infinity: yeah i've discovered that trick
<mwhudson> however i've already done my time in the launchpad slave pits, not going to try to fix this one :)
<infinity> Heh.
<sarnold> better luck with the next new core-dev :)
<infinity> sarnold: Better a core-dev unwilling to look at LP bugs than one who enjoys LP bugs so much that he defects.
<infinity> cjwatson: Traitor.
<sarnold> lol
<doko> mwhudson, you didn't yet hear about the archive slave pits ...
<mwhudson> doko: i am learning every day!
<slangasek> xnox: ahhh I see, so you fix build failures on s390x in universe when it suits you, and then when it regresses and you don't want to deal with it, it's mwhudson's problem ;)
<mwhudson> docker broke because of a golang upload i did, i think you'll have a hard time blaming this one on xnox
<nacc> Pharaoh_Atem: i think i need to use a pkg-php-tools-override and specify php-mongodb as the php7 compliant version
<nacc> Pharaoh_Atem: actuall, nm, it's not clear that's going to work, as php-mongodb is quite a bit different
<nacc> slangasek: so depending on the above --^ (and i've also filed a ticket with upstream horde), php-horde-mongo is going to be uninstallable for a bit
<simon_g> hi
<simon_g> i'm not sure if it's a proper channel, but I got a rather surprising error while compilling kernel on the newest (beta) ubuntu
<nacc> simon_g: depends, what kind of error? compiling the ubuntu kernel? or mainline?
<simon_g> hi, nacc. http://wklej.org/id/2193203/ here is a link, kernel was a standard one from the kernel.org, with no extra patches or in fact any modifications that i'd think of (apart from compiling ext2/3/4 as a part of kernel, not as a module)
<simon_g> i did sudo make-dpkg clean && fakeroot make-kpkg --initrd kernel_image -j10
<simon_g> it was a while since I was doing stuff on linux, but as far as i remember (and as far as the stuff i've found over the internet say) that was a valid way of compiling kernel (with .deb packages)
<simon_g> i'll try it with the 4.5 kernel now
<sarnold> simon_g: apt-get install libssl-dev
<Pharaoh_Atem> nacc: php-mongodb is dead, afaik
<Pharaoh_Atem> afaik, it was replaced with the new php-mongo
<Saviq> pitti, thanks, about our previous conversation - I've now got gsettings-qt, qtmir and qtmir-gles stuck in proposed because of the leftover Xs-Testsuite header http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#gsettings-qt - how'd you say we deal with that?
<Pharaoh_Atem> nacc: but I'll talk to Remi about the horde package, for sure
<Saviq> pitti, already have an MP up for it https://code.launchpad.net/~saviq/qtmir/drop-testsuite-header/+merge/290468 but that won't unblock gsettings-qt anyway since it's trying to run the previous qtmir tests
<nacc> Pharaoh_Atem: other way around
<simon_g> sarnold, yeap, that's what i thought i needed. but why the heck should i need it?
<Pharaoh_Atem> nacc: oh, was it?
 * Pharaoh_Atem gets them mixed up all the time :/
<nacc> Pharaoh_Atem: yeah, 16.04 has no php-mongo, has php-mongodb
<simon_g> even on the 4.5 with standard settings (nothing has been changed) i still get that error
<sarnold> simon_g: you may be able to turn off something in the kernel configuration file to no longer build those tools
<simon_g> thanks, sarnold, it's compiling.
<sarnold> \o/
<cjwatson> infinity: :-P
<infinity> cjwatson: :)
<mwhudson> infinity: so dh_golang is just looking at build-depends to generate built-using
<mwhudson> so i think it would be appropriate to do some special casing to report the golang-X.Y-go version too
<mwhudson> just not 100% sure how to do that
<infinity> mwhudson: Oh, really?  It's that brain-dead?
<infinity> mwhudson: So, yeah, I'd special-case "golang-go" to readlink /usr/bin/go | dpkg -S | reverse-lookup.
<infinity> Well, I guess it must already be doing the reverse lookup bit, unless it's REALLY brain-dead.
<infinity> Since Built-Using is meant to reference sources, not binaries.
<mwhudson> infinity: https://anonscm.debian.org/cgit/collab-maint/dh-golang.git/tree/script/dh_golang#n88
<infinity> So, just readlink | dpkg -S -> existing bits.
<mwhudson> is there Dpkg::foo for dpkg -S or should i just shell out?
<infinity> libdpkg-perl likely has the right bits in it somewhere.  I don't use it much.
<infinity> mwhudson: Actually, maybe not.  libdpkg-perl is more about manipulating packages, not the package database.
<infinity> mwhudson: So forking is probably the right way.
<mwhudson> ok
<mwhudson> infinity: http://paste.ubuntu.com/15563663/ seems to do the job, any ideas for proper testing?
<mwhudson> infinity: http://paste.ubuntu.com/15563673/
<infinity> mwhudson: Surely, that belongs in the if{}
<infinity> mwhudson: (In case someone builds a package with dh-golang that doesn't actually use golang because derpy derp)
<infinity> mwhudson: Also should only trip is "golang-go" is in the build-deps, I'd think.
<infinity> s/is/if/
<mwhudson> infinity: dh-golang invokes go xxx a bunch of times, if there's nothing there things are going to go bad
<mwhudson> but hmm
<mwhudson> maybe if golang-defaults turns up in the list of source packages
<infinity> mwhudson: It does?
<infinity> mwhudson: It only depends on perl, so that's surprising.
<infinity> mwhudson: Wow, it really does.  So, in that case, dh-golang is broken for your new world order anyway. :/
<infinity> mwhudson: Since it won't understand a package that build-deps on golang-1.6 and calls the compiler directly.
<infinity> mwhudson: But the quick fix for now while we assume the world all uses defaults would be to just keep what you have but move it back into the if block, IMO.
<mwhudson> infinity: http://paste.ubuntu.com/15563799/ ?
<infinity> mwhudson: And conditionalise it on that dpkg-query actually returning true.
<mwhudson> infinity: for that sort of thing, i've just been putting /usr/lib/go-1.6/bin on $PATH in rules
<mwhudson> which is possibly a bit dumb
<infinity> mwhudson: Ahh, I like that iteration better (not your rules file, but dh-golang fix).
<mwhudson> i guess that's not strictly strictly correct, you could build-depend on golang-src in which case there might not be a /usr/bin/go at all
<mwhudson> but there's only so much stupidity it's worth tolerating
<infinity> mwhudson: The PATH hack could concievably be the "right" way to do it in the Go world, but you should maybe codify that.  Or even get dh-golang to help somehow.
<infinity> mwhudson: Well, conditionalize the dpkg-query.
<infinity> mwhudson: If they build-dep on golang-src and there's no /usr/bin/go, then that search will fail.
<infinity> mwhudson: And perhaps eat stderr on that.  dpkg-query is noisy when it hates you. :P
<mwhudson> infinity: what's perl for telling if the command succeeded?
<mwhudson> i think if i 2>/dev/null i'll endup appending just " " so it kinda almost "works" in that case
<mwhudson> oh $?
<infinity> mwhudson: http://paste.ubuntu.com/15563848/
<infinity> mwhudson: That's how I'd do it, likely.
<infinity> (base)adconrad@nosferatu:~/golang/dh-golang-1.12$ perl foo.pl
<infinity> foo bar baz coreutils
<infinity> Huh, though I'm getting an extra \n out of that.
<nacc> slangasek: fyi, the php-horde-spellchecker failure seems odd: "E: Failed to fetch http://ftpmaster.internal/ubuntu/pool/main/g/groff/groff-base_1.22.3-7_amd64.deb  Temporary failure resolving 'ftpmaster.internal'"
<mwhudson> infinity: http://paste.ubuntu.com/15563863/
<mwhudson> infinity: extra newlines matter <= 0 in this context i think :)
<nacc> slangasek: it built successfully for me with and without -proposed, so I think it might have been a trasnient issue
<infinity> mwhudson: Possibly not, but easily fixed with a chomp too.
<infinity> http://paste.ubuntu.com/15563889/
<mwhudson> infinity: is a string that is just "\n" truthy in perl?
<infinity> mwhudson: Strings should never be evaluated for truthiness.
<infinity> mwhudson: Perl has different operators for strings and values.
<mwhudson> isn't that what the if statement is doing? or is perl being even odder than i expect?
<infinity> mwhudson: eq/ne/etc are literal string comparisons.
<infinity> Wait, which if?
<cjwatson> truthiness of strings is dangerous to use in perl because "0" is false, for instance
<cjwatson> as it happens "\n" is true in a boolean context, but ...
<mwhudson> oh `` returns undef if the command fails
<infinity> My "if" is testing if the `` exited cleanly and, thus, set the variable.
<infinity> The later if is doing a string comparison with ''
<tsimonq2> bug 1547395 is the cause of the FTBFS for libquvi, what needs to happen now? Desktop team ack? Just curious...
<ubottu> bug 1547395 in luasocket (Ubuntu) "MIR: new dependencies for libquvi-scripts / libquvi" [Undecided,New] https://launchpad.net/bugs/1547395
<mwhudson> yeah ok
<cjwatson> infinity: your if in http://paste.ubuntu.com/15563889/ is testing string truthiness though
<cjwatson> or at least may be
<infinity> cjwatson: Shouldn't be.
<infinity> cjwatson: Oh.  I see.  Yeah, it's not in the failure case, but might be in the success case.
<cjwatson> Right.
<infinity> My perl is rusty.
<cjwatson> I'd do "my $golang_go_dep = `...`; if ($? == 0) { ... }"
<infinity> Luckily, a package name will probably always be "true", but ick.  Remind me how to express that properly?
<infinity> Fair enough.
<infinity> mwhudson: ^-- Listen to the irishman.
<mwhudson> blarghl i had that version at one point :)
<infinity> mwhudson: Plus chomp, cause chomp is never wrong.
<infinity> First thing I learned about string manip in perl. :P
<cjwatson> or if you want to be fancy then I think it's possible to glue autodie into backtick handling
<mwhudson> i have no desire to be fancy at all
<infinity> Fanciness is overrated.
<mwhudson> beyond what is necessary when in perl-mode
<cjwatson> but that probably has rather more effects on the program as a whole
<mwhudson> i don't think it would be appropriate here
 * mwhudson rebuilds lxd for the 20th time
<infinity> cjwatson: Wait.  Are you sure I'm testing the string?
<mwhudson> http://paste.ubuntu.com/15563916/
<infinity> cjwatson: Replacing the `` with `echo 0` and `echo 1` seem to both succeed and add to the list.
<cjwatson> try s/echo/printf/g
<cjwatson> "0" is false, "0\n" is true
<infinity> cjwatson: Shouldn't the () around the expression be testing the return of the assignment rather than the content?
<cjwatson> thanks Larry
<infinity> Hahaha.
<infinity> Hah.
<infinity> Hah hah hah.
<infinity> cjwatson: I concede.  And also, HAH.
<mwhudson> oh right, it's the shell's `` that strips a trailing newline if present
<cjwatson> the return value of an assignment expression is the assigned thing
<cjwatson> basically
<cjwatson> if I were writing perl stuff from scratch these days I'd probably start with Modern::Perl and autodie
<infinity> cjwatson: So there's no way to express the shell shortcut of "if assign = expr", you have to go longhand with the return?  Oh well.
<cjwatson> and using largely python-style exception handling
<cjwatson> infinity: well, you can, it's just that the assigned thing in this case isn't very boolean-friendly
<cjwatson> you could say "if (length(my $foo = ...))"
<infinity> mwhudson: That looks plausibly correct, given above.
<mwhudson> it also seems to work
<cjwatson> (iirc)
<infinity> cjwatson: Right, fair.  length() would be a cheat in cases where success also implies I set something non-null.  Which works here.
<cjwatson> you can also write it as "chomp(my $golang_go_dep = ...)" I think
<infinity> cjwatson: I guess I'm looking for the shell shorthand where I'm not actually testing the assignment at all, but the rv of the ``
<infinity> cjwatson: Which is probably more of a bug in POSIX sh than a lack of feature in Perl.
<cjwatson> infinity: well, but you are here, it's just that the test on the rv has different semantics
<cjwatson> it's still a test on the rv though
<infinity> cjwatson: Yeah, you could chomp on either line, but chomping where he did keeps line length down. ;)
<mwhudson> chomp returns the number of characters chomped i think?
<infinity> Oh, it does.
<infinity> Yeah.
<infinity> Keep the chomp where it is.
<infinity> It's lovely.
<infinity> And chompy.
<infinity> On nom.
<infinity> mwhudson: Ship it before we bikeshed more.
<infinity> I need a shower.
<mwhudson> anyway i need lunch
<infinity> And to run out.
<mwhudson> yeah ok
<infinity> Every time I do something Perly, I feel guilty about all the Perl I've forgotten.
<infinity> Has the same experience futzing with sbuild a few days ago.
<infinity> s/Has/Had/
<mwhudson> infinity: [ubuntu/xenial-proposed] dh-golang 1.12ubuntu1 (Waiting for approval)
<infinity> mwhudson: Danke.
<infinity> mwhudson: Are you uploady for that in Debian too?  Should be fixed there as well if you've done the defaults thing.
<mwhudson> infinity: no, and that hasn't happened yet
<mwhudson> hopefully soon
<mwhudson> i've sent a mail to debian-newmaint and then a whole lot of nothing has happen afaict
<infinity> mwhudson: Also, that diff had another diff inside.
<infinity> mwhudson: debdiff before upload. ;)
<mwhudson> oh right, native package
<mwhudson> infinity: you'll reject?
<infinity> mwhudson: Already have.
<infinity> You should have angry email.
<mwhudson> nope
<infinity> Well, you will some day. :P
<mwhudson> but i assume it'll arrive in due course
<sarnold> funny that the "AOL guy" didn't go with "You've got angry email"
<infinity> Anyhow, it's rejected.
<mwhudson> uploaded again
<tsimonq2> cyphermox: you around? (sorry for the naked ping)
<tsimonq2> ahh, looks like he's AFK
<infinity> mwhudson: Ta.
<mwhudson> infinity: ah got the rejection mail now, i like your explanation
<infinity> mwhudson: Given that we kinda want to start tracking built-using properly, we might want to do no-change rebuilds of all golang things once this lands, but we can worry about that another time.
<infinity> mwhudson: I might wait for the inevitable next lxd upload first, see how things look, then perhaps rebuild the world.
<mwhudson> ok
<mwhudson> well rebuild all things with binaries that are in main, at least :-)
<mwhudson> anyway, really need lunch now
<mwhudson> biab
<nacc> slangasek: aiui, phpmyadmin is ok to leave as-is, as all the php5 dependencies are from alternatives?
#ubuntu-devel 2016-03-31
<nacc> slangasek: actually, we'll need some updates, nm
<slangasek> nacc: dns resolution failures of ftpmaster.internal are transient failures and should be retried. was that a package build or autopkgtest?
<cyphermox> tsimonq2: I'm around, mostly. just took an hour to get food and get my mind off upgrades for a big
<tsimonq2> cyphermox: hey, I have an idea on bhow to solve 4 FTBFSes, a build-dep error
<tsimonq2> *how
<tsimonq2> cyphermox: I'm willing to bet the FTBFS on oxide-qt has been solved (waiting on build-deps) as the build was tried on 3-10 and the latest upload of the dependency it was waiting on is 3-16, could you please trigger a rebuild? https://launchpad.net/ubuntu/+source/oxide-qt/1.13.6-0ubuntu1/+build/9329555 and https://launchpad.net/ubuntu/+source/libhybris/0.1.0+git20151016+6d424c9-0ubuntu7 for proof, the (2) dependencies it were waiting on have
<tsimonq2> cyphermox: 4 different build-dep FTBFSes caused by it, media-hub, oxide-qt, unity-webapps-qml, and webbrowser-app, so if it works on oxide-qt, it should work on the others as well
<tsimonq2> cyphermox: mind confirming or denying my hunch?
<cyphermox> denying right away
<cyphermox> libhybris isn't built on arm64, that's a long time issue
<sarnold> iirc when I looked at the code it had issues that'd keep it from working correctly on 64 bit platforms
<nacc> slangasek: it was a packge build
<cyphermox> sarnold: seems to be build on amd64 in any case
<cjwatson> tsimonq2: It's very easy to check this using "rmadison libhybris-dev" and noting the absence of arm64.
<cyphermox> sarnold: not that it's very useful there ;)
<tsimonq2> cjwatson: oh thanks :)
<cjwatson> tsimonq2: Also, dep-waits like that are automatically given back if the dependency becomes available.
<cjwatson> tsimonq2: It's only necessary to do anything with them by hand if something has gone wrong with Launchpad.
<tsimonq2> cjwatson: makes sense, sorry, thanks :)
<sarnold> cyphermox: hah :) surprising..
<cyphermox> haha, not really
<cyphermox> it's weird android magic, IIRC
<sarnold> yeah
<tsimonq2> while I have some people here, what's holding up bug 1547395 ?
<ubottu> bug 1547395 in luasocket (Ubuntu) "MIR: new dependencies for libquvi-scripts / libquvi" [Undecided,New] https://launchpad.net/bugs/1547395
<sarnold> I'd expect it to build on arm32 and only arm32..
<cyphermox> it builds on amd64, but won't do anything and might in fact blow up if you try to use it
<cyphermox> yeah
<tsimonq2> so then why do we have it in Ubuntu?
<tsimonq2> JUST for those people?
<cyphermox> tsimonq2: it is necessary on armhf for some ubuntu touch stuff
<tsimonq2> ohh I see :)
<tsimonq2> cyphermox: so then should we expect those guys to take a look?
<TJ-> Do we have any Network Manager code-huggers or is it all upstream?
<cjwatson> tsimonq2: not until it becomes important to port Ubuntu Touch to arm64
 * cyphermox whistles innocently
<cjwatson> tsimonq2: we don't *have* to clear all arch-specific dep-waits
<nacc> Pharaoh_Atem: can you also sync with remi & ondrej on php-mysqlnd-ms (https://bugs.php.net/bug.php?id=70371)
<cjwatson> sometimes things are just hard to port
<tsimonq2> cjwatson: I see :)
<cjwatson> it's only any kind of blocker if it results in a package's architecture support regressing
<tsimonq2> now, I went on a tangent, I'll ask this for the last time (so I don't annoy people further), but bug 1547395 ?
<ubottu> bug 1547395 in luasocket (Ubuntu) "MIR: new dependencies for libquvi-scripts / libquvi" [Undecided,New] https://launchpad.net/bugs/1547395
<cyphermox> tsimonq2: that's kind of why I suggested you look at the red things before the orange ones on the ftbfs report; unbreaking the red might unblock some orange by itself (and for others it's because deps aren't targetted for that arch at all)
<tsimonq2> cyphermox: that bug would unblock the only red in main, FYI, so yes, I took your recommendation ;)
<tsimonq2> (only all-arch)
<tsimonq2> (and the only one I even have a sight hope of fixing)
<tsimonq2> *slight
<nacc> slangasek: is there a good way for me to fix the false positives in `reverse-depends` with php-pear (which used to come from src:php5, but now is from src:php-pear) ?
<nacc> slangasek: fwiw, it does seem like our list is going well and reduced quite a bit, the ones that are still present that i've marked as done in my list are due to php-pear or due to allowing php5(*) | php(*)
<nacc> down to 125 packages in my list! :)
<slangasek> nacc: we can remove php5 from the archive, and then the false positives will disappear
<slangasek> at the cost of other packages becoming immediately uninstallable
<nacc> slangasek: it's ok, i just am making notes to myself
<nacc> slangasek: i think we're looking good to be very close by friday at this rate
<nacc> slangasek: i might just try to write a wrapper for the tooling that handles the few cases i know about
<slangasek> right, you can also reverse-depends | grep -v php-pear :)
<nacc> slangasek: that's true, but i've been using reverse-depends src:php5
<nacc> nad the problem is php-pear is in that list, i'm guessing :)
<slangasek> nacc: yes, but the output of reverse-depends indicates what binary package the reverse-dependency is on.  So 'grep -v php-pear' should DWIM
<Pharaoh_Atem> nacc: yeah, I'll check into it
<nacc> slangasek: oh i see what you're saying! yeah, i've been using -l, but w/o it, i can do what you suggested
<slangasek> nacc: ah yes - grep -v and then postprocess, to reproduce the -l style list :)
<nacc> yep :)
<slangasek> I only learned about -l recently, and already forgot it again ;)
<nacc> slangasek: fair enough :)
<nacc> nice that gets me down to 199 src packages, plus the ones still going through right now, which is closer to my list
<nacc> will need to do some more post-processing to ensure that if something depends on php5* and php*, it doesn't show up in the list :)
<nacc> slangasek: thank! i'm done for the day again
<mwhudson> ho boy i can no longer remember how to use bzr
<sarnold> mwhudson: heh, same happened to hallyn earlier today. he went to play in the sun instead... :)
<mwhudson> funnily enough it's basicaly time to take my daughter swimming
<sarnold> have fun :)
<slangasek> mwhudson: schroot -c trusty -c 'apt-install bzr-git; ...'
<slangasek> except obviously not that ;)
<mwhudson> yeah how about no
<nacc> Pharaoh_Atem: thanks!
<Pharaoh_Atem> nacc: Remi seems to believe that mysqlnd_{ms,qc} modules are dead projects, due to Oracle not matching up to their promises on updating it
<Pharaoh_Atem> and he's got no idea about whether php-horde-mongo is even being maintained/updated
<Pharaoh_Atem> a little poking around indicates nothing particularly good: https://github.com/horde/horde/commits/master/framework/Mongo
<sarnold> superm1: dude, 1536871, beautiful work.
<superm1> sarnold: thanks
<sarnold> superm1: you have no idea how nuts this was driving me.
<superm1> sarnold: i should have trusted the fact that the test suite failed meant something.  i bet this is also causing weird problems for other apps that use gpgme1.0
<sarnold> superm1: oh hell.
<sarnold> I bet you're right.
<superm1> at least for 16.04 the answer is to update to gnupg2 2.1 (which I just uploaded to -proposed)
<sarnold> mdeslaur: ^^^ is there a reason we were on gnupg2 2.0 still? i've got a vague feeling that there was something Important but I can't recall what I am thinking of
<sarnold> superm1: well, good news, looks like only ruby-gpgmg and fwupd in the debian codesearch archives use that function.
<superm1> sarnold: ok that's good news indeed.  i'm surprised seahorse doesn't also use it because running into failures with it is what led me down this rabbit hole.  must be completely separate problems :)
<sarnold> superm1: or the version of seahorse where you ran into it isn't indexed in DCS :/
<sarnold> it's a great tool but only approximate to what we ship.. :(
<superm1> yeah
<Unit193> I'm missing the source browser. :/
<ScottK> superm1: If you update gnupg2 to 2.1, you'll need to sync pygpgme from Debian too.
<superm1> ScottK: OK thanks for the heads up
<ScottK> yw
<cpaelzer> good morning
<pitti> Good morning
<pitti> Saviq: I'll mark them as bad tests for this version for now
<dholbach> good morning
<Saviq> pitti, morning, did you manage to get ssh-into-britney going? we have another case of WTH with a failure we can't reproduce locally https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-046/excuses.html (any of the Regression ones, really)
<pitti> Saviq: what is "ssh into britney"?
<pitti> oh, ssh into a failing test? yes, that works
<pitti> testbed, I mean
<Saviq> pitti, yeah, that
<pitti> Saviq: I thought you asked me two weeks ago, but then wanted to try something else first
<Saviq> pitti, yeah we found the issue then
<Saviq> pitti, but now we have another one we can't reproduce locally and it might be most time-effective to just get in the failing testbed
<pitti> Saviq: I started the test manually with -s
<Saviq> pitti, ack, thanks
<pitti> cjwatson: hmm, snakefruit is still precise and its apt-ftparchive does not yet know xz; but I don't even see the option documented in xenial; does LP just pack them manually, or do you use apt-ftparchive?
<pitti> err, germanium, but same thing
<cjwatson> pitti: LP uses a backport of trusty's apt (slightly patched to add source caching)
<cjwatson> it's in precise-cat-lp or some such
<cjwatson> and we do use apt-ftparchive, yes
<mdeslaur> superm1, sarnold: yeah, we were waiting for debian bug 796931 to be resolved before switching to gnupg 2.1
<ubottu> Debian bug 796931 in gnupg-agent "gnupg-agent: no longer writes $GNUPGHOME/gpg-agent-info-$(hostname) file" [Normal,Open] http://bugs.debian.org/796931
<doko> mdeslaur, ugh, it looked to me that seth was fine with approving qnupg 2.1 ... so should we remove it from -proposed?
<pitti> cjwatson: http://ddebs.ubuntu.com/dists/xenial/main/binary-amd64/
<doko> mdeslaur, superm1: ^^^it's dep-wait for now anyway
<mdeslaur> superm1, sarnold, doko: I'm not exactly sure what the exact impact of that is going to be, or if that bug will get resolved at some point...I do think it's going to break some use-cases, but perhaps those use-cases need to be adjusted
<cjwatson> pitti: ah, excellent; will it also now cope with bz2 being absent from the Ubuntu archive?
<mdeslaur> superm1, sarnold, doko: I'm not sure what the right answer is
<doko> mdeslaur, I was looking at https://bugs.launchpad.net/ubuntu/+source/npth/+bug/1536871
<ubottu> Launchpad bug 1536871 in fwupd (Ubuntu) "[MIR] fwupd" [Undecided,In progress]
<pitti> cjwatson: ah, not yet, but that's a simple change; is there any format that will be always present, i. e should I just switch .bz2 to .gz? (while .xz isn't yet available for all series)
<cjwatson> pitti: the best approach is to try .xz .bz2 .gz uncompressed in succession
<cjwatson> pitti: Debian is flirting with getting rid of .gz and we might eventually do the same
<pitti> ok; that's an extra urlopen/error check, but I'll do that after lunch then
<cjwatson> pitti: but at the moment .gz is always present, so if trying more than one is too hard then it's ok to just use .gz
<cjwatson> for now at least
<pitti> not too hard, just a bit more work than a single-letter change
<caribou> xnox: got a minute ?
<xnox> caribou, sure
<caribou> well, I can ask in the room, maybe somebody else will have an opinion :
<xnox> in the room is best =)
<caribou> The debian maintainer for vsftpd thinks it's a good idea to leave the package in a state that cannot start ( Bug#819546)
<caribou> they reverted listen_ivp6 from YES to NO to match the manpage default and now the systemd job will not start
<caribou> (between wily & xenial)
<caribou> my guess is that he/we should at least add a prompt to ask to enable it otherwise disable the systemd job
<xnox> i believe we too, do not start vsftpd by default.
<xnox> as one must configure it to start
<xnox> e.g. #ubuntu-hardened default is no open ports by default. And hence e.g. we never install openssh-server by default.
<caribou> xnox: let me recheck but it was set to YES in wily
<xnox> i'd rather look at e.g. trusty
<xnox> there is loads of flux in init/startup between there and now.
<caribou> xnox: well we didn't do anything, it was set to YES in the uptream package
<caribou> xnox: it starts by default on W
<caribou> lemme check trusty
<xnox> caribou, right and on trusty
<xnox> it does start and does listen
<xnox> tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      23463/vsftpd
<xnox> caribou, imho it should listen on ::* by default
<xnox> sorry [::]:21 that is
<xnox> (any ipv4/6 on port 21)
<xnox> annonymous access is disabled, and we don't install it by default so i think it's what we intended for it to be.
 * xnox is also looking at e.g. ftp server docs
<caribou> xnox: I think it is how it was done on Debian as well, until Bug: #803999
<ubottu> bug 803999 in evolution (Ubuntu) "evolution crashed with SIGSEGV in gdk_cairo_set_source_pixbuf()" [Medium,Expired] https://launchpad.net/bugs/803999
<caribou> nah debian bug
<caribou> I mean taking something that works on install and leave it broken because this is the manpage default doesn't look good to me
<xnox> imho it's the manpage that is broken.
<caribou> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819546
<ubottu> Debian bug 819546 in vsftpd "vsftpd no longer starts with systemd because of listen_ipv6=NO from Bug: #803999" [Normal,Open]
<xnox> but default should listen on _both_ ipv4 and ipv6 from a single daemon
<caribou> listen_ipv6 will do both
<xnox> that's a debian ipv6 goal
<xnox> but that's (a) regression (b) deviation from debian policy
<xnox> e.g. installing apache2 on debian does bring it up and start serving pages
<xnox> ditto ftp.
<xnox> caribou, patch it in ubuntu, and then comment more on the bug report.
<caribou> xnox: fine by me.
<caribou> xnox: on another topic, I've been testing zfcpdump
<caribou> xnox: as inaddy said, we do need a small footprint kernel in order to get it to work
<xnox> caribou, talk to kernel people about it =)
<xnox> kernel team maintains all kernels on s390x.
<caribou> xnox: yes, been doing so, just wanted to keep you posted
<xnox> (well the one kernel)
<xnox> cool.
<pitti> cjwatson: ok, done; it now does the xz â gz â uncompressed fallback
<cjwatson> pitti: could you then do https://paste.ubuntu.com/15567519/ and we'll see if everything works with bz2 indexes dropped from xenial?
<cjwatson> pitti: in lp-shell production devel
<pitti> cjwatson: done
<cjwatson> pitti: thanks, let's see how that works out
<doko> ginggs, do you know about the background for the different wine packaging in Debian/Ubuntu ?
<ginggs> doko: yeah, i did some digging a few weeks ago
<ginggs> so I know a little
<doko> ?
<ginggs> what is it you want to know? I put some of the info I found here LP: #1558480
<ubottu> Launchpad bug 1558480 in wine1.6 (Ubuntu) "remove wine1.6 package" [Undecided,Confirmed] https://launchpad.net/bugs/1558480
<highvoltage> Scott Ritchie (YokoZar) did a large amount of work on wine in ubuntu but that didn't make it back to debian.
<ogra_> he always did it directly upstream instead
<doko> ginggs, I'm more curious why 1.8 was not uploaded
<ogra_> skipping debian in the chain
<doko> the packages in the ppa were last touched in December
<doko> ginggs, highvoltage, ogra_: the easy way would be to upload the debian package, bumping the epoch for the wine binary package
<ogra_> afaik upstream was always unhappy about some splits debian did ... YokoZar is originally more of an upstream guy than a debian dev
<doko> yeah, but if nothing is happening ...
<ogra_> the prob will likely be upgrades here
<ginggs> doko: lack of time? interest? i don't know... I tried contacting both members of wine team
<ginggs> doko: i don't think it is as easy as that, there are some packages in debian/ubuntu wine that have different names and some that have the same names
<highvoltage> might be a good idea to get in touch with scott: https://wiki.ubuntu.com/ScottRitchie - maybe he would like to pick it up again or maybe he wants to retire from it for good.
<ogra_> right
<doko> ginggs, not afaics
<highvoltage> ginggs: aah
<ginggs> doko: i had an idea for a transitional package, that i was testing in my ppa, it sort of worked, but then keeps wanting to upgrade one of the packages, I think because wine1.6 still exists in the archive
<ginggs> doko: i think removing wine1.6 is the first step
<doko> ginggs, reverse-depends tells you otherwise
<doko> Reverse-Recommends
<doko> ==================
<doko> * q4wine [amd64 arm64 armhf i386 powerpc]  (for wine)
<doko> * q4wine [amd64 i386]           (for wine1.6)
<doko> * winetricks                    (for wine)
<doko> Reverse-Depends
<doko> ===============
<doko> * dssi-vst [i386]               (for wine1.6-i386)
<doko> * playonlinux                   (for wine)
<doko> * pq                            (for wine)
<doko> Reverse-Build-Depends
<doko> =====================
<ginggs> doko: if it is not possible to have a transitional package to deal with the epoch bump, I can try working with the debian packagers to do it there
<doko> * dssi-vst                      (for wine1.4-dev)
<doko> ginggs, did you try to use the wine1.8 packages in the ppa?
<ginggs> doko: no, i have been using the debian packages for some time now
<TJ-> anyone know how to prevent the Network Manager build from failing due to testsuites not workable, on a local 'fakeroot' build ?
<ginggs> doko: since november last year, there is another "wine team" PPA https://launchpad.net/~wine/+archive/ubuntu/wine-builds
<TJ-> specifically: "ERROR: test-nm-client - too few tests run (expected 9, got 0)"
<cyphermox> TJ-: typically you want to run that in autopkgtests
<cyphermox> or in a vm, or in a chroot
<cyphermox> the tests are dependent on the interfaces on your system, so that may explain why they fail
<doko> ginggs, ogra_: sent email
<TJ-> cyphermox: any way to simply disable the tests with an env-var for the 'debian/rules binary' build process; I'm wanting to test some patches and don't need the testsuite right now
<doko> ginggs, only devel builds
<cyphermox> TJ-: override_dh_auto_test to not contain anything
<TJ-> cyphermox: so "override_dh_auto_test: > dbus-test-runner -m 300 -t dh_auto_test" becomes just "override_dh_auto_test:" ?
<cyphermox> TJ-: precisely
<TJ-> cyphermox: thank you :)
<TJ-> cyphermox: for reference I'm working up a patch for bug 1533631
<ubottu> bug 1533631 in network-manager (Ubuntu) "Failed to renew DHCPv6 lease after suspend" [High,Triaged] https://launchpad.net/bugs/1533631
<TJ-> ah, that needs renaming to be accurate, it's now "dhclient killed when DHCPv6 lease is out-of date"
<ginggs> doko: i think it was mlankhorst who did the last wine ppa upload
<cyphermox> TJ-: have you tried git master? it likely already has a patch
<TJ-> cyphermox: I'm working from master; there's no handling of deprefer upstream at all
<cyphermox> ok
<TJ-> cyphermox: I gen the patch on master, then import into the Ubuntu package for testing
<pabelanger> morning, did openjdk-7-jdk get removed from ubuntu xenial?
<pabelanger> it was installable up until last night
<pitti> pabelanger: yes, see bug 1563986
<ubottu> bug 1563986 in radare2-bindings (Ubuntu) "openjdk-7 removal for 16.04 LTS" [Undecided,Fix released] https://launchpad.net/bugs/1563986
<pabelanger> pitti: thanks for confirming
<pitti> arges, tjaalton: would you mind reviewing/accepting the postgresql SRUs for p, t, and w? (should just be a formality, but self-acceptance is bad)
<tjaalton> pitti: I will tomorrow, if arges doesn't beat me to it before that
<arges> working on something now, may have time later today
<pitti> thanks
<Saviq> pitti, hey, we managed to find a way to repro locally, you can release, thanks!
<rharper> slangasek: I updated https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1473691 ; the previous upload (1ubuntu3) resolved the removal of squid3 service file; 1ubuntu4 addresses your second comment (remove logic around service name and just use restart squid);
<ubottu> Launchpad bug 1473691 in squid3 (Ubuntu) "[FFe] squid: Update to latest upstream release (3.5)" [Critical,Fix committed]
<pitti> Saviq: cool, thanks
<pitti> arges: thanks
<nacc> Pharaoh_Atem: i filed https://bugs.horde.org/ticket/14309 for php-horde-mongo
<nacc> Pharaoh_Atem: so do you think we're safe to remove them? i'll check revdeps
<nacc> Pharaoh_Atem: ok, no revdeps, will schedule for removals
<doko> apw, infinity: are these expected failures? autopkgtest for linux 4.4.0-16.32
<pitti> we have a hint for 4.4.0-15.31 as -15 broke the apparmor test; looks like that's still true for -16?
<chiluk> infinity xnox  https://bugs.launchpad.net/ubuntu/+source/quassel/+bug/1506550
<ubottu> Launchpad bug 1506550 in quassel (Ubuntu) "quassel can't play audio notifications in wily" [Low,In progress]
<nacc> woo, down to 131 packages blocking removal of src:php5, src:php-json, src:dh-php5!
<tyhicks> pitti: hi - are you talking about a kernel failure?
<Son_Goku> nacc: I think weâre good on removals for them
<Son_Goku> Iâve not encountered anything that uses either of them
<pitti> tyhicks: yes, on http://autopkgtest.ubuntu.com/packages/l/linux/xenial/amd64/
<tyhicks> I think I know the issue
<tyhicks> give me a sec to confirm
<Son_Goku> nacc: bbs as Pharaoh_Atem
<nacc> Son_Goku: thanks
<tyhicks> 14:37:07 ERROR| [stderr] Error: changeprofile failed. Test 'CHANGEPROFILE (no target, /tmp/sdtest.14571-11349-vxV2zx/file)' was expected to 'fail'. Reason for failure expect errno 13 != 2
<tyhicks> 14:37:07 ERROR| [stderr] Error: changeprofile failed. Test 'CHANGEPROFILE (no target, /tmp/sdtest.14571-11349-vxV2zx/file2)' was expected to 'fail'. Reason for failure expect errno 13 != 2
<tyhicks> pitti: the apparmor 2.10.95 upload (currently awaiting FFe approval) adjusts the CHANGEPROFILE test to match the behavior found in the -15 and -16 kernels
<tyhicks> https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1561762
<ubottu> Launchpad bug 1561762 in apparmor (Ubuntu) "[FFe] AppArmor 2.11 Beta 1 for policy namespace stacking and bug fixes" [Critical,New]
<pitti> tyhicks: ah, that should fix the test again? thanks for the heads-up
<tyhicks> pitti: yes, I'm 100% sure that'll fix the test
<slangasek> rharper: fwiw on squid, stgraber's dpkg-maintscript-helper changes were incomplete and wrong.  I'll follow up today
<doko> superm1, online?
<superm1> doko: Yep
<ice799> Hi there. I'm seeing quite a few Hash Sum mismatch errors when using APT against an APT repository I generated. I've verified manually with curl shasum and md5sum on the commandline that the hash sums are correct.
<ice799> I found this bug filed: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1373598 but it appears not to be assigned yet
<ubottu> Launchpad bug 1373598 in apt (Ubuntu) "apt-get update fails, hash sum mismatches with de.archive.ubuntu.com" [High,Confirmed]
<ice799> I was mostly curious what the process is for bugs that are marked high,confirmed to be assigned if there is one
<doko> superm1, any idea what would go wrong when updating to the new gnupg2 version?
<superm1> doko: the only that came to mind was what mdeslaur raised regarding the difference in behavior with the agent
<superm1> there was quite a bit of discussion on the debian bug about it
<doko> superm1, do you know about packages which would depend on this?
<ice799> a similar bug was reported for XZ compressed APT repositories, against APT here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744758 which was fixed in APT version 1.0 and newer
<ubottu> Debian bug 744758 in apt "apt: hash sum mismatch" [Normal,Fixed]
<superm1> doko: depend on the new command line arguments that came in version 2.1?
<superm1> or you mean the difference in behavior with the agent?
<doko> superm1, the debian bug talks about the changed filename, not command line options
<cjwatson> ice799: if it's a repository you generated yourself I'd still suspect the repository before suspecting apt.  there are various debugging options under the "DEBUG OPTIONS" section of "man apt.conf" that you should try first to determine precisely which checksums it's complaining about
<cjwatson> ice799: bug 1373598 seems a lot more likely to be some kind of proxy handling bug, it's unlikely you in fact ran into that with a local repo
<ubottu> bug 1373598 in apt (Ubuntu) "apt-get update fails, hash sum mismatches with de.archive.ubuntu.com" [High,Confirmed] https://launchpad.net/bugs/1373598
<superm1> doko: right i was meaning the impetus that got into pulling gnupg 2.1 in the first place.  on that bug i think it would really  affect expected behavior from previous versions of gpg-agent
<cjwatson> (and we're working on a general solution to that class of problem, hopefully for 16.04, but that's on the server side and won't apply to a locally-generated repository)
<superm1> so it might affect what gets passed through on say an SSH login
<doko> so maybe people need adjust, but no packages need adjustments
<superm1> right
<superm1> if anything at some point it might be worthwhile to SRU the outcome of that debian bug
<nacc> slangasek: just filed LP: #1564492, which is a FTBFS due to a debhelper issue (patch for debhelper attached)
<ubottu> Launchpad bug 1564492 in php-mf2 (Ubuntu) "FTBFS: php-mf2 due to unicode in substvars file" [Undecided,New] https://launchpad.net/bugs/1564492
<slangasek> nacc: er, is non-ascii allowed in description fields under Debian policy?
<nacc> slangasek: the fix is from Debian, so I assumed so, let me see if i can find it i the policy
<nacc> slangasek: hrm, good point...
<doko> superm1, mdeslaur, https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1536871  subscribing foundations. can you subscribe security too? same as currently for gnupg2
<ubottu> Launchpad bug 1536871 in npth (Ubuntu) "[MIR] fwupd" [Undecided,Incomplete]
<nacc> "The field name is composed of US-ASCII characters excluding control characters, space, and colon (i.e., characters in the ranges 33-57 and 59-126, inclusive)."
<nacc> slangasek: so names can't have non-ASCII, but it's unclear if the value can
<slangasek> nacc: it's allowed these days in /some/ fields, but I'm not sure if Description is one or if it makes sense to
<cjwatson> I'm fairly sure Description can be UTF-8 and non-ASCII
<nacc> slangasek: ok, reading https://www.debian.org/doc/debian-policy/ch-controlfields.html I don't see anything specifying it, but maybe looking in the wrong place
<cjwatson> It seems like one of the most obvious fields that would want to be non-ASCII
<slangasek> ok
<slangasek> cjwatson: I knew we'd allowed it for Maintainer, but for description I wasn't sure if it was allowed or if that was only permitted in translated fields
<cjwatson> The policy language seems a bit woolly on it though
<nacc> "All control files must be encoded in UTF-8" and it only explicitly mentions "field name" as being in ASCII
<nacc> afaict
<nacc> slangasek: i mean, i think it's the "long dash" character in teh description, which we could also change ... whatever you'd prefer
<cjwatson> There are examples that already do, e.g. cvs, deja-dup
<cjwatson> cvs is a bit gratuitous but deja-dup is IMO reasonable
<cjwatson> or firefox-locale-nb which is definitely reasonable
<superm1> mterry: when you did a local test suite run for fwupd (that presumably had libtool-bin installed), did you see something like this in your output log [ Fu:ERROR:fu-self-test.c:219:fu_provider_func: assertion failed (error == NULL): Error creating directory                : Permission denied (g-io-error-quark, 14) ]?
<doko> superm1, both promoted
<superm1> doko: okay thanks
<mterry> superm1: uh my test failure just said something like Aborted, as if there was a segfault...  let me run it again
<superm1> does launchpad drop permissions for the build?  i can only seem to reproduce it on launchpad, not in pbuilder locally
<superm1> mterry: src/test-suite.log unfortunately isn't automatically output, so you need to apply something like this to get it to output in an automated build: http://pastebin.com/z1aRQBSf
<mterry> superm1: ah yes, in test-suite.log: Fu:ERROR:fu-self-test.c:219:fu_provider_func: assertion failed (error == NULL): Error creating directory: Permission denied (g-io-error-quark, 14)
<cjwatson> superm1: Launchpad uses sbuild which runs the build as a non-root user
<superm1> ah OK.  I'll dig further into this then
<ricotz> could someone take care of https://bugs.launchpad.net/ubuntu/+source/pcre2/+bug/1557955
<ubottu> Launchpad bug 1557955 in pcre2 (Ubuntu) "Please sync pcre2 10.21 from Debian" [Undecided,New]
<nacc> ricotz: wouldn't it need a FFe?
<teward> it would at this point
<teward> past FeatureFreeze
<nacc> ricotz: https://wiki.ubuntu.com/FreezeExceptionProcess
<ricotz> nacc, it does, I was about to file a bug, and found about that one
<ricotz> filed a proper one https://bugs.launchpad.net/ubuntu/+source/pcre2/+bug/1564510
<ubottu> Launchpad bug 1564510 in pcre2 (Ubuntu) "FFe: Sync pcre2 10.21-1 (universe) from Debian unstable (main)" [Undecided,Confirmed]
<Odd_Bloke> cjwatson: pitti: I'm not 100% sure what's happening with Packages.(bz2|xz), but http://archive.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages.xz doesn't exist (which is breaking some of our scripting :).
<Odd_Bloke> (I am fixing the script(s) to handle failing over to different compression types)
<cjwatson> Odd_Bloke: your scripting is indeed just buggy, since that file isn't advertised in .../xenial-security/Release
<cjwatson> Odd_Bloke: Packages.xz will appear next time xenial-security is actually published :)
<Odd_Bloke> cjwatson: OK, cool.
<ice799> cjwatson: may i ask what the proposed server-side solution is for 16.04? Is it documented somewhere?
<ice799> cjwatson: its not a proxy bug -- no proxy is being used and the repo is being transmit over HTTPS
<ice799> cjwatson: i've manually verified all checksums, but i agree that getting APT to be more verbose about what it thinks is wrong would be helpful
<cjwatson> ice799: Basically https://wiki.debian.org/RepositoryFormat#indices_acquisition_via_hashsums_.28by-hash.29, but this is only applicable if your problem is a race condition between clients and repository updates; if you're seeing problems when the repository is at rest then this is not relevant.
<cjwatson> ice799: You very much need to not conflate a ton of different possible causes for hash sum mismatches.
<ice799> ah finally
<ice799> indexes with hash sums in the URL
<cjwatson> ice799: -o Debug::Acquire::https=true -o Debug::Hashes=true is probably a good place to start/
<cjwatson> s,/,.,
<mterry> doko: fwupd tests weren't sorted out yet man
<doko> mterry, ohh, sorry
<doko> superm1, ^^^
<mterry> doko: it's ok, superm1 is working on them
<mterry> superm1: please continue to work on them, even though fwupd is in main now  :)
<superm1> yeah i'll get something in next upload
<superm1> the test suite is just referring to stuff outside the build dir, i'd like to fix it the right way upstream first
<ice799> cjwatson: Debug::Hashes doesn't seem to tell me anything but I do see some HTTP 416s come back
<ice799> looks a bit like this one: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/798023
<ubottu> Launchpad bug 798023 in apt (Ubuntu) "apt-get update fails with error 416 Requested Range Not Satisfiable" [High,Confirmed]
<cjwatson> ice799: I think I'd get further seeing the raw apt-get update output with those debug options than guessing at bugs
<cjwatson> (though am about to go for dinner)
<ice799> cjwatson: ah i see
<ice799> i had a typo
<ice799> yea so
<ice799> i see a "201 URI Done" with a list of hashes that all match
<ice799> followed by a "[6 Packages store 0 B]"
<ice799> with hashes that mismatch
<cjwatson> I'm not promising to debug it, but if I were you, I would put the output on paste.ubuntu.com rather than summarising it in prose
<cjwatson> a paste of the relevant Release file would probably be useful too
<ice799> the release file is right
<cjwatson> that doesn't mean it isn't useful for debugging
<ice799> agreed
<ice799> the actual APT error appears to be: W: Failed to fetch store:/var/lib/apt/lists/partial
<ice799> with a long path
<ice799> i need to read the apt source to see what failed to fetch store really means
<ice799> because from the output it looks like what apt is downloading is right, but after the download it tries to unpack it and then fails to verify
<cjwatson> also there are some subtleties that are not obvious, like handling of uncompressed files
<cjwatson> that's why I'm asking for the Release file
<ice799> im gathering all of this information now
<Saviq> slangasek, bad news, we've another cmake-3.5-related problem - the latest failure in http://autopkgtest.ubuntu.com/packages/u/unity8/xenial/amd64/ is caused by new cmake building/linking the test differently (I confirmed - downgraded cmake and test passes again)... not yet sure what the exact difference is :/
<doko> Saviq, what's the error?
<Saviq> doko, "QObject::connect: signal not found in DirectionalDragArea"
<Saviq> when running the test
<doko> Saviq, how do you know that's a link error?
<Saviq> doko, I don't, I just know the error goes away and test passes when I downgrade cmake...
<Saviq> doko, or, it's a red herring...
<cjwatson> dinner bell, EOD
<doko> Saviq, a little more investigation would be nice, or maybe ask LocutosOfBorg (currently not online)
<Saviq> doko, yeah, I'm trying to get as much data as possible (I'm not saying we're doing everything right), but I can confirm that downgrading cmake makes it work again...
<Saviq> doko, slangasek, OK unping, it's not about how it's built, but how the test is invoked - and it was invoked incorrectly before
<Saviq> or not, /me is lost completely
<Saviq> ok no, it is really how it is built
<ginggs> Saviq: LocutusOfBorg having trouble with irc lately, but drop him an email
<ginggs> doko: do you have any opinion on LP:  #1562287 ?
<ubottu> Launchpad bug 1562287 in julia (Ubuntu) "Julia FTBFS on armhf since 5.3.1-3ubuntu3, builds in Debian" [Undecided,New] https://launchpad.net/bugs/1562287
<doko> ginggs, no :-/
<slangasek> nacc: debhelper uploaded; are there other source changes needed in the packages that are FTBFS without this?
<nacc> nope, they just rebuild fine w/ that debhelper fixlet
<nacc> slangasek: --^
<ginggs> doko:  oh well, if you have any ideas, please give me a shout :)
<slangasek> nacc: ok, then please close the other tasks
<doko> ginggs, well, you could try to lower optimization
<nacc> slangasek: will do
<nacc> slangasek: are they goign to be rebuilt then, or do you want me to keep them in my next rebuild list?
<slangasek> nacc: put them in the rebuild list, please
<nacc> slangasek: ok, thanks!
<ginggs> doko: i'll try that, thanks
<nacc> slangasek: fyi, figured out the lintian issue with php-opencloud, i think .. working on it now
<Saviq> doko, slangasek, ok I found where cmake 3.2 and 3.5 differ: http://pastebin.ubuntu.com/15570003/
<Saviq> 3.5 does not pass "-Wl,-soname,libUbuntuGesturesQml.so"
<doko> Saviq, and which macro is this passed in?
<slangasek> that's fair, it's not a very good soname ;P
<doko> well, seems to be a plugin?
<Saviq> doko, yeah, this is likely where this whole issue stems from - it is a plugin but is linked to by the test executable
<Saviq> so I'm perfectly willing to accept we're Doing it Wrongâ¢
<doko> LoB identified some macros which were not used anymore. Is this one of them?
 * Saviq emails LoB
<doko> Saviq, better file a bug report and tell him the number
<Saviq> right, or that
<doko> ginggs, ohh, Scott Ritchie replied
<Saviq> ughh
<ginggs> doko: emailed you and ogra
<doko> superm1, can https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/1564234 be closed?
<ubottu> Launchpad bug 1564234 in gpgme1.0 (Ubuntu) "gpgme1.0 doesn't work properly with gnupg 2.0" [Undecided,New]
<superm1> doko: yes
<superm1> doko: once proposed migration finishes it should close
<Saviq> so, bug #1564571 FWIW
<ubottu> bug 1564571 in cmake (Ubuntu) "cmake 3.5.1 no longer passes -soname to linker reliably" [Undecided,New] https://launchpad.net/bugs/1564571
<lamont> stgraber: around?
<lamont> stgraber: I want to confirm that (for xenial) I can still run the squid binary as 'squid3' (in that you are not dropping that symlink that I saw in the 3.5 package a few days ago)
<rharper> lamont: AFAICT, /usr/sbin/squid3 is still present, we removed  /etc/init.d/squid3 , and instead the service file is going to be /etc/init.d/squid
<lamont> rharper: that's what it looked like in the 3.5 package.  I was just confirming that you're not planning to drop /usr/sbin/squid3 as well
<lamont> (currently, the binary is /usr/sbin/squid, with a symlink of squid3 -> squid
<rharper> right;  I know of no plans to remove the sbin symlink; just the service name;
<lamont> ta
<rharper> since it's not yet complete (the FFE) and slangasek is going to review it;  it's possible that it could be dropped; I'm expecting an update from slangasek about the current status
<rharper> lamont: if you're not already subscribed, tracking https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1473691 is a good idea
<ubottu> Launchpad bug 1473691 in squid3 (Ubuntu) "[FFe] squid: Update to latest upstream release (3.5)" [Critical,Fix committed]
<infinity> I don't see much reason to keep the symlink, personally.  We'd want to drop it eventually.
<rharper> infinity: yeah; if we're not keeping the service name squid3, then the binary ought to be called as squid as well, (and it is invoked that way); however, we may need to see if the universe packages refer to it as squid/squid3 and might need an update there if we drop the symlink
<infinity> Or, if the intent is to give people an LTS cycle to fix their scripts, replacing the symlink with a shell wrapper that does "echo squid3 has been renamed to squid\nexec squid" would help.
<rharper> that sounds nicer than breaking callers of squid3
<slangasek> nacc: I don't understand the latest updates to bug #1557599, haven't we fixed phing and php-apigen several times over?
<ubottu> bug 1557599 in php-apigen (Ubuntu) "php packages: add php-mbstring dependency" [Undecided,New] https://launchpad.net/bugs/1557599
<lamont> rharper: and subscribed thanks
<doko> superm1, http://autopkgtest.ubuntu.com/packages/a/apt/xenial/armhf/ triggered by gnupg2
<superm1> doko: i'm not sure that's actually caused by gnupg2
<superm1> doko: failure was "Test for successful execution of grep dlstatus:1:0:Retrieving file 1 of 1 apt-progress-https.log â¦ FAIL: Failed to detect download progress"
<robert_ancell> beuno, who handles canonical-indentity-provider? I'm trying to work out how you get the username from a login so we can check reviews come from the current user
<robert_ancell> http://canonical-identity-provider.readthedocs.org/en/latest/resources/index.html doesn't seem to have a method to query username
<superm1> doko: any way to re-run to check if was transient?
<doko> superm1, given back
<doko> ginggs, https://launchpadlibrarian.net/250530365/buildlog_ubuntu-xenial-arm64.deal.ii_8.1.0-6_BUILDING.txt.gz  Too many GOT entries for -fpic, please recompile with -fPIC
<ginggs> doko: why would that be a problem in ubuntu all of a sudden?
<doko> ginggs, ENOCLUE, but usually using -fpic instead of -fPIC isn't worth the trouble
<ginggs> doko ok i'll try -fPIC and see what happens, can I just do that for all archs?
<doko> ginggs, yes
<pitti> cyphermox, slangasek, infinity: systemd uploaded with the fix for the udev killing spree on upgrade; queue review appreciated, I tested it locally on my desktop and with its autopkgtests
<slangasek> pitti: looking
 * pitti waves good night
<ginggs> good night pitti
<ginggs> doko, deal.ii building in my PPA with -fPIC, will upload in the morning if successful
<doko> ginggs, ta
<nacc> slangasek: so i actually tried to use them (in order to debug something else)
<nacc> slangasek: they both call mb_ functions in their fiels
<nacc> slangasek: which means they need php-mbstring to be installed to work
<slangasek> nacc: ahh, runtime dep, ok
<karstensrage> any ubuntu backporters in here?
<teward> karstensrage: i guess my suggestion of waiting a while longer for a response given the proximity to Xenial release, of which I stated in -motu, is being ignored?
<nacc> slangasek: what does it mean for a package.install file to only contain, e.g., '/usr/include/php/ext/'?
<slangasek> nacc: "install this subdirectory of the build tree into the package at the same location"
<nacc> slangasek: ok, thanks, wasn't seeing that in the manual
<karstensrage> no teward not ignored, asynchronous suggestions from other channels
<karstensrage> sorry, its just that i have so many things stalled, i can compensate for 2 or 3 but when 5 things are stalled its hard to keep going
<ginggs> doko, i've been building julia on a rpi2 with -O instead of -O2, and it has just segfaulted at the same place (docs/helpdb.jl). I guess that is better than just getting stuck there for 150 minutes
<teward> karstensrage: ah.
<karstensrage> i know its not your priority teward i appreciate that, but its frustrating none the less
<infinity> karstensrage: Patience.  The backporters team is entirely volunteer-staffed, and have no stated SLA. :P
<teward> ^ that
<teward> :)
<doko> ginggs, -Og could be next ...
<ginggs> trying...
<tsimonq2> infinity: maybe there should be? :P
<tsimonq2> just saying
<nacc> slangasek: Pharaoh_Atem: I think I've found a bug in php-fshl, as well, trying to figure out why it wasn't seen earlier. Rebuilding the wily version also has this problem, but the version in the wily archive doesn't -- still debugging
<teward> tsimonq2: keep in mind proximity to Xenial - this close to a release, backports I believe have to be deprioritized in favor of bug squishing and running the final stretch ;)
<teward> it's one of the reaosn the nginx PPAs are delayed by a few days right now, even though nginx just recently released an update ;)
<Pharaoh_Atem> nacc: that's... bizarre
<nacc> Pharaoh_Atem: could be a side-effect of copying; it's something to do with phpab
<Pharaoh_Atem> hmm
<beuno> robert_ancell, hi
<beuno> robert_ancell, there isn't anything as a username
<beuno> the log in is your email
<robert_ancell> beuno, discussing with dobey in #ubuntu-desktop - rnrserver is returning the launchpad ID for username (if you have one) and the OAuth consumer key otherwise. Click reviews only return consumer_key which makes them easy to match to the credentials returned from canonical-identity-provider
<dobey> oh hi in here too
<dobey> beuno: i also pinged in internal irc and have been chatting with noodles about this
<nacc> Pharaoh_Atem: can you help me make sure i'm not crazy? php-fshl has an autoload file; in wily (and debian), that file contains, e.g. 'fshl\\generator' => /Generator.php'; but in xenial (and if i rebuild the wily version), i get 'fshl\\generator' => '/FSHL-2.1.0/FSHL/Generator.php', which fails to work at runtime (as that is not an accurate path)
<Pharaoh_Atem> nacc: what would you like me to do?
<nacc> Pharaoh_Atem: see if you can reproduce that with debian's package (that the installed version and the version you get if you run phpab manually in the source just debian/rules does) differ
<nacc> Pharaoh_Atem: then help me figure out why :)
<Pharaoh_Atem> heh
<Pharaoh_Atem> let me update my box and I'll go ahead and test that
<Pharaoh_Atem> nacc: you want me to grab from debian sid?
<nacc> Pharaoh_Atem: yes please
<ginggs> doko: -Og segfaults in the same way as -O
<doko> fun
<Pharaoh_Atem> :'(
<Pharaoh_Atem> apparently failed to fetch packages :(
 * Pharaoh_Atem re-runs
<Pharaoh_Atem> wow
<Pharaoh_Atem> one day, Ubuntu upgrades will not be slow... :(
<nacc> Pharaoh_Atem: is it normal for debian packages of pecl extensions to not enable the extension on installation?
<Pharaoh_Atem> I'm not sure
<nacc> ok
<nacc> it seems like some do and some don't
<Pharaoh_Atem> that's what I was about to say
<nacc> Pharaoh_Atem: i guess i'm struggling to figure out how else a runtime dependency (php-pecl-http in its php7.0 version) can be expressed upon another pecl extension, where the dependency check is that it's enabled
<Pharaoh_Atem> wait, it's specifically checking for it to be enabled?
<nacc> "configure:7033: error: Please install pecl/raphf and activate extension=raphf.so in your php.ini"
<nacc> it's in mods-available, just not mods-enabled
<nacc> afaict
<Pharaoh_Atem> ugh
<Pharaoh_Atem> is there even a capability to trigger it to be enabled automatically?
<nacc> actually, i think i see what's wrong, i might be able to use dh-php to handle it
<slangasek> nacc: fwiw libgd2-xpm-dev is a virtual package now, provided by libgd-dev; it ought to work for php-ps, except for the fact that php-ps's build-dep is versioned
<nacc> oh i see
<nacc> slangasek: let me try unversioning it and see if it succeeds, at least
<slangasek> nacc: you're welcome to, but I've already removed the package ;)
<nacc> slangasek: fair enough, it seemed pretty crufty and had no revdeps
<slangasek> yes
<nacc> slangasek: i apologize for not making much progress today, i've bene trying to figure out how to wrangle 3 packages we need to take from pecl that build actual extensions, i think i've got it now
<nacc> and mostly rebuilds from my list today (will attach to the other bug shortly)
<slangasek> nacc: that's perfectly fine
<slangasek> nacc: php-mysqlnd-ms is marked on bug #1547183, with no comments; anything that needs saying on this one?
<ubottu> bug 1547183 in php5 (Ubuntu) "Remove php5 specific packages from the archive" [Undecided,Incomplete] https://launchpad.net/bugs/1547183
<slangasek> it hasn't been removed from Debian yet, at least
<nacc> slangasek: per Pharaoh_Atem and remi (fedora php maintainer) it's not maintained any longer; i can't get it to build with php7 afaict
<slangasek> ok
<nacc> slangasek: just uploaded my debian tarballs to LP: #1564566
<ubottu> Launchpad bug 1564566 in php-raphf (Ubuntu) "[FFe] Update to PHP7.0 upstream versions" [Undecided,New] https://launchpad.net/bugs/1564566
<nacc> all three built for me now
<nacc> the only ugliness i ran into was dh-php complains if there is not a <package>.php file, so i had to create empty debian/<package>-dev.php files for the -dev packages
#ubuntu-devel 2016-04-01
<superm1> mterry: i've got patches that sort out the rest of test suite problems that are upstream now.  upstream is about to cut a new release so i'll just wait on that to do it all in one swoop tomorrow
<nacc> slangasek: for php-pinba, upstream has a branch that is testing successfully with php7, but not yet in a release. I've pinged them to see if they will release. Would it be ok to put that in the "broken needing SRU category", potentially?
<nacc> at the sametime, it's a leaf package and we can probably delete it :/
<slangasek> nacc: it /could/ be put in the "broken, SRU later" pile; but I think we should be realistic about how much time we want to spend on all of these leaf packages post-release
<nacc> yep, agreed, hence my amendment just now; i think we're better off just deleting it
<nacc> i'll file the bug
<Pharaoh_Atem> nacc: why are you trying to get drupal7 working on php7?
<Pharaoh_Atem> afaik, upstream isn't working on this, and has recommended drupal8 for php7
<nacc> Pharaoh_Atem: because drupal8 isn't packaged and i'm being told it's not acceptable to not have a drupal
<nacc> Pharaoh_Atem: upstream *is* working on this, fwiw
<Pharaoh_Atem> oh, they are?
<nacc> yes
 * Pharaoh_Atem didn't find an issue when he searched for it
<Pharaoh_Atem> good to know, though
<nacc> https://www.drupal.org/node/2483571
<nacc> https://www.drupal.org/node/2454439
<nacc> rather
<Pharaoh_Atem> nacc: so on a slightly unrelated note, the code change work has been finished for libvirt-php, and now we're going through testing
<Pharaoh_Atem> it might actually get done within the next two weeks :)
<nacc> cool
<sarnold> "not acceptable to not have a drupal"???
<sarnold> what darkness befalls us
<sarnold> madness envelopes us
<sarnold> our sanities and our humanities sundered
<Pharaoh_Atem> :(
<Pharaoh_Atem> well, it's been far too long since I've heard "Linux for Human Beings"... maybe this is why? :(
<sarnold> it may be a vicious cycle
<sarnold> no one updates drupal
<sarnold> so no one uses drupal
<sarnold> no one uses drupal
<sarnold> so no one updates drupal
<sarnold> http://people.canonical.com/~ubuntu-security/cve/pkg/drupal7.html
<sarnold> it pants a sad sad picture.
<nacc> sarnold: for s&g, i am trying to to uscan & uupdate to drupal8, which at least will be more current ... not sure that's really a better way to go, but curious if it will work
<mwhudson> does someone want to read a strange tale of compiler warnings? my comment #10 on https://bugs.launchpad.net/ubuntu/+source/juju-mongodb/+bug/1557852
<ubottu> Launchpad bug 1557852 in juju-mongodb (Ubuntu) "[needs-packaging] juju-mongodb3.2 in xenial, wily, and trusty" [Wishlist,Incomplete]
<sarnold> that's a good one
<cpaelzer> good morning
<pitti> Good morning
<cpaelzer> wgrant: I just realized you are online atm - if I would have known I would have asked
<cpaelzer> wgrant: so you didn't like the title change on bug 1564513 clarifying
<ubottu> bug 1564513 in Launchpad itself "Only drivers can target bugs to series" [Undecided,New] https://launchpad.net/bugs/1564513
<cpaelzer> wgrant: sorry, I thought reading your great explanations that would make it more clear - but I'm fine with the shorter title as well
<wgrant> cpaelzer: Had a longer reply penned, forgot to hit send. It's there now.
<wgrant> Happy to discuss further here.
<cpaelzer> wgrant: ok great  - let me digest all of that ...
<cpaelzer> wgrant: ok nice, details are good now
<cpaelzer> wgrant: so to quote you I think the current state and actual thing to tackle with the bug is "that's why it would be good to split out series targeting"
<wgrant> Yep, that's why I retitled the bug.
<wgrant> The problem is that only drivers can target bugs.
<cpaelzer> ack
<ginggs> morning pitti, julia's autopkgtest failed on i386 again and i can't see why - it ran the same tests successfully during the build. would you have a look please?
<cpaelzer> wgrant: thanks, I think we can keep the bug at that state until somebody finds time to really work at it
<sarnold> I couldn't get the xenial beta2 server "memory test" to run; does anyone know which component should get the bug report?
<cpaelzer> wgrant: maybe triage it away from status new now that it is kind of clear what would need to be done, but clearly that is your call to make
<wgrant> cpaelzer: Done.
<pitti> ginggs: it's very flaky on i386; I thought i386 was mostly broken/utterly slow due to some known llvm regression
<ginggs> pitti: that was fixed in llvm 3.8
 * pitti retries it
<ginggs> pitti: thanks. i was about to say you can see from the test durations when it went from >5hrs to 20min, but I see the very last duration was 5hrs again. :(
<pitti> yeah, it timed out
<ginggs> pitti: from what i can see, it seems to have run against the correct versions of openlibm and openspecfun. i'll wait to see what happens with the retry
<dholbach> good morning
<dholbach> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<dholbach> mhall119, Laney: so there are a bunch of svg icons in the sponsoring queue... what am I supposed to do with these? can I just assume they're under the same license as the source of the packages?
<tjaalton> doko: hi, bug 1558820 is assigned to you, and mesa will build depend on libva next week. do you have time to look at the MIR before that happens?
<ubottu> bug 1558820 in libva (Ubuntu) "[MIR] libva" [Wishlist,New] https://launchpad.net/bugs/1558820
<oSoMoN> Mirv, good morning! oxide in xenial is affected by https://bugreports.qt.io/browse/QTBUG-47940 and there doesnât seem to be any activity upstream, do you think you could escalate it, or maybe we could try and distro-patch it?
<Mirv> oSoMoN: if you have suggestion of a distro patch we should suggest it to upstream, but otherwise let's see if we can get some attention to it
<doko> tjaalton, not today, errands. will have to wait 'til next week
<tjaalton> doko: that's fine
<doko> ginggs, boinc-client-nvidia-cuda/ppc64el unsatisfiable Depends: libcuda1 | libcuda1-any | libcuda-7.5-1 | libcuda-7.0-1 | libcuda-6.5-1 | libcuda-6.0-1 | libcuda-5.5-1 | libcuda-5.0-1
<oSoMoN> Mirv, ok
<ginggs> doko: we will need http://www.nvidia.com/download/driverResults.aspx/100747/en-us packaged for ubuntu before that will be installable (in Debian it is packaged with the video driver)
<ginggs> doko: does that block boinc?
<dholbach> nacc, can you maybe upload the roundcube upload you want to sponsored to a ppa and link to it?
<dholbach> nacc, the problem with the long diff is that removals of files can't easily be applied like this - here's the errors I'm seeing: http://paste.ubuntu.com/15575439/
<ginggs> doko: nvm, I see the missing libcuda1 on ppc64el is blocking boinc. I emailed PlagueOfLocusts and he's uploaded a new version dropping ppc64el again
<ginggs> pitti: i think that julia test on i386 is going to fail again. can we ignore that failure please?
<dholbach> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Saviq> pitti, hey, can you please recycle https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-046/excuses.html for me? also... any idea what happened here https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-046/excuses.html ?
<GunnarHj> dholbach: Don't think upstream would need my hackish patch at bug #1563553. I suspect that there is a more 'correct' way to define ENABLE_NLS, e.g. in debian/rules, but I don't know how. Hence my patch to simply make it work in 16.04.
<ubottu> bug 1563553 in gnome-calendar (Ubuntu) "Translations not loading in Gnome Calendar 3.19.92-0ubuntu2" [High,In progress] https://launchpad.net/bugs/1563553
<rbasak> slangasek: may I have your opinion on 1564856 please? Can we bump that?
<rbasak> bug 1564856
<ubottu> bug 1564856 in myodbc (Ubuntu) "myodbc uses internal libmysqlclient functions no longer exported by 5.7" [Undecided,New] https://launchpad.net/bugs/1564856
<dholbach> GunnarHj, ok... I wasn't sure if the upstream project had the same issue with translations
<GunnarHj> dholbach: I'm not *100%* sure either. But I doubt it.
<dholbach> ok
<dholbach> GunnarHj, https://git.gnome.org/browse/gnome-calendar/commit/?id=4e735ef3cef514a7fda1e5b94cd64941dbd2507d
<dholbach> (landed in master 3 days ago)
<dholbach> maybe we should backport that or wait for the .1 release?
<dholbach> what do you think?
<GunnarHj> dholbach: So I was wrong. :( Well, if we cherry pick that patch, it adds to our collection of patches which need to be dropped later on. Same as the patch I proposed. So for practical reasons it doesn't matter.
<dholbach> ok, wfm - I can add a note to the changelog about this
<GunnarHj> dholbach: Sounds like a smart compromise to me. ;)
<asac> hmmm. my cups-browsed package doesnt really upgrade for days
<asac> Preparing to unpack .../cups-browsed_1.8.3-2ubuntu2_amd64.deb ...
<asac> Failed to execute operation: Failed to activate service 'org.freedesktop.systemd1': timed out
<asac> it hangs there
<asac> i ctrl-c eventually and then the package is in bad inconsistent state
<asac> so i cannot remove it :)
<pitti> xnox, infinity: I landed the "lolz number of jobs/failed units" fix upstream and pulled it into our tree
<asac> pitti: how do i best hack things so that purging a package does not try to stop the systemd job? in my case cups-browsed
<asac> just remove the service file in /etc/systemd?
<xnox> pitti, that makes sense
<pitti> asac: that rather sounds like its postrm getting stuck in systemctl daemon-reload; but that's guarded with a || true
<pitti> asac: i. e. sounds like dbus-daemon got restarted or something such?
<asac> ok let me see if i can hack up postrm
<asac> pitti: hmm. sudo systemctl --system daemon-reload indeed hangs
<asac> how can i debug this?
<asac> oh it times out with : Failed to execute operation: Failed to activate service 'org.freedesktop.systemd1': timed out
<asac> so yeah thats what i see in postrm
<pitti> asac: no off-hand idea how you got there; was this recently dist-upgraded, and you didn't reboot by any chance?
<asac> pitti: i didnt reboot for 2 days i think
<asac> dist-upgraded twice/three times a day
<asac> think it started yesterday
<asac> pitti: how can i find what the service having problems is?
<asac> or you say i should rather reboot first
<pitti> asac: that will help for sure
<pitti> I don't really know what else could help, though
<asac> ok
<asac> then lets ignore ... /me reboots
<Saviq> pitti, hey, any idea what happened here https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-046/excuses.html ?
<pitti> Saviq: err, no -- britney's idea of April's fool?
<pitti> ginkgocadx only exists in xenial-proposed
<pitti> but tpm2-tools exists in xenial
<pitti> the corresponding britney log would be interesteing
<pitti> https://requests.ci-train.ubuntu.com/static/britney/log_20160401_114001.txt
<pitti> oh, might be related to the removal of Packages.bz2
<pitti> http://archive.ubuntu.com/ubuntu/dists/xenial/multiverse/source/Sources.bz2:
<pitti> 2016-04-01 11:40:01 ERROR 404: Not Found.
<pitti> robru: ^ your script to retrieve the archive package indexes needs to move from .bz2 to .xz (with a fallback to .gz)
<cjwatson> For some reason it's using Packages.gz but Sources.bz2
<cjwatson> The simplest fix would be to just use .gz for both
<cjwatson> pitti,robru,Saviq: https://code.launchpad.net/~cjwatson/bileto/no-bzip2/+merge/290736
<pitti> cheers
<Saviq> tx :)
<rbasak> doko: I'm seeing a bunch of "error: âisnanâ was not declared in this scope" errors when rebuilding things for MySQL. Is this a common pattern that you're aware of - due to a new toolchain maybe? And if so, is there a standard pattern for a fix?
<cjwatson> Is it any more exotic than forgetting to #include <math.h>?
<infinity> rbasak: That's glibc 2.23 being more correct than you are.
<cjwatson> I mean, this kind of thing happens all the time when people sloppily rely on transitive header inclusion and then one of the links in the chain stops including something they actually needed directly.
<cjwatson> Oh and there's also some feature test macros required for isnan.
<rbasak> Yeah sure, I can just patch in include directives. I just wanted to check that there wasn't some more common understanding to fix it better.
<infinity> It's not indludes.
<infinity> It's namespaces.
<rbasak> http://stackoverflow.com/a/18129007/478206 suggests that it depends.
<rbasak> If they're already including <cmath> I guess I'll patch to use a qualified std::isnan.
<infinity> If my browser would wake up, I'd give you some references. :P
<cjwatson> Oh, sure, you didn't say it was C++ :)
<infinity> FWIW, https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=2.23;users=debian-glibc@lists.debian.org
<infinity> That's my list to fix before release.
<infinity> rbasak: ^-- Are your failing packages on that list?
<rbasak> libreoffice and hhvm are, yes. Maybe some others. I need to assemble a proper list.
<rbasak> I already have a separate patch to hhvm for a different MySQL issue.
<infinity> rbasak: https://sourceware.org/bugzilla/show_bug.cgi?id=19439 is the upstream discussion of why this now happens.
<ubottu> sourceware.org bug 19439 in math "Unix98 isinf and isnan functions conflict with C++11" [Normal,Resolved: fixed]
<rbasak> infinity: BTW, I did a test transition for MySQL in a PPA. It's looking fairly good, but there are a few sticky issues.
<rbasak> infinity: I'd like your opinion as to whether to go ahead. I'm not done summarising the issues yet though.
<infinity> rbasak: Comment #10 basically has the TLDR.
<rbasak> infinity: got it, thanks.
<infinity> rbasak: If you feel the urge to fix things in Ubuntu ahead of Debian, please do forward patches to the already-open Debian bugs.
<infinity> (And, to save yourself time, look there for patches first. :P)
<ginggs> infinity: hi, should i file a bug about fpc / powerpc for that glibc 2.23 list?
<infinity> ginggs: No.
<infinity> ginggs: The fpc/ppc issue is kinda special, and I'm still looking at it, but it's not technically FTBFS, per se, it's that the old binary fails to run. :P
<rbasak> infinity: well, I feel the urge to get MySQL 5.7 landed :)
<infinity> ginggs: I can rebootstrap it by hand, but I'd sort of like to figure out WTF they're doing that broke it like this.
<infinity> rbasak: Right.
<infinity> rbasak: As for opinions on the transition, I'm going to grab a coffee, if you have a summary of the issues by the time I get back, let's chat.
<rbasak> infinity: ack, thanks.
<ginggs> infinity: ok thanks
<rbasak> configure.ac:105: error: possibly undefined macro: AC_BAKEFILE
 * rbasak wonders if the author had a cold that day
<pitti> rbasak: robert_ancell actually used to work on https://launchpad.net/bake :)
<rbasak> Hmm
<rbasak> Yeah, seems like AC_BAKEFILE is actually a thing
<rbasak> infinity: ready. I've updated the description at https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1528583
<ubottu> Launchpad bug 1528583 in mysql-5.7 (Ubuntu) "[FFe] Please update to MySQL 5.7 series" [Wishlist,In progress]
<jtaylor> is there a place where release note info is collected?
<rbasak> jtaylor: http://launchpad.net/ubuntu-release-notes
<jtaylor> thx, just file a bug?
<rbasak> Yep, or add a task to an existing bug if there already is one that tracks an issue.
<infinity> Or just edit the release notes.
<xnox> jtaylor, for xenial -> just edit https://wiki.ubuntu.com/XenialXerus/ReleaseNotes there was a call to start gathering release notes a while back
<jtaylor> uh I do actually have rights to do that
<jtaylor> I'll add the vim/python2 and a point on docker image migration then
<jtaylor> hm I guess the vim default to python3 would go under new features? its not really new but the openssh entry is kind of in the same vain
<jtaylor> added some stuff, feel free to rewrite/move
<nacc> dholbach: sure, i can do that!
<jdstrand> pitti: hey, do you have a few minutes to talk about udev tags/properties in the context of snappy?
<pitti> jdstrand: what's up? (still finishing something else, but I'll respond)
<jdstrand> pitti: why don't you finish up-- it will be a discussion. shouldn't be more that 15 minutes
<pitti> jdstrand: done
<pitti> HO?
<jdstrand> pitti: yes
 * jdstrand creates link
<jdstrand> actually, give me two minutes I want to check one more thing so we don't have to in the meeting
<jdstrand> ok
<mhall119> dholbach: did Laney answer your question from this morning?
<jdstrand> pitti: pasted HO link in privmsg
<dholbach> mhall119, no
<dholbach> maybe he's on holidays?
<mhall119> could be
<dholbach> in any case sponsors won't know what to do with them
<mhall119> dholbach: in my blog I asked for CC-BY-SA for new icons, but didn't specify anything for using existing ones
<dholbach> I don't know where to put those files
<dholbach> or what exactly needs to be uploaded or adapted
<mhall119> if the icons come from upstream, I would assume they use the same license as other assets from that upstream, but I don't know if we can go on that assumption
<mhall119> hmmm, ximion would be able to answer that, but he's at the GNOME sprint this weekend I think
<dholbach> it'd be good to update the bugs accordingly
<dholbach> there's quite a few on http://reqorts.qa.ubuntu.com/reports/sponsoring/
<mhall119> dholbach: how can I help? I can ask the bug creator to specify the license for the icon file, but I'm not knowledgeable enough to tell you where it should go in the package
<dholbach> mhall119, I don't know where the image needs to be put
<dholbach> how does appstream pick this up?
<nacc> Pharaoh_Atem: what should we do about php-doc ?
<mhall119> from a couple of places I think, either an appdata.xml file or from the .desktop
<mhall119> does anybody know when Laney will be back?
<dholbach> no idea
<dobey> mhall119: calendar says monday
<dholbach> ok cool
<dobey> mhall119: or rather, it says he's at some gnome-software/appstream sprint next week
<mhall119> oh, is he there too?
<mhall119> dholbach: we can make him fix them while he's at the sprint about fixing them :)
<slangasek> rbasak: 1564856> define 'bump'?
<rbasak> slangasek: update to latest upstream version + patches, AIUI.
<rbasak> Skuggen: ^
<Skuggen> Unfortunately it looks like the latest version also has issues with this. A patch to make it work would probably be significant (though the devs on the package itself are working on finding a solution)
<Skuggen> this=MySQL 5.7
<nacc> slangasek: we might need to delete php5-{pecl-http,propro,raphf}{,-dev} to let those migrate?
<jdstrand> pitti: fyi, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1564976
<ubottu> Error: launchpad bug 1564976 not found
<nacc> slangasek: kirkland: so i was able to get a drupal8 build to succeed finally; i'm not trying to claim it's a great solution, but might be "better" than waiting on drupal7 -- opinions? I need to review the build, of course, but it was done with uscan/uupdate (with an update to the watch file) and will need to consider the upgrade path
<rbasak> Skuggen: I thought Fedora had it working? Or did that turn out to not be the case?
<nacc> rbasak: fyi (and not meant as anything other than that!), a few php7 migrations are blocked by mysql as well
<rbasak> Skuggen: after speaking to infinity, our priorities are to figure out what's happening with myodbc, mysql-proxy and mysql-workbench. All the MySQL-related stuff basically. Once we've got timelines on that, we can start the transition.
<rbasak> nacc: OK, thanks. Hopefully we'll clear this Real Soon Now.
<nacc> rbasak: :) good luck!
<nacc> down to 91 revdeps on php5!
<slangasek> rbasak: right, so myodbc, not part of the day job ;)  I'm aware that the current package is broken because of unexported symbols and have not tried to deal with it.  If someone wanted to take over Debian maintenance of myodbc that would be fine with me
<Skuggen> rbasak: The patch we had for Fedora wasn't enough, it seems. It needs more work, and would likely cause conflicts with what would be in /usr/include :|
<slangasek> nacc: actually, looks like it mostly just needed a bit of binary NEW processing (done)
<nacc> slangasek: ah ok, wasn't sure which way it iwas, thanks!
<slangasek> nacc: once the new binaries are in, proposed-migration can usually be a bit clever about noticing the old ones should go away with the old source
<nacc> slangasek: awesome
<linuxperia> Hi all. Can somebody tell me why nmcli does not return anymore when its called in the console? i have nmcli Version 1.0.4 and since yesterday when i try to stablish a connection using nmcli up uuid xyz the command never returns ...
<jdstrand> pitti: the add_match_tag() with add_match_property() issue I mentioned is not an issue. I made a mistake it is working fine (note, bug #1564976 is a different issue and I just subscribed you)
<ubottu> Error: Launchpad bug 1564976 could not be found
<sil2100> pitti: hey! You have a minute to help me figure out what happened?
<sil2100> pitti: I fixed something in the 15.04 langpack creation and did a manual run of langpack-o-mating on snakefruit
<sil2100> pitti: the logs show everything should be fine
<Pharaoh_Atem> nacc: that's currently unpackaged, right?
<sil2100> pitti: hm, actually I see l-o-m didn't change the version number...
<nacc> Pharaoh_Atem: what is?
<Pharaoh_Atem> php-doc
<Pharaoh_Atem> or are you talking about something else
<nacc> Pharaoh_Atem: no, it's there,
<nacc> 20140201-1
<nacc> which is the php5 documentation
<Pharaoh_Atem> oh, that
 * sil2100 fixes it manually
<Pharaoh_Atem> nacc: is it simple enough to regenerate with the php7 ones?
<Pharaoh_Atem> if not, just drop it
<Pharaoh_Atem> that's one of those packages that usually isn't worth the hassle
<linuxperia> Hi All. I could isolate the Problem related to nmcli freezing hanging after establishing a connection that is also Reported in this Bug Report here => https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1536077
<ubottu> Launchpad bug 1536077 in network-manager (Ubuntu) "nmcli hangs when running from tty and connecting to wifi" [Undecided,New]
<linuxperia> when i run the nmcli command with root rights aka sudo nmcli now it works
<linuxperia> but if i do it like allways it freezes / hangs
<linuxperia> not sure also but my syslog is getting heavy spammed with this error message here that i think is related to this problem too => gnome-session[1791] could not identify all Prozesses
<linuxperia> Root can show them
<linuxperia> hmmmm
<infinity> slangasek: FWIW, I'm not entirely opposed to just dropping myodbc if it's not fixable.  The one rdep is ORed.  But as the Debian maintainer, I'd leave that decision to you, I think.
<infinity> slangasek: (Or demoting it to -proposed to let the transition happen, and hoping we can fix it before release)
<kirkland> nacc: slangasek: looks like you guys got that sorted out?
<nacc> kirkland: re: drupal8? no, not yet
<nacc> kirkland: not yet discussed, i mean
<kirkland> nacc: ah so short recap?
<kirkland> nacc: drupal8 is needed for php7 compat?
<nacc> kirkland: drupal7 upstream is still not php7 compliant; we could leave it in the archive as broken until/if they get to it (it's unclear the priority the drupal7 community is applying to it, as they have released drupal8).
<nacc> kirkland: drupal8 is released upstream, but not yet in debian
<nacc> kirkland: i was able to uscan and repackage it
<nacc> kirkland: but need to verify that it is correct, and that it will dtrt
<nacc> kirkland: drupal8 is php7 compliant
<kirkland> nacc: rock!
<kirkland> nacc: so let's put out a call for testing of your drupal8/php7 packages
<kirkland> nacc: post to the ubuntu-server list?
<robru> pitti: cjwatson: Saviq: ok that fix is in production, should see train britney working again in 40 minutes or so
<cjwatson> thanks
<robru> also https://bugs.launchpad.net/bileto/+bug/1565019
<ubottu> Launchpad bug 1565019 in Bileto "fetch-indexes should default to .xz and fallback on .gz" [Undecided,New]
<nacc> kirkland: will do, thanks
<nacc> kirkland: yeah, there are a handful of packages that we are upgrading for php7 compat, i'll send out an e-mail today with those and ask for testing
 * lamont really misses his keyboardFocusPolicy=strict ...
<robru> pitti: cjwatson: Saviq: ah yeah, looking good so far https://requests.ci-train.ubuntu.com/static/britney/log_20160401_173001.txt
<dannf> pitti: http://paste.ubuntu.com/15580835/ <- is there new magic for that?
<infinity> dannf: Run it in C.UTF-8?
<Saviq> can someone please rerun http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#qtmir with the new unity8 in proposed? thanks
<slangasek> Saviq: rerunning with -proposed requires release team privs, #ubuntu-release is a better place to get attention generally - anyway, looking
<Saviq> slangasek, noted, thanks
<slangasek> Saviq: and it'll take me a little bit, I have to get openvpn to pass packets instead of eating 100% CPU first
<Saviq> slangasek, no rush :)
<slangasek> Saviq: triggered
<Saviq> tx
<slangasek> nacc: 140-ish packages to go for php5 removal?
<slangasek> hmm where did we get to on swig?
<slangasek> oh and that's a count of binary+source packages, so way high
<nacc> slangasek: yeah, my count is at 95 as of this morning, iirc
<slangasek> (as well as lagging behind the archive)
<slangasek> cool
<nacc> slangasek: swig is still no progress; i've been just trying to get our packages going as far as i can
<nacc> it's a pretty big change and i have to go and learn the internals of php a bit :)
<nacc> slangasek: 88 currently
<slangasek> swig was supposed to be removals, I thought?
<nacc> slangasek: sorry, for that big
<nacc> i think we're pretty close to done with those that needed packages removed/disabled
<slangasek> nacc: php-sabre-vobject-3 ftbfs
<nacc> slangasek: grr, sorry! you're right, i meant to move it to the other list
<slangasek> nacc: php-sabredav has php-horde-dav as a revdep (LP: #1565025).  What's the compatibility story for that?  (Please provide details on the FFe bug)
<ubottu> Launchpad bug 1565025 in php-sabredav (Ubuntu) "Please sync from Debian experimental" [Undecided,New] https://launchpad.net/bugs/1565025
<nacc> slangasek: urgh, ok, let's hold off on that, i don't think we can move just one piece of horde around
<nacc> slangasek: will investigate
<slangasek> nacc: ok, commented on the bug in the meantime, thanks
<nacc> slangasek: thanks, might be able to avoid upgrading by just fixing the tests
<nacc> verifying that now
<slangasek> nacc: and php-net-ldap2 uploaded, if you can't reproduce the autopkgtest failure I'm going to not care about it unless it reproduces on the production infra
<slangasek> let's not waste time debugging idiosyncracies of /my/ autopkgtest setup
<nacc> slangasek: sure, thanks ... i'm really not sure; i did see it before i fixed the deps
<slangasek> nacc: I saw a /different/ failure before I fixed the dep
<nacc> funny
<slangasek> one that very clearly pointed to PEAR.php not being on the include path :)
<nacc> heh, yeah, i did see that one earlier too
<slangasek> ah, php-radius, two of my favorite technologies in one small package
<nacc> heh
<slangasek> nacc: question for you in the bug on php-radius, whenever you have a chance to look
<nacc> slangasek: will do; fyi for the FFe just refrenced, i think we can get away with some testcase updates and updated deps
<nacc> testing it now
<nacc> will modify the bug
<nacc> slangasek: fyi, php-xml-serializer FTBFS in wily too; not sure why yet, it seems to be a path issue with phpunit
<nacc> it's very confusing, as some tests are clearly passing during build
<nacc> slangasek: nm, found advice from debian in some bugs
<slangasek> nacc: does the patch on bug #1565025 for php-sabre-vobject mean no further update is required for php-sabredav?  or are you still working through that part?
<ubottu> bug 1565025 in php-sabredav (Ubuntu) "Update for PHP7.0 dependencies and syntax" [Undecided,New] https://launchpad.net/bugs/1565025
<nacc> slangasek: just posted that part too
<nacc> slangasek: sorry, shoudl have mrked the state properly as i was working on it
<slangasek> nacc: no worries, it just means you wind up having to talk to me more
<nacc> slangasek: yep, sorry, i've bene pretty quiet today just trying to figure those last two out
<slangasek> nacc: php-pecl-http has unsatisfiable versioned deps on php-raphf and php-propro, because something said '2.0.0dev' and the actual versions are '2.0.0-' which is lower so the dep is not satisfied.  something (pkg-php-tools?) needs to translate 'dev' to '~dev', or else something needs to be manually fixed in a package.xml or such
<nacc> slangasek: ah i see it now -- i'll send an update right now; not sure why they did that to pakcage.xml
<nacc> and not sure why it built here ... strange
<slangasek> it builds, it's just uninstallable after
<nacc> oh i see
<nacc> yeah
<nacc> ok
<nacc> slangasek: new diff posted in LP: #1564566
<ubottu> Launchpad bug 1564566 in php-raphf (Ubuntu) "[FFe] Update to PHP7.0 upstream versions" [Undecided,Fix committed] https://launchpad.net/bugs/1564566
#ubuntu-devel 2016-04-02
<slangasek> nacc: ok.  I think this is something that ought to be filed as a bug against pkg-php-tools as well
<nacc> slangasek: yep, i'll take it as  followup
<nacc> slangasek: ok, just subscribed you to my last set for the day
<nacc> by my count, we've only got 22 more revdeps
<nacc> jgrimm: --^
<slangasek> ah, of course, a fix for operator precedence change; I remember all the work we had to do when C99 support came out that we had to do to update our operator precedence rules, it stands to reason the same thing would apply to php7
<nacc> slangasek: :)
<nacc> php was ... inconsistent before? i guess
<nacc> so they are now consistent, but means that the implicit way things work before is not true anymore
<nacc> from waht i could gather, "good" php code never shoudl have been affected... :)
<slangasek> so it's getting better?  ok, I guess I can allow them that
<nacc> :)
<nacc> slangasek: have a great weekend! looking forward to being done with php5 next week :)
<TJ-> Can anyone make sense of this potentially serious security/DoS issue after installing/enabling libapache2-mod-php5? A user reported this early hours of today in #ubuntu+1. User's 'sudo' group membership was somehow removed. Captured in http://pastebin.ubuntu.com/15585996/
<Unit193> Is anyone currently active?  Newsbeuter that was uploaded into Debian now covers the delta we have (memleak fix) plus an additional segfault fix or two.  It'd really benefit a sync at little to no cost as it's not seeded.
<Unit193> If not, well the memleak was pretty awful so that fix is good, and one segfault is only in translations so if you're American no problem. :>
<ginggs> Unit193: requestsync please
<Unit193> ginggs: Heh, was worth a shot.  Sure, will do.
<ginggs> Unit193: at least you know there's someone who might look at it now.
<Unit193> \o/
<ginggs> Unit193: I see your name on LP: 1406825
<ubottu> Launchpad bug 1406825 in xscreensaver (Ubuntu) "xscreensaver complains "This version of xscreensaver is VERY OLD!"" [Medium,Fix released] https://launchpad.net/bugs/1406825
<Unit193> ginggs: Old report, yeah.  I suppose you've seen all the noise in Debian then. :P
<ginggs> yeah :) so how did you fix it in ubuntu?
<Unit193> I don't remember if we just ended up updating it or adding the patch, but last time I merged it there was no patch.
<Unit193> So, Lubuntu users are going to hit it half way through Xenial. :/
<ginggs> ah, ok and 5.15 in trusty doesn't have the time bomb yet
<Unit193> Not sure if it was lost or what, I remember looking into it.  Also, https://build.opensuse.org/package/view_file/openSUSE:13.2:Update/xscreensaver.4176/xscreensaver-disable-upgrade-nagging-message.patch
<Bluefoxicy> Bah, no BFQ in Xenial :(
<Bluefoxicy> libenchant1c2a:amd64 depends on libhunspell-1.3-0v5 (>= 1.3.3) Xenial
<Laney> doko: I'm not that happy with skipping glib2.0's testsuite - and it wasn't a first build (if it was then it would have migrated).
<Laney> Something external obviously broke it and now we don't have visibility of that problem
<Unit193> ginggs: There we go, finally picked up: #1565370.
#ubuntu-devel 2016-04-03
<lamont> from the land of "things I don't like": sudo -s
<lamont> Segmentation fault (core dumped)
<infinity> lamont: Maybe if you didn't pass it the --segv option.  Duh.
<infinity> lamont: (Also, release, bug report, etc)
<lamont> infinity: yeah... just need to get the machine quiescent enough to actually have a sane bug report
<lamont> which means tomorrow after I wake up again
<lamont> wait how did it get to be almost midnight?
<infinity> lamont: Temporal gnomes.
<lamont> infinity: I blame you... I don't know why, but this late hour is clearly your fault.
<infinity> That's fair.
<lamont> tomorrow is "actually pay attention to postfix" day
<infinity> Is that wise?
<lamont> so 3.1.0 should be getting uploaded before I sleep.  It's sane from upstream, the scary part is tyhat *()&* debian maintainer.
<lamont> it needs my love in a big way...
<infinity> I find that paying attention to the MTA is the only thing that ever interrupts my mail.
<infinity> s/the MTA/my MTA/
<lamont> fair point
<infinity> Then again, I use exim, so muck with postfix all you want.
<lamont> HA!
<lamont> the current issue is that it generates all kinds of logspam about compat stuff, which largely amounts to me needing to migrate things to the NWO.
<infinity> I've had one of those "I planned to be super productive today, but also it's the weekend, so maybe I'll accidentally nap for 4 hours in the middle of the day and do nothing instead" Saturdays.
<lamont> heh. those are the best
<lamont> with that, I think it's time for a several-hour nap, not to be confused with the permanent nap.
<infinity> lamont: At your age, it could be either.
<lamont> :p
 * lamont is not that old, can still take infinity
<infinity> :)
<lamont> young punk! :D
<infinity> That's more a comment on my fitness, not yours.
<lamont> heh
 * lamont was speaking in the absence of knowledge on your fitness.. :p
<infinity> lamont: If you want to feel old, think of how young I was when we first met, and that I'm now very nearly 40.
<lamont> ew
<lamont> dammit now it's tomorrow
<infinity> Heh.  G'night.
<lamont> g'night.  /me sleeps
#ubuntu-devel 2017-03-27
<javier4> abeato: are you there?
<abeato> javier4, yep
<abeato> javier4, any luck with sending the resume registration message?
<javier4> abeato: still struggling with it. I'm not exactly a coder, then probably it will took a little bit more than expected. I have a question:
<javier4> I need to use a pointer to a struct ofono_netreg
<javier4> it's defined in src/network.c.
<javier4> better redefine the struct, or link the existent one?
<abeato> javier4, you do not need to have the structure defined to have a pointer to it
<abeato> javier4, just a typedef that must already exist
<abeato> javier4, just include <ofono/netreg.h>
<javier4> -.-" I included just "netreg.h", thinking it was into default include dirs.
<javier4> abeato: still getting
<javier4> https://www.irccloud.com/pastebin/0zdH66bq/
<abeato> javier4, show me youd code, I don't think you need to access data inside ofono_netreg
<javier4> https://www.irccloud.com/pastebin/tkm0FcPG/%23ifdef%20HAVE_CONFIG_H%20%23include%20%3Cconfig.h%3E%20%23endif%20%20%23define%20_GNU_SOURCE%20%23include%20%3Cstring.h%3E%20%23include%20%3Cstdlib.h%3E%20%23include%20%3Cstdio.h%3E%20%20%23include%20%3Cglib.h%3E%20%20%23include%20%3Cofono%2Flog.h%3E%20%23include%20%3Cofono%2Fmodem.h%3E%20%23include%20%3Cofono%2Fn
<javier4> etreg.h%3E%20%23include%20%3Cofono%2Fspn-table.h%3E%20%20%23include%20%22common.h%22%20%23include%20%22gril.h%22%20%20%23include%20%22grilreply.h%22%20%23include%20%22grilrequest.h%22%20%23include%20%22grilunsol.h%22%20%23include%20%3Cofono%2Fnetreg.h%3E%20static%20void%20ril_network_state_change(struct%20ril_msg%20*message%2C%20%09%09%09%09%09%09%09gpointer
<javier4> %20user_data)%20%7B%20%09struct%20ofono_netreg%20*netreg%20%3D%20user_data%3B%20%09struct%20netreg_data%20*nd%20%3D%20ofono_netreg_get_data(netreg)%3B%20%20%09g_ril_print_unsol_no_args(nd-%3Eril%2C%20message)%3B%20%20%09ril_registration_status(netreg%2C%20NULL%2C%20NULL)%3B%20%7D%20%20static%20void%20ril_strength_notify(struct%20ril_msg%20*message%2C%20gpoin
<javier4> ter%20user_data)%20%7B%20%09struct%20ofono_netreg%20*netreg%20%3D%20user_data%3B%20%09struct%20netreg_data%20*nd%20%3D%20ofono_netreg_get_data(netreg)%3B%20%09int%20strength%20%3D%20g_ril_unsol_parse_signal_strength(nd-%3Eril%2C%20message%2C%20%09%09%09%09%09%09%09%09nd-%3Etech)%3B%20%20%09ofono_netreg_strength_notify(netreg%2C%20strength)%3B%20%7D%20%20stat
<javier4> ic%20void%20ril_nitz_notify(struct%20ril_msg%20*message%2C%20gpointer%20user_data)%20%7B%20%09struct%20ofono_netreg%20*netreg%20%3D%20user_data%3B%20%09struct%20netreg_data%20*nd%20%3D%20ofono_netreg_get_data(netreg)%3B%20%09int%20year%2C%20mon%2C%20mday%2C%20hour%2C%20min%2C%20sec%2C%20dst%2C%20tzi%2C%20n_match%3B%20%09char%20tzs%2C%20tz%5B4%5D%3B%20%09gcha
<javier4> r%20*nitz%3B%20%20%09nitz%20%3D%20g_ril_unsol_parse_nitz(nd-%3Eril%2C%20message)%3B%20%09if%20(nitz%20%3D%3D%20NULL)%20%09%09goto%20error%3B%20%20%09n_match%20%3D%20sscanf(nitz%2C%20%22%25u%2F%25u%2F%25u%2C%25u%3A%25u%3A%25u%25c%25u%2C%25u%22%2C%20%26year%2C%20%26mon%2C%20%09%09%09%09%26mday%2C%20%26hour%2C%20%26min%2C%20%26sec%2C%20%26tzs%2C%20%26tzi%2C%20%
<javier4> 26dst)%3B%20%09if%20(n_match%20%21%3D%209)%20%09%09goto%20error%3B%20%20%09sprintf(tz%2C%20%22%25c%25d%22%2C%20tzs%2C%20tzi)%3B%20%20%09nd-%3Etime.utcoff%20%3D%20atoi(tz)%20*%2015%20*%2060%3B%20%09nd-%3Etime.dst%20%3D%20dst%3B%20%09nd-%3Etime.sec%20%3D%20sec%3B%20%09nd-%3Etime.min%20%3D%20min%3B%20%09nd-%3Etime.hour%20%3D%20hour%3B%20%09nd-%3Etime.mday%20%3D
<javier4> %20mday%3B%20%09nd-%3Etime.mon%20%3D%20mon%3B%20%09nd-%3Etime.year%20%3D%202000%20%2B%20year%3B%20%20%09ofono_netreg_time_notify(netreg%2C%20%26nd-%3Etime)%3B%20%20%09g_free(nitz)%3B%20%20%09return%3B%20%20error%3A%20%09ofono_error(%22%25s%3A%20unable%20to%20notify%20ofono%20about%20NITZ%20(%25s)%22%2C%20%09%09%09%09%09%09__func__%2C%20nitz%20%3F%20nitz%20%3
<javier4> A%20%22null%22)%3B%20%09g_free(nitz)%3B%20%7D%20%09%09%09%09%09%09%09%20static%20gboolean%20ril_delayed_register(gpointer%20user_data)%20%7B%20%09struct%20ofono_netreg%20*netreg%20%3D%20user_data%3B%20%09struct%20netreg_data%20*nd%20%3D%20ofono_netreg_get_data(netreg)%3B%20%09ofono_netreg_register(netreg)%3B%20%20%09%2F*%20Register%20for%20network%20state%20
<javier4> changes%20*%2F%20%09g_ril_register(nd-%3Eril%2C%20RIL_UNSOL_RESPONSE_VOICE_NETWORK_STATE_CHANGED%2C%20%09%09%09ril_network_state_change%2C%20netreg)%3B%20%20%09%2F*%20Register%20for%20network%20time%20update%20reports%20*%2F%20%09g_ril_register(nd-%3Eril%2C%20RIL_UNSOL_NITZ_TIME_RECEIVED%2C%20%09%09%09ril_nitz_notify%2C%20netreg)%3B%20%20%09%2F*%20Register%2
<javier4> 0for%20signal%20strength%20changes%20*%2F%20%09g_ril_register(nd-%3Eril%2C%20RIL_UNSOL_SIGNAL_STRENGTH%2C%20%09%09%09ril_strength_notify%2C%20netreg)%3B%20%09%09%09%20%09g_ril_register(nd-%3Eril%2C%20MTK2_RIL_UNSOL_RESPONSE_REGISTRATION_SUSPENDED%2C%20%09%09%09mtk2_reg_suspended%2C%20netreg)%3B%20%20%09%2F*%20This%20makes%20the%20timeout%20a%20single-shot%20
<javier4> *%2F%20%09return%20FALSE%3B%20%7D%20%20%20struct%20mtk2_ril_data%20%7B%20%09GRil%20*ril%3B%20%09enum%20ofono_ril_vendor%20vendor%3B%20%09int%20sim_status_retries%3B%20%09ofono_bool_t%20init_state%3B%20%09ofono_bool_t%20ofono_online%3B%20%09int%20radio_state%3B%20%09struct%20ofono_sim%20*sim%3B%20%09int%20rild_connect_retries%3B%20%09GRilMsgIdToStrFunc%20requ
<javier4> est_id_to_string%3B%20%09GRilMsgIdToStrFunc%20unsol_request_to_string%3B%20%09ril_get_driver_type_func%20get_driver_type%3B%20%09struct%20cb_data%20*set_online_cbd%3B%20%09int%20suspend_id%3B%20%7D%20%20static%20void%20mtk2_reg_suspended(struct%20ril_msg%20*message%2C%20gpointer%20user_data)%20%7B%20%09struct%20ofono_modem%20*modem%20%3D%20user_data%3B%20%09
<javier4> struct%20mtk2_ril_data%20*md%20%3D%20ofono_modem_get_data(modem)%3B%20%09struct%20parcel%20rilp%3B%20%09int%20session_id%3B%20%20%09session_id%20%3D%20g_mtk2_unsol_parse_registration_suspended(md-%3Eril%2C%20message)%3B%20%09if%20(session_id%20%3C%200)%20%7B%20%09%09ofono_error(%22%25s%3A%20parse%20error%22%2C%20__func__)%3B%20%09%09return%3B%20%09%7D%20%20%
<javier4> WTF. 0.o
<javier4> I'm sorry.
<abeato> lol
<abeato> nw
<javier4> https://pastebin.com/7E6e036N
<abeato> javier4, what you need is the definition of "struct netreg_data", not of ofono_netreg
<abeato> javier4, that struct is defined in rilmodem/network-registration.c
<abeato> javier4, you need to move that to a header, rilmodem/network-registration.h
<abeato> javier4, check rilmodem/gprs.h for an example of how that is done in other case
<abeato> javier4, basically whenever mtk/mtk2 need a struct from rilmodem, that is how it gets done
<javier4> You're right. I confused a line with the next one...
<javier4> abeato: I see that inside rilmodem/network-registration.c the struct is defined but not declare: is it implicit? I have to put the declaration inside the new header without stripping off anything from the source, right?
<abeato> javier4, correct
<rbasak> cpaelzer, pitti: any opinion on postgres being in the server packageset? It isn't currently I think.
<pitti> sounds appropriate to me
<pitti> it has "server" in the package description, and it serves bits :)
<rbasak> Yeah that's what I was thinking :-)
<rbasak> It's also mostly a leaf package - you don't install the server daemon unless you want to be a server.
<cpaelzer> rbasak: I'm fine with that as an approach to the application I brought up - we can discuss that in the DMB next week in just that scope right?
<javier4> abeato: I solved a bunch of include issues, but now I got
<javier4> drivers/mtk2modem/network-registration.c:125:2: error: unknown type name âril_get_driver_type_funcâ   ril_get_driver_type_func get_driver_type;
<javier4> then I included ril.h, and got this
<javier4> https://www.irccloud.com/pastebin/f1LKXOgh/
<rbasak> cpaelzer: sure
<camako> tjaalton, So are you good with the Mesa and vulkan patches?
<abeato> javier4, try to add same includes as in rilmodem/gprs.h first
<javier4> abeato: are you sure? That enum is defined inside src/ofono.h that's not included by that header.
<Guest59895> why tor exit node not work in IRC
<abeato> javier4, then include ofono.h ;)
<javier4> abeato: I'll try. the things that seems strange to me, is that ofono.h wasn't directly included by ril.h
<barry> jbicha: hi.  do you have any plans on fixing LP: #1671572 for zesty?  just wondering
<ubottu> Launchpad bug 1671572 in chrome-gnome-shell (Ubuntu) "chrome-gnome-shell error popup when log in to non-GNOME" [Low,Triaged] https://launchpad.net/bugs/1671572
<jbicha> barry: chrome-gnome-shell fix uploaded to zesty unapproved queue
<dobey> anyone know anything about sbuild and /run/user within it?
<nacc> powersj: re: LP: #1625043, i was mostly trying to figure out if you deployed something tomcat6+java6 on 12.04 and upgraded to 14.04 -- did the tomcat6 deployment break because tomcat6 was now built with java7 ?
<ubottu> Launchpad bug 1625043 in tomcat7 (Ubuntu) "tomcat7 package not compliant with tomcat specification" [High,Confirmed] https://launchpad.net/bugs/1625043
<powersj> nacc: if you relied on something that had an API change then yes
<nacc> powersj: right, i need you (or me) to do that due diligence and understand if that was supported better in that transition, etc
<nacc> powersj: maybe by asking jamespage to take a look at that bug briefly :)
<powersj> what do you mean by supported better
<nacc> powersj: was there packaging changes, etc., so things didn't break
<nacc> powersj: or is there precedence that LTS -> LTS tomcat upgrades require work?
<tjaalton> camako: they're fine, i'll upload them after new X
<camako> tjaalton, thanks... I'm assuming this will be the last upload for Zesty, correcT?
<nacc> jgrimm: i just realized something re: LP: #1634989 -- i think you actaully wanted 3.5.7-1ubuntu0.16.04.1 -- not that it's likely, but if there was a ubuntu16 of 3.5.7, this upload would sort after it
<ubottu> Launchpad bug 1634989 in rabbitmq-server (Ubuntu Yakkety) "Segfault on rabbitmq-server start" [Medium,In progress] https://launchpad.net/bugs/1634989
<dobey> why would anything run during a build with sbuild, be run as uid 106?
<tjaalton> camako: pretty much
<powersj> nacc: I went through the change log to check for exactly those changes, but if someone who was around could comment that would probably be good :)
<nacc> powersj: ok, jamespage is probably our best bet -- or you could see if there are older/close tomcat6 bugs tht maybe refer to something similar
<jgrimm> nacc, cool i'll look at that later today
<nacc> jgrimm: thanks, i'm happy to sponsor with tht fixed
<jgrimm> nacc, thanks!
<nacc> jgrimm: np -- sorry for the delay
<jgrimm> nacc,  no worries, was not urgent, i would have poked it it was. ;)
<nacc> powersj: regardless, i guess, do you want to mark that bug as in progress by you? or triaged or something? (rather htan confirmed)?
<nacc> cpaelzer: similar question for you for LP: #1320709 ?
<ubottu> Launchpad bug 1320709 in awstats (Ubuntu) "incorrect info in /usr/share/doc/awstats/README.Debian.gz about logrotate" [Medium,Confirmed] https://launchpad.net/bugs/1320709
<powersj> nacc: hmm I'm almost tempted to put it into incomplete, but having one last comment would be good, so how about triaged
<powersj> if you have it open :) otherwise I can go do it
<nacc> powersj: seems reasonable, i'm happy with whatever you decide, i just want consensus in the bug and an agreement (if posisble) from the submitter
<nacc> powersj: updated that bug
<powersj> nacc: thanks and thanks for the ping on that one
<barry> jbicha: great, thanks!
<powersj> nacc: can I punt LP: #1597344 to you? :)
<ubottu> Launchpad bug 1597344 in apache2 (Ubuntu) "package apache2 2.4.18-2ubuntu3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/1597344
<nacc> powersj: sure,
<nacc> powersj: any context (i'll just put it on the end of my triage list rightnow)
<powersj> a2enmod of php7 failure
<nacc> powersj: ok
<powersj> hoping you would know more about that possibly
<nacc> powersj: thanks, will take a look
<nacc> teward: thanks for picking up LP: #1673056
<ubottu> Launchpad bug 1673056 in nginx (Ubuntu) "Upgraded nginx-upload-progress module has showstopper" [High,In progress] https://launchpad.net/bugs/1673056
<cpaelzer> nacc: I kept it confirmed instead of triaged as I would have waited on the Debian feedback to decide
<cpaelzer> nacc: reporting to Debian without and response is almost identical to not reported yet
<cpaelzer> nacc: once I can consider the position of the Debian peer to us for a given case I switch states, but I'm good with you setting triaged just as much
<cpaelzer> nacc: I guess that is down to preferences
<nacc> cpaelzer: mostly dont' want to have to re-triage it
<jgrimm> nacc, bug1634989 updated per request
<nacc> jgrimm: thanks!
<jgrimm> thank you!
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<mwhudson> apw, smb: do you know why the ubuntu-fan autopkgtest is failing with the new docker in zesty-proposed?
<mwhudson> it started failing with the 1.12.6-0ubuntu3 upload but there's no way the change in that broke the fan
 * mwhudson takes it to mail
<mwhudson> halp
<mwhudson> infinity, robru: you around (or anyone else who understands britney)
<infinity> mwhudson: I'm around, but I make no claim to understanding britney.
<mwhudson> infinity: i was wondering why britney thinks the docker autopkgtests are "always failed" on http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#runc
<infinity> mwhudson: It's close enough to true. :P
<infinity> But more seriously, I'm not sure of the criteria used there.
<mwhudson> heh
<mwhudson> the test failed, but probably because it ran against the docker in release, which has a buggy test
<mwhudson> at least i hope that's why it failed
<infinity>                 if ever_passed and not self.has_force_badtest(src, ver, arch):
<infinity>                     result = 'RUNNING'
<infinity> stgraber:force-badtest docker.io/1.12.6-0ubuntu1
<infinity>                 else:
<infinity>                     result = 'RUNNING-ALWAYSFAIL'
<infinity>                 url = 'http://autopkgtest.ubuntu.com/running'
<infinity> So, there you go.  It's "always failed" because of a badtest hint.
<infinity> mwhudson: ^
<mwhudson> infinity: ah hah
<infinity> mwhudson: Any idea why the ubuntu-fan tests fails (only on amd64?) with the new docker?  Then we could promote it and that would go away.
<mwhudson> infinity: no, i just sent a nastygram to apw and smb about that
 * infinity nods.
<infinity> I guess, to be fair, it fails on lots of arches, but the amd64 failure is both different and new.
<mwhudson> infinity: i don't think it can be a docker changed, it stopped working between ubuntu2 and ubuntu3
<mwhudson> infinity: which is this diff http://launchpadlibrarian.net/310436103/docker.io_1.12.6-0ubuntu2_1.12.6-0ubuntu3.diff.gz
<mwhudson> (which, ironically, is the thing we really want in release)
<bdmurray> flexiondotorg: Do your actions in bug 1641915 mean you no longer want it sponsored?
<ubottu> bug 1641915 in Ubuntu theme "GtkToolButtons clip and overlap" [Undecided,In progress] https://launchpad.net/bugs/1641915
<mwhudson> infinity, stgraber: so is it appropriate to badtest the ubuntu-fan to let docker.io migrate?
<mwhudson> someone(tm) still needs to figure out why the test is failing but it seems letting docker migrate would strictly improve the situation
<mwhudson> (fortunately the fixed docker autopkgtest does actually pass with the new runc so i can relax a bit on that score)
<flexiondotorg> bdmurray It still needs sponsoring.
<bdmurray> flexiondotorg: I'd sponsor it if you answered my question.
<flexiondotorg> bdmurray It was added to Zesty by jbicha I believe.
#ubuntu-devel 2017-03-28
<sarnold> "It"?
<infinity> mwhudson: I'm quite sure their test likely sucks.  Though, it might suck because it relies on docker, giving them multiple layers of suck.  I'm happy to smear the blame around.
<infinity> mwhudson: But yes, I think we can ignore the fan failure as "probably not docker's fault".
<mwhudson> infinity: hooray, or words to that effect
<nacc> rbasak: can you take a look at LP: #1675924
<ubottu> Launchpad bug 1675924 in mysql-5.7 (Ubuntu) "package mysql-server-5.7 5.7.17-0ubuntu0.16.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/1675924
<mwhudson> in entirely unrelated news, why the heck is networkd not noticing a new network device when i hotplug it with the qemu monitor
<infinity> Huh.  How did 6pm happen already?
<nacc> powersj: should we start skipping certain packages that don't need triaging by our rota? e.g., lxd, cloud-init, curtin?
<nacc> powersj: maas comes to mind as well, and juju
<powersj> nacc: I completely agree; I'm trying to remember why we didn't filter them out in the past. When I do triage I tend to glance at those packages and 99% of the time move on.
<nacc> powersj: right, maybe put in a flag for --show-all, but by default, let's skip some that don't need triaging
<nacc> powersj: also, we should clarify whether triaged/incomplete bugs shoudl show up (i have taken to just subscribing myself when i mark that state change in a bug and then if they change it back i get notified)
<powersj> nacc: I do think those should continue to show up. If an update happened it is nice if I am the one triaging to help push it along more. I do see that you and cpaelzer subscribe yourselves to bugs as well though.
<nacc> powersj: right, i treat those as relatively different priorities :)
<nacc> powersj: and triaged should mean ubuntu-server was subscribed, meaning we all get those e-mails, right?
<powersj> I don't :)
<nacc> hrm
<powersj> nacc: well I get some from updated bugs, but I don't think I get everything
<nacc> powersj: i wondered about tht
<nacc> powersj: ok, there's room for improvement regardless
<nacc> powersj: also, i'm using rbasak's fork, because it has some good changes
<nacc> powersj: and the script now throws some backtraces on 17.04 :)
<nacc> non-fatal ones, but import failures
<powersj> nacc, for example today I got a ton about lvcreate, but I didn't see any emails from the triaging you or I did today.
<powersj> nacc: ha! ok time to look at his fork again. Last time he told me it was WIP
<nacc> powersj: ok, it might be, but it might be worth getting it to merged :)
<powersj> nacc: yeah I'll take a look tomorrow
<nacc> powersj: thanks
<cpaelzer> xnox: the z-p checks on lvm2 failed for docker.io, but the fail is a docker.io one which is fixed in recent versions
<cpaelzer> xnox: would you mind retriggering the test to pickl up the latter fixed docker version so that lvm2 can pass?
<KeithW> Hi, I am the DM of mosh (in Ubuntu universe). Zesty currently has a release candidate (mosh 1.3.0~rc2-1) synced from Debian sid. Debian sid now has the final release (1.3.0-1).
<KeithW> We filed https://bugs.launchpad.net/ubuntu/+source/mosh/+bug/1676218 requesting an FFe/sync of the final release. (Changes are minimal.) Is there anybody I should ping to make sure it gets looked at by the right people in the release team? Thanks for any help on this.
<ubottu> Launchpad bug 1676218 in mosh (Ubuntu) "[FFe] Sync Mosh 1.3.0 instead of release candidate" [Undecided,New]
<seb128> KeithW, if the update has no new feature compared to what is currently in the archive you don't need a ffe
<KeithW> seb128: Thanks -- how do I ask for a sync then?
<smb> infinity, mwhudson as in email reply fan tests fail because nc now does no longer fail with data errors which were by chance not causing the test to fail but now fail with timeout because netcat-openbsd upstream decided in their great wisdom that closing a connection when local input closes is now an optional thing.
<seb128> KeithW, you subscribe ubuntu-sponsors on that bug so it's in the sponsoring queue
<seb128> KeithW, you can also ask on this channel as you did, I'm going to have a look
<KeithW> Thanks!
<seb128> yw!
<seb128> KeithW, done, https://launchpad.net/ubuntu/+source/mosh/1.3.0-1
<KeithW> seb128: Thanks much!
<seb128> KeithW, np, thanks for the work/filing the sync request and watching after the ubuntu version ;-)
<xnox> cpaelzer, retriggered
<cpaelzer> thanks, lets hope it picks up the new one now
<alkisg> xnox: hi, could you please have a look at two bugs in friendly-recovery, in which I've attached patches and everything should be ready to commit and then maybe even SRU?
<alkisg>  
<alkisg> https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/1675805
<ubottu> Launchpad bug 1675805 in friendly-recovery (Ubuntu) "Friendly recovery uses invalid font" [Undecided,New]
<alkisg> https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/1675824
<ubottu> Launchpad bug 1675824 in friendly-recovery (Ubuntu) "system-summary fails due to missing file /sys/.../scaling_available_frequencies" [Undecided,New]
<alkisg> In the first one, friendly-recovery.service has 2 syntax errors, while in the second one, it tries to read a /sys/.../file that doesn't exist in 90% of the cases
<sil2100> tjaalton: hey! It seems your latest xf86-input-wacom upload caused xserver-xorg-input-wacom to be uninstallable
<sil2100>  xserver-xorg-input-wacom : Depends: xorg-input-abi-22
<tjaalton> sil2100: because there's a new xserver
<tjaalton> with -abi-24
<tjaalton> 0.34.0 is installable, or should be
<sil2100> tjaalton: ah, I see it's now fetchable through apt - I saw the new version in -proposed through launchpad but it seems apt didn't see it yet (same for all the builders)
<sil2100> tjaalton: yeah, seems to work now
<sil2100> I actually thought the new upload was broken, but it seems it was fixing the breakage, just I tried using it too early
 * Laney eyes sil2100 
<Laney> you're using zesty-proposed?
<sil2100> No, but our Bileto PPA builds do!
<sil2100> And I checked what happened in my zesty-proposed chroot
<Laney> ok, you can live :P
<sil2100> phew!
<onlinedbug> Hey, where is a good place to file a bug about packages installed by default?
<onlinedbug> Such as requesting to stop installing package X as a default because it is deprecated
<cpaelzer> onlinedbug: at the package itself in launchpad?
<onlinedbug> cpaelzer, fair enough, was making sure this is the right place
<onlinedbug> I just don't want the report to go unnoticed because it's posted in the launchpad of a basically deprecated package
<onlinedbug> anyway where are the default package determined?
<onlinedbug> I mean there gotta be a list the aggregates everything no
<onlinedbug> nvm im @ https://wiki.ubuntu.com/SeedManagement now
<onlinedbug> ty
<cjwatson> well, a lot of that happens by way of dependencies, but more or less the top-level master list is in the seeds
<cjwatson> so https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.zesty etc.
<cjwatson> the specific details in the wiki page will be somewhat out of date but the broad brush is close enough
<cpaelzer> onlinedbug: also if there is an obvious successor you can add that as additional bug task to make to be seen more
<onlinedbug> not really. I'm looking at libwmf, if you are wondering. It's installed by default on every desktop and it has many security flaws. I can't bother to list everything now, so I'm just making a request to deprecate it specifying the reasons
<onlinedbug> Nobody had touched it since 2000-09-13.
<onlinedbug> correct me if I'm wrong
<cjwatson> you're wrong
<cjwatson> I haven't checked its upstream status but it's had security patches in Debian/Ubuntu much more recently than that
<onlinedbug> cjwatson, where can I see that?
<onlinedbug> I'm just not very familiar with bazaar, it's really confusing.
<ginggs> https://launchpad.net/ubuntu/+source/libwmf/+changelog
<cjwatson> bzr isn't relevant - just look at the installed package's changelog
<ginggs> http://metadata.ftp-master.debian.org/changelogs/main/libw/libwmf/unstable_changelog
<ginggs> Ubuntu is missing the security fix from 0.2.8.4-10.6 though
<cjwatson> it's in the desktop due to a dependency from libmagickcore-6.q16-2-extra I think
<ginggs> rbalint: ^
<onlinedbug> well this complicates things then. I guess it's more reasonable to post specific bug reports/cve's then...
<cjwatson> probably, yes
<onlinedbug> it becomes a real hassle because nobody is working on the original project though
<rbalint> ginggs: yes
<cjwatson> I agree that it's pretty dead upstream at the moment (though the last date I found was 2005-07-27 rather than 2000-09-13), but it still looks like it would better to fix where necessary than remove
<cjwatson> s/would better/would be better/
<rbalint> i fixed it a once indeed
<cjwatson> if removal were eventually necessary it would have to be by carefully going through everything that depends on it and working out if it's possible to replace the functionality with something else, or otherwise how to deal with deprecating/removing functionality
<cjwatson> which is generally a very case-by-case exercise, of course
<onlinedbug> mmm so from what I understand, the package itself has a baazar source, that's been updated in 2005, and since then all changes are patches to the package?
<cjwatson> I didn't check what VCS it happened to be hosted in at the time, but the last upstream release has files dated in 2005, yes
<cjwatson> and yes it seems to have been maintained by downstream patching since then
<onlinedbug> is this normal with open source projects?
<cjwatson> it's not ideal but it happens
<onlinedbug> it just seems like a real mess to me
<cjwatson> original authors move on and sometimes it's a project that's sufficiently done that nobody cares to take over
<onlinedbug> well that's fair
<cjwatson> sometimes somebody is eventually motivated to take over
<onlinedbug> one thing that bothers me the most is that libwmf uses gd 2.0.1 beta, which is a project which had been continued and now developed as libgd2
<onlinedbug> and there are many security updates that's been added to it
<onlinedbug> which are not applied to libwmf which uses hard coded gd
<rbasak> nacc: bug 1675924: looks like the reporter deleted /etc/mysql/conf.d/, so the server is expected to fail to start, so not a bug - commented and marked Incomplete with one of my usual templates.
<ubottu> bug 1675924 in mysql-5.7 (Ubuntu) "package mysql-server-5.7 5.7.17-0ubuntu0.16.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Incomplete] https://launchpad.net/bugs/1675924
<cjwatson> mm, sounds like somebody should work out exactly what changes were made to libwmf's vendored copy and whether any still need to be upstreamed, then work out how to build it against an external library
<cjwatson> would be a great thing for a new upstream maintainer to do ;-)
<rbasak> powersj, nacc, cpaelzer: maybe worth having a brief sync on how the triaging is going, proposed script and process modifications and so on?
<rbalint> cjwatson: as i remember libwmf was not terrible, just a little buggy when i did the update
<onlinedbug> I'll try to see if I do it myself, but in the meantime I'll post a bug report in case I can't make enough time to take care of this. cjwatson and everyone else thanks for your time and clarifications :-)
<rbalint> onlinedbug: i see no important security issues for libwmf in Debian
<rbalint> onlinedbug: i can upload a patch merging the missing one if you want to open the bug about that
<tjaalton> https://wiki.ubuntu.com/Debug%20Symbol%20Packages shows that foo-security should be in ddebs.ubuntu.com, but they are not
<tjaalton> so, where are they?
<cpaelzer> rbasak: if you have any new major things to discuss I'm around
<cpaelzer> rbasak: nacc might not yet be around
<rbasak> cpaelzer: nothing new, just a catch up
<cpaelzer> rbasak: 30 mins beofre the IRC meeting maybe?
<rbasak> And maybe trying to land my changes into Josh's tree.
<rbasak> Sure
<cpaelzer> rbasak: to have a chance to be all around?
<cjwatson> tjaalton: packages from -security are copied to -updates
<tjaalton> ok
<cjwatson> (unless there's a conflict, but that's v rare)
<tjaalton> so the wiki don't need that
<tjaalton> line
<cjwatson> yeah
<cpaelzer> rbasak: btw I have a uvtool merge request for you about the per arch templates in a few minutes
<cpaelzer> rbasak: I'd only do so for the master or do you want potential changes to the ubunut/devel branch right away?
<cpaelzer> not sure if any are needed actually
<cpaelzer> no, not needed since dh_auto will take care of everything
<cpaelzer> rbasak: thanks for /usr/share/uvtool/libvirt/template.xml not being a conffile
<cpaelzer> rbasak: submitted
<cpaelzer> cjwatson: would mind sponsoring the X/Y versions of our ssh fix on bug 1668093?
<ubottu> bug 1668093 in openssh (Ubuntu Yakkety) "ssh-keygen -H corrupts already hashed entries" [High,Triaged] https://launchpad.net/bugs/1668093
<cjwatson> cpaelzer: done, sorry for the delay
<cpaelzer> cjwatson: thank you - I don't mind the delay
<cpaelzer> cjwatson: just wanted to close a potential race with e.g. sucurity updates
<cjwatson> indeed
<tinoco> Hello. Could someone please upload https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1317491 to -updates when gets a chance ? Verification was already done long time. Thank you.
<ubottu> Launchpad bug 1317491 in libvirt (Ubuntu Trusty) "virsh blockcommit hangs at 100%" [Medium,Fix committed]
<camako> tjaalton, I implemented EGL_KHR_platform_mir. Is there still time to include this or have you already started the landing process?
<tjaalton> camako: haven't uploaded yet
<tjaalton> or committed
<camako> tjaalton, do you mind if I send it your way?
<tjaalton> camako: is it closed to what will be upstreamed?
<tjaalton> closer
<tjaalton> feel free to
<camako> tjaalton, yes very close... though the enum might be changed by khronos (the spec has not been ratififed - waiting on our implementation)
<tjaalton> cool
<camako> thanks
<morphis> mardy: I saw your mail but didn't had time to look into it yet
<mardy> morphis: ok, thanks for the ack
<tjaalton> LocutusOfBorg: do you want to handle bumping the xorg abi on vbox?
<tjaalton> LocutusOfBorg: actually, since it doesn't have the video driver anymore, perhaps just drop the abi dep
<sil2100> LocutusOfBorg: hey! You tracking the systemd merge you did for zesty?
<sil2100> LocutusOfBorg: it seems the autopkgtests are failing here and there
<LocutusOfBorg> tjaalton, feel free to fix it, if you think it is useless, yeah drop it
<LocutusOfBorg> I admit I have really low knowledge on that stuff, and it gives me headaches
<LocutusOfBorg> sil2100, I don't know how to fix that, because they seems to fail but for unrelated reasons (new kernel is the culprit?)
<LocutusOfBorg> so I would prefer somebody (pitti?) having a look ;p
<tjaalton> okay
<LocutusOfBorg> just please try to create a zesty VM and install virtualbox-guest-x11 and see after the reboot if everything is good
<LocutusOfBorg> (who am I to say this stupid things to you? sorry!)
<tjaalton> i just want it to pass tests now that xserver 1.19 is on proposed
<tjaalton> blocked by not being installable
<LocutusOfBorg> SERVER_DEPENDS = $(shell cat /usr/share/xserver-xorg/videodrvdep 2>/dev/null)
<LocutusOfBorg> yep, I see
<LocutusOfBorg> if you want a no change rebuild I can deal with it
<tjaalton> right, please :)
<LocutusOfBorg> somebody from release team has to accept vbox :)
<sil2100> zul: hey!
<sil2100> zul: I wanted to take a look at a new cinder SRU in the queue but I see the previous one is still in -proposed - it looks like it's failing some autopkgtests there
<sil2100> zul: can you take a look at that?
<sil2100> zul: failure log: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/armhf/c/cinder/20170309_173517_53255@/log.gz
<sil2100> zul: is that something a re-run might fix, or is this a real problem?
<zul> sil2100: ill take a look
<barry> dannf: i've confirmed that those error messages from eieio.el happen in amd64 builds of emacs25.  they just don't crash over there.  i have a meeting in a bit but afterward i'll try to get on the porterbox and see what i can see
<nacc> rbasak: thanks!
<nacc> rbasak: cpaelzer: i'm aroundnow
<dannf> barry: cool, thx!
<nacc> barry: ah good to know!
<rbasak> nacc, cpaelzer, powersj: now or after the IRC meeting is fine with me.
<powersj> same
<cpaelzer> same
<rbasak> nacc, powersj, cpaelzer: so if everyone's happy, shall we say in 8 minutes - 1530 UTC?
<cpaelzer> ack
<powersj> wfm
<cpaelzer> the first who posts a link in #server is the HO we go to
<stgraber> infinity, kees, mdeslaur, slangasek: TB meeting in 9 minutes
<mdeslaur> ack
<nacc> jgrimm: --^ hrm, isn't that the same time as the server meeting? ~
<stgraber> nacc: we're in #ubuntu-meeting-2 so shouldn't conflict
<nacc> stgraber: ah! ok :)
<jgrimm> nacc, diff channel
<jgrimm> yeah
<jgrimm> nacc, its always been at the same time. :)
<nacc> funny
<rbasak> smb, sforshee: server team meeting?
<smb> rbasak, already again...
<nacc> should there be some kind of clarifying statement at https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#LTS_Hardware_Enablement_Stack that if you use fglrx, it won't work with 14.04.5 stack & kernel?
<nacc> tjaalton: --^
<tjaalton> nacc: it can't be used without force
<nacc> tjaalton: right, but that's not documented on that page at all
<tjaalton> upgrading will take care of it, by uninstalling fglrx..
<nacc> tjaalton: right, but if a user *wants* fglrx
<nacc> tjaalton: which they had previously
<nacc> 14.04.4 kernel/X is EOL, they need to downgrade (aiui) to 14.04.0/1
<tjaalton> yes
<nacc> and that's not docuemnted :)
<tjaalton> feel free to add something
<nacc> ok
<rbalint> onlinedbug: LP: #1676958
<ubottu> Launchpad bug 1676958 in libwmf (Ubuntu) "Please merge 0.2.8.4-10.6 from Debian" [Undecided,New] https://launchpad.net/bugs/1676958
<rbasak> slangasek, cyphermox: I wonder if bug 1676597 is related to some reported DNS issues on Xenial? Patches are attached.
<ubottu> bug 1676597 in dnsmasq (Ubuntu) "dnsmasq doesn't manage destruction/recreation of tun interface" [Undecided,New] https://launchpad.net/bugs/1676597
<nacc> rbasak: is that related to LP: #1639776 ?
<ubottu> Launchpad bug 1639776 in dnsmasq (Ubuntu Yakkety) "dnsmasq fails to send queries out after suspend disconnects the interface" [Undecided,In progress] https://launchpad.net/bugs/1639776
<rbasak> nacc: that's what I'm wondering. I haven't looked deeply; it just sounds like it's in a similar area.
<cyphermox> I suppose it's plausible
<nacc> i have the fix queued in that bug locally
<nacc> rbasak: it appears they point to the same RHEL bug and upstream fix
<rbasak> Ah
<rbasak> So a dupe?
<nacc> which is in 17.04 and was NMU'd in debian
<nacc> rbasak: i'd say so
<cyphermox> one extra patch in yours though
<nacc> they both refer to two upstream patches (as debian's fix did too)
<nacc> iirc
<cyphermox> nacc: sound like you have this under control
<rbasak> Shall I mark the dupe then?
<cyphermox> you're applying http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=16800ea072dd0cdf14d951c4bb8d2808b3dfe53d  too?
<cyphermox> rbasak: yeah, you could dupe it
<nacc> cyphermox: yeah
<rbasak> Duped.
<nacc> and was going to submit that for xenial and yakkety today (the yakkety is trivial, the xenial were some minor conflicts, but easy resolved)
<barry> dannf, nacc well, that's interesting.  i apt-get source'd the proposed version of emacs25 on the arm64 porter box, installed the build-deps, and dpkg-buildpackaged it.  no crash
<barry> in a zesty-arm64 chroot
<dannf> barry: right - the hard part is getting to fail outside of scaling stack. i managed to do it the first few times i tried in a VM, but whatever magic has since gone away
<dannf> barry: i suspect it's a matter of getting the GC working during the build. I tried a few env vars to make it hungrier, and limited the memory on my vm, but haven't been able to get a reliable reproducer
<dannf> s/a few/a few GC settings via one env var/
<barry> dannf: yeah.  it reliably fails in my ppa.  i'm trying to think if we can somehow get the build to give us a gdb backtrace when it crashes
<barry> so not real-time debugging, but maybe enough to give us a clue what's going on
<barry> dannf: one thing i did find.  when i grepped the source i saw a hack of max_specpdl_size for CEDIT, which is suspiciously related to where we see the crash.  i don't see a lisp_eval_depth error in the output though (i did find a related bug from a few years ago)
<barry> i think i might try just boosting that even higher and doing a ppa build
<dannf> barry: i posted a gdb backtrace in the bug when i was able to get it to crash
<dannf> barry: LP: #1656474
<ubottu> Launchpad bug 1656474 in emacs25 (Ubuntu) "FTBFS on arm64: make[4]: *** [../../lisp/cedet/semantic/bovine/c-by.el] Segmentation fault (core dumped)" [High,Confirmed] https://launchpad.net/bugs/1656474
<barry> dannf: oh, i missed that.  looking
<barry> interesting.  that still doesn't make anything jump out at me, but let me poke around in emacs bugs
<mwhudson> uh rmadison is hanging for me
<barry> dannf: gotta run out for a quick errand.  bbs
<rbalint> barry: have you tried compiling it with -00? maybe it is an optimization problem in GCC
<rbalint> barry: i at least would give it a shot
<barry> rbalint: i haven't yet, but i have seen references to that
<rbalint> arm64 is a young arch
<barry> i think it's a good idea.  there's some missing information in the bt (tail = <optimized out>) and it sure looks like it's trying to chase a linked list, probably heading off into la la land
<rbalint> barry: maybe a null check is optimized away
<barry>       for (tail = BUF_MARKERS (b); tail; prev = &tail->next, tail = *prev)
<barry> could be.  if that 'tail' conditional isn't breaking
<rbalint> barry: i'm sorry, have to leave now, but would be interested in the -O0 results
<barry> rbalint: no worries.  i'll follow up here if i have any results
<rbalint> barry: the list seems to be corrupted earlier
<barry> rbalint, dannf okay, i think i have a -O0 arm64 build going in my ppa.  let's see what happens
<nacc> Logan: re: LP: #1672941, you don't close the bug in the changelog. Are you ok if i fix locally while sponsoring?
<ubottu> Launchpad bug 1672941 in cyrus-sasl2 (Ubuntu) "FTBFS with older versions of OpenSSL" [High,New] https://launchpad.net/bugs/1672941
<nacc> infinity: freeze clarification -- Logan has provided a fix for a FTBFS for src:cyrus-sasl2 as in z-p. Given that it's already there, is it ok to upload the fix w/o an exception?
<nacc> i'm especially asking because some binaries are seeded, so i wanted to be extra cautious
<tinoco> Hello, could anyone from SRU team release LP: #1317491 (Trusty SRU) ? Thank you
<ubottu> Launchpad bug 1317491 in libvirt (Ubuntu Trusty) "virsh blockcommit hangs at 100%" [Medium,Fix committed] https://launchpad.net/bugs/1317491
<nacc> powersj: ping
<powersj> nacc: ack
<nacc> powersj: looking at your mongosniff MRs
<nacc> powersj: the dep3 headers are off
<nacc> powersj: you're not hte AUthor, afaict?
<nacc> powersj: and i think you should update your target to what you branched off of
<nacc> powersj: (for yakkety)
<powersj> ok first, dep3 headers. Is there a best way of making those?
<nacc> powersj: you should be able to use the raw patch from github, etc.
<nacc> powersj: directly as the patch
<nacc> powersj: and then dep3changelog *should* do the right thing :)
<powersj> oh ok, never used dep3changelog
<powersj> (not sure how to get raw patch from github either)
<powersj> nacc: so 1) get raw patch from github 2) run dep3changelog?
<nacc> powersj: https://github.com/mongodb/mongo/commit/5d05a2b0767f2f6122ee509678e0df3fa36f94a7.patch
<nacc> powersj: instead of https://github.com/mongodb/mongo/commit/5d05a2b0767f2f6122ee509678e0df3fa36f94a7
<nacc> (jsut add .patch)
<nacc> powersj: so yeah, you wget -O- that into d/p/
<nacc> powersj: update series
<nacc> dep3changelog d/p/newpatchfile
<powersj> ah ok adding .patch is easy :)
<powersj> nacc: thank you this is much easier
<powersj> nacc: put the LP# at the end of the auto-generated change log entry?
<nacc> powersj: ah ok, so you'll need to add some headers
<nacc> sorry, forgot that bit
<powersj> https://paste.ubuntu.com/24270609/
<nacc> powersj: so given the raw patch, you'll want to add some stuff after it, before the path
<nacc> e.g., Bug-Ubuntu
<nacc> and Origin
<nacc> if you do, then dep3changelog will do the LP: # for you
<nacc> i have a bug to fix so that it ignores whitespace lines, but for now, just don't put a blank line int
<nacc> powersj: note, taht i've also taken to doing the following
<nacc> 1) get patch, update series
<nacc> 2) update patch with dep3 headers
<nacc> 3) dep3changelog patch
<nacc> 4) edit changelog for series, etc.
<nacc> 5) git commit debian/patches
<nacc>  and in there (i use vi): !read git --diff -- debian/changelog
<nacc> and use the d/changelog entry as teh commit message, basically (excluding the header and footer)
<nacc> then you can commit d/changelog as 'changelog' -- what's nice about that is that `git-reconstruct-changelog` can reproduce the changelog
<infinity> nacc: Bugfixes are always welcome, especially FTBFS fixes.
<powersj> nacc: awesome, thank you for breaking it out like that
<powersj> nacc: I'll give it a shot now
<nacc> infinity: ok, just wanted to confirm, i recalled something about seeded packages being special
<nacc> powersj: np, that's something i intend to blog about / document on the wiki for the drive-by backport case
<nacc> powersj: the reason for git-reconstruct-changelog to work is that it lets merges be rebases
<nacc> Logan: also, no dep3 header for the bug, i'm realizing, i'll fix locally and sponsor
<nacc> jgrimm: ok, last nit, i swear, looking at LP: #1634989 again -- there are two changelog entries, but I think you can just drop the first?
<ubottu> Launchpad bug 1634989 in rabbitmq-server (Ubuntu Yakkety) "Segfault on rabbitmq-server start" [Medium,In progress] https://launchpad.net/bugs/1634989
<jgrimm> nacc, err?
<nacc> jgrimm: http://paste.ubuntu.com/24270716/
<jgrimm> nacc, oh you just want to drop the cherrypicked from upstream
<jgrimm> nacc, fine by me tho its pretty standard to include in changelog (though someone could also dig deeper into the actuall d/p/*.patch and read that's where it came from too
<nacc> jgrimm: is it? as it's own line?
<nacc> jgrimm: as it's own line it reads funny and i've not seen that
<nacc> jgrimm: as i was taught (by rbasak) one changelog entry per change -- and that reads as two
<jgrimm> nacc, possibly indented next line then
<nacc> jgrimm: yeah either way, i think it's clearer
<jgrimm> nacc, i can agree with that
<jgrimm> nacc, i'll update with indent and bullet then
<jgrimm> nacc, did you notice the ibm bugproxy reposting patches in that bug? i reported to michael to make them aware/fix. just fyi
<nacc> jgrimm: thanks and sorry for the nitty iterating
<nacc> jgrimm: i hadn't noticed that until just now
<nacc> jgrimm: and very strange :)
<jgrimm> nacc, heh.. well for counter point look at the 3.5.4-3.1 changelog
<jgrimm> not exactly the same scenario but a meta changelog entry first
<nacc> jgrimm: ' * Non-maintainer upload.' is a specific string required for NMU (or so it seems to me) in Deiban
<nacc> *Debian
<nacc> jgrimm: yes, i see what you mean, but in this case, the two bullets are the same change
<powersj> nacc: updated both mongodb merges
<nacc> powersj: ah and one last thing -- the version is now incorrect for (yakkety) at least
<nacc> powersj: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<jgrimm> nacc, i'm find to be best practice.
<jgrimm> fine
<nacc> powersj: so in this case, should be 1:2.6.11-1ubuntu1.1 (iirc) for y and 1:2.6.10-0ubuntu1.1 for x
<powersj> so even though incrementing 1 -> 2 would be ok version when comparing release-to-release upgrades, it is preferred to add the .1?
<barry> nacc, dannf, rbalint -O0 is looking pretty good: https://launchpad.net/~barry/+archive/ubuntu/experimental/+build/12372450
<barry> the build isn't done yet, but it's past the point of segfault
<barry> if it finishes, i will upload
<dannf> barry: cool
<barry> dannf, nacc, rbalint here's the diff http://paste.ubuntu.com/24270807/
<barry> ignore the changelog
<barry> so it'll only use -O0 on arm64.  i have no idea what that'll actually do to performance, or whether anyone will care, but if it fixes the ftbfs, we'll call it a day ;)
<barry> i do plan on reporting this to upstream, even though it might be near impossible for them to repro
<jgrimm> nacc, updated
<powersj> nacc: also updated
<jgrimm> nacc, i'm EODing but you can of course leave me feedback here or in bug
<nacc> jgrimm: thanks
<nacc> powersj: thanks
<powersj> nacc: oh thank you for the quick review :)
<nacc> jgrimm: sponsoring, fyi
<nacc> powersj: heh, dep3changelog apparently didn't understand the continuation line :)
<nacc> powersj: "Fix mongosniff for decoding messages without a."
<nacc> powersj: not super important, and/or you can just make that one line in the patch itself?
<powersj> oh I literally thought it was cut it off after a certain number of characters to make it look all nice in the change log lol
<powersj> nacc: sure I'll fix it up
<nacc> powersj: it's just a pretty straightforward perl script, so it just chomps the subject or description line as given (but only reads in the one line)
<powersj> nacc: so in order to make sure I'm doing this right, if I do want to fix the patch I have to essentially reset my commits and run through it all again, right?
<nacc> powersj: not entirely
<nacc> powersj: so you've got a branch locally, we'll call it 'fix'
<nacc> git checkout fix
<nacc> git rebase -i lpusip/ubuntu/yakkety (or whatever you started from)
<nacc> mark some commits to edit
<nacc> save/quit the editor and at the first commit to edit run:
<nacc> git reset HEAD^
<nacc> which unstages the commit
<nacc> make changes to what you want
<powersj> nacc: oh ok just like when doing the merge
<nacc> presuming all you did was edit, you shold be able to do `git commit -a -c ORIG_HEAD` and edit the commit message
<nacc> powersj: yeah
<nacc> and then you'll force push over your old branch on lp and the merge will update
<nacc> powersj: albeit in this case, given the nature of the change and the need to redo both commits (so the commit message matches the changelog) i end up usually dropping my chagnelog entry (as it should be easily reproducible after fixing the commit message) and then use `git-reconstruct-changelog HEAD^` after commiting the fixed chagne
<nacc> pitti: hallyn: when you get the chance, can you respond to my findings in LP: #1576341
<ubottu> Launchpad bug 1576341 in systemd (Ubuntu) "systemd in degraded state on startup in LXD containers" [High,Confirmed] https://launchpad.net/bugs/1576341
#ubuntu-devel 2017-03-29
<barry> dannf, nacc, rbalint emacs25_25.1+1-3ubuntu4 uploaded, awaiting approval.  i'm eod.  crossing fingers :)
<nacc> barry: nice one
<rbasak> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Zesty Final Beta Released | Archive: post-beta denouement | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: rbasak
<rbasak> http://pad.ubuntu.com/sponsorship-party
<rbasak> Sponsors who can help today: please join me there.
<Unit193> Have fun!
<seb128> hey rbasak, I'm going to try to help a bit
<rbasak> Thanks!
<seb128> yw, thanks for organizing that sponsoring day
<rbasak> cyphermox: could you help with https://code.launchpad.net/~noorez-kassam/ubuntu/trusty/initramfs-tools/fix-for-1317437/+merge/288981 please? It's a wubi/installer patch. Not sure who else might be able to help?
<rbasak> LocutusOfBorg: is bug 1608200 still relevant please?
<ubottu> bug 1608200 in openssl (Ubuntu) "please merge openssl from Debian" [Wishlist,New] https://launchpad.net/bugs/1608200
<rbasak> What's our general plan for openssl at the moment? Does anyone know?
<seb128> rbasak, https://lists.ubuntu.com/archives/ubuntu-devel/2017-February/039680.html
<seb128> rbasak, but that merge is on the 1.0 serie so still relevent I guess
<seb128> happyaron, is bug #1578193 something you could look at (it's in the sponsoring queue)?
<ubottu> bug 1578193 in network-manager-strongswan (Ubuntu) "cannot load legacy-only plugin" [Medium,Confirmed] https://launchpad.net/bugs/1578193
<seb128> Laney, do you have cycles to review bug #1641915 from fle_xiondotorg (it's a css change which doesn't look too big)?
<ubottu> bug 1641915 in Ubuntu theme "GtkToolButtons clip and overlap" [Undecided,In progress] https://launchpad.net/bugs/1641915
<Laney> Not immediately, but if the status is correct and it's Fix Released, then someone could check it's a straight backport?
<rbasak> seb128: thanks
<rbasak> xnox: could you take a look at bug 1608200 please?
<ubottu> bug 1608200 in openssl (Ubuntu) "please merge openssl from Debian" [Wishlist,New] https://launchpad.net/bugs/1608200
<rbasak> xnox: do you want it? Defer to next cycle? Or definitely don't want it? Just want to know wrt. the sponsorship queue.
<seb128> Laney, gtk versions are not the same so it's always tricky to know if a straight-backport is right, but I guess it's a "if it looks like, it's fine" and don't need somebody who understand if the css makes sense then?
 * seb128 doesn't like much SRU things he doesn't understand how they work just because they seem to work
<seb128> but if that's what is recommended with css then alright
<Laney> The gtk-3.0 directories in ubuntu-themes for zesty should be updated too
<Laney> I am not saying that blind uploading is recommended
<Laney> I'm saying that *I* don't have time *right now* to look
<seb128> right
<seb128> let's see, doesn't need to be soon in any case
<seb128> that's not an important issue
<Laney> If you want to work out how the containers work to determine whether this is right, feel free
<Laney> that's what I would have to do anyway
<Laney> and the SRU is waiting for a response to questions from bd_murray too
<LocutusOfBorg> rbasak, I can handle it by myself now, nevermind and thanks
<rbasak> LocutusOfBorg: thanks. I'll unsubscribe ~ubuntu-sponsors then? :)
<LocutusOfBorg> sure ta
<LocutusOfBorg> I'll merge from openssl1.0 into openssl
<rbasak> Thanks!
 * rbasak takes a break
<seb128> Laney, k, thanks
<seb128> rbasak, how do you recommend handling/marking items where somebody-who-is-probably-right-for-review got pinged (like happyaron on the n-m-strongswan one) but didn't reply/said he would look at it? would be nice to record that but it shouldn't block other reviewers to deal with it if they feel like they can get it done
<seb128> happyaron, bug #1666912 as well
<ubottu> bug 1666912 in network-manager-openvpn (Ubuntu Zesty) "Invoking openvpn removed option --tls-remote" [Medium,Confirmed] https://launchpad.net/bugs/1666912
<Laney> seb128: meh, I started looking after all
<seb128> Laney, thanks :-)
<Laney> easily distracted
<sil2100> Hey! Just wanted to know: is anyone looking into the systemd upload that's blocked in -proposed due to autopkgtest regressions?
<seb128> sil2100, you? ;-)
<sil2100> seb128: ;) Yeah, looking at it, but didn't want to step on someone else's toes
<seb128> sil2100, check with xnox and slangasek I guess, they are the ones most likely to be looking at that one
<LocutusOfBorg> xnox uploaded it yesterday
<sil2100> Eh
<sil2100> Another upload on top
<xnox> hm?
<Laney> seb128: ok, so it was Needs Fixing :P
<xnox> rbasak, we probably do want to update the 1.0.x series point release. we are not taking 1.1 series yet.
<xnox> (somehow did not receive highlight)
<xnox> sil2100, yeah it is stuck and there are bugs open about it. There is an unxplained hang on zesty userspace.
<sil2100> xnox: yeah, I see it's hanging on TEST-12-ISSUE-3171 from the systemd upstream tests
<sil2100> xnox: you remember if there's a bug for that handy?
<xnox> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1672542
<ubottu> Launchpad bug 1672542 in systemd (Ubuntu) "systemd 232-18ubuntu1 ADT test failure with linux 4.10.0-13.15" [Undecided,New]
<rbasak> seb128: I've been marking those as BLOCKED with an additional list at the top with more details
<rbasak> By BLOCKED I mean from a sponsorship process perspective, as opposed to not-ready-for-sponsorship. For the latter I've been unsubscribing ~ubuntu-sponsors with an explanation and a request to resubscribe when ready.
<rbasak> From a sponsorship process perspective, I agree with the idea that anyone feeling confident can take it and I encourage other sponsors to look at stuff marked BLOCKED still.
<zyga> cyphermox: I'm looking for someone that could troubleshoot a modem-manager + network-manager on 16.04 issue; DNS from mobile connection is not propagated to the system and while all the connectivity is OK name resolution always fails
<zyga> cyphermox: ara suggested that you may be the right person
<GunnarHj> rbasak: Hi Robie, it would be great if you could sponsor bug #1655782 during your piloting shift today.
<ubottu> bug 1655782 in xkeyboard-config (Ubuntu) "[FFe] Elfdalian layout + merge with Debian 2.19-1" [Medium,In progress] https://launchpad.net/bugs/1655782
<rbasak> sil2100: I'm looking at bug 1562308. You had commented and the contributor has replied. I wonder if you'd be happy to sponsor now, or would you prefer that I looked at it?
<ubottu> bug 1562308 in less (Ubuntu) "missing or duplicate lines caused by a wrapped line with wide characters" [Medium,Confirmed] https://launchpad.net/bugs/1562308
<rbasak> GunnarHj: trying to hit everything in the sponsorship queue today: https://lists.ubuntu.com/archives/ubuntu-devel/2017-March/039714.html
<rbasak> GunnarHj: that bug is in the list :)
<rbasak> http://pad.ubuntu.com/sponsorship-party
<rbasak> Sponsors who can help today: please join me there.
<rbasak> seb128: are you marking the bugs you're looking at / have looked at?
<Unit193> flexiondotorgâ® Uhh, for LP 1559249 you fixed it on Unity, that bug is specifically about != Unity, sooo problem very much still remains...
<ubottu> Launchpad bug 1559249 in nautilus-dropbox (Ubuntu) "Dropbox indicator is broken on non-Unity environments" [High,Fix released] https://launchpad.net/bugs/1559249
<Unit193> non-Unity == Xfce, LXDE, etc, etc.
<sil2100> rbasak: hey! Thanks for for the poke, let me take care of it in that case :)
<rbasak> sil2100: thank you!
<Laney> Unit193: How did this indicator work before?
<Unit193> Laneyâ® It hasn't for a while, there's been workarounds to get it to at least show a tray icon.  However,  XDG_CURRENT_DESKTOP=Unity dropbox start  brings back the indicator in Xfce too.
<Unit193> (Otherwise it shows a 'missing icon' in the tray, with a non-functional menu.)
<GunnarHj> rbasak: Ok, thanks, crossing my fingers.
<Laney> Unit193: Is that how it decides whether to show the indicator or not, or something?
<Laney> I can imagine that setting it to Unity all the time would be a problem
<Unit193> That's how it decides to show it in a functional state, at least.  Yeah.
<Laney> What if you are on gnome-shell or something?
<Unit193> No idea.  I'd be interested if you ran tint2, set that env, then started DB.
<Laney> Dunno what that is, but that's the kind of concern I have. :)
<Laney> Feel free to investigate and propose a new patch
<Unit193> (Tint2 is a common panel for openbox type desktops, no indicator support.)
<rbasak> seb128: do you have an opinion on bug 1132063 please?
<ubottu> bug 1132063 in unity-control-center (Ubuntu) "Mouse settings missing from Mouse & Touchpad dialog" [High,Triaged] https://launchpad.net/bugs/1132063
<rbasak> Not really sure what "upstream" that should probably land in first.
<Unit193> Laneyâ® Removed the indicator plugin in Xfce, forced 'Unity', started, and it opened with the tray icon.  I have no idea why it even checks that env var.
<Unit193> bluesabreâ® â
<rbasak> Laney: who looks after ubuntu-dev-tools? Looking for an opinion on https://code.launchpad.net/~nacc/ubuntu-dev-tools/update-vcs/+merge/308871 as it's in the queue.
<rbasak> Is that any core dev?
<Laney> rbasak: Yeah, but in the past it's been mainly t_umbleweed and b_drung
<Laney> If you can't get them then I think it's OK for anyone to review, assuming they do actually review. :)
<rbasak> tumbleweed or bdrung: please could you review https://code.launchpad.net/~nacc/ubuntu-dev-tools/update-vcs/+merge/308871 ? It's been languishing for a while.
<Laney> It's uploaded to Debian and then synced, so ping your friendly local DD for an upload when you want one
<rbasak> IMHO, if tumbleweed or bdrung have no opinion, perhaps nacc could send it to ubuntu-devel@ since it would change the flow a bit. And if no objection, then we should just upload.
<rbasak> tyhicks or mdeslaur: in trying to get the sponsorship queue to zero, do you have an opinion on removing bug 1639372 from the security sponsorship queue given that there's currently nothing to sponsor?
<ubottu> bug 1639372 in cairo (Ubuntu Yakkety) "CVE-2016-9082: DOS attack in converting SVG to PNG" [Medium,Confirmed] https://launchpad.net/bugs/1639372
<mdeslaur> rbasak: one sec, looking
<mdeslaur> rbasak: unsubscribed, thanks
<rbasak> Thank you!
<rbasak> http://pad.ubuntu.com/sponsorship-party
<rbasak> Sponsors who can help today: please join me there.
<seb128> Laney, thanks for the theme review!
<Laney> np!
<seb128> rbasak, sorry I was at lunch, agreed on what you said about "blocked" items that can still be reviewed and I had a look at that u-c-c issue/L_aney had a go at it in the past as well, it's a bit tricky because I don't have hardware to trigger the problem
<seb128> I can try to poke a bit upstream to see if they changed something though and if the change should be forwarded there
<seb128> oh, and yeah I'm going to edit the pag
<seb128> pad
<rbasak> OK. Thanks!
<rbasak> seb128: FWIW, for that sort of thing I think it might be fine to say "no hardware, get it upstream first". IMHO the only thing there then is to set expecations - to make it clear what the next steps should be, and to take it out of sponsorship queue explicitly.
<seb128> right
<tinoco> rbasak: could u publish LP: #1317491 for me, pls ?
<ubottu> Launchpad bug 1317491 in libvirt (Ubuntu Trusty) "virsh blockcommit hangs at 100%" [Medium,Fix committed] https://launchpad.net/bugs/1317491
<rbasak> tinoco: the pending-sru still flags bug 1483071 and bug 1511830. I suspect they're no longer relevant, but could you summarise what's going on there please?
<ubottu> bug 1483071 in libvirt (Ubuntu) "Error creating new VM with OVMF" [High,Fix released] https://launchpad.net/bugs/1483071
<ubottu> bug 1511830 in libvirt (Ubuntu Wily) "apparmor denies VM startup when image is network mounted" [High,Fix released] https://launchpad.net/bugs/1511830
<tinoco> rbasak: sure, an end user told me that one snapshot method was broken in Trusty.
<cpaelzer> rbasak: those two are dropped because nobody verified them
<cpaelzer> rbasak: dropped in like november 2016
<tinoco> rbasak: I reviewed it, described the method and why it was broken and saw that 2 commits (for the affected file) after Trusty release, this "feature" was "blocked" from "virsh".
<tinoco> rbasak: So feasible SRU was to block the feature instead of looping endlessly.
<cpaelzer> tinoco: you are describing the issue you fixed, I'm not 100% that was what he asked - was it rbasak?
<rbasak> Right cpaelzer. But I think you got it, thanks :)
<tinoco> rbasak: is this enough ?
<rbasak> I think so. Let me just check a diff of 17->20 to make sure that my understanding of what is happening is correct.
<tinoco> rbasak: tku
<rbasak> Hmm. libvirt has never been imported before? :-/
<cpaelzer> rbasak: it had a good git based dev before the importer
<cpaelzer> rbasak:  we still use that
<cpaelzer> rbasak: should be in the VCS I hope
<cpaelzer> d/control tag
<cpaelzer> rbasak: let me know if not
<rbasak> cpaelzer: understood. The importer is still useful to match against the actual archive though.
<cpaelzer> well maybe not on trusty
<cpaelzer> rbasak: oh yeah, for sure
<cpaelzer> rbasak: but due to working on the repo I never cared/checked if it was imported
<rbasak> Yeah that makes sense :)
<rbasak> http://pad.ubuntu.com/sponsorship-party
<rbasak> Sponsors who can help today: please join me there.
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Zesty Final Beta Released | Archive: post-beta denouement | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: rbasak, mterry
<cyphermox> zyga: please file a bug, that way happyaron, who is now maintaining NetworkManager, can look too
<bdmurray> xnox: What's the status on bug 1651623?
<ubottu> bug 1651623 in apport (Ubuntu Yakkety) "adt tests fail on zesty for apport" [Undecided,New] https://launchpad.net/bugs/1651623
<xnox> *sigh*
<seb128> tyhicks, hey, could you unsubscribe the security sponsors from bug #1662164 so it drops from the sponsoring queue until the submitter does the changes you requested at least?
<ubottu> bug 1662164 in ldapscripts (Ubuntu) "ldapscripts.passwd uses insecure permissions by default" [Medium,Incomplete] https://launchpad.net/bugs/1662164
<tyhicks> seb128: hi - done!
<seb128> tyhicks, thanks!
<GunnarHj> mterry: Thanks for sponsoring xkeyboard-config!
<mterry> GunnarHj: you're welcome!  Would be nice to squeeze it into zesty
<GunnarHj> mterry: Yeah, it's FFe'ed so probably it will make it.
<sil2100> seb128: hey! Just out of curiosity - are you looking getting updated zesty language-packs?
<sil2100> *looking into
<seb128> sil2100, yes, we just got a first launchpad export a few days ago, I started looked that generating the deb from it today but it's probably going to be continued tomorrow now since I got sidetracked helping on the sponsoring
<sil2100> seb128: ok, great, good to know! If you'd need any help then just give me a ping, I have limited experience (touch packs only) but yeah
<sil2100> seb128: thanks!
<seb128> sil2100, k, thanks, and yw!
<dobey> sil2100: can we get updated -touch langpacks for xenial-overlay?
<rbasak> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Zesty Final Beta Released | Archive: post-beta denouement | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: mterry
<rbasak> I'm EOD now. Thanks mterry and seb128!
<rbasak> seb128: I'd call "unsubscribed sponsors" DONE FWIW.
<seb128> rbasak, thanks to you for leading the effort!
<mterry> rbasak: :)  I'll keep working a bit, but I don't think we'll get to 0  :)
<seb128> rbasak, k, fair enough
<mterry> rbasak: and yeah thanks for spearheading it
<rbasak> mterry: no. But I think we're making a bit dent. Thanks!
<seb128> yeah, I might do a bit more tonight
<seb128> and maybe some u.s based people join still as well
<rbasak> We could do this another couple of times and we'd clear it I reckon.
<nacc> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Zesty Final Beta Released | Archive: post-beta denouement | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: nacc, mterry
<nacc> are we coordinating somewhere?
<mterry> nacc: http://pad.ubuntu.com/sponsorship-party
<nacc> mterry: thanks
<Unit193> cyphermoxâ® Re: 1673625.  The other has more logs, sure, but I'm not really talking about upgrade errors, I'm simply trying to say that the override file itself should be in nplan, it only makes sense to have it there since it's only useful there.
<cyphermox> Unit193: I understand that, but I disagree, this belongs in NM and NM is supposed to make sure that it doesn't break things (which is why there is a bug for upgrade). nplan is in standard and on all systems, whereas NM doesn't normally exist on servers. The intent here is to make sure that NM behaves the right way given that nplan is on all systems, and that it does so following whether netplan is in use or not
<cyphermox> Unit193: so; I've deduped it and commented/updated the bug to make things clearer. I'm sorry I didn't quite handle this very well; hopefully it makes more sense now.
<Unit193> cyphermoxâ® Ok, thanks.  That's some reasoning at least, and thanks very much for putting it in the bug report!  It's more clear, I just don't happen to agree.
<mterry> @sponsor out
<udevbot> Error: "sponsor" is not a valid command.
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Zesty Final Beta Released | Archive: post-beta denouement | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: nacc
<nacc> coreycb: re: LP: #1664203 -- is there actually something to sponsor there?
<ubottu> Launchpad bug 1664203 in neutron-lbaas (Ubuntu Trusty) "[SRU] v1 driver does not delete namespace when pool deleted" [High,New] https://launchpad.net/bugs/1664203
<bdrung> rbasak, I looked at https://code.launchpad.net/~nacc/ubuntu-dev-tools/update-vcs/+merge/308871 and commented it
<nacc> bdrung: thanks!
<bdrung> nacc, besides my comments, having this functionality in update-maintainers seems useful to me
<nacc> bdrung: yeah, we use it relatively commonly (but by hand) in our server team merge flow
<bdrung> nacc, you get bonus points for test cases ;)
<nacc> bdrung: being able to script it would be a win for us :)
<nacc> bdrung: good call! :)
<bdrung> tests should be relatively easy, but i do not remember if we have any yet
<bdrung> this python code is quite old and my python foo enhanced since then
<nacc> bdrung: i see a tests :)
<bdrung> and flake8 and pylint checks?
<nacc> err, test-data and ubuntutools/test/
<nacc> there is a test_pylint
<nacc> but it seems like we should run those during pkg build
<nacc> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Zesty Final Beta Released | Archive: post-beta denouement | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<rbasak> smb: is https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1648143/comments/26 correct? Wrong bug?
<ubottu> Launchpad bug 1648143 in linux (Ubuntu Xenial) "tor in lxd: apparmor="DENIED" operation="change_onexec" namespace="root//CONTAINERNAME_<var-lib-lxd>" profile="unconfined" name="system_tor"" [Undecided,Triaged]
<rbasak> bdrung: thanks!
<stgraber> yeah, looked odd to me to, I don't see the link between that security fix and this bug
<rbasak> Let's reopen for now. If it's wrong, smb can re-close it perhaps?
<sbeattie> rbasak, stgraber: yeah, they all need to be re-opened.
#ubuntu-devel 2017-03-30
<coreycb> nacc, i think everything's been sponsored for bug 1664203.  dosaboy, does trusty need a patch for that bug?
<ubottu> bug 1664203 in neutron-lbaas (Ubuntu Trusty) "[SRU] v1 driver does not delete namespace when pool deleted" [High,New] https://launchpad.net/bugs/1664203
<nacc> coreycb: thanks, was just doing the sponsorship queue cleanup, if you can verify and unsub sponsors?
<smb> rbasak, Yes thanks, all apparmor/yakkety needs re-opening (or needed). The changes accidentally included the references again due to ripples in space-time continuum (the release it is based was not in updates at the time of creation but had to be treated as if it hadwill happened in the past by the time it got released)
<rbasak> nacc: seen http://paste.ubuntu.com/24280631/ before? I wonder if it's a package version issue on Xenial.
<nacc> rbasak: no i have not see gbp fail like that before -- is it reproducible (gbp-import-orig should be runnable on its own)
<rbasak> nacc: it did it for every import around that time, so I'd say yes.
<rbasak> I will need to check though.
<nacc> rbasak: strange
<bdmurray> jamespage: in bug 1668313 you say "trusty-mitaka-proposed" and "xenial-mitaka-proposed" I don't see any "xenial-proposed" test results.
<ubottu> bug 1668313 in swift (Ubuntu Xenial) "[SRU] mitaka point release" [Undecided,Fix committed] https://launchpad.net/bugs/1668313
<jamespage> bdmurray: xenial-mitaka-proposed == xenial-proposed
<jamespage> xenial shipped with mitaka openstack
<bdmurray> jamespage: okay its not the Ubuntu Cloud Archive
<jamespage> bdmurray: nope that's trusty-mitaka-proposed
<jamespage> which is a backport of xenial packages to trusty in the UCA
<bdmurray> Having mitaka in both words seems confusing to me.
<bdmurray> jamespage: I just think it could be clearer which archive you are testing when you post test results.
<jamespage> bdmurray: ok I can clarify that
<bdmurray> jamespage: that'd be great thanks
<jamespage> bdmurray: noted on the bug above - I'll make sure that zul and coreycb know to detail that in future as well
<jamespage> bdmurray: two tasks are still not released on https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/1664306
<ubottu> Launchpad bug 1664306 in swift (Ubuntu Yakkety) "[SRU] newton stable releases" [Undecided,Fix committed]
<jamespage> nova and swift  - anything blocking those?
<bdmurray> jamespage: there's an autopkgtest failure for the old nova with the new libvirt...
<jamespage> bdmurray: lookling now
<nacc> mapreri: thanks for the extra bug and link(s). I hope to update my MR tmrw
<smoser> hey, i'd appreciate it if someone could take a look at
<smoser>  https://code.launchpad.net/~smoser/ubuntu/+source/resolvconf/+git/resolvconf/+merge/321203
<smoser> and give thoughts.
<smoser> the referenced bug has more information, but essentially dns-* entries on ENI interfaces fight/race each other in a deathmatch
<smoser> this is one way out of it. in a not-break-stuff manner
<mapreri> nacc: yw.  I was kinda wanting to switch everything to git over there, but before flipping it over (or, better, contextually), I wanted to merge (or reject) everything pending and do some bug triaging.  Considering how otherwise busy I am it will take time, so nvm :)
<nacc> mapreri: i'm happy to retool to git anytime, just let me know :)
<mapreri> nacc: if you are like me on this (knowing that several others are), you probably would actually prefer to "retool" in git right now, rather than way :P
<nacc> mapreri: yeah :)
<nacc> rbasak: do you have any advice for LP: #1322264 -- there is not a clear test case, but it's an obvious fix from upstream
<ubottu> Launchpad bug 1322264 in munin (Ubuntu Trusty) "Munin fails to generate graph, stat should be less than end" [Undecided,In progress] https://launchpad.net/bugs/1322264
<nacc> rbasak: mostly because you'd have to configure munin in order to test this
#ubuntu-devel 2017-03-31
<rbasak> nacc_: commented and marked the Trusty task Incomplete.
<jtaylor> is unity in some way connected to oxideqt? I'm looking at bug 1629188 and my sound not working since an update yesterday
<ubottu> bug 1629188 in compiz (Ubuntu) "compiz crashed with SIGSEGV in unity::input::Monitor::Impl::UpdateEventMonitor()" [Medium,Confirmed] https://launchpad.net/bugs/1629188
<jtaylor> the only related update seems to be oxideqt but it doesn't seem to be related to unity as far as I can tell
<jtaylor> hmm just some webapp plugins I don't use
<jtaylor> ok removing those breaks my login, so its probably oxide
<seb128> jtaylor, compiz/unity shouldn't have have to do with it
<jtaylor> seb128: that is my update list: http://paste.ubuntu.com/24287045/
<jtaylor> its not linux as the sound works in lightdm
<jtaylor> aptdaemon shouldn't be related
<seb128> you are sure it's due to an update?
<seb128> does sound work in a guest session?
<jtaylor> I haven't changed anything else on the system
<jtaylor> I can try that
<seb128> it doesn't mean it's due to an update
<seb128> could be a config/local/random bug that would have happened without package changes
<jtaylor> guest session works strange
<jtaylor> I guess I'll reset my configuration then
<jtaylor> hm no dice ... well about time I install zesty anyway
<jtaylor> urg zesty grub does not deal with lvmcache devices
<jtaylor> bug 1678112
<ubottu> bug 1678112 in grub-installer (Ubuntu) "grub fails on lvmcached raid1 volume" [Undecided,New] https://launchpad.net/bugs/1678112
<slashd> rbasak good friday, have you been able to look at my email I sent (re: isc-dhcp) ?
<rbasak> slashd: not yet, sorry. On my list.
<slashd> rbasak, no problem was just curious, tks
<mdeslaur> nacc_: thanks for imagemagick! :)
<smoser> stgraber, I wonder if you would take a look at https://code.launchpad.net/~smoser/ubuntu/+source/resolvconf/+git/resolvconf/+merge/321203 and give it a think.
<smoser> i'd like *someone*'s input on it.  the fix seems sane and safe to me.
<jgrimm> slangasek, would you be able to review smoser's resolvconf change or pointer to someone that would be good reviewer?
<nacc_> rbasak: thanks!
<nacc_> mdeslaur: of course, np!
<stgraber> smoser: doesn't seem unreasonable to me, slangasek and cyphermox may have opinions too and you should talk to upstream. Back when I did the resolvconf integration for Ubuntu upstream was very reactive and willing to work on such feature additions, so worth a chat with him before we start diverging from Debian
<smoser> stgraber, thanksl
<cyphermox> indeed, talk to upstream, they're likely to be happy with the change
<cyphermox> I would say come up with a use-case for this that isn't cloud-init; it this is something that makes sense to write up manually for some reason, it will make it easier to understand
<slangasek> smoser: I concur in the whole with my colleagues ;)
<smoser> so ifupdown "upstream" is just debian, right?
<smoser> slangasek, ? i'll file a debian bug?
<cjwatson> yes
<mdeslaur> doko: any plans on merging bash again?
<nacc> infinity: i feel like an idiot, but i'm not sure how to figure out why older binary packages from src:imagemagick are still in rmadison? http://paste.ubuntu.com/24289042/
<infinity> nacc: If I had to guess, I'd say that's because powerpc isn't actually removed yet, and the publisher domination code won't allow removal of arch-indep packages from a source that still has arch-dep packages published.  The part where you can't see powerpc from the outside world makes this monumentally more confusing.
<infinity> wgrant: ^--- Yo, time's running out.  Also, the "hang on to arch:all cruft" codepath in domination means we're hanging on to cruft due to powerpc's aging binaries, which may or may not have weird outcomes.
<nacc> infinity: oh sure, that makes sense
<nacc> infinity: yeah, i was looking through all the revdeps and nothing was holding them by version
<nacc> rbasak: fyi, i just pushed a fix to how we invoke gbp-import-orig; it might have fixed the import issue you were seeing
<nacc> rbasak: sigh, not quite -- debugging some more
<nacc> rbasak: so i think i unerstand the problem, but not sure how to fix it -- let's say you ran the importer once (or did pull-lp-source at some point) and have some symlinks for orig tarballs somewhere. gbp import-orig doesn't handle that great :)
<wgrant> infinity: Ah, I'd forgotten about the arch-indep caveat. Will fix on Monday.
#ubuntu-devel 2017-04-01
<baojg> how to debug gnome? i met the gsettings-data-convert crash
<Pishuilu> @cyphermox Hi,cyphermox. I have a question about ubiquity-slideshow-ubuntu package. Update translations from Launchpad for ubiquity-slideshow-ubuntu package. But Ubuntu Kylin slideshow translations was modified to the previous version. I want to ask this is my way of change is wrong, or other problems?
<udevbot> Error: "cyphermox" is not a valid command.
<Pishuilu> cyphermox, I have a question about ubiquity-slideshow-ubuntu package. Update translations from Launchpad for ubiquity-slideshow-ubuntu package. But Ubuntu Kylin slideshow translations was modified to the previous version. I want to ask this is my way of change is wrong, or other problems?
#ubuntu-devel 2017-04-02
<rolli__> hi all I trying to install somethig with umake
<rolli__> I  want to install for all user and not for specific user, how can I do it?
<rolli__> https://github.com/ubuntu/ubuntu-make/issues/79
<rolli__> Thanks for your help :-)
#ubuntu-devel 2018-03-26
<Unit193> Debian 894065, since there's a lot of talk about that in Ubuntu.
<ubottu> Debian bug 894065 in tar "tar: zstd support" [Wishlist,Open] http://bugs.debian.org/894065
<doko> tdaitx, slangasek: do you use a specific tag for java9 related autopkg test regressions?
<rbasak> sil2100: thanks for replying to the dep8 SRU thread. My main concern is that of users having to download no-op (for them) updates and rebuild regression risk though - I don't think you considered those consequences?
<doko> jamespage: please could you subscribe openstack to python-msgpack (source renamed from msgpack-python, which openstack is subscribed to)
<jamespage> doko: done
<doko> jamespage: promoted/demoted
<jamespage> doko: ta
<sil2100> rbasak: no, I didn't and I agree this is a valid concern, but still I do not consider that as a big enough risk, we have the aging period of 7 days to make sure the update doesn't introduce visible regressions - and batching it up with other changes would just move this risk in time
<jamespage> ahasenack: hey - you PPA network-manager fix for the IPv6/VPN issue works nicely for me
<jamespage> thanks!
<seb128> bdmurray, hey, I guess you saw that your apport update is blocked on failing ubuntu-drivers-common autopkgtests
<rbasak> sil2100: OK. I hadn't thought about it before, but if we're relying on regular SRU verification and the aging period, then I suppose that dep8-only SRUs would require a bug, even though for a regular SRU I'm happy with no bug reference for dep8 fixes.
<sil2100> rbasak: yeah, I think I would bump back an autopkgtest-only SRU if it didn't have a bug, I also know I like having an SRU bug for such changes even when it's bundled in a bigger upload
<sil2100> True, I probably wouldn't reject a bigger upload if it didn't have a bug for the test-fixes, but I know I like such things documented as well
<Faux> Is there a (public) log of why Bionic stuff is stuck in proposed, ooi? e.g. https://launchpad.net/ubuntu/bionic/+source/ansible 2.4 has been since 1st Feb; long before the freeze.
<seb128> doko, could you have a look to the meson build issue? upstream thinks it's a problem with gdc so likely one of your gcc-8 updates that created the issue
<seb128> doko, https://launchpadlibrarian.net/361909061/buildlog_ubuntu-bionic-amd64.meson_0.45.1-1_BUILDING.txt.gz
<Unit193> Faux: http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#ansible
<Faux> Unit193: Woo, cheers.
<Unit193> Sure thing!
<rbasak> sil2100: I'm surprised that you prefer dep8 fixes to have SRU tracking bugs. I have generally been telling people that they're unnecessary because they're self documenting and don't need SRU verification. Interesting that I prefer no dep8-only SRU but no dep8-specific tracking bugs, and you the opposite :)
<doko> seb128: on my list. discussing with upstream about turning on the shared libs by default
<seb128> doko, thx
<ahasenack> jbicha: hi, wrt this: <jamespage> 08:49:06> ahasenack: hey - you PPA network-manager fix for the IPv6/VPN issue works nicely for me
<ahasenack> jbicha: were you going to upload a new n-m?
<ahasenack> or shall I propose that fix in the meantime at least?
<jbicha> ahasenack: it's on my to-do list :)
<ahasenack> would you be upset if I proposed that ppa fix?
<jbicha> I won't be upset, it might be superseded by the new NM version thoughâ¦
<dupondje> ahasenack: just do a mr for nm :)
<jbicha> ahasenack: do you want me to push the NM update to a PPA first, or straight to bionic?
<ahasenack> jbicha: I don't have a preference, whatever you normally do is fine
<jbicha> ok, straight to bionic it is :)
<ahasenack> cool
<ahasenack> thanks
<dupondje> Great! thx jbicha  :)
<tdaitx> doko, slangasek: didn't need a tag until now, but I believe it is a good idea, do you have suggestions for a tag?
<mdeslaur> slangasek: I just uploaded another unixodbc package, let me know if you notice anything blowing up before I do. Thanks!
<jbicha> doko: ha, you made the same typo I did (earlier in glib): dh-python/amd64 unsatisfiable Depends: python3-distuils
<bashfulrobot> I may have missed this, is python3 going to be the default in 18.04?
<bashfulrobot> (sorry - do not have bionic in front me me to check)
<coreycb> bdmurray: hi, do you think we would be able to fast-track the xenial/artful fixes for bug 1758411 to -updates?
<ubottu> bug 1758411 in neutron (Ubuntu Artful) "[SRU] Revert fix for bug 1752838 regression" [Critical,Fix committed] https://launchpad.net/bugs/1758411
<jbicha> bashfulrobot: what do you mean "default" ?
<bashfulrobot> replacing python2
<bashfulrobot> @jbicha ^^
<udevbot> Error: "jbicha" is not a valid command.
<bashfulrobot> jbicha ^^
<cjwatson> It won't be /usr/bin/python
<cjwatson> It will be the only python flavour present out of the box in at least some configurations
<cjwatson> So, "maybe" :)
<bashfulrobot> cjwatson: What types of config will differ to dictate if it will or will not? :-)
<cjwatson> bashfulrobot: Whether any package that the image in question ships requires Python 2
<cjwatson> Pretty simple
<bashfulrobot> ahh ok. That makes sense.
<bashfulrobot> I was just tryign to get a feel as to what the experience will be going forward with the 2.x series on it's way out (sort of)
<bashfulrobot> Thanks for the help everyone!
<jbicha> doko: ping! are you going to fix dh-python in bionic or should I just do it?
<sil2100> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, jbicha, micahg, rbasak, sil2100: DMB ping.
<jbicha> doko: (I uploaded dh-python)
<Odd_Bloke> slashd: Congrats!
<tsimonq2> slashd: Congratulations!
<mwhudson> sladen: welcome to the funhouse!
<tsimonq2> >:D
<Unit193> With horror mirrors and smoke all around?
<tsimonq2> It's a must!
#ubuntu-devel 2018-03-27
<fundies> can anyone tell me how I get backportpage check universe?
<fundies> backportpackage*
<seb128> doko, it would be nice if you documented a bit more why you do hacks/workaround, like why you disabled gdc in meson, is that pending a gcc fix or...?
<doko> seb128: why are you interested in the dropped test dependencies?
<seb128> doko, because I'm likely going to merge/sync that package on Debian next time and now I've no clue if that delta is meant to stay, if it's Ubuntu specific and why it's there
<seb128> should the same change be applied in Debian?
<doko> I file separate bug reports for debian. that package is a hell ...
<seb128> thx
<acheronuk> didrocks: do you have a sec to answer a ubiquity question?
<didrocks> acheronuk: sure
<acheronuk> didrocks: I was following what jbicha did to do his changes, and on running debconf-updatepo is makes changes to debian/po and debian/real-po. Jeremey only committed the debian/real-po changes. is that correct?
<didrocks> acheronuk: yes! Did you have to change strings though? If you reused the strings than the ones we have in debian/templates*, it should be a no-op
<acheronuk> didrocks: yes, I did make some new strings to better explain the software selection for KDE
<didrocks> acheronuk: ok, so, just ensure you added tem correctly to debian/templates* (not extracted from .ui file it seems), then, run debconf-updatepo as you did, and only commit debian/real-po
<acheronuk> didrocks: that is precisely what I have done :)
<didrocks> excellent \o/ :)
<acheronuk> didrocks: I'll double check it all for a bit, then commit to a branch to merge later. I assume I use Jeremy's branch with my changes on top, as the changes make no sense without his work
<cjwatson> fundies: backportpackage doesn't care whether something is in universe or not; you don't need to do anything to get it to check universe
<cjwatson> fundies: (I suspect there may be a category error in your question, so if you still have problems please give more details ...)
<acheronuk> didrocks: oh. po is a symlink to real-po! duh....
 * acheronuk feels sheepish
<cjwatson> Right, that was a hack so that LP Translations would import things
<cjwatson> I forget the exact details
<fundies> cjwatson, I gave up but basically libgrpc-dev isn't in trusty I try to back port in a trusty vm using backportpackage and it couldnt find it in xenial
<fundies> under the lists of repos it looked where security and few others but uinverse wasn't listed
<fundies> and the package is in universe
<fundies> were*
<cjwatson> fundies: backportpackage works by source package, not by binary package
<cjwatson> fundies: so the name you should give to backportpackage is grpc
<fundies> grpc is just a meta package isnt it?
<fundies> i tried libgrpc0 as well
<cjwatson> grpc is not a metapackage, but even if it were that would be irrelevant.
<cjwatson> It's the name of the source package that builds libgrpc0 and libgrpc-dev.
<fundies> well i ran backportpackage on it and it worked but it didnt add the children to my ppa
<cjwatson> "children"?
<fundies> ie libgrpc0 and libgrpc-dev
<cjwatson> Binary packages have to be built before they're published ...
<fundies> I thought backport package would rebuild them
<fundies> guess the  tool does less than I thought
<cjwatson> If you've told backportpackage to upload to a PPA, then Launchpad does the building
<cjwatson> What PPA is this?  I can look
<fundies> https://launchpad.net/~cheeseboy16/+archive/ubuntu/ppa
<cjwatson> fundies: You haven't registered a GPG key with Launchpad, so Launchpad threw away your upload
<cjwatson> fundies: You need to do https://help.launchpad.net/YourAccount/ImportingYourPGPKey first
<cjwatson> fundies: And then do the backportpackage thing again
<fundies> cjwatson, is ok I've went another route
<fundies> #ubuntu people told me I couldnt get help with backportpackage at all
<cjwatson> #ubuntu people are often wrong
<cjwatson> There are certainly ways in which backportpackage might fail when you'd be on your own, just not this one :-)
<fundies> I tried to tell them they were and they tried to report me to ops
<cjwatson> Well, there are ways of saying things
<fundies> I don't think I was too harsh
<fundies> I deleted my ubuntu image
<cjwatson> I think the conversation just got kinda confused
<fundies> they where trying to help me despite knowing as litte (probably less) as I did
<cjwatson> It may yet be that grpc won't backport cleanly to trusty for one reason or another; they're certainly correct that you're on your own if that is the case
<cjwatson> It is true that there is absolutely no guarantee whatsoever that a source package from a later release will be backportable to an earlier one.  It's often true, but by no means always
<fundies> cjwatson, my question was purely why calling backportpackage wasn't finding the -dev
<cjwatson> However, in this case the problem was just in even getting started
<cjwatson> Right, and that's because of a category error, libgrpc-dev is a binary package name and backportpackage takes source package names
<fundies> they said something like ubuntu doesnt support backporting that werent in trusy packages
<fundies> and when I tried to tell them that can't be the case they got mad
<cjwatson> Which is true
<cjwatson> Lots of things happen to work a lot of the time that aren't supported as such
<fundies> I just built my own deb real quick
<fundies> and tossed vm
<Unit193> Things switching to dh 11 even make backporting to xenial and artful more than no-change backports, unless one first backports dh 11. :P
<Unit193> ...Then pkgbinarymangler too needs a rebuild, for PPAs.
<fundies> dh?
<cjwatson> debhelper
<fundies> it's pretty annoying travis-ci only offers acient ubuntu and I gotta deal with this all the time
<fundies> but its free so I can't complain too much
<doko> cyphermox: is it known that network-manager (the UI) calls home to some gnome.org domain (forgot the name of the subdomain) when a wifi network requests a user id and password?
<doko> a la captive.apple.com
<seb128> tsimonq2, LocutusOfBorg, is any of you looking at the gsequencer & why3 autopkgtest issues blocking the recent gtk+2.0 update?
<LocutusOfBorg> seb128, they are both regressed in release, but I can have a look shortly
<seb128> LocutusOfBorg, well if they are then maybe the right thing is to ask for those to be ignored?
<seb128> LocutusOfBorg, thx
<LocutusOfBorg> yes, I want to ask for glib/gtk2 and gtk3, as soon as retries against release are finished and I looked at them
<seb128> LocutusOfBorg, great, thx
<seb128> doko, I guess you saw that your meson update failed to build on "Unknown compiler "javac"" errors?
<doko> seb128: yes, uncovered by removing the gdc dependency
<doko> I don't see how it would fail. the meson tests are independent of the java version
<doko> all these test dependencies look so wrong ...
<fundies> cjwatson, you still about?
<cjwatson> fundies: What's up?
<fundies> I decided to try again
<fundies> I'm getting Unable to identify 'Greg Williamson':<cheeseboy16@.com> in launchpad
<bshah> Hi there, current base-files in bionic seems to produce the empty package when rebuilt.. sitter mentioned to me that this issue seems to be fixed in debian version 10.1 : http://metadata.ftp-master.debian.org/changelogs/main/b/base-files/base-files_10.1_changelog
<fundies> oh my email got cutoff
<fundies> idk how
<fundies> got it now I think
<cjwatson> right, @.com certainly isn't going to work :)
<fundies> cjwatson, funny it can send an email to my correct email telling it I set the email incorrect
<fundies> cjwatson, https://launchpadlibrarian.net/362282244/buildlog_ubuntu-trusty-amd64.grpc_1.3.2-1ubuntu2~ubuntu14.04.1~ppa1_BUILDING.txt.gz
<fundies> anything I can do about that?
<cjwatson> It can email you because it can identify your account from the GPG key
<cjwatson> I have no idea, now you're in the "you're on your own" territory
<TJ-> Terra-incognita ?
<cjwatson> You will apparently have to modify the package in some way to get it to build on trusty, but I don't know the details here.  If you're lucky it's as simple as playing with compiler/linker flags in debian/rules
<fundies> I'm able to build the source on trusty
<fundies> locally
<cjwatson> Perhaps you're not using the xenial packaging though
<fundies> I wasnt
<fundies> I used straight from grpc
<cjwatson> So work out the differences between your successful build and the failed build
<fundies> how do I see ubuntu's rules?
<cjwatson> debian/rules in the source package
<cjwatson> that's the entry point
<cjwatson> If you still have the .dsc that backportpackage constructed, you can use dpkg-source -x on that to unpack the source package
<cjwatson> If you don't, you can download it from your PPA - go to the web UI for the PPA, "View package details", expand the source in question, copy the URL to the .dsc file, and use dget on that URL to fetch and extract it (dget is in the devscripts package)
<fundies> make shared_c
<fundies> thats not a real cmd
<fundies> real target I mean
<fundies> what kinda trickery is it doing...
<cjwatson> No mention of shared_c in your build log
<cjwatson> There's "make shared prefix=/usr"; that's simply part of the upstream build system as far as I can see
<cjwatson> Though "shared_c" certainly is a real target, right there in Makefile
<fundies> oh the xz doesnt give me the src
<fundies> sigh
<cjwatson> I told you how to unpack it
<cjwatson> dpkg-source -x on the .dsc file
<fundies> sorry i missed that
<cjwatson> (dget wraps the download of multiple times and the unpack in a single step)
<cjwatson> *multiple files
<cjwatson> fundies: A first thing to try IMO, and this is just an educated guess, would be to comment out "export DEB_BUILD_MAINT_OPTIONS = hardening=+all" from debian/rules; I suspect that the details of the hardening rules aren't quite right for trusty and this package together, or something
<cjwatson> I could be wrong
<fundies> how do I tell it to build this locally the same way the ppa server tried to?
<cjwatson> https://wiki.ubuntu.com/SimpleSbuild
<fundies> ubuntu doesn't make any of this easy...
<cjwatson> or, if you already have an environment with all the necessary build-dependencies installed, then you can run "dpkg-buildpackage -b -uc -us" - that's a much less good emulation of what Launchpad does to build the package, and it's less "safe", but it involves much less setup
<cjwatson> (we have git-based work in progress to make this kind of thing a lot easier, but it's not quite there yet)
<fundies> bleh ran outta space
<fundies> guess I have to install a vm
<fundies> cjwatson, I'm going to come back to this but while youre here. say I fix rules file how would I submit it?
<cjwatson> fundies: since you already have a PPA, the best thing would be to go through https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage
<cjwatson> (and the next steps it links to)
<fundies> ok thanks for the help. I'm off to bed. I'll tinker more when I get up
<cjwatson> np
<Laney> slangasek: does https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1750465 need fixing in xenial too?
<ubottu> Launchpad bug 1750465 in ubuntu-mate-artwork (Ubuntu Artful) "upgrade attempting to process triggers out of order (package plymouth-theme-ubuntu-text 0.9.2-3ubuntu17 failed to install/upgrade: dependency problems - leaving triggers unprocessed)" [Undecided,Confirmed]
<Laney> (because I see a similar failure at least when trying a desktop do-release-upgrade in a chroot)
<slangasek> Laney: LP: #1750465> ah, because of upgrades from xenial to bionic? hmm, it's possible but it doesn't seem to have been reported on that upgrade path yet so xenial's package manager may not be affected
<ubottu> Launchpad bug 1750465 in ubuntu-mate-artwork (Ubuntu Artful) "upgrade attempting to process triggers out of order (package plymouth-theme-ubuntu-text 0.9.2-3ubuntu17 failed to install/upgrade: dependency problems - leaving triggers unprocessed)" [Undecided,Confirmed] https://launchpad.net/bugs/1750465
<Laney> slangasek: ah, I've closed the chroot already I'm afraid, but https://paste.ubuntu.com/p/dTsCdqPMpY/
<alkisg> Hi, I just hit https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889869, is a pull planned or should I file a bug report in ubuntu with sru etc?
<ubottu> Debian bug 889869 in bash "bash: crash in qemu-user: bash: xmalloc: ... cannot allocate XX bytes (0 bytes allocated)" [Important,Fixed]
<alkisg> I.e. bash in 18.04 doesn't run in qemu-user chroots/containers
<slangasek> Laney: ok then yes, I guess we ought to fix it in xenial, thanks :)
<alkisg> *ffe, not sru...
<nacc> alkisg: bugfixes don't need ffe
<nacc> alkisg: as it's not a feature :)
<alkisg> nacc: how can I see the bionic-proposed list, i.e. if it's already in some pull queue?
<nacc> alkisg: as to whether the bugfix is going to get cherry-picked, cpaelzer is out this week
<nacc> alkisg: rmadison?
<nacc> alkisg: or http://pad.lv/u/qemu and see the publishing info
<nacc> alkisg: nothing in bionic-proposed currently
<nacc> smb: --^ would you happen to know with cpaelzer out?
<alkisg> nacc: the bug is in bash, not qemu... looking there...
<smb> nacc, I would not know of anything pending but yeah, I'd say if there was something it would show up in rmadison
<nacc> alkisg: oh sorry, wrong person then, but same idea :)
<jbicha> alkisg: it's LP: #1751011 and the Debian bash maintainer claims that qemu needs to be fixed for bionic not bash :(
<ubottu> Launchpad bug 1751011 in bash (Ubuntu) "bash crashes in qemu-user environments (bionic)" [High,Triaged] https://launchpad.net/bugs/1751011
<nacc> heh
<nacc> round and round we go!
<jbicha> I did add the bug to https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes and hopefully it will be fixed by someone before 18.04
<alkisg> Thanks a lot guys, subscribing there...
<doko> coreycb: 0.1.17-0ubuntu1.1 ???
<doko> in bionic?
<coreycb> doko: sorry is that bad?
<coreycb> doko: we do generally do that for n-1 releases
<coreycb> doko: i can update it if you want
<doko> coreycb: we usually don't do that for the development release
<doko> no need to update
<coreycb>  doko: ok, noted
<slangasek> kees, mdeslaur, infinity, stgraber: TB in 10, kees as chair?
<mdeslaur> ack
<slangasek> also, either the agenda page or the calendar is a lie
<slangasek> woop no
<slangasek> my use of 'date' is a lie
<fundies> hi
<fundies> can someone help me with building a deb?
<nacc> fundies: where are you stuck?
<fundies> nacc, so the xenial / bionic package is 11million versions behind. so I grabbed the source release from github. I don't get how do I put the newer source into the other debs build config
<nacc> fundies: what are you trying to package?
<fundies> nacc, still grpc
<nacc> fundies: i lack context ... sorry
<nacc> fundies: did you try uupdate and uscan?
<fundies> nacc, we talked yesterday :P
<nacc> fundies: i remember you trying to use backportpackage, that was it
<nacc> fundies: let's just say you weren't the only person i talked to in the last 24 hours?
<fundies> nacc, I don't know what those commands are
<nacc> fundies: uscan will look at debian/watch and see if there is a new upstream release to update to and download the orig tarball for it
<nacc> fundies: uupdate will take that orig tarball and create a new source package directory based off of it, using the current source package as a template
<fundies> I run this in the grc-version folder i have from deb-source -x?
<nacc> fundies: yes
<fundies> no outout
<fundies> output*
<fundies> ubuntu has grpc 0.11.1 but there is version 1.10 on github
<nacc> fundies: uh, bioinic has 1.3.2 ?
<nacc> *bionic
<fundies> 1.10 is latest :/
<fundies> no bionic is 7 versions behind
<nacc> fundies: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875747
<ubottu> Debian bug 875747 in libgrpc-dev "libgrpc-dev: Please package latest upstream version" [Wishlist,Open]
<nacc> fundies: well, it's in universe, meaning community maintained, and the debian version is at the same upstream level
<nacc> fundies: oh i see, the source package doesn't have a debian/watch file :(
<fundies> well guess I'll try 1.32 for now
<fundies> bleh I need protobuf 3 and backportpackage can't build that either...
<fundies> i really hate ubuntu
<sarnold> feel free to build your deps from source withotu packages if you wish
<nacc> fundies: well, it seems like what you should hate is not ubuntu but something else, but hwatever
<fundies> sarnold, that's too slow.
<fundies> nacc, it's ubuntus tools that are failing me
<nacc> fundies: what tools?
<fundies> backportpackage
<nacc> fundies: what failed with it?
<nacc> fundies: it's not magic, it doesn't figure out what dependencies are also needed to be backported
<fundies> nacc, it's not even a dependency error
<nacc> fundies: then you need to be more verbose than "backportpackage"
<jbicha> fundies: is there a reason you can't use Ubuntu 17.10 if you need new software?
<fundies> jbicha, this is for travis-ci
<fundies> I wish they'd use newer ubuntu or arolling ditro
<fundies> distro*
<sarnold> jbicha: I think the complaint is in part that even 18.04 is too far behind upstream for at least one package
<fundies> thats one complaint
<fundies> i have many :P
<sarnold> hehe
<jbicha> fundies: travis uses ancient Ubuntu :(
<fundies> yep
<jbicha> it took a few months after 12.04 LTS was end of life for them to switch to 14.04 LTS
<fundies> I wish they would offer arch as an option
<fundies> ubuntu is fine for lts but you need to test bleeding edge too
<jbicha> could you switch from github to gitlab and have your own ci runners?
<fundies> too poor
<fundies> plus I'd rather not admin a server
<fundies> if I add a dependency to my ppa and retrigger an older build on it will it use that dependency automatically?
<tsimonq2> If I need to upload a fix for package foo that has a version of e.g. 1.1.1-1fakesync1 then would 1.1.1-1ubuntu1 be appropriate (like in the case of build1) or would 1.1.1-1fakesync1ubuntu1 be appropriate?
<nacc> fundies: i believe so, yes
<nacc> tsimonq2: i'd expect ubuntu1 would be fine for versioning purposes, but you'd want to check if it's been copied forward, etc.
<nacc> tsimonq2: although i'd also expect to see it be fakesync1ubuntu0.1  if you went that way
<tsimonq2> nacc: This is in devel.
<nacc> tsimonq2: oh ok
<tsimonq2> nacc: So I'll go with ubuntu1 then. Thanks.
<nacc> tsimonq2: i'd probably wait for at least one other coredev (or so) to respond, but i can't see an obvious issue with it
<tsimonq2> nacc: ack
<fundies> Dependency wait on lcy01-amd64-020
<fundies> what?
<tsimonq2> fundies: Got a link?
<fundies> https://launchpad.net/~cheeseboy16/+archive/ubuntu/ppa/+build/14503891
<tsimonq2> Oh, "on lcy01-amd64-020" is irrelevant here.
<tsimonq2> Look further, you're missing a dependency on debhelper.
<tsimonq2> (Er, you get what I mean.)
<tsimonq2> Enabling Backports will probably help, although do that at your own risk.
<tsimonq2> Otherwise, the packaging needs to use the debhelper which corresponds to that release.
<tsimonq2> So, debhelper 9.
<cjwatson> trusty doesn't have a debhelper 10 backport, so backports will make no useful difference in this case.
<tsimonq2> Oh.
<tsimonq2> Right.
<fundies> sigh
<cjwatson> I'd look for the change in Debian that bumped to debhelper 10 and undo it.
<cjwatson> Failing that, just whack it back to 9 and see what the next thing is that goes wrong :)
<fundies> im running low on patience
<cjwatson> https://tracker.debian.org/media/packages/g/gflags/changelog-2.2.1-1 doesn't document any particular *reason* for the change, so just change 10 to 9 in debian/compat and (>= 10) to (>= 9) in debian/control
<jbicha> fundies: why don't you try using docker to use Ubuntu 17.10? https://docs.travis-ci.com/user/docker/
<fundies> jbicha, I run like 20 tests
<jbicha> fundies: or to use Arch or whatever
<fundies> wuld take forever
<jbicha> would it really? it sounds like what you're doing now to try to hack 14.04 together is taking a while? :)
<fundies> jbicha, this will take me a long time 1x doinf that would take a long time 20x everytime I commit
<jbicha> can't you run all 20 tests in the same OS image?
<fundies> that would also be slow
<fundies> travis is parellelized
<jbicha> ok, keep on doing what you're doing then :)
<jbicha> you asked for Travis to support newer OS releases and I believe this is Travis' official answer
<fundies> jbicha, and it sucks. thats why everyone uses ppas
<nacc> fundies: sounds like a problem for travis, though?
<fundies> not really.
<fundies> travis is the root of me needing ppa but I need help with the ppa not travis
<nacc> fundies: and i think, you've been told everything one would need to use the ppa?
<nacc> fundies: it's not going to be a 5-second fix
<fundies> I;m not sure what youre asking
<nacc> fundies: I'm asking if there's something you actually need from the channel right now?
<fundies> maybe I should go back to my hacky solution
<fundies> I built google everything and put in google-trash.deb
<fundies> but when I install it its not installing the headers
<fundies> idk why
<nacc> fundies: are the headers packaged?
<fundies> https://github.com/RemoveRusky/grpc-trusy/releases/download/1.10/google-trash.deb
<fundies> yes
<nacc> fundies: uh because you botched the packaging?
<nacc> fundies: there's no top-level /include path
<nacc> fundies: i'm guessing you forgot to have --prefix=/usr in your rules or something
<fundies> https://github.com/RemoveRusky/grpc-trusy/blob/master/.travis.yml#L12
<fundies> thats the proccess I used
<nacc> fundies: so it *maybe*  created /include and put it all in there
<sarnold> "apt -get"
<fundies> heh it still worked
<sarnold> oh, since there's an 'apt' command now .. I wonder what it does with a '-get' argument. heh.
<nacc> fundies: well, i'm not particularly interested in debugging it further than what i told you :)
<fundies> nacc, so I want /home/travis/google-trash/usr instead of /home/travis/google-trash ?
<cjwatson> for the CMAKE_INSTALL_PREFIX, yes
<nacc> fundies: no, probabl your cmake invocation is wrong
<cjwatson> not for the other occurrences
<nacc> fundies: so i guess it depeonds on where you want that string to appear
<nacc> fundies: what cjwatson is saying more clearly :)
<cjwatson> well, normally it's actually -DCMAKE_INSTALL_PREFIX=/usr and then make install DESTDIR=/path/to/temporary/location
<cjwatson> the prefix should be the as-installed path
<nacc> cjwatson: yeah that looks more normal to me
<cjwatson> so in this case I'd do cmake -DCMAKE_INSTALL_PREFIX=/usr /home/travis/grpc && make && make install DESTDIR=/home/travis/google-trash
<cjwatson> $ sudo apt -get install cmake curl
<cjwatson> E: Command line option âgâ [from -get] is not known.
<cjwatson> (in a trusty container)
<sarnold> thanks cjwatson :)
<cjwatson> they were probably just installed already or something
<doko> tsimonq2: not amused about your mercurial sync. any reason to drop the patches?
<tsimonq2> doko: Indeed, now that I take another look at it, it probably wasn't the best idea. I'm sorry, I'll be more careful next time. You're an archive admin; you're welcome to remove it from -proposed, or I can readd the patches in another upload, whatever you'd like to do.
#ubuntu-devel 2018-03-28
<joelkraehemann> hi all
<joelkraehemann> how is the bionic beaver release?
<joelkraehemann> I just ask since there is a new release of GSequencer in unstable:
<joelkraehemann> https://tracker.debian.org/pkg/gsequencer
<joelkraehemann> https://launchpad.net/ubuntu/+source/gsequencer
<rbasak> joelkraehemann: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsequencer shows problems getting 1.4 into Bionic.
<joelkraehemann> with the new release the integration tests pass, again
<joelkraehemann> https://ci.debian.net/packages/g/gsequencer/unstable/amd64/
<joelkraehemann> rbasak: there was a broken test
<joelkraehemann> ags_functional_audio_test.c
<joelkraehemann> Please consider to sync.
<rbasak> joelkraehemann: is there an upstream changelog describing the changes from 1.4.19 to 1.4.24 please?
<joelkraehemann> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ChangeLog?h=1.4.x
<joelkraehemann> fixed ags_functional_audio_test.c to create notation as needed
<joelkraehemann> ^^ this was actually the solution ags (1.4.20)
<rbasak> Are there any feature changes?
<joelkraehemann> since 1.4.19?
<rbasak> Yep
<joelkraehemann> work-around reverted pulseaudio GMainLoop integration
<joelkraehemann> ^^ this is important
<rbasak> "defaulted disable OSS4"
<joelkraehemann> else the application crashes as doing Pulseaudio
<joelkraehemann> improved ags_lv2_manager.c to be faster
<joelkraehemann> ^^ this is a nice improvement
<rbasak> joelkraehemann: could you perhaps follow https://wiki.ubuntu.com/SyncRequestProcess to document all of this please? It feels a little more complicated than a quick IRC confirmation.
<joelkraehemann> Yes, for sure :)
<rbasak> Please describe the changes in your request, and for the ones that sound like feature changes, please explain why they aren't, or request a freeze exception if they are.
<rbasak> joelkraehemann: thanks! If the conclusion is that there aren't feature changes, and the changelog and upstream commits appear to match this, then I'll be happy to sponsor a sync for you.
<rbasak> If they contain feature changes then we need a release team approval first.
<joelkraehemann> only for Apple OS X there is a new feature CoreMIDI support
<joelkraehemann> but this won't affect GNU+Linux
<rbasak> Just point out in the request why it won't affect Ubuntu and that's fine.
<rbasak> Once you've documented the sync request in a bug, feel free to continue pinging here for attention if it's needed.
<rbasak> (as in: please don't assume it'll get attention automatically)
<joelkraehemann> seb128: I just recognized you was asking for GSequencer update
<seb128> joelkraehemann, hey, did I? I think I asked if somebody was looking at the autopkgtest issues for it
<joelkraehemann_> https://bugs.launchpad.net/ubuntu/+source/gsequencer/+bug/1759549
<ubottu> Launchpad bug 1759549 in gsequencer (Ubuntu) "Sync gsequencer 1.4.24-1 (universe) from Debian unstable (main)" [Undecided,New]
<joelkraehemann> seb128: autopkgtest told about regression due to a broken integration test
<joelkraehemann> seb128: this is fixed, now
<seb128> joelkraehemann, ah, good, thanks
<joelkraehemann> here is the prove https://ci.debian.net/packages/g/gsequencer/unstable/amd64/
<seb128> joelkraehemann, synced, let's see :)
<joelkraehemann> you are awesome
<seb128> :)
<seb128> I just did the sync, not the actual work, but thx :)
<coreycb> rbasak: hi, any chance we could fast-track the xenial/artful fixes for bug 1758411 to -updates? it fixes a bad regression.
<ubottu> bug 1758411 in neutron (Ubuntu Artful) "[SRU] Revert fix for bug 1752838 regression" [Critical,Fix committed] https://launchpad.net/bugs/1758411
<rbasak> coreycb: looking
<coreycb> rbasak: thanks, we also have a stable point release of neutron in the artful upload
<rbasak> coreycb: "There should be none as long as the code is reverted to what it was before the SRU for 1752838" -- isn't that statement wrong then?
<coreycb> rbasak: the fix reverts all the code from another SRU that caused the regression
<rbasak> Right, and that part is fine to consider for a fast track.
<GunnarHj> seb128, cjwatson: Two especially disturbing translation bugs:
<coreycb> rbasak: so there should be no regression potential, at least that's what i was trying to say
<GunnarHj> Bug #1758684 because snapd is a 'hot' package which also affects other distros, and we are upstream.
<ubottu> bug 1758684 in snapd (Ubuntu) "LP only imported a fraction of the snappy translation template" [High,Confirmed] https://launchpad.net/bugs/1758684
<GunnarHj> Bug #1756547 because it probably affects quite a few packages and prevents strings with plural options (for certain languages) to show up as translated for Ubuntu users.
<ubottu> bug 1756547 in gnome-shell (Ubuntu) "LP does not understand msgstr[2] entries in PO files" [Undecided,New] https://launchpad.net/bugs/1756547
<rbasak> coreycb: but I think that choosing to bundle further updates disqualifies it from that.
<seb128> GunnarHj, thanks for raising this up
<coreycb> rbasak: think we could at least get xenial released? i'm not too concerned about artful.
<rbasak> coreycb: I think that should be OK. Still looking.
<arges> rbasak: hey looking at some srus this morning
<rbasak> arges: OK. I'm just looking at neutron for coreycb as above. I've not looked at anything else yet.
<arges> ok i'm just looking at the top of xenial atm
 * coreycb waves to arges
<arges> coreycb: hi : )
<coreycb> arges: howdy :)
<joelkraehemann_> The tests are running now on my system and as expected:
<joelkraehemann_> PASS: ags_functional_audio_test
<joelkraehemann_> Just noticed https://launchpad.net/ubuntu/bionic/+source/gsequencer
<joelkraehemann_> Thank you all
<cjwatson> GunnarHj: Ack, but chances of me having time to look before Easter are slim
<joelkraehemann> Where can I see your test results?
<GunnarHj> cjwatson: I understand if the msgstr[2] thing may be tricky, but it would be great if you could check why on earth snappy.pot does not get fully imported.
<joelkraehemann_> https://autopkgtest.ubuntu.com/packages/gsequencer/bionic/amd64
<joelkraehemann_> seb128: are the tests running anywhere?
<rbasak> coreycb: done
<coreycb> rbasak: thanks!
<seb128> joelkraehemann, they are going to be once the binaries are published/picked up
<seb128> joelkraehemann, you can keep an eye on e.g http://autopkgtest.ubuntu.com/packages/g/gsequencer/bionic/amd64
<joelkraehemann> great!
<cjwatson> GunnarHj: Chances of me having time to look before Easter are still slim.  I have another urgent project
<cjwatson> I'm not saying I won't look after Easter, just setting expectations
<GunnarHj> cjwatson: I see. Just wanted to call attention to those two. Btw, is there anybody else who could look at the snappy thing?
<GunnarHj> wgrant: ^ ?
<wgrant> GunnarHj: The latter doesn't look like a bug to me. The msgid includes a %d, the msgstr[0] doesn't include the %d.
<wgrant> GunnarHj: So the msgstr[0] is invalid; it's nothing to do with msgstr[2].
<wgrant> msgid "%d minute ago"
<wgrant> msgid_plural "%d minutes ago"
<wgrant> msgstr[0] "pÃâ¢ed minutou"
<wgrant> msgstr[1] "pÃâ¢ed %d minutami"
<wgrant> msgstr[2] "pÃâ¢ed %d minutami"
<GunnarHj> wgrant: Some languages has separate form for 2, i.e. they don't have just singular or plural. I have been told that such options are common in many GNOME translation files.
<GunnarHj> wgrant: So probably gettext understand, but LP does not.
<GunnarHj> wgrant: Ah, now I see what you mean. Wondering if the missing %d is a common denominator. Need to recheck.
<wgrant> GunnarHj: That's why there's three forms rather than two
<wgrant> GunnarHj: The missing %d is absolutely the bug in the upstream translation.
<wgrant> It's nothing to do with plural forms at all; the singular translation is just buggy.
<wgrant> (LP supports up to nplurals=6, eg. Arabic)
<GunnarHj> wgrant: Thanks for the lesson. Then there are plenty of buggy translations out there. :( I'll follow up on the bug report.
<wgrant> GunnarHj: Do you know how many packages this has hit?
<wgrant> GNOME stuff used to be reasonably well behaved.
<GunnarHj> wgrant: No. But apparently damned lies accepts it.
<seb128> GunnarHj, wgrant, are you sure it's illegal? https://www.gnu.org/software/gettext/manual/html_node/Translating-plural-forms.html#Translating-plural-forms states that
<seb128> "Can you do this in your translation as well?
<seb128> msgstr[0] "jednom datotekom je uklonjen"
<seb128> Well, it depends on whether msgstr[0] applies only to the number 1, or to other numbers as well. If, according to the plural formula, msgstr[0] applies only to n == 1, then you can use the specialized translation without the number placeholder."
<seb128> also msgfmt -c doesn't complain about the po attached to the bug
<seb128> cz uses nplurals=3; plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2; it seems
<jbicha> for languages with a separate plural form for 2, it's often unnecessary (and even wrong) to explicitly use the numeral 2 in the phrase
<GunnarHj> seb128, wgrant: I'll await with closing the bug report. ;)
<seb128> jbicha, do you have a reference to that, the gettext page I was mentioning doesn't include that case
<jbicha> um, I know some Arabic which has a separate form for 2
<seb128> well I guess the principle is the same, if the form applies to a specific/unique number then include the %d doesn't make sense
<jbicha> the word itself already tells you there is 2 of the item
<seb128> wgrant, ^ how does launchpad verify the validity? it uses msgfmt or equivalent or has its own implementation?
<jbicha> but I guess it depends on context a bit too
<wgrant> seb128: It uses gettext
<wgrant> I wonder if there's some flag on the message that makes it more pedantic.
<seb128> wgrant, the gettext command? it has a "validate" mode?
<wgrant> seb128: It's a Python binding to gettext
<seb128> ah
<seb128> maybe it's a bug in the binding then
<GunnarHj> wgrant: Ouch. Python isn't reliable wrt l10n matters. ;)
<wgrant> Hmm
<wgrant> It's javascript-format, I wonder if that's extra pedantic in some gettext
<wgrant> The bindings are very thin, there can't really be this sort of bug in them.
<wgrant> GunnarHj, seb128: It's a difference between xenial and bionic gettext
<wgrant> GunnarHj, seb128: javascript-format in xenial requires an exact match
<wgrant> I wonder which is right.
<seb128> wgrant, well, the gettext upstream documentation I pointed earlier made it clear it's optional
<seb128> "If, according to the plural formula, msgstr[0] applies only to n == 1, then you can use the specialized translation without the number placeholder.""
<wgrant> seb128: It probably depends on the syntax mode selected.
<GunnarHj> wgrant, seb128: Maybe gettext has adapted to better fit the grammar rules of certain languages.
<wgrant> So we should probably establish whether javascript-format is meant to be pedantic or not, and probably fix xenial's gettext or give LP a patched one.
<GunnarHj> wgrant: In regular strings it's probably motivated to be pedantic wrt number of %s etc.
<GunnarHj> Or isn't it possible to distinguish between regular strings and plural form strings?
<seb128> wgrant, why do we use javascript mode?
<wgrant> seb128: We don't. The .pot does.
<seb128> ah, ok
<wgrant> You can repro the issue with xenial's msgfmt -c
<seb128> tha's what I tried, it doesn't complain
<wgrant> Just stick "#, javascript-format" before the problematic message to match the .pot
<wgrant> What exactly did you try?
<seb128> ah
<seb128>  msgfmt -v -c gnome-shell.po
<seb128> 423 messages traduits.
<seb128> I tried
<seb128> k, that does it indeed
<seb128> wgrant, so one workaround would be to remove the javascript-format from the pot?
<seb128> in gnome-shell
<wgrant> Yep, that would be an easy workaround.
<seb128> GunnarHj, ^
<GunnarHj> seb128: Yeah, I saw.
<seb128> wgrant, how do we go about figuring out if gettext handling of javascript mode is buggy in xenial or bionic?
<wgrant> seb128: I have no idea.
<wgrant> I'm not a translator, I just play one on Launchpad :)
<GunnarHj> seb128: OTOH, the .pot is not the problem. All the .po files are.
<seb128> GunnarHj, the .po don't have that javascript format hint
<seb128> the pot has
<GunnarHj> seb128: But it's the .po files which are (partially) rejected by LP.
<GunnarHj> Or can that be because of that comment in the .pot?
<seb128> GunnarHj, wgrant said that launchpad does the validation in javascript format because that's what the pot tell it to do
<wgrant> The POs are validated against the POT
<GunnarHj> seb128, wgrant: I see.
<GunnarHj> So I suppose we are talking about modifying the .pot during package build. Worth a try for now, I suppose.
<GunnarHj> seb128: Or should we let dh_translations do it? :)
<GunnarHj> (forget the latest remark. This is meson, I suppose.)
<seb128> GunnarHj, well I don't think dh_translations can do that
<cjwatson> Looks like this changed in gettext 9b9ebf8f96dd3b142e4202ca4a60feac9db0820e
<seb128> ah, cjwatson is better than me at it
<seb128> I was building gettext to bisect
<seb128> thanks cjwatson
<cjwatson> https://git.savannah.gnu.org/cgit/gettext.git/commit/?id=9b9ebf8f96dd3b142e4202ca4a60feac9db0820e
<cjwatson> (I'm guessing slightly, but it removes the offending error message at least ...
<cjwatson> )
<cjwatson> seb128: I just searched the git log for "javascript" and looked at the first few matching commit s:)
<seb128> cjwatson, I did that as well for "plural" and "javascript" but the title for that commit didn't make me look at the diff
<cjwatson> Giving LP a gettext backport mightn't be totally silly, since they're adding support for new features
<cjwatson> I'm slightly surprised we haven't had to do so in my memory, but I guess gettext is pretty slow-moving
<seb128> cjwatson, wgrant, what do you recommend us doing for gnome-shell meanwhile? hack the .pot to remove the javascript format? or do you think that launchpad can be changed/fixed in the next week or so?
<cjwatson> If people agree that a gettext backport is the right response then we could probably do that next week or so
<seb128> where people is you and wgrant? ;)
<wgrant> That might be reasonable.
<cjwatson> I guess, though opinions welcome since I've spent all of five minutes looking at this and mooching off wgrant's analysis :)
<seb128> well, I think it would make sense to base launchpad on recent gettext, as you said some new features/changes are being added that upstreams are taking advantage off
<joelkraehemann> Hi all
<joelkraehemann> do you provide an ISO installer image for s390x?
<TJ-> joelkraehemann: see http://cdimage.ubuntu.com/releases/16.04.4/release/   ubuntu-16.04.4-server-s390x.iso
<joelkraehemann> TJ-: thank you
<xnox> joelkraehemann, yes.
<xnox> joelkraehemann, we also have smaller d-i installer too (which fetches all packages from the network archive), possibly nicer for ftp-loads / zvm uploads.
<xnox> joelkraehemann, http://ports.ubuntu.com/dists/xenial-updates/main/installer-s390x/current/images/ both in GA kernel; and rolling hwe kernel variants.
<xnox> joelkraehemann, note there is #ubuntu-s390x too, if you have more s390x specific questions =)
<TJ-> which reminds me ... do we have any ISO installers for 32-bit EFI systems (so the ISO has /EFI/BOOT/GRUBIA32.EFI ) ?
<TJ-> we've been getting a lot of users wiht Intel Atom based deviecs with 32-bit EFI that suffer due to the installer not being seen/bootable
<xnox> TJ-, all Intel Atom devices use 64 UEFI, since a long time ago.
<xnox> TJ-, even the minnow boards.
<xnox> TJ-, and the answer is no, we do not ship 32bit uefi images.
<xnox> TJ-, you are hearing a small vocal minority. And if they have such devices, that you should use the amd64 mini.iso and discover that it just works; or e.g. upgrade their firmware - minnow board provides eufi firmware of both arches for download.
<TJ-> xnox: We're seeing this especially for Acer tablet/2-in-1 devices, and we've had some HP and Lenovo in the last 3 months as well.
<cjwatson> bionic gettext builds on xenial with a couple of Build-Depends tweaks, at least.
<cjwatson> Should probably run the LP translations tests against it.
<xnox> TJ-, but Intel stopped supporting that.... Do you have exact model numbers?
<seb128> it builds, ship it!
<seb128> :)
<wgrant> Heaps of Bay Trail devices have 32-bit only UEFI
<wgrant> Not all, but a lot.
<xnox> TJ-, and you mean that said hardware was released "in the last 3 months"?
<xnox> wgrant, but bay trail is very very very old it's like 2013/2014? i think it was the last ones still in the pipeline, when everybody agreed that 32bit uefi is silly with a 64bit cpu
<xnox> even if userspace/kernel will be 32bit
<TJ-> xnox: No, I mean user's come to #ubuntu unable to install on these systems. We have to spend a lot of time to diagnose the cause, but the user's have the opnion "Ubuntu won't work with my PC"
<xnox> TJ-, buy Ubuntu preinstalled from Dell? stop taking old weird things (e.g. tablets) and try to install ubuntu on them =)
<xnox> TJ-, we killed the Touch/Tablet project ;-)
<xnox> TJ-, what I am saying no new hardware is shipped like that, and the hardware that was shipped is niche, and yes there will be random people who try to use ubuntu on those devices.
<xnox> TJ-, but there really was no market demand to support 32bit uefi, on ubuntu, ever. it is not something that was ever big, or growing... it's shrinking.
<TJ-> xnox: OK, so we can just tell them Ubuntu won't install
<coreycb> doko: in adding the .symbols file requested for the liblasso3 MIR, i'm adding it with versions back to precise only. does that make sense?
<coreycb> doko: first time adding a symbols file
<jbicha> coreycb: I don't even bother going back in time when making a new symbols file
<coreycb> jbicha: ah, ok i was wondering about that. probably doesn't hurt though if i've done that a bit already.
<coreycb> jbicha: thanks
<jbicha> yeah it won't hurt, but maybe less work next time :)
<coreycb> jbicha: yep! :)
<jbicha> here's a recent one I added: https://salsa.debian.org/utopia-team/volume-key/commit/8545cd24
<xnox> TJ-, it can be done, but it's for people who know how to boot & install without using d-i.
<xnox> TJ-, e.g. one can manually prepare grub, manually prepare kernel image and initrd, boot that, and use debootstrap and manually configure /etc/fstab, bootloader, reboot....
<TJ-> xnox: right, which is why I asked since it takes a lot to talk people through it, or to direct them to sensible, clear instructions. It only boils down to installing grub-efi-ia32 into ISO EFI-SP and having the package install at end of install
<coreycb> doko: i've made the requested updates for bug 1610286 and switch it back to New
<ubottu> bug 1610286 in libapache2-mod-auth-mellon (Ubuntu) "[MIR] libapache2-mod-auth-mellon, liblasso3" [Medium,Triaged] https://launchpad.net/bugs/1610286
<xnox> TJ-, but people who need such guidance, should probably be told "yeah, it's hard, don't do it"
<TJ-> xnox: they end up using other people's respins of the ISOs that have had grub-efi-ia32 added
<TJ-> xnox: trouble is it takes some digging when a user reports 'ubuntu installer won't work' to figure out the cause.. mostly it's they used some weird method to prepare the USB device (like copying the ISO as a file rather than writing it as a device!) - ends up creating quite a lot of support effort before we get to the point of identifying 32-bit UEFI is the issue
<TJ-> especially as many recent systems have locked-down firmware (Insyde H2O and others) across recent Acer, HP, and Lenovo models, where the installer doesn't show up as a boot option because in those you have to go into FW Setup> Security > and specifically /trust/ the EFI boot loader file by using a file-browser
<xnox> we do not have 32bit shim; and we do not have secureboot 32bit; hence yeah, one will not boot.
<xnox> 64bit is secureboot
<xnox> Ubuntu was first to ship secureboot stable release; even ahead of Windows itself.
<xnox> TJ-, it's simple really.... if installer doesn't boot, we don't support it =)
<xnox> can you boot 64bit image - no? what about 32bit image - no? tried legacy boot settings ? still no.... yeah, we don't support that.
<TJ-> right, but even amd64 fails to boot the installer on the systems I just mentioned because the firmware doesn't 'trust' any boot-loader path that isn't Windows specific
<TJ-> it's not as simple as 'does it boot?' in many cases because we first have to verify the user actually wrote the ISO to the installer device correctly. These wider issues I'm mentioning is because they consume a lot of support time and create a lot of frustration. A new LTS is generally the time the support channel gets inundated with this kind of problem.
<xnox> TJ-, you should start documenting model numbers, devices, and their release dates.
<xnox> like we did for non-PAE i386 to discover devices that lie, and we made quirks for them.
<TJ-> xnox: will do; it's got to the point where I cringe when these issues come along... they're easy to solve in-front of the PC but painful when trying to talk someone through even the diagnostic steps - especially when they're reliant on Windows at the pre-install point
<xnox> TJ-, ability to discover what the UEFI is from windows, would be nice.
<TJ-> xnox: yeah... I've not touched Windows since 2005 so out of the loop on that aspect :)
<seb128> joelkraehemann, http://autopkgtest.ubuntu.com/packages/g/gsequencer/bionic/amd64 ... it worked :)
<joelkraehemann> great!
<joelkraehemann> but it fails for s390x
<joelkraehemann> Currently I try to setup a VM using qemu
<joelkraehemann> but I don't get a screen
<seb128> joelkraehemann, that's an improvement still :) do you need a screen to debug the autopkgtest?
<seb128> bdmurray, hey, did you see the ubuntu-devel@ discussion about apport warning vs error? seems the consensus is that stopping reporting warnings was the wrong fix, what do you think about reverting? the change currently impact negatively our capacity to understand reports at a time in the cycle where we need those details ...
<seb128> bdmurray, if you are unsure maybe we can enable them at least for beta and rediscuss what to do before bionic turns stable?
<bdmurray> seb128: I didn't feel like a consensus was reached. One idea I had was making reports w/ journal warnings private but given how JournalErrors are added that'd be every report. If we were to do that could we limit which packages collect the journal warnings?
<ahasenack> hi, anybody working on https://bugs.launchpad.net/ubuntu/+source/freeipa/+bug/1754936 ? It's stuck in excuses due to a test failure
<ubottu> Launchpad bug 1754936 in freeipa (Ubuntu) "freeipa cleint missing" [Undecided,Confirmed]
<ahasenack> if not, I can take a look
<ahasenack> (bug is unassigned)
<nacc> ahasenack: i saw someone mention it just now on the ML, I believe no one has looked explicitly, but tjaalton may know
<ahasenack> nacc: could you import it into git please?
<ahasenack> freeipa-client
<ahasenack> actually
<ahasenack> let me check if it's just not a binary from the same source
<ahasenack> it is, n/m
<ahasenack> the whole thing is gone, not just the client
<nacc> ahasenack: starting import
<seb128> bdmurray, I don't think limiting makes sense, warnings often give useful clues and we lost them
<doko> coreycb: it only makes sense in the development series where new upstream versions appear. it doesn't hurt for older releases
<seb128> bdmurray, what would help you to feel like we have a consensus? do we need the input for more people, like maybe ask slangasek what he thinks?
<slangasek> seb128: I punted to bdmurray ;)
<seb128> shrug
<seb128> seems we are stucked then :/
<coreycb> doko: ok
<seb128> slangasek, maybe I put it on the TB agenda then, but I feel like it's going to be too slow of a process to hit bionic
<bdmurray> seb128: I'll look at the emails again today and send a reply.
<seb128> thanks
<seb128> or at least we are going to miss beta
<seb128> which is a shame because that's when we need the info the most to be able to address bugs
<bdmurray> okay, I could add it back for now while the discussion continues
<seb128> that would be great, if that are concerns about specific log output we should fix those apps
<seb128> I'm going to have a look to see where the one that triggered the bug is coming from and make sure it's fixed
<nacc> ahasenack: it should be done?
<nacc> ahasenack: that is, current
<ahasenack> yes
<ahasenack> yes
<ahasenack> the good news is that the failure also happens locally
<nacc> ahasenack: that is 'good'
<bdmurray> seb128: What about only including JournalErrors w/ warnings for crash reports? Those would be private by default and you could ask for "bug" reports.
<seb128> bdmurray, that would be a good middle way
<bdmurray> seb128: Okay, I'll do that today then.
<seb128> bdmurray, great, thank you!
<joelkraehemann> seb128: where can I get the gsequencer.changes file you have created?
<joelkraehemann> or better does a launchpad repository exist?
<seb128> joelkraehemann, I didn't create one, the package was copied from debian by the importer
<seb128> joelkraehemann, is https://launchpad.net/ubuntu/+source/gsequencer/1.4.24-1 including what you need?
<seb128> joelkraehemann, it's a pure source copy from debian
<seb128> joelkraehemann, you have the "builds" section on the right, if you click on an arch there you get download the debs
<joelkraehemann> I use the debian repo now and create a .deb file
<joelkraehemann> I created a small patch doing sigaction()
<joelkraehemann_> how long does it take until I can see the PPA?
<joelkraehemann_> dput -u  ppa:~jkraehemann/ppa ../build-area/gsequencer_1.4.24-1_amd64.changes
<joelkraehemann> what happens to the package as the ubuntu version is not specified?
<jbicha> joelkraehemann: you need to use an Ubuntu series in the .changes file (usually done with the most recent debian/changelog entry)
<jbicha> joelkraehemann: I recommend you look into using backportpackage from the ubuntu-dev-tools package to make it easier
<Unit193> I note that 'devel' is a symlink to the development version of Ubuntu (right now, bionic), though not a lot of people use that.
<joelkraehemann> yeah, I just left it to UNRELEASED :/
<tjaalton> nacc, ahasenack: it needs nss-pem, one way or another. ipa-server that is
<nacc> tjaalton: ok, thanks
<tjaalton> if that won't make it, I can make freeipa client-only
<joelkraehemann_> hi all
<joelkraehemann_> http://codepad.org/Te4gZiiS
<joelkraehemann_> http://codepad.org/hRmGgAUf
<joelkraehemann_> ^^ shows the last output of the commands run
<joelkraehemann_> https://launchpad.net/~jkraehemann/+archive/ubuntu/gsequencer
<joelkraehemann_> ^^ but still nothing available :/
<ginggs> joelkraehemann_:  you should be uploading gsequencer_1.4.24-1_source.changes
<joelkraehemann> I don't have it.
<joelkraehemann> I do `gbp buildpackage`
<nacc> joelkraehemann: i dont' think you generally can upload debs directly to PPAs as you did
<nacc> joelkraehemann: you upload source packages and LP builds them in the PPA
<nacc> joelkraehemann: specifically you need to pass -S somewhere, probably
<joelkraehemann> ginggs: thank you
<joelkraehemann> I got it
<ginggs> joelkraehemann_: \o/
<joelkraehemann> nacc: thank you, too
<nacc> joelkraehemann: yw
<joelkraehemann> where can I see the build log?
<nacc> joelkraehemann: once the PPA starts building it you can see it
<joelkraehemann> I see
<joelkraehemann> https://launchpad.net/~jkraehemann/+archive/ubuntu/gsequencer/+builds?build_state=building
<nacc> joelkraehemann: you should get an emil that it's been accepted and it usually builds shortly after
<joelkraehemann> Yeah, I have got one
<nacc> looks like it's started
<flexiondotorg> infinity: Way back when 16.04 release was approaching you directed me at a "package" that helps the release upgrade process.
<flexiondotorg> I can't remember what it was. But it almost certainly needs updating given the changes in Ubuntu MATE between 16.04 and 18.04.
<sarnold> do-release-upgrade?
<flexiondotorg> sarnold: Maybe, I think this was something that the release upgrader downloaded perhaps.
<jbicha> flexiondotorg: check the whole ubuntu-release-upgrader package
<krytarik> flexiondotorg: https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/data/DistUpgrade.cfg - might be what you are thinking of.
<joelkraehemann> the tests are running, now.
#ubuntu-devel 2018-03-29
<joelkraehemann> thank you for releasing latest GSequencer :)
<joelkraehemann> https://launchpad.net/ubuntu/+source/gsequencer/1.4.24-1
<joelkraehemann> hi all
<joelkraehemann> https://launchpad.net/builders/bos02-s390x-010
<joelkraehemann> ^^ is this server still up?
<joelkraehemann> I don't get any progress for half an hour
<wgrant> joelkraehemann: All three architectures are stuck in the same place, so it looks like a package bug.
 * wgrant wonders if whichever test runs after ags_functional_mixer_test tries to use the network or something like that.
<sarnold> thanks wgrant, I didn't think to look for other architectures
<joelkraehemann> there a few things linux doesn't like ...
<joelkraehemann> like sigaction on SIGSEGV ?
<flexiondotorg> krytarik: Thanks, that was it.
<flexiondotorg> tsimonq2: FYI See earlier comment from k_rytarik
<tsimonq2> flexiondotorg: ack
<joelkraehemann> so it was the update hanging-up the VM?
<joelkraehemann> can I restart the build?
<joelkraehemann> I have canceled all builds
<joelkraehemann> and started rebuild
<infinity> flexiondotorg: Quirking things in the release-upgrader should be a last resort for bugs you can't fix (ie: because the bug exists in xenial and can't be easily worked around)
<infinity> flexiondotorg: It's not a replacement for just making sure "apt-get dist-upgrade" DTRT in 99% of cases.
<flexiondotorg> OK
<flexiondotorg> What sort of bugs is it intended to workaround?
<sarnold> does it break all those "looping triggers" bugs?
<flexiondotorg> I was updating it to make sure some obsolete packages seeded in xenial and remove during the upgrade.
<flexiondotorg> *are removed
<infinity> flexiondotorg: Obsolete as in "no longer in the archive", or just "not part of foo-desktop anymore"?
<flexiondotorg> Not part of ubuntu-mate-desktop any more, and...
<infinity> flexiondotorg: Unseeded-but-still-in-the-archive shouldn't be removed by an upgrade.  A user might have been using it.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/topmenu-gtk/+bug/1744912
<ubottu> Launchpad bug 1744912 in topmenu-gtk (Ubuntu) "Please remove topmenu-gtk from the Bionic archive" [Undecided,New]
<infinity> flexiondotorg: If it *must* be removed, do to it breaking other things, that's for dpkg relationships to handle, not the release upgrader.
<flexiondotorg> Those packages need ejecting. Very broken.
<infinity> flexiondotorg: But if removed from the archive, release-upgrader already handles that in a second pass for all upgrades.
<flexiondotorg> OK.
<flexiondotorg> So if that removal request is processed I'm good?
<infinity> Yeah.
<flexiondotorg> Do all flavours need an entry in the release upgrader?
<flexiondotorg> I don't see Budgie.
<infinity> Pretty sure budgie is there.
<infinity> Or maybe it was another flavour I added last cycle.
<infinity> Or this cycle.
<infinity> ubuntu-release-upgrader (1:18.04.8) bionic; urgency=medium
<infinity>   * data/DistUpgrade.cfg: Add ubuntu-budgie-desktop support.
<infinity>   * Run pre-build.sh to update mirrors.cfg and demoted.cfg.
<infinity>  -- Adam Conrad <adconrad@ubuntu.com>  Mon, 05 Feb 2018 04:00:06 -0700
<flexiondotorg> Actually, yeah, Just saw it.
<joelkraehemann> wgrant: what is the command line of autopkgtest actually used?
<joelkraehemann> ^^ excuse me pbuilder or alike?
<infinity> flexiondotorg: Also, topmenu-gtk isn't in bionic?
<flexiondotorg> Oh, did it get removed already?
<flexiondotorg> It was there when that bug was raised.
<infinity> flexiondotorg: Removed by Steve a month and a half ago when processing Debian removals.
<flexiondotorg> But great.
<flexiondotorg> Thanks infinity
<wgrant> joelkraehemann: This isn't autopkgtest. Builds use sbuild.
<flexiondotorg> infinity: https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-release-upgrader/ubuntu-mate-bionic-update/+merge/342372
<joelkraehemann> wgrant: I don't think its a bug, just try add missing dependencies on data (files from different packages)
<joelkraehemann> ags_functional_drum_test tries to open a not-existing directory
<joelkraehemann> looking at the logs inside the schroot following message looks suspicious:
<joelkraehemann_> Failed to create secure directory (/run/user/1000/pulse): No such file or directory
<joelkraehemann> is it possible to run within a container rather then a schroot?
<GunnarHj> wgrant: It was a fruitful discussion yesterday. Any chance you can take a look at the snapd import issue too?
<joelkraehemann> I just run the test on a SLES 12.3 linux one instance it seems fine so far, no crash
<joelkraehemann> I was using https://build.opensuse.org/package/show/home:jkraehemann/libinstpatch
<joelkraehemann> now I try the libinstpatch version available in ubuntu
<joelkraehemann> it crashes
<joelkraehemann> actually, I can reproduce it
<joelkraehemann> this is the bt http://codepad.org/mKZ5c5dA
<ahasenack> tjaalton: hi,
<ahasenack> tjaalton: so freeipa is doomed in bionic?
<ahasenack> tjaalton: I found this thread: https://www.redhat.com/archives/freeipa-users/2017-February/msg00322.html
<ahasenack> it looks like the /etc/httpd/alias -> /etc/apache2/nssdb is also not in certmonger
<joelkraehemann> however, there was a critical warning before the line number of the SIGSEGV
<joelkraehemann> (ags_functional_ffplayer_test:52633): libInstPatch-CRITICAL **: ipatch_container_get_children: assertion 'IPATCH_IS_CONTAINER (container)' failed
<tjaalton> ahasenack: no, but it would need libnsspem anyway
<joelkraehemann> for short, I have 2 versions one working the other not
<ahasenack> tjaalton: do you know if a previous version of freeipa required that too?
<joelkraehemann> !DIFF!
<ahasenack> or we never saw it because it was never updated, and the setup script (which is the dep8 test) never ran?
<tjaalton> ahasenack: it did
<tjaalton> ahasenack: ah, no, new ipa server requires libnsspem now
<tjaalton> before it was just the client to renew certs
<tjaalton> which didn't work, obviously
<ahasenack> so should the bionic version be reverted for now?
<tjaalton> no
<ahasenack> the situation now as I understand it is that it does not exist in bionic anymore
<tjaalton> true
<ahasenack> the package in proposed won't migrate
<tjaalton> correct again
<tjaalton> the release team will weigh in about nss-pem, and how it should be packaged, if at all
<ahasenack> does it exist in debian?
<tjaalton> no
<ahasenack> I think it's broken there too
<ahasenack> yep
<ahasenack> with final freeze coming up next week, it looks like freeipa won't make it then
<tjaalton> it's in universe
<ahasenack> now it's not even there :)
<tjaalton> right, but still, different rules
<ahasenack> ah, wrt the freeze you mean?
<tjaalton> right
<GunnarHj> cjwatson, wgrant: I "fixed" bug #1758684 through a manual upload of the template. Possibly that's it, but I'm going to keep an eye on it when the package is uploaded next time.
<ubottu> bug 1758684 in Ubuntu Translations "LP only imported a fraction of the snappy translation template" [High,In progress] https://launchpad.net/bugs/1758684
<seb128> GunnarHj, what did you change/how did you generate the right template?
<GunnarHj> seb128: I grabbed it from the tarball with stripped files. Didn't change anything.
<seb128> GunnarHj, so it's identical to the one which is in the builddir after build?
<GunnarHj> seb128: Yes.
<seb128> but the after-build being imported is incomplete?
<GunnarHj> seb128: Yes, so it was for some reason. Let's see what happens next time.
<seb128> GunnarHj, and that happened on several uploads?
<GunnarHj> seb128: Yes, a few I think. Haven't digged deep into the history. But artful has a reasonable number of strings.
<seb128> that's weird
<GunnarHj> yep
<seb128> indeed https://launchpad.net/ubuntu/bionic/+upload/17785673/+files/snapd_2.32+18.04_amd64_translations.tar.gz has a complete pot
<seb128> and uploading the same "by hand" works?
<seb128> cjwatson, wgrant, you didn't switch launchpad to the new gettext yet, did you?
<GunnarHj> seb128: Yes. And no complaints.
<seb128> GunnarHj, https://translations.launchpad.net/ubuntu/bionic/+source/snapd/+imports has no older/other files than your manual upload
<seb128> are you sure they made it to the import queue?
<seb128> GunnarHj, I think it's another case where https://translations.launchpad.net/ubuntu/bionic/+source/snapd/+sharing-details is set to share with upstream so the template from the source isn't imported?
<GunnarHj> seb128: Yes, I'm 100% sure they were there. They disappear after a while after having been imported.
<seb128> k, weird
<GunnarHj> seb128: I also saw that, but autosync isn't enabled. The affects of those sync settings isn't crystal clear to me.
<seb128> yeah, it's confusing to me as well :/
<cjwatson> seb128: no
<seb128> cjwatson, ok, thanks
<seb128> GunnarHj, well, I don't understand what's going on there then
<GunnarHj> seb128: Well, correction I think. The *template* was imported. The PO files don't really need to be imported since we are upstream. The snapd project grabs the PO files from LP exports.
<seb128> GunnarHj, the french translate page has a mention "These translations are shared with Snappy trunk series template snappy."
<seb128> which points to https://translations.launchpad.net/snappy/trunk/+pots/snappy/fr
<seb128> but that has 102 strings only
<seb128> so something seems buggy/not configured as it should
<GunnarHj> seb128: Indeed.
<seb128> GunnarHj, https://github.com/snapcore/snapd/tree/master/po has no update for 5 months
<seb128> so that seems buggy
<seb128> GunnarHj, can you post about that / how are translations updated on https://forum.snapcraft.io/ ?
<seb128> GunnarHj, I've a feeling translations is not something the snappy team is giving much attention to atm so the discussion/reminder might be useful
<GunnarHj> seb128: I have precisely the same feeling. Sure, I can call their attention to it.
<seb128> GunnarHj, thanks, I can follow up on the post as well
<GunnarHj> seb128: Btw, this is the latest sync I noticed upstream:
<GunnarHj> https://github.com/snapcore/snapd/pull/4053/commits/f884b3ba
<GunnarHj> Don't know if they had exported from the LP project or the LP package, though.
<seb128> GunnarHj, could be from https://code.launchpad.net/~snappy-dev/snappy/snappy-moved-to-github but it looks like things changed with the move to github so unsure how it's meant to work nowadays, the name of that branch suggests it's deprecated ... I think we need to talk to the snappy team, the forum is the right place
<GunnarHj> seb128: Sure, it's on my list. :)
<seb128> thx
<seb128> stgraber, the lxd manpage seems buggy on the current bionic package, ".TH PANIC: "1" "March 2018" "panic: failed to configure SQLite replication" "User Commands""
<stgraber> seb128: yeah, that's known
<stgraber> seb128: help2man is unhappy with our --help, we'll switch to some other way to generate them
<joelkraehemann> seb128: http://codepad.org/1pUsFFpl
<joelkraehemann> ^^ this is a fix that is actually not in ubuntu
<xnox> joelkraehemann, interesting
<joelkraehemann> there some more changes available upstream actually not in ubuntu
<joelkraehemann> just run the ubuntu libinstpatch version with the diff previously shared
<joelkraehemann> and it works
<joelkraehemann> I just reported on debian reportbug including the patch
<joelkraehemann> Bug#894386
<joelkraehemann> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894386
<ubottu> Debian bug 894386 in src:libinstpatch "libinstpatch: memory corruption in file IpatchSF2Reader.c" [Normal,Open]
<flexiondotorg> infinity: Thanks for the release upgrade review last night.
<flexiondotorg> I've revised my merge proposal - https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-release-upgrader/ubuntu-mate-bionic-update/+merge/342372
<TJ-> what would be the appropriate package to report an S3 resume bug that only happens when suspend was triggered by lid close. On resume the unlock/greeter is shown and I authenticate then when it switches to the user session the screen goes and remains black. Switching to other VTs works fine but the Xorg GUI remains black. No indications in any log files, expected processes still running
<nacc> TJ-: taht sounds like the greeter itself? gdm maybe?
<nacc> TJ-: given that the kernel is fine (it seems)
<TJ-> nacc: it's after the greeter, when the user session is switched. there's a possible clue in "Failed to configure CRTC 63" !
<nacc> TJ-: ah is taht from X?
<TJ-> seems to be, I'm tracking it down
<seb128> joelkraehemann, thanks, nice debugging!
<rlink> I've just uploaded a debdiff to fix LP#1752306 for Xenial.  (already fakesync'd for Trusty and fixed in Bionic.)  Anyone around to take a peek?
<nacc> rlink: i can
<nacc> rlink: fyi, use LP: #1752306, the bot will link to it
<ubottu> Launchpad bug 1752306 in xmltooling (Ubuntu Artful) "Security bug in XMLTooling-C before 1.6.4 [CVE-2018-0489]" [Undecided,Incomplete] https://launchpad.net/bugs/1752306
<nacc> rlink: oh but you need security sponsoring
<nacc> sarnold: --^ any advice?
<nacc> smoser: re: https://code.launchpad.net/~smoser/ubuntu/+source/ssh-import-id/+git/ssh-import-id/+merge/342231, did you upload tag it first?
<sarnold> nacc,rlink, cool, thanks
<nacc> sarnold: thanks, i figure your team has to pick that up, right?
<sarnold> nacc: right; whoever is on community on a given week will normally do it
<nacc> sarnold: yep, thanks
<sarnold> nacc: this week it's ratliff :) I don't know how she's doing on time for the day, so I can't promise anything
<ratliff> rlink, sarnold: I'm working on it now
<sarnold> cool! thanks ratliff :)
<rlink> nacc, sarnold, ratliff: Thank you.
<ratliff> rlink: thanks for providing the debdiff!
<rlink> ratliff:  No prob.  I provided the last Xenial one for xmltooling, too, so I think I got everything right on the first try this time.  ;-)
<ratliff> rlink: it looks good to me so far. do you have a way to test it if I put it in the security-proposed ppa?
<rlink> ratliff:  Yes, but not until tomorrow.
<sarnold> infinity: are webbrowser-app and mediascanner2.0 good candidates for the do-release-upgrade tool to remove on upgrading to 18.04 LTS? https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1756800
<ubottu> Launchpad bug 1756800 in ubuntu-release-upgrader (Ubuntu) "Failed to start AppArmor initialization with status=123/n/a" [Undecided,Confirmed]
<smoser> nacc: i did not push tag.
<infinity> sarnold: The release upgrader should offer to remove both as "obsolete", since they've been removed from the archive.
<infinity> sarnold: If they genuinely *break* something, and you want to force them off, the something broken by them should conflict and force them off.  Otherwise, users get a choice to keep old junk around.
<infinity> sarnold: Ahh, and now that I've read the bug, release-upgrader removing things won't magically remove conffiles any better than a conflict will.
<sarnold> infinity: hrm. On re-reading the bug it looks like it might be in part due to the packages being removed but not *purged*.
<sarnold> infinity: thanks. I guess the best we can do is sob along with the users :/
<infinity> sarnold: I think at least a versioned breaks (which is effectively a conflict, since there's no unbroken version in this case) is correct there.
<infinity> sarnold: And then, due to the fact that you now have a dpkg relationship that says "we're doing evil things here with those old packages", the apparmor maintainer scripts could thwack those conffiles.
<infinity> sarnold: It's not perfect, but it beats doing nothing.
<infinity> sarnold: Anyhow, I disagree that an upgrading tool should be working around this when it could be solved at the package level.
<sarnold> infinity: that scares me. I think you're right that it's probably better than nothing. But I'm still scared that fiddling with something like that this late in the cycle
<infinity> sarnold: It's... Not that scary?
<sarnold> infinity: it is to me :)
<sarnold> it's been five years since I last goofed around with handling conffiles in maintainer scripts, and that was all from one package :)
<sarnold> thanks infinity
<infinity> sarnold: As a side note, if we haven't already, we should move to a world where apparmor profiles live in /lib/apparmor, and /etc/apparmor is used for user overrides.
<infinity> sarnold: Which would sidestep this whole issue.
<sarnold> infinity: yeah .. that's part of some recent work john is doing. hysterical raisins across ubuntu, debian, suse, snap, libvirt, lxd, make the whole thing a right mess :/
<infinity> sarnold: One could also fix this current bug in apparmor proper by simply making it ignore #include statements that return ENOENT.
<infinity> sarnold: Seems entirely reasonable to do opportunistic includes rather than requiring them to exist.
<sarnold> we opted instead for #include_if_available or something similar to retain backward compatibility
<infinity> sarnold: (Which is, actually, what this profile was doing, since it's including directories, so any argument that "lack of files should be an error to avoid injection trajectories" or some such is BS :P)
<infinity> sarnold: I'm not sure how allowing ENOENT would break backward compat.  Can you honestly say with a straight face that anyone would rely on the behaviour "it won't load if the file isn't there" to perform some complex startup logic?
 * infinity shrugs.
<sarnold> if abstractions/base isn't there you're gonna have a bad time if the profiles load anyway
<infinity> sarnold: Okay, that's fair.  Maybe.  Except that comes with apparmor, so it's very much a self-foot-shooting issue if you have apparmor but not that bit.
<sarnold> infinity: yeah... it's just that there's cases where the profile should fail and cases where it shouldn't, so new behaviour gets a new name
<infinity> sarnold: Anyhow, if those two packages are the only ones with this obsolete-conffiles-doing-includes issue, magling/deleting the files is much easier than changing behaviour.
<sarnold> hrm. it would be nice to know if this is exhaustive list or not.
<infinity> sarnold: Check Contents.amd64 for xenial (and maybe trusty, if you're feeling bored) for anything that ships files in /etc/apparmor.d, grab (or install) all debs, grep for include (or other things known to break on remove-but-not-purge), profit?
<infinity> sarnold: I suppose the other middle road to the include issue could have been to make the behaviour different from <relative> and "absolute" includes, but maybe that would have been too magic.
<infinity> (Since I suspect this class of bug probably only exists for "absolute" usage)
<sarnold> infinity: I *think* that might have been raised as a possibility during discussion of the "include if exists" feature, but not selected ..
<sarnold> infinity: thanks for the tip on Contents.amd64.
<infinity> Fair enough.
#ubuntu-devel 2018-03-30
<Unit193> Something odd with the builders now?  I wouldn't expect https://launchpad.net/~xubuntu-dev/+archive/ubuntu/staging/+build/14510915 to fail, and if it were to fail I'd expect a log. (This is a retry.)
<Unit193> https://buildd.debian.org/status/package.php?p=xfce4-timer-plugin&suite=unstable
<flamendless> where is jml here?
<sarnold> Unit193: maybe give it another repoke
<nacc> smoser: ok, np
<Unit193> sarnold: Alrighty-o.
<Unit193> sarnold: That seems to have worked, though generally not in favor of 'retry until it works', that seems to have done it. :P
<sarnold> Unit193: great ;) the *timing* of the "retry" wasn't exactly random, but I wasn't confident of the end result :)
<Unit193> sarnold: So you're saying...The timing on the timer seemed on time for another issue?
 * Unit193 ducks.
 * sarnold swings and misses
<wgrant> Unit193: LP builds should be happy now, just had a bit of fun with one of our core routers.
<Unit193> wgrant: Ouch.  And indeed, thanks!
<alkisg> Hi, I'm trying 18.04 on a raspberry pi 2, and the 4.13 linux-raspi2 kernel doesn't boot, while 4.15 from proposed boots fine. Is it stuck in proposed? LP: #1757165
<ubottu> Launchpad bug 1757165 in Kernel SRU Workflow "linux-raspi2: 4.15.0-1005.6 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1757165
<alkisg> Also, NetworkManager doesn't manage the devices by default, because `/etc/netplan/01-network-manager-all.yaml` doesn't exist. Shouldn't that be shipped as a conffile instead of created by ubiquity or whatever? Or at least netplan should default to that if nm is installed...
<xnox> alai, maybe try #netplan? i think netplan is innert by default, which is the right thing for it to do.
<enyc> Hrrm,  OpenSSL  have put out key security-update in 1.1.0h ...   Is it worthwhile sync'ing bionic openssl to 1.1.0h-2 from debian very soon,  or  only treat as 'security fix' later ???
<jdstrand> sarnold: if you give me a list, I can do the packaging for the apparmor bug and do the Breaks as infinity suggests
<pjotr> Hello, I know you guys are extremely busy right now, but is there any chance that this GDebi bug will be fixed in time for Bionic:
<pjotr> https://bugs.launchpad.net/ubuntu/+source/gdebi/+bug/1756238
<ubottu> Launchpad bug 1756238 in gdebi (Ubuntu) "gdebi-gtk broken in 18.04 error: unable to read filedescriptor flags" [Critical,Confirmed]
<jbicha> pjotr: maybe the fix for LP: #1719746 is incomplete. I don't use gdebi though.
<ubottu> Launchpad bug 1719746 in gdebi (Ubuntu Artful) "gdebi 0.9.5.7+nmu1ubuntu3 broke being able to open .debs on default Ubuntu desktop" [High,Triaged] https://launchpad.net/bugs/1719746
<jbicha> I see that Ubuntu MATE includes gdebi by default so maybe ask them to look into the gdebi issues
<pjotr> jbicha: thanks for the tip, I'll try to contact them
<rlink> ratliff:  Tested the xmltooling packages from security-proposed.  Looks good.
<rlink> LP: #1752306
<ubottu> Launchpad bug 1752306 in xmltooling (Ubuntu Xenial) "Security bug in XMLTooling-C before 1.6.4 [CVE-2018-0489]" [Undecided,In progress] https://launchpad.net/bugs/1752306
#ubuntu-devel 2018-03-31
<tsimonq2> jbicha: Martin asked me and I bounced to you so they won't find much irt gdebi. :P
<Unit193> Laney: Hrm, so any chance of that dh backport happening?
<Unit193> darkxst: Congrats, DM.
<darkxst> Unit193, thanks!
<darkxst> Unit193, I probably should have applied a long time ago though!
<Unit193> DD sigs can be hard to come by!
<darkxst> tell me about it, will need another before I apply for DD
<Unit193> I might too, not sure yet.
<tsimonq2> darkxst: Congrats on DM!
<tsimonq2> I'll go for DM myself as soon as I get two keysigs at LFNW.
<tsimonq2> I'm going for two, idc. :P
 * tsimonq2 sees the channel name and moves to one of the -offtopics...
#ubuntu-devel 2018-04-01
<TJ-> where would bugs about the mini.iso instigated installer be reported against? Issue is that even when installing the most basic option something adds "vt.handof=7 to the boot options so when booting the installed system there's no log-in unless the user knows (how) to switch tty
<tsimonq2> TJ-: debian-installer I think.
<TJ-> tsimonq2: I'll poke around in the code... it's via GRUB's /etc/grub.d/10_linux - seems like it's doing the 'desktop' think not the 'server' by default
<tsimonq2> TJ-: OK
<TJ-> which comes from the setting in /etc/default/grub ... could be that's been set as the default shipped file. I best check
<TJ-> I suspect this is one that cjwatson will know how to solve in 2 seconds flat!
<TJ-> Bug #1697968
<ubottu> bug 1697968 in grub2 (Ubuntu) "$vt_handoff causes black screen even when nomodeset is used" [Medium,Triaged] https://launchpad.net/bugs/1697968
<cjwatson> Not been my bailiwick for a while, I'm afraid
<cjwatson> (There isn't a lot of code, but there are a lot of constraints and they fell out of my head some time ago)
<TJ-> cjwatson: I thought you were the d-i guru :)
<TJ-> seems to me the sane way to do it would be to have grub not add 'splash', have it added by a core GUI package/service that's installed for all GUIs
<cjwatson> TJ-: Not so much since https://www.chiark.greenend.org.uk/~cjwatson/blog/moving-on-but-not-too-far.html
<TJ-> cjwatson: oh yeah, I recall reading that originally! ha! Your reputation is too persistent
<TJ-> you'll have to send me a 'right to be forgotten' demand :)
#ubuntu-devel 2019-03-25
<IOhannes> i'm a Debian Developer and wonder whether there's a way for me to close bugs on launchpad a) without having a launchpad account and b) without going through debian/changelog (that is: for old bugs that have been fixed long ago, but have not been closed with an "LP: #XXXXX" stanza back then)
<IOhannes> and generally: how to interact with launchpad bugs without having an account
<cjwatson> IOhannes: "LP: #XXXXX" in the changelog will close bugs when the package is synced/merged into Ubuntu; but other than that, you must have a Launchpad account in order to make any kind of modification to data held by Launchpad.
<IOhannes> too bad
<IOhannes> cjwatson: but thanks anyhow
<cjwatson> yw
<cjwatson> (The changelog thing isn't really an exception; the bug change just gets attributed either to a bot account in the case of verbatim syncs, or the person who did the merge if there was manual merge work required.)
<IOhannes> would an LP account automatically grant me powers to close bugs?
<zyga> stgraber: hey, I came across this bug https://bugs.launchpad.net/snapd/+bug/1805182 -- I think it warrants some aid from foundations
<ubottu> Launchpad bug 1805182 in snapd "/tmp is sometime cleaned up after snaps are launched" [High,Triaged]
<cjwatson> IOhannes: Some kinds of status changes are restricted and the exact details of what's restricted may change, but at the moment if you have an account and can see the bug then you can close it, yes
<IOhannes> thx again
<stgraber> zyga: yeah, we've seen ocasional reports of this one from LXD users, maybe xnox has an idea what's going on with systemd
<juliank> $ sudo /snap/bin/apt --version
<juliank> apt 1.8.0 (amd64)
<juliank> Yes, I already installed a package with it, it's working fine
<juliank> hmm
<juliank> it seems the wrapper run the host apt, not the snap
<jdstrand> bdmurray: hey, fyi, I updated the description in bug #181112 based on my recollection of our conversation and reuploaded to bionic and cosmic. let me know if I need to do anything else to have it approved
<ubottu> Error: Launchpad bug 181112 could not be found
<jdstrand> bug #1811129
<ubottu> bug 1811129 in ufw (Ubuntu Cosmic) "update ufw to 0.36" [Undecided,In progress] https://launchpad.net/bugs/1811129
<bdmurray> jdstrand: I briefly reviewed the description and it seems fine. I'll look at the whole SRU tomorrow during my shift.
#ubuntu-devel 2019-03-26
<rbasak> cjwatson: ah, thanks. I did look for existing bugs but didn't spot that one.
<cjwatson> rbasak: Not convinced I found the only one, but \o/
<cjwatson> er I mean :shrug: or similar
<cjwatson> https://code.launchpad.net/~cjwatson/update-manager/changelog-source-version/+merge/365103 now anyway
<jdstrand> bdmurray: thanks! :)
<robert_ancell> bdmurray, do you know why the snapd-glib SRU packages are all stuck "Pending Publication"?
<robert_ancell> https://launchpad.net/ubuntu/+source/snapd-glib
<bdmurray> robert_ancell: they are over here https://launchpad.net/ubuntu/cosmic/+queue?queue_state=0&queue_text=
<bdmurray> in the New queue
<robert_ancell> oh, it's the -tests packages
<robert_ancell> bdmurray, I can blame you for those then :)
<bdmurray> robert_ancell: tjaalton seems more appropriate since he accepted it
<robert_ancell> bdmurray, you requested I add those :)
<bdmurray> well alright
#ubuntu-devel 2019-03-27
<doko> jbicha, willcooke: was the gtk2 demotion on your plate, or will it stay in main, and maybe for how long?
<willcooke> I don't know, I'd need to ask seb128 (who is on holiday) - didrocks, any ideas? ^
<didrocks> I didn't follow the gtk2 demotion, I guess that can wait for Monday as won't happen this cycle
<gpiccoli> Hi rbasak , we were discussing in private the absence of some dbg symbols from trusty packages - you even pointed to LP # 1465777
<rbasak> o/
<gpiccoli> Just for curiosity / full clarification, given that a dbg symbol package was built (like irqbalance example) and we can find the dbg pkg in the ppa builder
<gpiccoli> Can't we copy this ddeb to the regular place where ddebs live, in order to allow apt-get to download the package?
<gpiccoli> I think it makes sense for some packages, and only for the latest versions of them, of course...
<gpiccoli> In other words - is it feasible to do a manual copying of the dbg package to the right place?
<gpiccoli> rbasak ^
<gpiccoli> fabiomirmar, ^
<rbasak> There's probably a data integrity issue there. We'd want to be sure that the debug symbols package really does match the corresponding binaries.
<rbasak> The only way to be sure is if they actually came out of the same build.
<rbasak> Is that the case here?
<gpiccoli> exactly rbasak, it's the same build!
<gpiccoli> let me find the link
<gpiccoli> to provide an example
<gpiccoli> rbasak, https://launchpad.net/ubuntu/+source/irqbalance/1.0.6-2ubuntu0.14.04.4/+build/7896738
<gpiccoli> this package is present in trusty, though if we check [0], the dbg symbols pkg is not there.
<gpiccoli> [0] - http://ddebs.ubuntu.com/pool/main/i/irqbalance/
<gpiccoli> my idea: to move this .ddeb package to ddebs.ubuntu.com/pool in order we can "fix" the situation, at least for some packages as we found them. Not sure if it's super laborious, or if it's worthed heheh
<gpiccoli> Just want to understand the feasibility for that
<rbasak> From bug 1465777 I was under the impression that the missing ddebs were no longer available.
<ubottu> bug 1465777 in php-json (Ubuntu) "A subset of ddebs built during the Trusty cycle are missing" [Undecided,Won't fix] https://launchpad.net/bugs/1465777
<rbasak> This case appears to be different.
<rbasak> I'm not sure what's going on there.
<rbasak> Perhaps it's not a case of that bug, but something else.
<gpiccoli> oh, interesting rbasak
<coreycb> rbasak: hi there, if you have some time we have new versions of neutron in the unapproved queues for disco, cosmic and bionic with some very important patch fixes. these package versions can replace the current versions that are in -proposed.
<bdmurray> willcooke: I take your on comment on bug 1821415 to mean that there isn't some new hot replacement for pkexec, is that right?
<ubottu> bug 1821415 in policykit-1 (Ubuntu) "pkexec fails in a non-graphical environment" [Undecided,New] https://launchpad.net/bugs/1821415
<willcooke> bdmurray, correct, no new replacement
<willcooke> andyrock thinks he can fix it though
<bdmurray> that'd be helpful
<bdmurray> willcooke: Do you know what the status of systemd user sessions is?
<willcooke> bdmurray, AFAICR, not finished this cycle, will land early next cycle
<bdmurray> willcooke: Well as long as it happens sometime! ;-)
<willcooke> :))
<infinity> robert_ancell: Was there a master plan to make snapd-glib-tests in disco actually ship stuff (like the one you uploaded to cosmic)?
<robert_ancell> infinity, is the binary package empty?
<infinity> Very.
<robert_ancell> oops
<infinity> robert_ancell: http://paste.ubuntu.com/p/4Nh79khq6w/
<infinity> robert_ancell: Note the last three files that differ. :)
 * robert_ancell hastily fixes
<infinity> robert_ancell: Just confirming that the cosmic SRU is correct and it's disco that's buggy?
<infinity> robert_ancell: Before I go processing the cosmis stuff in NEW.
<robert_ancell> I'll just double check
<robert_ancell> infinity, the cosmic package seems correct here.
<infinity> robert_ancell: Alrighty.  So, please fix disco.  Kthx.
<robert_ancell> ah, didn't bzr add the .install file
<infinity> And two others, I'd assume.
<infinity> debian/tests/*
<robert_ancell> file(s)
<robert_ancell> yes
<infinity> bdmurray: Alright, snapd-glib/cosmic NEW reviewed and accepted, and exposed an icky bug in snapd-glib/disco. :)
#ubuntu-devel 2019-03-28
<tjaalton> RAOF: I've uploaded a new version of intel-mediasdk with d/copyright fixed and using a packaged googletest. ipp can't be split though, it's only a subset of the real thing
<RAOF> tjaalton: ta. Ipp was the wishlistiest wishlist bit.
<tjaalton> ok ;)
<RAOF> Is anything using the mediasdk yet? ð
<tjaalton> I have the compute runtime (NEO opencl) building now, I'll push the rest to the queue this week
<RAOF> Ah, rad.
<tjaalton> eventually will, it'll allow building opensource shaders for the media driver
<tjaalton> so strictly for universe for now
<tjaalton> all of this
<RAOF> Neo OpenCL? Is this a third Intel OpenCL implementation?
<tjaalton> yeah
<tjaalton> what they'll actually support
<RAOF> Is this the one that'll have SYCL support?
<tjaalton> probably
<RAOF> Heh
<coreycb> hi, i'm not seeing sil2100 but if someone else is on SRU rota today, we have new versions of neutron in the unapproved queues for disco, cosmic and bionic with some very important patch fixes. these package versions can replace the current versions that are in -proposed.
<coreycb> those are needed by a bootstack customer
<rbasak> cpaelzer: what's the test plan for the Posgres MRE SRUs? I can't find one documented anywhere.
<rbasak> cpaelzer: or does it meet the criteria listed under https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases?
<cpaelzer> rbasak: this is from before the time of being listed there
<cpaelzer> rbasak: but we got passed the procedure which essentially is "it has a vast assortment of build time and related autopkgtests - make sure those pass or fails are understood"
<cpaelzer> this is how pitti described and handled it (o/ pitti)
<cpaelzer> and this is how we do it since
<cpaelzer> TBH all the upgrade errors we found this time were catched by exactly this assortment of autopkgtests
<pitti> o/ cpaelzer
<rbasak> cpaelzer: thanks. That meets the criteria then. We should probably document that in the template.
<pitti> we used to have a special exception for postgresql, and then generalized the policy so that it (and similar packages) falls under it
<pitti> https://wiki.ubuntu.com/StableReleaseUpdates?action=diff&rev2=232&rev1=231
<pitti> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions?action=diff&rev2=60&rev1=59 was the former explicit list (including psql)
 * juliank even used microrelease exceptions for apt SRUs. When I collected a bunch of apt bug fixes upstream (without individual LP bugs) that all had autopkgtests :)
<Eickmeyer> Anybody know who I can ping about a UX bug in Ubiquity? (bug 1822134)
<ubottu> bug 1822134 in ubiquity-slideshow-ubuntu (Ubuntu) "Ubuntu Studio Installation - Black Text on Dark Gray" [Undecided,New] https://launchpad.net/bugs/1822134
<Eickmeyer> Actually, looks like cyphermox might be my man. ^
<cyphermox> oh that's cute
<cyphermox> Eickmeyer: you want to make the changes in ubiquity-slideshow-ubuntu?
<Eickmeyer> cyphermox: Would that be me just pulling the repo, making the change, then setting-up a PR?
<cyphermox> yup
<Eickmeyer> Okay, I'll work on it.
<Eickmeyer> cyphermox: Though, it appears right when Ubiquity opens, so not sure it's just the slideshow. I'll investigate.
<cyphermox> ah
<cyphermox> then yeah, it wouldn't be the slideshow
<cyphermox> could you add a screenshot to the bug? I'll help you debug this and then I can sponsor a fix
<Eickmeyer> I'll see what I can do. Studio's ISO doesn't play well in a VM.
<cyphermox> ah, in that case I'll just download the image and run it on a spare system somewhere
<Eickmeyer> cyphermox: I almost have something usable.
<Eickmeyer> cyphermox: I have a screenshot in the bug report now.
<cyphermox> yeah ok, that's indeed theming and not at all the slideshow
<handsome_feng> Hi, cyphermox, let me join your conversation too, could you have a look at https://code.launchpad.net/~feng-kylin/ubiquity-slideshow-ubuntu/updateVersionNum/+merge/364663 when you are free, :)
 * Eickmeyer will probably update Studio's slideshow for 19.10. Too much going on this time around.
<Eickmeyer> cyphermox: Are we talking the GTK theme or Ubiquity's usage of it?
<cyphermox> Eickmeyer: a little bit of both, probably
<Eickmeyer> If we can adapt Ubiquity to use white text, then that should solve the issue.
<cyphermox> sure, but it already works for the other flavours
<cyphermox> IIRC it's already white text
<infinity> powersj: I see no ubuntu-server beta ISO testing.  Coming in late, or someone forgot the release schedule (and isn't subscribed to devel-announce)?
<powersj> infinity, just haven't published results
<infinity> I thought we'd talked about this. :P
<Eickmeyer> cyphermox: Then, are we looking at a bug in the theme itself?
<cyphermox> Eickmeyer: I think so; but I'm unsure what exactly
<Eickmeyer> Okay. Should I add materia-gtk-theme to the bug report?
<cyphermox> I'm not really familiar with theming; what I can tell you is that this is an issue with the GtkLabel being in a 'menubar', probably
<infinity> tjaalton: Can you triage and reassign https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1822026 to where it belongs (pretty sure it's not ubiquity :P)
<ubottu> Launchpad bug 1822026 in ubiquity (Ubuntu) "Live USB freezes or cannot complete install when nouveau driver is loaded" [Undecided,New]
<cyphermox> I see your menubars already are grey but they do have white text
<Eickmeyer> Intersting.
<cyphermox> Eickmeyer: please ask in #ubuntu-desktop; someone there might be in a position to help you out in how to debug this / compare with the other themes, unfortunately I don't know enough how this works
<Eickmeyer> cyphermox: Okay, will do.
<cyphermox> essentially right now I'm just guessing, but I know the grey background is because the section of that page in ubiquity is a 'menubar' class
<cyphermox> I don't know if / how much there is inheritance of styling for objects in other objects like in css for the gtk theming
<Eickmeyer> Okay.
<cyphermox> Eickmeyer: so; if there's evidence that it's an issue in ubiquity, then sure let's change it there, but right now I don't see what picks color for that particular GtkLabel; seems it's all about the theme, so I'd first look there
<Eickmeyer> Okay. I just pinged #ubuntu-desktop on the issue.
<tjaalton> infinity: likely the kernel..
<bdmurray> rbalint: I updated bug 1809920 but yes the second upgrade did not work which is as we suspected
<ubottu> bug 1809920 in update-manager (Ubuntu Xenial) "prompt to upgrade to 18.04 shows while upgrade to 16.04 is still in progress" [Medium,Confirmed] https://launchpad.net/bugs/1809920
<rbalint> bdmurray, good, then it is just annoying, not a deadly trap :-)
<bdmurray> rbalint: right!
#ubuntu-devel 2019-03-29
<tsimonq2> rbasak, bdmurray: Could I please get a second set of eyes here? bug 1804513
<ubottu> bug 1804513 in Mixxx "Cosmic: Mixxx 2.1.3 is not stable with Qt5" [Critical,Confirmed] https://launchpad.net/bugs/1804513
<tsimonq2> I'm unsure on the justification for the update, so I thought I'd check.
<wxl> the 2.1.x packages (not really qt5 compatible) have qt5 depends, so totally shot. the only way to make those usable is to change those to qt4 depends.
<wxl> the other option is to just use 2.2.x and qt5.
<wxl> sorry, i perked up when i saw mixxx. i haven't used it in a while, but that's lovely software.
<tsimonq2> Yeah, that's why I'm deferring to the SRU team. :)
<sarnold> does bug 1822024 need a FFE? I'm not sure what the next step for this bug ought to be, any advice welcomed :)
<ubottu> bug 1822024 in flatpak (Ubuntu) "Sync flatpak 1.2.3-2 (universe) from Debian unstable (main) for CVE-2019-10063" [Undecided,New] https://launchpad.net/bugs/1822024
<mwhudson> does anyone happen to know how fuse filesytems get automounted?
<sarnold> I could imagine some via /etc/fstab, some via systemd units, maybe some via udisks2? maybe some via filemanager things?
<mwhudson> yeah i think it's udisks2
<mwhudson> sarnold: https://github.com/storaged-project/udisks/blob/udisks-2.8.2/src/udiskslinuxfilesystem.c#L224-L243 <- lovely
<sarnold> umsdos.. well known, eh? :)
<sarnold> does linux still support that? :)
<sarnold> $ git grep umsdos
<sarnold> Documentation/ioctl/ioctl-number.txt:0x04       D2-DC   linux/umsdos_fs.h       Dead since 2.6.11, but don't reuse these.
<mwhudson> nice
<mwhudson> hmm actually i'm not sure that's the thing that causes the mounting to happen
<mwhudson> that might just be the presense of mount.ntfs and mount.exfat
<rbasak> tsimonq2: if it's really broken for all users then a major version bump would be acceptable on the basis that it would certainly make it less broken with no regression risk.
<rbasak> tsimonq2: however I don't see any such justification in that bug or in the linked bugs.
<rbasak> tsimonq2: AFAICT, the reason seems to be "we don't like it and don't want to support it"
<rbasak> tsimonq2: rather than any set of actually reported bugs that are causing a problem for existing users
<LocutusOfBorg> doko, general question... I see gcc is defining __FILE__ macro with the full path, do you know a way (with pre-defined macro) to have only the filename? looks like this feature is missing in gcc... am I correct?
<tsimonq2> rbasak: Yeah, that was my feeling, but I was borderline on it and wanted to confirm.
<tsimonq2> Thanks.
<rbasak> tsimonq2: yw. I commented on the bug but am struggling there now I think.
<rbasak> The reporter seems to be presupposing the answer, and seems to conflate his opinion and support policy with an SRU justification.
<rbasak> "How is the user impacted?" -> "bypassed all quality checks" etc.
<tsimonq2> Yeah.
<tsimonq2> I'll get in touch with Sebastinas, who pointed me at this bug.
<rbasak> Thanks!
<tsimonq2> Thank *you* :)
<rbasak> I think I'll refrain from posting again. I don't think I can be constructive any further.
<tsimonq2> Fair enough.
<rbasak> tsimonq2: if you can sort the bug out with an SRU justification though, I'll happily look again
<tsimonq2> Sounds good.
<rbasak> I'm confident you understand what is needed :)
<tsimonq2> Yeah, I'll re-review with his changes in mind.
<tsimonq2> My goal with these is to be understanding; I understand that upstream just wants to see their package made right, and I want to help them reach that goal, but we also have policy
<rbasak> Thanks.
<rbasak> It seems likely that our policy won't prevent him from fixing things up.
<tsimonq2> I agree.
<rbasak> But AFAICT it's only really possible if he understands our policy and works with us to demonstrate that he's meeting it, and that's what I'm not being successful with in the bug I don't think.
<rbasak> Or someone who understands SRU policy needs to dive in deep and do the work.
<tsimonq2> My goal at this point is going to be to ask more precise questions. Where I think I'm going to draw the line on this one is actually drafting the SRU paperwork; he has justification, we just need to answer the right questions here.
<rbasak> tsimonq2: on the Mixx bug: it's also behaviour changes, not just new bugs introduced.
<tsimonq2> rbasak: Right; I did allude to that when I said my point was to ask him to verbosely state that information.
<rbasak> tsimonq2: example: a user is all ready for a performance, runs an update, and then can't proceed with the performance due to UI changes.
<tsimonq2> Right.
<rbasak> OK - let's see what he comes back with.
<tsimonq2> Sounds good.
<sarnold> 99% [59 Sources store 0 B]
<sarnold> awww. somehow the two thousand-something PB/s part didn't get copied. :(
<tsimonq2> Woah :D
<sarnold> it never lasts long :)
<sarnold> though somehow I doubt that's because I was actually getting petabytes per second transfer :)
<tsimonq2> haha
<tsimonq2> Are LAN speeds even that fast?
<sarnold> the fastest I've heard of is 200gb/s.
<sarnold> I think I've seen 400gb/s on slidedecks before but that may still be in the future :)
<Unit193> sarnold: If you have a clock that slips a little, if you wait long enough between syncs you can fire off ntp during apt update/upgrade and it'll give you that same result (even better when the clock goes back to before when you started. :D )
<sarnold> Unit193: hahaha
<Unit193> Taking negative years to apt update is fantastic.
<ahasenack> any idea why I cannot add "bionic" and "cosmic" series to the samba task in this bug? https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1778322
<ubottu> Launchpad bug 1778322 in samba (Ubuntu) "gvfs-smb-browse can't browse samba/smb tree" [High,In progress]
<ahasenack> those values don't show up
<tribaal> Hi all! I just upgraded to the Dingo beta, and everything was absolutely smooth and is going great. Thanks a lot for all the hard work! That is all :P
<valorie> tribaal: no problems?
<valorie> I did my travel laptop and it was zero problems
<valorie> this one I'm typing on is next
<tribaal> valorie: exactly, not a single problem.
<valorie> excellent
<valorie> I hope for the same with this lappy
#ubuntu-devel 2019-03-30
<tinoco> rafaeldtinoco was removed by: rafaeldtinoco
#ubuntu-devel 2020-03-23
<alkisg> Hi all. Could someone be so kind and sync ltsp from unstable to focal? I uploaded a one-bug/security fix release to unstable, but I don't yet have rights to upload it to focal...
<Unit193> Ah, aka: https://github.com/ltsp/ltsp/commit/ecca725849f4653db06d625b4d9d903b7afb943b
<alkisg> Righto :)
<Unit193> alkisg is your LP username?
<alkisg> Yes
<Unit193> Done.
<alkisg> Thank you Unit193, have a great day!
<Unit193> You as well.
<tarzeau> what are the chances to get in hpx if it gets an ACCEPT from ftp-master into debian? https://repology.org/project/hpx/versions (it's important for HPC users)
<doko> tarzeau: file a FFe
<ginggs> FFe not needed for new packages https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_packages
<ginggs> tarzeau: i think you'll just need to file a sync request (or run requestsync)
<tarzeau> great infos, thanks.
<rbalint> doko, i've filed LP: #186854 , could you please take a look? i can add more of the template if needed
<ubottu> Launchpad bug 186854 in Deriver "ImagePDF file type confusing deriver?" [Undecided,Fix released] https://launchpad.net/bugs/186854
<rbalint> LP: #1868542
<ubottu> Launchpad bug 1868542 in libtest-simple-perl (Ubuntu) "[MIR] new dependencies of lintian" [Undecided,New] https://launchpad.net/bugs/1868542
<ddstreet> Laney unfortunately, i am able to reproduce the systemd failure using the main autopkgtest server, but when i test with my own autopkgtest setup, the tests pass :(
<ddstreet> rbalint do you have any idea what might be causing the systemd-upstream autopkgtest failures?  they all seem to hang right after/during installing the newly-built systemd packages
<rbalint> ddstreet, no, sorry, seems like an infra issue :-(
<ddstreet> yeah, unfortunately it does, it may need Laney or someone with access to the autopkgtest instances to debug :(
<ddstreet> for reference, here is the log from a run using my upstream ppa build on the main autopkgtest servers, that fails: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic-ddstreet-systemd-upstream/bionic/amd64/s/systemd/20200322_213630_1f1b6@/log.gz
<ddstreet> and a log with the same upstream ppa build, but on my own autopkgtest deployment, that passes: https://swift-proxy.bos01.canonistack.canonical.com:8080/v1/AUTH_c14f9cd6e857495990d3438d775fa4a9/autopkgtest-bionic-ddstreet-systemd-upstream/bionic/amd64/s/systemd/20200322_232851_fdf06@/log.gz
<gpiccoli> o/ bdmurray - I received an email about increase in libvirt crash reports after a release with a patch from me reached -updates, hence stopping phasing
<gpiccoli> It points a link with a chart, etc..but I cannot see any of those crash. I'd like to have access to data to try correlate those crashes with my (small and non-intrusive) patch, or discard the correlation
<gpiccoli> This is the link: https://errors.ubuntu.com/?release=Ubuntu%2018.04&package=libvirt&version=4.0.0-1ubuntu8.15&period=week
<ahasenack> cpaelzer: some assistance please? I'm failing to understand why dpkg-gensymbols wants me to add the 0ubuntu1 suffix to the symbols file: https://paste.ubuntu.com/p/GRrg7jvdcP/
<gpiccoli> I cannot open the crash reports though, it says I don't have permission. If you or anybody here can help me on this, I appreciate
<ahasenack> cpaelzer: and lintian says the binary deb has them, and complains about that:
<ahasenack> $ lintian -I --pedantic
<ahasenack> E: libcbor0.6: symbols-file-contains-current-version-with-debian-revision on symbol _cbor_alloc_multiple@Base and 230 others
<ahasenack> cpaelzer: d/libcbor0.6.symbols: https://paste.ubuntu.com/p/kvgprG3qQj/
<gpiccoli> [please ping my nick whenever talking back to me, I'll detach the channel! =) ]
<ahasenack> maybe it's related to old debhelper? The package is using 9, I intend to update it
<ddstreet> gpiccoli i have access to the error reports, i'll take a look
<Laney> ddstreet: feel free to file an RT to get access temporarily in order to let you look at it interactively there
<gpiccoli> Thanks a lot ddstreet =)
<Laney> 'infra issue' could mean a lot of things couldn't it
<gpiccoli> I'm not sure if cpaelzer highlights on libvirt, but I guess worth highlight him for awareness
<cpaelzer> ahasenack: reading ..
<cpaelzer> gpiccoli: I'm highlighting on it :-)
<cpaelzer> ahasenack: you are right not to add the ubuntu1 suffix
<cpaelzer> ahasenack: your file has "libcbor.so.0.6.0 libcbor0.6 #MINVER#"
<ahasenack> oh
<gpiccoli> hehe cool cpaelzer =)
<cpaelzer> but needs "libcbor.so.0.6 libcbor0.6 #MINVER#"
<ahasenack> it's soname, and package
<cpaelzer> ahasenack: the rest you can keep as-is
<ahasenack> got it
<ahasenack> thanks
<cpaelzer> ahasenack: did this have a symbols file before?
<ahasenack> yes
<cpaelzer> ahasenack: if yes could you keep all symbols that existed before at the version they were before?
<ahasenack> they were kept
<ahasenack> oh
<ahasenack> at 0.5.0 you mean
<cpaelzer> yes
<ahasenack> ok
<cpaelzer> that will give you a list of only a few that are added on 0.6.0
<cpaelzer> that helps dh_shlibs and such tools to make better dependencies
<cpaelzer> e.g. >= 0.5.0 if it only uses symbols out of that
<cpaelzer> now with you gpiccoli
<cpaelzer> gpiccoli: you have to wait for the data to load
<cpaelzer> (usually)
<ddstreet> gpiccoli in that error report i'm only seeing a small number of captured errors, and none of them are new; they've all been seen on previous versions of libvirt
<gpiccoli> exactly ddstreet, that was my impression too
<gpiccoli> Not related with the new versions
<gpiccoli> cpaelzer, it seems there are files I could get...but I don't have permissions
<ddstreet> i'll let bdmurray decide if they can be ignored when he gets in, but it seems like they probably can
<gpiccoli> nifty ddstreet, I hope so
<cpaelzer> this happens quite often on packages that are installed a lot and have services
<ddstreet> yeah, do ask him if you can have access to the error tracker, it's useful
<cpaelzer> service gets restarted and due to local config breakage an old error is crashing it (again)
<gpiccoli> oh, so it explains what happens cpaelzer, ty!
<cpaelzer> and I agree to ddstreet none of these look "new" like "added with your patch"
<gpiccoli> outstanding, thank you both for that! let's then discuss with bdmurray when he gets in =)
<cpaelzer> gpiccoli: I usually reply to the mail send it to bdmurray and explain why it can be ignored
<cpaelzer> with some more words than what we had here, but still similar in content
<cpaelzer> e.g. comparing the signatures seen with what the patch changed
<gpiccoli> cpaelzer, but I didn't feel comfortable in ignoring that without looking those reports
<cpaelzer> yep gpiccoli and reaching out was the right choice
<cpaelzer> thank you
<gpiccoli> thank you for the information Christian!
<ahasenack> cpaelzer: did you ping someone about the builders being sluggish?
<ahasenack> you mentioned dep8 before I think, but I'm noticing something wrong with the builders too
<ahasenack> I just pinged ops
<cpaelzer> ahasenack: I had no issue with builders yet
<cpaelzer> ahasenack: just a long test queue
<cpaelzer> and it wasn't slow, just a long queue
<cpaelzer> something big must have appeared in focal
<ahasenack> I'm always confused by this statement in the debian policy: "The package build should be as verbose as reasonably possible,"
<ahasenack> does that mean d/rules should always have DH_VERBOSE=1?
<ahasenack> rbasak: any opinion on that? ^
<cjwatson> I don't think that's the usual interpretation
<cjwatson> It generally means showing compiler commands and such
<cjwatson> It's not necessarily an unreasonable interpretation, but it's not the usual one
<ahasenack> ok, thanks
<rbasak> ahasenack: if someone said to me that policy means that DH_VERBOSE=1 be set in all debian/rules files, I'd argue that debhelper should have its default changed.
<rbasak> (if that were true)
<rbasak> So to me it doesn't follow that we should set that in the usual case.
<rbasak> !dmb-ping
<ubottu> ddstreet, rafaeldtinoco, rbasak, sil2100, slashd, teward, tsimonq2: DMB ping
<GunnarHj> Hi bdmurray, There are a few verified SRU proposals at bug #1844853. There are also some minor autopkgtest failures, but our suggestion is to disregard those. My question is if the autopkgtest failures cause those items to not show up as 'ready to be considered' to the SRU team.
<ubottu> bug 1844853 in glib2.0 (Ubuntu Eoan) "IBus no longer works in Qt applications after upgrade" [High,Fix committed] https://launchpad.net/bugs/1844853
<bdmurray> GunnarHj: On the pending SRU report you can see the regressions are called out there, so yes we consider them not ready. https://people.canonical.com/~ubuntu-archive/pending-sru.html
<bdmurray> Any suggestion about disregarding tests should be made in one of the SRU bugs
<GunnarHj> bdmurray: But we have already done that. In comment #30 and #31 at bug #1844853 (where the verification was documented) I referred to L_aney's suggestions to disregard them. So now I'm trying to call the SRU team's attention to it. :)
<ubottu> bug 1844853 in glib2.0 (Ubuntu Eoan) "IBus no longer works in Qt applications after upgrade" [High,Fix committed] https://launchpad.net/bugs/1844853
<LocutusOfBorg> GunnarHj, did you ask me about unicode-data?
<LocutusOfBorg> I remember somebody asking, but forgot who
<LocutusOfBorg> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3989/+packages
<LocutusOfBorg> in case, please upload there ^^
<GunnarHj> LocutusOfBorg: Nope. I just made a note on the bug that I think it's a good idea.
<bdmurray> GunnarHj: got it
<GunnarHj> bdmurray: Do you possibly have time to look at it?
<bdmurray> GunnarHj: everything but Eoan based on L_aney's comment right?
<GunnarHj> bdmurray: eoan also, see https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1850932/comments/12 (but let's drop disco...)
<ubottu> Launchpad bug 1850932 in glib2.0 (Ubuntu Eoan) "[SRU] Backport 2.62.4-1" [Undecided,Fix committed]
<LocutusOfBorg> mmm strange, I can't find anymore the log here
<LocutusOfBorg> GunnarHj, I meant, ibus merge, that was depending on unicode-data
<bdmurray> GunnarHj: Yes, I can have a look shortly
<GunnarHj> LocutusOfBorg: That's correct. I have a proposed upload at https://launchpad.net/~gunnarhj/+archive/ubuntu/ibus, and if you can take that into account it would be great.
<GunnarHj> bdmurray: Great, TIA!
<LocutusOfBorg> uploaded thanks
<LocutusOfBorg> will go in as soon and if release team acks the unicode transition
<GunnarHj> LocutusOfBorg: Nice!
#ubuntu-devel 2020-03-24
<alkisg> Hi, I'd like to help in getting the patch in https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/1867908 accepted for Focal, how can I help? Send it as a debdiff instead of a .patch?
<ubottu> Launchpad bug 1867908 in wpasupplicant (Ubuntu) "Patch for MAC randomization" [Undecided,New]
<sarnold> alkisg: I can't promise anything, but a tested debdiff, and descriptions of how to test, would probably help, yes
<alkisg> sarnold: thank you, I will try to do that later on today
<alkisg> sarnold: I uploaded a merge request for LP bug #1867908, and I've tested the generated .deb package for four wifi adapters that I had, and it solved the issue for all of them. If/when you have time, please have a look, thank you!
<ubottu> Launchpad bug 1867908 in wpasupplicant (Ubuntu) "Patch for MAC randomization" [Undecided,New] https://launchpad.net/bugs/1867908
<seb128> xnox, hey, you hacked on casper/plymouth before, do you maybe have debugging hint you can share on bug #1867909 ?
<ubottu> bug 1867909 in plymouth (Ubuntu) "plymouth spinner can not show the messages after installation." [Medium,Confirmed] https://launchpad.net/bugs/1867909
<rbasak> bryce: here's the MP: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/381116
<bryce> rbasak, thanks
<doko> tjaalton: dogtag-pki is missing build-deps, trying to download stuff during the build
<tjaalton> doko: yes, somehow it wasn't an issue on debian, but -1u1 fixes it
<ahasenack> hi, some imput please. I was tasked with adding "tests" to a package that is going through a MIR (libfido2). The package has regression tests, but they are only enabled in a debug build. So I added this as DEP8: https://paste.ubuntu.com/p/ns5WzVcCnH/
<ahasenack> I do a build with debug enabled, which is enough to run the tests. To be sure, I do another run, where I patch a test to fail, and then expect the test run to fail, that way I'm sure the tests were being run
<ahasenack> when they pass, they are invisible
<ahasenack> now, I could have done the same thing in a dh_auto_test override in d/rules
<ahasenack> what do you think is better?
<ahasenack> sarnold: ^
<doko> tjaalton: debian buildds have network access
<ahasenack> this is the good dep8 output: https://pastebin.ubuntu.com/p/KQqcfYPtFv/
<ahasenack> this is when the expected failure doesn't happen: https://pastebin.ubuntu.com/p/JqttQZCSrN/
<sarnold> ahasenack: "Expected regression test failure did not happen", nice
<tjaalton> doko: huh, ok
<ahasenack> sarnold: I commented out the patch on that run
<ahasenack> the patch that introduced the failure
<ahasenack> for srus, I generally feel that a build-time test is more effective, as excuses will be looked at much later after the package was built, once the sru is accepted
<sarnold> ahasenack: it's not the easiest thing to try to convey that something should have failed, but it didn't fail, and that's a failure :)
<sarnold> ahasenack: but this does a good job of it, well done
<ahasenack> thanks
<ahasenack> the messaging in the good case should be better, after all, anyone looking will see a core dump, and go wtf
<ahasenack> why did this pass
<sarnold> ahasenack: I don't know what the dh_auto_test override would look like, but this looks nice to me
<ahasenack> it would be similar. I would create an empty directory, cd into it, invoke the build with the debug parameter
<ahasenack> might use sed instead of a patch to change the source for the expected failure case, and do it again
<ahasenack> and I think it would be easier for the security team, since you usually can't use the public dep8 infrastructure to test packages
<ahasenack> so if you see a failure in your private ppa, that's immediate
<sarnold> oh, right, so .. that'd be double the build time, roughly, but provide 'instant' feedback?
<ahasenack> 3 times
<ahasenack> the real build, then build 1 for the good case, build 2 for the bad case
<ahasenack> all 3 took about 5min on my laptop
<sarnold> oh right
<ahasenack> together
<sarnold> wow, that's a lot better than I feared
<sarnold> (same as the autopkgtest, I expected that runtime to be worse too)
<ahasenack> well, 5min was with dep8, and in my dep8 run i was also building the package itself
<ahasenack> I can experiment without throwing this away
<Laney> ahasenack: The best autopkgtests are supposed to test the artifacts that users will run; building something and then testing that thing is not really ideal in that respect
<Laney> If you can build the tests and then convince them to run against the system's stuff, ...
<ahasenack> Laney: agreed, I have seen dep8 tests being just unit tests, and wondered why they were never run at build time
<ahasenack> turns out some are, and again as dep8. I think the latter is to check interactions with other packages in the system, that were not there at build time (different versions?)
<Laney> I guess you can summarise it as "is the package in the archive still working properly?" - you should be trying to write autopkgtests which answer that question IMO
<Laney> build-time tests are: is that thing I just built something which works properly?
<ahasenack> sarnold: ok, now it's at build time
<ahasenack> sarnold: https://paste.ubuntu.com/p/gnP7FFRSqp/ <-- when the injected failure did not happen
<ahasenack> https://paste.ubuntu.com/p/PYWSksqBXC/ <-- when it happened and was caught
<ahasenack> for both cases, scroll to the bottom
<ahasenack> actually, for the good case, go to line 4925: SUCCESS, the expected failure happened.
<ahasenack> easier to find
<ahasenack> I'll add some more verbosity and call it good, and submit an MP
<sarnold> ahasenack: very nice, thanks!
<doko> rafaeldtinoco: you merged kmod to suppress warnings, however these still show up in every autopkg tests. could you have a look? see https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1864992
<ubottu> Launchpad bug 1864992 in kmod (Ubuntu Focal) "depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin'" [Medium,New]
<doko> sforshee: ^^^
<doko> so why didn't that help?
<rafaeldtinoco> doko: will check
<rafaeldtinoco> doko: https://git.launchpad.net/~rafaeldtinoco/ubuntu/+source/kmod/commit/?id=d08be3cad6af9e1d414af1aed7cdaa158f43773c
<rafaeldtinoco> this is the fix
<rafaeldtinoco> -proposed for bionic and eoan
<doko> but not working in focal
<rafaeldtinoco> hum. ok]
<rafaeldtinoco> let me fix it
<doko> e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/d/doit/20200323_182614_c1613@/log.gz
<rafaeldtinoco> doko: alright, ill push a fix in a few
<rafaeldtinoco> focal is still applying that patch, I missed that before the sru
<doko> so maybe also merge from debian
<rafaeldtinoco> there was a fight about this fix and we decided to drop that change while they decided
<rafaeldtinoco> lets see if they got that sorted out
<rafaeldtinoco> ah great they dropped it
<rafaeldtinoco> doko: kmod gets updated after linux-image and thats why there is still errors there. you can see kmod being updated *after* The kernel gets updated
<rafaeldtinoco> so you would have to wait for the cloud images to get kmod updated
<rafaeldtinoco> paride: ^
<rafaeldtinoco> paride: as you opened this bug.. just to make sure we get kmod updated in cloud images
<rafaeldtinoco> orelse kernel updates might take end users crazy with those libkmod error messages
<rafaeldtinoco> (if kernel is updated before kmod)
<LocutusOfBorg> rbalint, hello kodi* syncs?
<rbalint> they would just drop the delta
<rbalint> LocutusOfBorg where it mattered i've already synced
#ubuntu-devel 2020-03-25
<paride> thanks rafaeldtinoco
<Unit193> kanashiro: FWIW, I just got an email that my "upload" is stuck because ruby-zip is still stuck in -proposed.
<xnox> seb128:  added debugging tips on https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1865161
<ubottu> Launchpad bug 1865161 in casper (Ubuntu Focal) "Written "press return to shutdown the computer" does not appear." [Critical,Confirmed]
<seb128> xnox, thx
<kanashiro> Unit193, yes, I think ruby-zip is the last package needing a fix
<AsciiWolf> kenvandine, I have recently added some details to https://bugs.launchpad.net/snap-store/+bug/1866998 about how it could be fixed... not sure if you got an email about it (you don't seem to be subscribed to the bug, however you are assigned to it)
<ubottu> Launchpad bug 1866998 in snap-store "Snap Store snap can be uninstalled using Snap Store" [High,Triaged]
<caravena> Hello users of Ubuntu (:
<caravena> I'm bug with browser
<caravena> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1868999
<ubottu> Launchpad bug 1868999 in firefox (Ubuntu) "Characters in the web browser do not work" [Undecided,New]
<mantas-baltix> Hi, are any ubuntu developers online ? ;)
<kenvandine> AsciiWolf: i'm planning on fixing that along with the update to 3.36.1
<mantas-baltix> Could someone accept simple patch for console-setup, see bug #1863001
<ubottu> bug 1863001 in console-setup (Ubuntu) "[PATCH] Incorrect LAYOUT is set when choosing Lithuanian in dpkg-reconfigure keyboard-configuration and Ubiquity" [Undecided,Confirmed] https://launchpad.net/bugs/1863001
<seb128> xnox, plymouth/fsck integration does show for me in focal with spinner, I would be interested to know how you tested?
<seb128> xnox, the message handling is a bit buggy but it does display
<seb128> xnox, https://people.canonical.com/~seb128/plymouth/diskcheck.jpg
<xnox> seb128:  where is the message that 1 out 1 device check is in progress (XX% percent)?
<seb128> xnox, that's the "is a bit buggy" part :)
<xnox> seb128:  during fsck i should see at least 2 messages (one with progress %, one with key codes) simultaniously
<seb128> xnox, it looks like spinner doesn't handle multi-line messages correctly, which we will fix
<xnox> and during casper-md5check there whould be 3 messages simultaniously
<xnox> it is not a single message
<seb128> xnox, but that's a different bug from "doesn't has itnegration"
<xnox> it is a separate status message
<seb128> right
<seb128> that's a bug, I confirm and we will fix
<seb128> but you report was not about the message being buggy, but about the integration being missing
<seb128> so I wonder if you hit another problem maybe?
<xnox> which is handled specially, i.e. keycode ones, updates the keycode line; status updates the status message; and the fsck one updates the % line; and update of any one of those three, doesn't wipe the other two
<seb128> xnox, right, again that's a confirmed problem and we can act on it
<seb128> xnox, now I'm wondering if when you said 'doesn't support fsckd progress messages ' you meant you had the same that I had on my screenshot
<xnox> seb128:  the original bug report was based on users saying "no progress output visible" and hence i filed a bug report. because the spinner theme, is not processing "fsck:*" messages and is not displaying 1 of 1 fsck in progress (10% done)
<xnox> seb128:  that screenshot is not showing the "fsck:" % complete.
<xnox> that is my bug report.
<seb128> xnox, again, I'm not discussing that
<seb128> k, thanks
<seb128> that's just what I wanted, make sure it's the same issue you were having, the description was not very specific
<xnox> you can do it from plymouth cmdline too, by simply sending 'fsck:sda1:10' as a message with plymouth client
<seb128> xnox, thanks
<xnox> seb128:  ok. I assumed "everyone" knows about 'fsck:LABEL:0..100' special status messages =)
<xnox> but maybe it is just me =(
<seb128> we don't have anyone knowing about plymouth in desktop at this point
<seb128> but we are learning now :p
<cpaelzer> rbasak: FYI the new importer code on diglett is able to import gpsd fine
<rbasak> \o/
<rbasak> Thank you for testing
<niedbalski> rbasak: sil2100 hey guys o/ , any chance for you to check sru(s) on https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=python-barbicanclient and https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=containerd ?
<niedbalski> thanks!
<ahasenack> hi, I managed to get an NBS binary in my own ppa, i.e., a previous source package was building bin:libcbor0, but I changed that to bin:libcbor0.6. Now bin:libcbor0 is lingering there. How can I delete it?
<ahasenack> maybe best asked in #launchpad
<rbasak> niedbalski: I'm occupied right now, but I'll try and look in an hour or two. I'm not sure I'll get to it though.
<niedbalski> rbasak: thank you, robie. I appreciate it.
<cpaelzer> rbasak: what is the rule on MPs that are "not for us" do we want/need to make anyone else aware of https://code.launchpad.net/~alkisg/ubuntu/+source/wpa/+git/wpa/+merge/381089 ?
<rbasak> alkisg: ^
<cpaelzer> well he opened it
<rbasak> Thank you for the MP, but please note that the git workflow is still experimental and currently won't automatically end up on any review queue
<cpaelzer> the question is who to target with it
<cpaelzer> ah yeah, you were about to write something :-)
 * rbasak has adjusted the bug
<rafaeldtinoco> rbasak: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1866119
<ubottu> Launchpad bug 1866119 in pacemaker (Ubuntu Bionic) "[bionic] fence_scsi not working properly with Pacemaker 1.1.18-2ubuntu1.1" [Undecided,In progress]
<rafaeldtinoco> rbasak: https://bugs.launchpad.net/ubuntu/+source/fence-agents/+bug/1865523
<ubottu> Launchpad bug 1865523 in fence-agents (Ubuntu Bionic) "[bionic] fence_scsi not working properly with Pacemaker 1.1.18-2ubuntu1.1" [Medium,In progress]
<rafaeldtinoco> those 2 for bionic
<rafaeldtinoco> thanks for this, pls ping me if you need info
<doko> tkamppeter: please could you have a look at https://launchpadlibrarian.net/470639931/buildlog_ubuntu-focal-amd64.ppl_1%3A1.2-7build1_BUILDING.txt.gz ?  ghostscript error. Debian has a newer upstream
<doko> tkamppeter: and if you update, please re-instate building with -O2 on ppc64el
<coreycb> xnox: can I get your opinion on something? upstream pyscss and django-pyscss were lacking maintenance so have been forked upstream to pyscss2 and django-pyscss2. would require new source package or if we could just re-use the existing one? reverse-depends are minimal to update to the new binary package.
<coreycb> (sorry that question doesn't read well)
<xnox> coreycb:  did they break the api/abi/classes?
<xnox> coreycb:  if yes, you will need new binary packages, you can use the existing source package, but then all of our bug trackers and CVE trackers will be off
<xnox> coreycb:  it's best to use a new source and binary package name
<xnox> and remove the other one.
<coreycb> xnox: ok so new source either way would be your suggestion regardless of api/abi/class breakage.
<coreycb> xnox: makes sense, thanks
<xnox> yeah, unfortunately
<xnox> it should be quick to review/accept.
<xnox> i.e. i do new source package for each new boost update
<kanashiro> Unit193, I think I have a fix for ruby-zip in s390x, I'll submit a patch soon
<alkisg> cpaelzer, rbasak, hi, the debian maintainer committed the fix for lp bug #1867908 in unstable, and suggests a sync from debian; I don't know how I can help there, but I guess my merge request isn't appropriate now; if you think I can somehow help, tell me how
<ubottu> Error: Could not gather data from Launchpad for bug #1867908 (https://launchpad.net/bugs/1867908). The error has been logged
<cpaelzer> well, wpa is mostly under the desktop teams watch
<cpaelzer> recent upload were mostly security fixes but still it would be desktop
<cpaelzer> lets tag is for them to be more visible
<rbasak> Any uploader should be able to review/sponsor this though
<rbasak> If I have time today I'll take a look.
<seb128> sil2100, ckb langpacks failed upload,
<seb128> The signer of this package is lacking the upload rights for the source package, component or package set in question.
<cpaelzer> rbasak: but you know how easy it is to sponsor a package you never changed before
<seb128> sil2100, is that a new language that needs to be added to a set?
<rbasak> cpaelzer: this looks like a cherry-pick for a bug fix. Those ones should be fine?
<cpaelzer> oh is it just that?
<sil2100> seb128: yeah, see my message on -release
<sil2100> seb128: I knew and re-uploaded a while ago
<sil2100> All good now
<sil2100> seb128: btw. is it possible for me to get those e-mails as well somehow?
<seb128> sil2100, k
<oSoMoN> juliank, I could use your help with an apt problem: IÂ have snapcraft.yaml part definition that runs "apt download 'language-pack-gnome-*-base'" in its override-pull phase, and it's working in my local tests (downloading all the packages matching the wildcard expression), but it's silently failing on an upstream CI system (return code 100), and IÂ don't know why
<oSoMoN> how can IÂ instruct apt to be more verbose about what's not working?
<oSoMoN> I've tried "apt -o Debug::pkgAcquire::Worker=true download 'language-pack-gnome-*-base'", but no luck
<tkamppeter> doko, which package is that which does not build?
<tkamppeter> doko, current Ghostscript in focal is 9.50 is there a known bug in 9.50 which makes this build fail and 9.52 (current of Debian) would make it succeed?
<rbasak> niedbalski: for next time, it would help me review quicker if you included dep3 headers like Origin:
<tkamppeter> Would this rectify a FFe for Ghostscript?
<juliank> oSoMoN: so that's running on bionic, then i guess
<oSoMoN> yes
<juliank> oSoMoN: because in eoan, or focal, that would not be a valid package name :)
<rbasak> niedbalski: in bug 1867676, could you flesh out the impact statement please? I don't understand why the code not falling back into the legacy mode would cause a problem. What's the actual use case that's a problem here?
<ubottu> bug 1867676 in python-barbicanclient (Ubuntu Bionic) "Fetching by secret container doesn't raises 404 exception" [High,Triaged] https://launchpad.net/bugs/1867676
<juliank> oSoMoN: but pkgacquire::worker should give you some information at least, debug::acquire::http maybe more
<rbasak> niedbalski: and Regression Potential needs to consider what areas of testing would find a regression if there is one please. See https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<oSoMoN> juliank, it doesn't. all IÂ get is:Â https://paste.ubuntu.com/p/cJjdyYPBJg/
<doko> tkamppeter: the package name is seen in the URL ;p
<tkamppeter> doko, is it "ppl"
<juliank> oSoMoN: now that's useful
<juliank> Handler silently failed
<niedbalski> rbasak: ack, reviewing that section
<tkamppeter> doko, I have located it now.
<rbasak> niedbalski: thanks. I commented in the bug so my request wouldn't get lost.
<tkamppeter> doko, current Ghostscript in focal is 9.50. Is there a known bug in 9.50 which makes ppl's build fail and 9.52 (current of Debian) would make it succeed?
<rbasak> niedbalski: it's the same with bug 1867398, if you could fix that too please.
<ubottu> bug 1867398 in containerd (Ubuntu Bionic) "[Regression] unsupported protocol scheme" [Undecided,New] https://launchpad.net/bugs/1867398
<doko> tkamppeter: I don't know
<rbasak> niedbalski: since during SRU review I'm trying to weigh the benefit of making the change vs. the risk of making it, I really need to understand the user story that is broken.
<rbasak> I hope that makes sense. If it's not clear what I'm after, happy to chat more.
<oSoMoN> juliank, that doesn't sound very helpful, as an error message. any clue how iÂ can debug further?
<niedbalski> rbasak: i undertsand, i think is contained in different pieces, will make sure to organize the impact section so you can clearly understand it.
<rbasak> niedbalski: thanks! Same for regression potential for containerd please.
<juliank> oSoMoN: it means that DoDownload() returned false w/o setting an errorr
<juliank> oSoMoN: now I'm afraid the only way to go further is to run gdb
<juliank> and see where it returns
<juliank> because it means we are not logging an error
<juliank> Maybe handler silently failed should be renamed to "The command implementation returned a failure, but did not produce any error messages"
<tkamppeter> doko, the update of Ghostscript to versions 9.51 and 9.52 came both after our FFFFF therefore Focal has version 9.50. And I think an FFe to update to 9.52 at this time for building the documentation of a Universe package is too much.
<oSoMoN> juliank, not an option, this is on a CI system I don't control, and it's working in my local tests
<juliank> oSoMoN: Well, you gotta figure out the gdb commands then and run it non-interactively :)
<doko> tkamppeter: it's a failing autopkg test blocking a package in main
<juliank> oSoMoN: also try -o APT::Get::Print-URIs=1 (or I guess --print-uris) to see if it gets that far, maybe
<tkamppeter> doko, as the problem happens only on amd64 and not on the other platforms there is perhaps a probability that repeating this build could pass. Have you already tried this?
<rbasak> rafaeldtinoco: fence-agents looks very non-trivial :-/
<rafaeldtinoco> rbasak: yep, it is
<rafaeldtinoco> rbasak: if you go through merge request comments
<rafaeldtinoco> it will be more clear I suppose
<rbasak> Thanks
<doko> tkamppeter: yes
<tkamppeter> Could you perhaps run this test locally to find out which file gets fed into Ghostscript and which Ghostscript command line gets called? With this I could report an upstream bug.
<tkamppeter> doko, ^
<rbasak> rafaeldtinoco: rather than get into it now, I'm going to set aside at least a couple of hours for this.
<rbasak> (which won't be today)
<zyga> hey
<zyga> who can I talk to about  azure.archive.ubuntu.com
<zyga> it's quite unreliable
<zyga> (from github actions)
<rafaeldtinoco> rbasak: no problem!
<rafaeldtinoco> rbasak: thanks for tackle it whenever u can!
<rafaeldtinoco> tacke/tackling
<Eickmeyer> rbalint, teward, xnox, juliank: We've been moved here by Laney.
<juliank> Oh I did not notice we were in #buuntu-release before
<juliank> :D
<juliank> sorry Laney
<rbalint> Eickmeyer, were not totally off-topic :-)
<Eickmeyer> rbalint: I agree, but Laney wants us here.
 * Laney resists arguing with you all :)
<rbalint> so my question/offer still stands, but i need to do a bit of preparations because git-remote-bzr is broken in focal and i use it for verification
<rbalint> Laney, at least on #ubuntu-release ;-)
<Eickmeyer> rbalint: Yeah, if you could do it, you'd do it faster. I converted a ton of stuff in ~ubuntustudio-dev, but that was about two years ago and the method I used is broken, hence the python errors.
<rbalint> Eickmeyer, ok, i wanted to convert a few other repos, too
<oSoMoN> juliank, "Handler silently failed" with --print-uris too
<juliank> nuce
<teward> *pours firewater on Laney for reasons*
<teward> :P
<cjwatson> zyga: I'd start with IS though I'm not completely sure they operate the cloud mirrors
<teward> s/firewater/liquid fire/
<zyga> thanks cjwatson
<Eickmeyer> juliank: So, basically, you have a commit in ubiquity that supposedly fixes the problem? It really comes down to the automatic deselection of entire metapackages based on one package which, in turn, autoremoves everything that metapackage depends on.
<juliank> Eickmeyer:   * When removing packages, also remove automatically installed packages that
<juliank>     are no longer required (LP: #1798992)
<ubottu> Launchpad bug 1798992 in ubiquity (Ubuntu Focal) "Fresh minimal desktop installation has packages pending autoremoval, pending updates" [High,Fix released] https://launchpad.net/bugs/1798992
<juliank> Eickmeyer: that was the last thing I did
<juliank> Eickmeyer: I
<juliank> Eickmeyer: I would not call that a fix, as it does not sound like what you want
<Eickmeyer> juliank: Not entirely..? I'd say it's related, however. Seems the problem happens at the end of the installation where anything that is deselected at the end of the installation is removed, but then it marks its metapackage for autoremoval, which then marks everything in the metapackage as "no longer needed" which gets removed during autoremoval.
<juliank> Anyhow, it's too late for today
<Eickmeyer> juliank: Understandable. FYI, I'm on the US West Coast, so it's still morning for me. :)
<arunpyasi> Hi everyone, is it mandatory to setup a local repository in order to install local packages as dependency for a new package ?
<arunpyasi> for sbuild
<jphilips> bdmurray: i had submitted a few patches to the manual tests. are you the one handling approving them?
<bdmurray> jphilips: I can
<jphilips> thanks
<jphilips> this is my branch https://code.launchpad.net/~philipz85/ubuntu-manual-tests/ubuntu-manual-tests
<jphilips> and guiverc also has some https://code.launchpad.net/~guiverc/ubuntu-manual-tests/ubuntu-manual-tests
<jphilips> i have another round of patches, but want to know that i'm doing it right before continuing :D
<bdmurray> jphilips: generally speaking it looks right but I have one question I'll ask in the MP
<bdmurray> jphilips: currently updating the test cases on the server is a manual process so I'd prefer to do them en masse if you have multiple updates
<jphilips> how can i make it easiest for you
<bdmurray> if you are making multiple changes to the same test number e.g. 1300_Install... just do them all at once
<seb128> xnox, do you know how to trigger the end of install/screen that should display the 'press a key to reboot" from a liveCD session without having to go through the install?
<jphilips> bdmurray: okay and then should i send it to launchpad or how should i pass it long to you
<bdmurray> jphilips: The Launchpad MP is the right way, my point was more about if I change 1300 on the server today and have to do it again tomorrow that wouldn't be efficient.
<bdmurray> jphilips: So if you have multiple changes do them all at once. ;-) Thanks for improving the quality of the test cases!
<jphilips> bdmurray: okay. i'll work on one complete file at a time.
<jphilips> i'm new to bzr, so is there a means for me to reset the branch to the master
<seb128> bdmurray, you might know as well about the question I just asked. Do you know how to trigger the end of install screen from a live session? the plymouth screen that shows the 'press a key to reboot now'
<bdmurray> seb128: I don't, sorry!
<seb128> bdmurray, no worry, thanks for replying anyway :)
<mwhudson> seb128: it's one of the casper bits that does that
<mwhudson> trying to find it
<seb128> mwhudson, thanks
<mwhudson> casper-stop
<cjwatson> arunpyasi: No, you can use --extra-package
<seb128> mwhudson, I tried to sudo casper-stop from the live session but it didn't seem to do anything ... should I also call reboot/close the session manually?
<Unit193> kanashiro: Nice!
<mwhudson> seb128: yeah i don't know what environment this expects to run in, probably one without the DE running though
<mwhudson> seb128: if you look in the file it has all sorts of reasons why it might exit without doing anything
<mwhudson> i also can't remember how it's hooked into the shutdown process
<seb128> mwhudson, I will poke around, thanks
<mwhudson> ah casper.service which is WantedBy=final.target
<seb128> debugging those plymouth integration problems is no fun :/
<mwhudson> yeah i can only imagine
<kanashiro> Unit193, uploaded version 2.0.0-2 to Debian and I'll request a sync as soon as it lands in unstable
<xnox> seb128:  every shutdown should show it
<xnox> seb128:  so just shutdown....
<xnox> but like can do systemctl start debug-shell
<xnox> to have a tty bash on tty9
<seb128> xnox, thx
<seb128> xnox, so I've no idea how to debug those problems, having someone from foundation (you?) poking would be nice
<seb128> xnox, the casper-md5check script on an installed system does lead to text being displayed on the plymouth screen (incorrect layout/just one  line) and I've no idea why that doesn't work  on the livecd
<xnox> fun
#ubuntu-devel 2020-03-26
<niedbalski> rbasak: fixed sru templates for lp #1867676 and lp #1867398, if you could please review them again. thank you!
<ubottu> Launchpad bug 1867676 in python-barbicanclient (Ubuntu Bionic) "Fetching by secret container doesn't raises 404 exception" [High,Triaged] https://launchpad.net/bugs/1867676
<ubottu> Launchpad bug 1867398 in containerd (Ubuntu Bionic) "[Regression] unsupported protocol scheme" [Undecided,New] https://launchpad.net/bugs/1867398
<tkamppeter> seb128, My libmtp printer fix made it all the way through to Debian and upstream:
<tkamppeter> https://github.com/libmtp/libmtp/issues/24
<tkamppeter> https://salsa.debian.org/debian/libmtp/-/commit/01797b1808e5e01115af10d30b557c14d85a8d1b
<rbalint> could an archive admin please unblock kodi? LP: #1868499
<ubottu> Launchpad bug 1868499 in kodi (Ubuntu) " Please remove s390x binaries for 2:18.5+dfsg1-0ubuntu3 with all reverse dependencies" [Undecided,New] https://launchpad.net/bugs/1868499
<mantas-baltix> Hi
<seb128> rbalint, you have more chance by using ubuntu-archive as an alias on #ubuntu-release, that should highlight the right people. But also it would help if the bug had the anylisis of the rdepends, the list and sign they got checked and they are fine to remove. I would be fine doing removal commands but I don't have the free cycles to do the investigation work atm
<ddstreet> it seems like git-remote-bzr has been removed from the archive since eoan, is there some other way to use remote bzr repos locally with git?
<rbasak> cpaelzer: uvtool> all sounds good to me. Thanks!
<rbasak> I'm also happy to deprecate --host-passthrough
<rbasak> With a warning, for eventual removal.
<cpaelzer> rbasak: great
<cpaelzer> rbasak: we have a bug and I have a card in the roadmpa for next cycle for myself already
<cpaelzer> I'll get back to it when it is the right time
<rbasak> ack
<oSoMoN> how do IÂ suggest/request that a package (jsunit) be added to a package set (mozilla) ?
<gQuigs> xnox: are you still running DNSSEC=yes?  would do you expect It to protect you against?  (https://github.com/systemd/systemd/issues/15158)
<oSoMoN> sil2100, being on the developer membership board, do you happen to know IÂ can suggest/request that a package (jsunit) be added to a package set (mozilla) ?
<oSoMoN> *how
<Laney> oSoMoN: email devel-permissions@lists.ubuntu.com with the request
<oSoMoN> Laney, thanks!
<xnox> gQuigs:  do you have resolved debug log from when the second authenitcated no query happens?
<gQuigs> xnox: no, but I could get that trivially.. (I think)
<xnox> gQuigs:  please
<xnox> gQuigs:  i wonder if badssl.com has like highjacked entries too
<gQuigs> xnox: added to GH issue..
<gQuigs> xnox: it does the right thing if it partially wrong (aka resolvectl query dnssec.fail
<gQuigs> dnssec.fail: resolve call failed: DNSSEC validation failed: no-signature) -   was wondering the same thing if there was a public reproducer for what I did...
<niedbalski> rbasak: or sil2100 i've updated again the affected series, description and regression potential sections of LP: #1867676
<ubottu> Launchpad bug 1867676 in python-barbicanclient (Ubuntu Bionic) "Fetching by secret container doesn't raises 404 exception" [High,Triaged] https://launchpad.net/bugs/1867676
<niedbalski> coreycb: rbasak in my opinion this should be a UCA dependency rather than archive. ^^
<sil2100> niedbalski: I guess since rbasak did the review, he's the best one to continue on it
<coreycb> niedbalski: anything that lives in uca starts in distro
<rbasak> coreycb: IIRC we hit this before. I wish I could remember the package to see what happened then.
<rbasak> coreycb: it makes sense in the general case that fixes go into the archive first. But here's a case where a change to a package is required only because of a UCA backport. I think, from the POV of the Ubuntu archive, it's not a bug at all?
<rbasak> Ah. Here we are: bug 1829823
<ubottu> bug 1829823 in Ubuntu Cloud Archive mitaka "libvirt-bin: during shutdown libvirt-bin is stopped before libvirt-guests causing hang" [High,Fix released] https://launchpad.net/bugs/1829823
<rbasak> In that case it was an obviously safe patch to an unused (in the archive) upstart script, so staging it was OK.
<rbasak> In this case there's more regression risk I think as it actually changes functionality.
<rbasak> So it's the same class of question, but the resolution last time is not necessarily appropriate here.
<coreycb> rbasak: niedbalski: ok I just re-read the bug. this releases >= rocky (ie. >= cosmic). we can look at fixing in the cloud archive only for those releases.
<coreycb> s/this/this affects/
<coreycb> rbasak: niedbalski: this is an odd case where we don't already have barbicanclient in the uca for rocky, stein, and train because the version in bionic satisfied the requirement for those uca's, so it's awkward.
<rbasak> I appreciate how it's awkward
<rbasak> I think the trade-off is awkwardness for UCA maintenance/tooling vs. an SRU (with its regression risk, etc) that isn't otherwise necessary or wanted for the Ubuntu archive itself
<coreycb> niedbalski: are you sure this doesn't affect queens (ie. bionic)? this fix is in the upstream stable/queens branch. the regression potential of backporting barbicanclient to 3 uca releases is much higher than backporting a single patch to the bionic package.
<rbasak> coreycb: much higher> how so? Wouldn't users be installing exactly the same patched package whichever way?
<rbasak> If you're worried about the binary, you could build the package on the oldest UCA release and copy it forward
<coreycb> rbasak: not in this case because we don't have the package in the UCA for rocky, stein, or train. the version in bionic satisfies the min required version for those releases.
<rbasak> coreycb: so instead of a bionic SRU you'd add it to rocky, and copy it forward (with binaries) to stein and train. The user experience in terms of which package build is being installed will be identical in all cases.
 * rbasak EODs
<niedbalski> coreycb: rbasak this is is bionic only; i don'
<niedbalski> coreycb: unless you think is worth doing what rbasak just mentioned ^^
<coreycb> niedbalski: I was trying to figure out if the bug exists in bionic. do you know if it does?
<niedbalski> coreycb: remember this bug triggers only with octavia-api, that's UCA only bionic base + a UCA release
<coreycb> niedbalski: maybe, or have we only seen it in that scenario
<niedbalski> coreycb: well, yes
<coreycb> niedbalski: it does look like the issue exists in bionic. since we can't test it with octavia on bionic we should be able to test it with the steps mentioned at: https://storyboard.openstack.org/#!/story/2003197
<arunpyasi> Hi everyone, is it mandatory to debuild -S in order to dput to PPA Launchpad ?
<tumbleweed> Launchpad only accepts source uploads, if that's what you're asking
<Unit193> arunpyasi: What is it that you don't like about that?
<niedbalski> coreycb: the sru is targeting bionic, what do you mean?
<coreycb> niedbalski: right but I think we need a case for getting it fixed in bionic
<arunpyasi> Unit193, not that I don't like but having an issue. I build packages via sbuild but if I dput it I get the following error :
<arunpyasi> https://pastebin.com/iqTJuexA
<mwhudson> niedbalski: sorry for not getting to that containerd bug, i'm glad you got it uploaded
<mwhudson> niedbalski: this is fixed upstream, right? so if i upload 1.3.4 we won't lose the fix?
<mwhudson> niedbalski: (the upstream bug was still open when i last looked)
<arunpyasi> Is 'python' package depreciated from the focal repo ?
<gQuigs> arunpyasi: short answer, yes it's gone..  if you need python2, install/depend on python2
<arunpyasi> gQuigs, oh ok. Thank you very much for quick response.
<niedbalski> mwhudson: o/
<niedbalski> $ git show --oneline 37b9a34 | head -n1
<niedbalski> 37b9a34 Improve host fallback behaviour in docker remote
<niedbalski> $ git tag --contains 37b9a34
<niedbalski> mwhudson: afak 1.3.4 hasn't been tagged yet, so yes .. that fix is contained in the current 1.3 release branch but not yet tagged afaiu.
<mwhudson> niedbalski: ok cool
<mwhudson> uh i guess we should fix in focal anyway, release is close
<niedbalski> mwhudson: focal and eoan, last time i checked they were on 1.2.X, which doesn't have this particular issue. did you upload 1.3.3 series there recently?, probably uploading 1.3.4 soon-ish would be the way to go.
<mwhudson> niedbalski: focal and eoan have 1.3.3
<mwhudson> we don't upload newer versions to stable releases than devel usually...
<niedbalski> mwhudson: then yes, same patch will have to be promulgated to eoan and focal as well if they have 1.3.3, if you have no other plan (as doing a 1.3.4 upgrade), i can go ahead and propose the backports for both tomorrow morning.
<mwhudson> niedbalski: do you happen to know when 1.3.4 will be out?
<mwhudson> but yeah, we shold get the patch into f&e, it's my friday but i can upload on monday if not before
<niedbalski> mwhudson: amazing, thanks. i'll ping you once the debdiffs are up in the bug report.
<niedbalski> mwhudson: asked here for the 1.3.4 release cut dates https://github.com/containerd/containerd/pull/4104#issuecomment-604731418
<niedbalski> lets see
#ubuntu-devel 2020-03-27
<niedbalski> mwhudson: attached F/E patches to the bug
<mwhudson> niedbalski: thanks
<niedbalski> mwhudson: yw, have a good day o/
<mwhudson> niedbalski: uploading
<mwhudson> (with a tweak to the version number on eoan)
<RikMills> juliank: hi, is merging apt-xapian-index in the works?
<sil2100> jibel: hey! Did you finish your tests on https://code.launchpad.net/~hugh712/ubiquity/+git/ubiquity/+merge/380808 ?
<jibel> sil2100, I'm on it and something else for kde
<jibel> sil2100, why?
<jibel> sil2100, I'll do more tests today, it seems that g-s-d is not running but I hardly see why this mp would break it. So i'll check on a default install
<jibel> not running during end user setup
<sil2100> jibel: hm, ok, thanks! Was poking about it because the OEM team seemed to have that as a priority
<jibel> sil2100, the MP is fine, I'll merge it. OEM config is broken though
<sil2100> jibel: how is it broken?
<jibel> sil2100, not themed, not the right font, ... g-s-d is probably not running
<juliank> RikMills: why?
<juliank> we have the changes already, why should we do a pointless merge _now_?
<RikMills> juliank: python-apt in proposed has breaks on apt-xapian-index version in release pocket
<juliank> oh did I do that?
<juliank> hmm
<juliank> ok then
<RikMills> thanks
<doko> RikMills: telepathy is a kde thing. could you have a look at telepathy-salut, -python, -haze, whether to remove them or port to python3?
<RikMills> doko: telepathy is not a KDE thing per se. 2 of those are recommends of kde-telepathy-minimal, but to be honest I had never heard of them. the kde telepathy stack is anyway borderline removable itself, as upstream maintenance is minimal
<RikMills> in other words, I don't think I can say
<doko> RikMills: ok, I'm filing removal bugs then, also for pidgin-skype, seen no update since 2014
<RikMills> this older style desktop messaging is generally a quite neglected thing now
<doko> RikMills: could you comment on https://bugs.launchpad.net/ubuntu/+source/telepathy-salut/+bug/1869361
<ubottu> Launchpad bug 1869361 in telepathy-salut (Ubuntu) "remove Python2 based telepathy-* plugins and rdeps" [Undecided,New]
<RikMills> doko: done
<doko> cpaelzer, coreycb: https://launchpad.net/ubuntu/+source/python-tx-tftp has a server subscription. can the package be removed?
<ahasenack> kanashiro: puppet migrated \o/
<kanashiro> ahasenack, and also ruby-zip :)
<coreycb> doko: it doesn't appear to be part of the openstack dependency chain so it's not needed on my end
<ahasenack> kanashiro: ah, that was applied?
<ahasenack> ubuntu-release:force-badtest ruby-zip/all/i386
<ahasenack> yep
<ahasenack> sil2100: hi, libcbor upstream released 0.6.1 with the soname fixed (like in our patch in 0.6.0): https://github.com/PJK/libcbor/releases
<ahasenack> he also clarified in the docs how it will be from now on
<ahasenack> sil2100: shall I update? I'll comment in the bug
<ahasenack> cpaelzer: FYI ^
<doko> RikMills: ping on https://bugs.debian.org/952060
<ubottu> Debian bug 952060 in src:libsignon-glib "libsignon-glib: FTBFS: signon-auth-service.c:72:13: error: G_ADD_PRIVATE [-Werror]" [Serious,Open]
<doko> coreycb: please comment on https://bugs.launchpad.net/ubuntu/+source/python-tx-tftp/+bug/1869366
<ubottu> Launchpad bug 1869366 in python-tx-tftp (Ubuntu) "RM: python-tx-tftp package, not needed anymore?" [Undecided,New]
<RikMills> doko: I don't know what to do about that
<doko> RikMills: same question for libaccounts-glib
<RikMills> same answer I am sure
<arunpyasi> Hi guys, does anyone where work on building go debian packages ? I wanted to ask how can we resolve the go dependencies without making a debian package for the dependency ?
<arunpyasi> *here
<ahasenack> you could vendor the dependency
<ahasenack> some packages do that
<arunpyasi> ahasenack, Do I go get inside Makefile or rules ?
<doko> seb128: do we still have an artwork theme? https://launchpad.net/ubuntu/+source/human-theme
<ahasenack> arunpyasi: that I don't know, you should check existing packages
<seb128> doko, no idea sorry
<ahasenack> arunpyasi: runc and containerd are some examples
<arunpyasi> ahasenack, I had go get inside Makefile but while building, I got permission denied.
<arunpyasi> ahasenack, OH ok, let me check :D
<ahasenack> it shouldn't fetch from the network during build
<arunpyasi> ahasenack, So, we need to build respective .deb file ?
<arunpyasi> or download and keep in the source ?
<cpaelzer> doko: python3-txtftp was in for maas
<cpaelzer> doko: they are a snap now and don't need it from the archive
<cpaelzer> doko: you should ask them if it is needed
<cpaelzer> e.g. in bionic python3-maas-provisioningserver depended on it
<ahasenack> arunpyasi: when it's vendored, it's part of the source tarball
<doko> cpaelzer: any idea who to ask?
<arunpyasi> ahasenack, ok, thanks !
<cpaelzer> doko: I'd say sparkiegeek - but he is not on this chan
<arunpyasi> ahasenack, BTW, I liked the way pkgbuild works in Archlinux :D https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/golang-deepin-lib
<doko> sparkiegeek: so is python-tx-tftp still needed in the archive, or can it be removed?
<sparkiegeek> doko: still needed - MAAS has indeed moved to a snap for primary deployment method, but the snap itself is built from packages in the archive
<doko> sparkiegeek: can you port it to python3 then?
<sparkiegeek> doko: hmm, we depend on the python3 binary package, which comes from python-tx-tftp source? https://packages.ubuntu.com/focal/python3-txtftp
<sparkiegeek> doko: so I'm not clear what porting is needed, if any
<doko> sparkiegeek: so we can remove python-tx-tftp?
<doko> sparkiegeek: stop building the python2 module?
<sparkiegeek> doko: stopping building python2 module is fine, yes
<sparkiegeek> doko: but removing python-tx-tftp (which is the source package) is not fine, just ok to remove python-txtftp (binary)
<doko> sparkiegeek: and there's no update since 2017?
<sparkiegeek> doko: https://github.com/shylent/python-tx-tftp so it seems, yes
<doko> sparkiegeek: please can you upload the package?
<sparkiegeek> doko: am not an Ubuntu developer :|
<doko> pff
<sil2100> ahasenack: hey! I guess that would be nice, then we'd be hack-free o/
<ahasenack> sil2100: yeah, but check out my comment in the bug
<ahasenack> I think he made a release of master by mistake
<doko> sparkiegeek: ftbfs with Python3:
<doko> [ERROR]
<doko> Traceback (most recent call last):
<doko>   File "/usr/lib/python3/dist-packages/twisted/trial/runner.py", line 804, in loadByName
<doko>     return self.suiteFactory([self.findByName(name, recurse=recurse)])
<doko>   File "/usr/lib/python3/dist-packages/twisted/trial/runner.py", line 733, in findByName
<doko>     obj = reflect.namedAny(name)
<doko>   File "/usr/lib/python3/dist-packages/twisted/python/reflect.py", line 313, in namedAny
<doko>     raise ModuleNotFound("No module named %r" % (name,))
<doko> twisted.python.reflect.ModuleNotFound: No module named 'tftp'
<doko> tftp
<doko> -------------------------------------------------------------------------------
<doko> Ran 1 tests in 0.073s
<doko> FAILED (errors=1)
<sparkiegeek> doko: https://paste.ubuntu.com/p/XqJJjCt8r8/ i assume you have something like that? I just knocked it up, completely untested
<doko> sparkiegeek: yes, the trial3 call fails
<doko> community-themes
<doko> feisty-session-splashes
<doko> feisty-wallpapers
<doko> gutsy-wallpapers
<doko> human-theme
<doko> xnox, Laney, seb128: any idea who owns these packages? or if we can remove them?
<seb128> doko, no-one I guess? and probably
<xnox> but i like them!
<xnox> doko:  i'll set maintainer to myself?!
<ogra> +1
<ddstreet> rbasak whenever you have a chance, is it possible to import 'meson' into git-ubuntu?
<gpiccoli> bdmurray, ping
<bdmurray> gpiccoli: hello
<ahasenack> ddstreet: I can take care of that for you
<ahasenack> ddstreet: I also added it to the list of packages to import, but to have that live will require a re-deployment of the importer, something we do every now and then. Just ping me if you notice the git repo is out of date
<ddstreet> thanks!
<ahasenack> ddstreet: it's currently importing, I'll let you know once it's done
<ahasenack> it's at 0.27.0-1 now
<zyga> hmm
<zyga> does anyone know why on focal /etc/X11/Xsession.d/95dbus_update-activation-env unsets XDG_SESSION_ID?
<zyga> or maybe, why XDG_SESSION_ID is not set in the session now
<zyga> (maybe that file is a false positive)
<Laney> The session is now spawned by the systemd --user instance, which runs outside of any logind session
<zyga> hmmm, right,
<zyga> hmm
<zyga> should I be expecting XDG_SESSION_ID to be set?
<zyga> or is that deprecated
<Laney> Nope
<zyga> please forgive me if I'm asking unclearly
<zyga> I would like to learn of the logind session ID somehow
<zyga> given a process or otherwise
<Laney> sd_uid_get_display() is what most things that really do still want to know what the 'graphical' session have been moved to use
<zyga> Laney: I'm not after the graphical session if that is a factor, just about the logind session of the current process
<zyga> effectively when I run loginctl show-session
<zyga> I'd like to know the ID of the session I'm in
<zyga> I need this for some testing so that I can then wrap up that session wiht loginctl kill-session
<Laney> Then there's sd_pid_get_session(), but not all processes run inside a logind session - that's the behaviour you are seeing
<Laney> including those spawned from systemd units
<zyga> Laney: hmm, I'm confused,
<zyga> so what is a logind session?
<zyga> or more specifically, what is the relationship to a logind session
<zyga> and a systemd --user instance
<zyga> if I login to a focal desktop I see it's a logind session
<zyga> it has an ID
<Laney> You get at most one systemd --user instance per user per machine, and one D-Bus session bus to go along with that
<zyga> right
<zyga> that makes sense
<Laney> and then each login - be that VT, graphical, SSH gets its own logind session
<zyga> and are you saying that XDG_SESSION_ID is no longer coupled to a logind session
<zyga> therefore the variable is not set?
<Laney> which *can* be a container for processes, but also the systemd instance can spawn stuff that is *not* associated with any of those sessions in particular
<Laney> so like if you do SSH, start a user unit, VT, log out of SSH, that unit will still be running
<zyga> is that linger or is that unrelated?
<Laney> lingering would make it so that if you additionally log out of the VT then it stays around, otherwise it would be killed
<zyga> ah
<zyga> right
<zyga> okay then I sort of understand this part
<zyga> so I guess I must use sd_pid_get_session -or equvalent- it is just for testing  after all
 * zyga digs in to see what that does
<zyga> probably cgroups
<zyga> Laney: thank you, I can share what I'm building that needs this
<zyga> if you want to spend some time on it and poke holes at the idea
<Laney> you can do: loginctl session-status <session id> to see all the processes that are in there
<zyga> (it's a shell script that helps to test interactions that normally happen in a user session)
<Laney> also systemd-cgls is an interesting thing to look at to see how things are laid out nowadays
<Laney> sure, I can try to take a look!
<zyga> I'm familiar with cgls
<zyga> this is for a part of testing snap run's use of StartTransientUnit with a scope unit
<ahasenack> ddstreet: it's on artful now
<ahasenack> busy little package
<seb128> on https://help.ubuntu.com/community/InstallCDCustomization
<seb128> MBR_FILE=/tmp/ubuntu_isohybrid_mbr.img
<seb128> does anyone know how that file is created or where it's copied from?
<seb128> ah there is a dd command
<ahasenack> yes, copied from the iso
<ahasenack> with a magic count
 * ahasenack thought it was 512 bytes
<seb128> dd if="$OLD_IMAGE" bs=1 count=446 of="$MBR_FILE"
<seb128> works!
<gpiccoli> Sorry bdmurray, I've missed your ping that time
<gpiccoli> I'd like to ask you about an email I received, about libvirt crash increase rate after one version with a patch from me got in -proposed
<gpiccoli> I want to confirm that phasing continues, or if it stopped, what can I do ? Don't have accesss to the logs there, about that crash faults..but they seem to be present in older versions
<bdmurray> The rate of crash increase calculation can return false positives in the first day or two, so the first step should be to see if the phasing is still stopped.
<gpiccoli> ok bdmurray, how can I check that?
<bdmurray> The email says you can view the current status ... link
<bdmurray> http://people.canonical.com/~ubuntu-archive/phased-updates.html
<gpiccoli> Thnak you bdmurray - no libvirt there
<bdmurray> No problem, sorry for the false alarm.
<gpiccoli> no problem, thanks for the information bdmurray =)
<gpiccoli> havea good weekend
<marcoagpinto> guys?! What is the maximum size of icons in toolbars in Ubuntu?
<marcoagpinto> someone in the PureBasic forum was saying that OS APIs limit the size to 24x24 but I think it is not true
<ahasenack> ddstreet: meson import is done
<ddstreet> thanks!
<ahasenack> marcoagpinto: no idea, maybe try #ubuntu-desktop?
<marcoagpinto> ahhhh
<marcoagpinto> thanks
<sasiru> hello :)
<xnox> kenvandine:  https://bugs.launchpad.net/ubuntu/+source/vte2.91/+bug/1869440
<ubottu> Launchpad bug 1869440 in vte2.91 (Ubuntu) "missing breaks/replaces for files moved between packages?" [Undecided,New]
<kenvandine> xnox: i've already uploaded a fix
<xnox> kenvandine:  nice, which version?
<xnox> kenvandine:  ah, i see it ubuntu2
<Unit193> kanashiro: I see zip transitioned, thanks.
<kenvandine> xnox: yup
<kanashiro> Unit193, my pleasure
<seb128> xnox, kenvandine, quite some users seem to enable focal-proposed :-/
#ubuntu-devel 2020-03-28
<santa_> ricotz: hi, I got an user which is having a problem with one of your libreoffice packages, which seems to have a missing a Breaks/Replaces
<santa_> let me paste the dpkg error...
<santa_> ricotz: https://paste.ubuntu.com/p/xSZxTmf6Rh/
<santa_> this is for kde neon (which is based on ubuntu 18.04) apparently
<arunpyasi> Hi guys is  libgnome-keyring-dev removed from focal ?
<ricotz> santa_, make sure to upgrade to 1:6.4.2-0ubuntu0.18.04.3
<ricotz> see https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1869357
<ubottu> Launchpad bug 1869357 in libreoffice (Ubuntu) "package libreoffice-math 1:6.4.2-0ubuntu1 failed to install/upgrade: trying to overwrite '/usr/lib/libreoffice/share/config/soffice.cfg/modules/smath/menubar/menubar.xml', which is also in package libreoffice-common 1:6.4.1-0ubuntu1" [High,In progress]
<santa_> ricotz: ok, so it's libreoffice-math. this user was using the "fresh" PPA, so I think the 1:6.4.2-0ubuntu0.18.04.2 -> 1:6.4.2-0ubuntu0.18.04.3 upgrade produced the problem
<ricotz> santa_, see https://askubuntu.com/questions/1220541/error-during-the-upgrade-of-libreoffice-from-6-3-5-to-6-4-2
<ricotz> 1:6.4.2-0ubuntu0.18.04.3 should fix the problem
<ricotz> which is just available for 4 hours
<santa_> ricotz: hmm, so the failed upgrade was x -> 1:6.4.2-0ubuntu0.18.04.2 then. thank you for fixing it
#ubuntu-devel 2020-03-29
<arunpyasi> Hi people, how can we use quilt with a git repository ?
<arunpyasi> Do you suggest quilt or dpatch or patch ?
<arunpyasi> anyone around pleas e?
<CarwynNelson> I
<CarwynNelson> I'm trying to figure out how the ubuntu software center (gnome-software) is packaged and what specific patches have been applied to it, but I'm struggling to track things down. I've found that there appears to be some form of gnome-software fork in debian salsa, but I don't see any patches specific to ubuntu.
<CarwynNelson> Is there an easy way for me to find out where the debian packaging for gnome-software on ubuntu lives?
<jbicha> CarwynNelson: see the commits after March 13 at https://gitlab.gnome.org/Community/Ubuntu/gnome-software/-/commits/ubuntu-master
<jbicha> there are other branches there too
<CarwynNelson> thanks very much :)
<quidnunc> The wiki says beta freeze is April 2 (which is Thurs), but in parenthesis it says (Monday). https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule
<quidnunc> Is beta freeze on Monday or Thursday?
<jbicha> beta freeze is on Monday
<quidnunc> jbicha: Thank you
<jbicha> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2020-March/001274.html
<quidnunc> thanks
